TheJach.com

Jach's personal blog

(Largely containing a mind-dump to myselves: past, present, and future)
Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

Tooling is the problem, not the type system

I'm firmly in the dynamic typing camp, but I also recognize that some dynamic languages like JavaScript leave a lot to be desired. I think that almost all of the things that might be desired can be addressed with tooling, however, and that tooling can be addressed in three ways.

The first way is on the language level. This is best because there's nothing more to do. Common Lisp is more than just a language, it's also a runtime, and a compiler, and the runtime itself ships with a COMPILE function. Normal operation is to COMPILE every piece of Lisp code into assembly and execute it with runtime wrappers (just like C compilers end up converting C to assembly with runtime wrappers around things like calling conventions). The artifacts that go along with being COMPILED let you later tell the runtime to TRACE something, or profile something, or BREAK and debug something step by step (with other much richer debugging options than you normally get with gdb or eclipse with java), they let you ask the runtime "who calls this function?", or "where is this thing referenced?", or "who sets this?" The answers to those questions will be complete as of right now because you're asking a living program.

In Java Land, I commonly ask about who calls what, or to find references for something. It's often slow, and that's even after it's done its indexing work. Yes, in Java Land these questions are derived statically, which means they can be wrong because you might not have statically seen everything, in addition to they might be wrong if they're stale because you're asking again in the future. With Lisp, you just have the second possibility of wrongness. Another advantage is that you tell the Lisp compiler how you want your source compiled right there, in the source, so you can of course tell it to optimize purely for speed and no safety and perhaps not full support for everything that might only be useful at development time.

See Full Post and Comments

Delicious baked goods

you need eyes

Why do so many things named after a grandma taste so good? My grandmas cooked delicious meals, did everyone's?

Anyway, this brand of bread and this brand of sugar cookie are the best (that is, my favorite) but previously I could only get a hold of them in Utah. Once I even made use of a Mormon missionary care package website to ship a bunch of the cookies to me out here in Washington. Utah residents know what I'm talking about, especially with the Granny B's pink cookie.

See Full Post and Comments

Why not wireheading?

A ton of money and engineering is being spent on trying to reach the dream of full-body haptic VR. Many of the components are ready, and they're being pieced together bit by bit into a full system. The company furthest along doesn't really think of these as individually owned devices though (probably because their full thing requires a giant hydrolics-powered arm that swings you around and lets you 'run' in place), more of something you'd find at an "arcade" or other experience-center. To me that's a mistake, in-line with companies that try to justify space research with 'space tourism' for the ultra-rich, but we'll see how it plays out. Go-Kart tracks are still a thing after all.

Prices may fall, but by how much? Physics demands certain requirements of a powered machine capable of suspending and manipulating an average human, and that level of equipment isn't going to fall that much anytime soon without breakthroughs in other technologies.

All this leads me to the titular question, albeit my terminology may not be precise. Why not devote the money and time into figuring out wireheading? By that I mean not just implanting a wire to stimulate one's pleasure center, but the act of implanting a wire or device or devices that can input arbitrary signals to the brain as if they were real. (If someone has a better word I'm willing to update this post with it...) I'm not fully convinced that the combination of vibration, heat, and pressure will really simulate the feeling of holding a cat, but if you hooked up some signal loggers to my brain, you could have me hold a cat, record it, and then replay it later.

See Full Post and Comments

Types of employees

For a long time my own definition (everyone's got their own...) of a senior software engineer as distinguished from a non-senior software engineer is that the senior can articulate how what they work on directly impacts business value. Many non-seniors will be perfectly happy to spend their jobs taking items off a queue someone else prioritizes, working on them, and completing them, without ever caring about anything other than the problem in front of them. And if they're really excellent problem solvers, they should definitely be promoted and paid well, but they might not fit my arbitrary definition of 'senior'. Implicit in my definition is a capacity to be independent that this hypothetical problem solver doesn't seem to have, or at least it hasn't manifested itself through desire to control what one works on more directly.

Agile methodologies try to make us all equivalent cogs. So while I don't really like practicing (and many so-called 'agile' groups at work don't either) making sure story titles follow the naming convention of "As a [persona], I want [desire] so that [business value] is achieved" I do see the inherent value of it and the direct focus on what a company exists for: creating value so that customers can be delighted.

This line of thinking made me consider another aspect of the work place which is that some employees can be Typed differently than others, even if they supposedly fill the same titles and on-paper roles. There are probably more types but the two big ones I noticed were Costs and Assets.

See Full Post and Comments

Character flaws aren't static




For me now, green, but orange I can make the justification for used to be like that. Maybe some remnants I can't easily see anymore. But the point is that progress has been made, and will continue to be made. Of course decline is possible. Pot is legal in my state, easy to get. Alcohol too.

One of the fundamental insights is that one isn't all that gifted or smart, even if one were unburdened by things like some of the above. ("If I wasn't so tired all of the time I could do anything!" Nope.) An aid to achieving that insight for me (besides actual burnout) was this quote, and I wasn't even the one being directly addressed:

See Full Post and Comments

What is philosophy?

Philosophy, in the broadest sense, is the branch of human thought concerned with asking questions and then pondering more than one possible answer. This distinguishes philosophy from naval-gazing, which is just about asking questions, and from religion, which tends to ponder one and only one possible answer to its central questions.

The types of questions, and through discussions on answers, lead to various sub branches of philosophy, and when certain answers are agreed upon for the moment, then those answers can lead to math, science, and other fields of thought.

For example, questioning what is truth, and what makes something true, can lead to first order logic. From there, math can be derived by making clear definitions, declaring axioms and rules of proof, and seeing what you find. You might wonder if mathematicians are like religious followers when they say that 2+2 can only be 4. But mathematicians can ponder another solution. This ends up with them simply showing a contradiction with some other thing they believe in. So either that thing is false too (or at least not the only answer), which they can consider (and develop non-Euclidean geometry for instance) or they've shown that so far there still seems to just be one correct answer for 2+2 and many incorrect ones. Serious religious people don't tend to ponder possible answers outside their own doctrine, even if they would judge those other possible answers are incorrect.

See Full Post and Comments

Caches are evil

There's an old joke in programming culture: "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."

Up until this year, I don't think I've fully appreciated the first issue of cache invalidation, or cache behavior in general. But over the last few months I keep running into issues caused by poorly thought out cache systems. Some of them my own fault, most of them other people's.

I'm at the point where I'm going to treat anyone who proposes a cache with suspicion, and make sure they can answer all of the following questions clearly. Depending on their answers, there might be no good reason to make a cache right now, or at least not to make the simplest cache with no control mechanisms. As one example, memoization is a neat trick to show off function decorators / macros, but it offers no control over the cache, so you need to know if you're just using it for a trick or for something useful! So, before making a cache of any sort, consider:

See Full Post and Comments