gruseom

This is superb! Pity it fell through the cracks.

I think that for many people music is deeply connected with ideas about identity, such as "this is the kind of music I like" and "I am the kind of person who likes this kind of music". This is very visible in popular music, where how the performers look and who they are is as important as the music itself.

Because of this, the satisfaction of listening to music isn't only auditory or aesthetic, but also an identity satisfaction, of feeling one's ideas about oneself confirmed.

It's probably true that humans inject identity ideas into everything, so this is nothing special to music. But it's a strange situation, since music per se is the most abstract of the arts and this extra layer we put on top of it is so obviously extrinsic.

But the hard parts are all political.

Wow, that is a great idea.

I wonder how such a thing could ever get started. Perhaps as an experiment in one of the smaller states?

Anybody care to chip in on the best way to do FF add-ons?

I wrote a Chrome extension that I use daily. Unfortunately, Chrome has become so bloated that I now have to wait a second or two (on OS X Mavericks) for the simplest things to happen. I really hate this, so I'm going to try porting it to FF, which appears to have no such problem.

It's a little surprising that the performance sweepstakes now favor FF (and Safari, which is even better), but I'm not the only person I know who's experiencing this.

When you hear the same quote attributed to two different famous people, that's usually a strong sign that it actually came from somebody obscure. Obscure people's quotes hop to famous people, and not always the same ones.

I have no idea about this quote in particular, though; it seems like a job for http://quoteinvestigator.com.

CSS does feel a lot more complex than it ought to be, but it's dominated in every variable of badness by XSLT. That's the one language that defeated my efforts to learn it (mainly by killing all desire to do so).

Ok, clearly not everybody. But I'm surprised to hear that. You're the first person I've heard say anything like it.

Interesting piece. This line:

More powerful programming languages rely less heavily on naming

... reminds me of section 1.1. of Compiling With Continuations:

The beauty of FORTRAN—and the reason it was an improvement over assembly language—is that it relieves the programmer of the obligation to make up names for intermediate results.

I remember going "Wha?" when I read that.

I apologize to the cat for my slander.

I can understand why you'd say poorly designed, because the tradition it comes out of is so austere. But "terribly implemented"? That detracts from what you're saying. The thing achieves performance everybody else dreams of.

No doubt its error handling leaves a lot to be desired, but single-character names are a different matter. That's part of the APL style, and it's a mistake to reject it out of hand. The trouble is that nearly everybody does, because it's so beyond the pale.

Edit: Perhaps I should explain what I mean about the APL style.

Languages in this style are not "unreadable"; rather, they trade lexical readability for whole-program readability. Their emphasis is not on names, but on operators; specifically, operator composition. Their advantage is the astonishingly high-level power of their operator strings—sequences of composed operators, each of which passes its output to the next, like Unix pipes.

After a while, typical operator strings become recognizable as idioms, making them leap out at the reader. This allows one to comprehend quickly what would take many lines of code in most other languages. True, each of those many lines would be more lexically "readable" in the sense that you could grok its individual tokens more easily. But that's not how you comprehend what a program is doing. To do that requires grokking the intent of a bunch of lines together. In other words, program intelligibility is not primarily a matter of token readability but of whole-program comprehension. We're just so used to one way of doing it that we reject all others as "unreadable". We forget that variable and function names are not an end in themselves, but a means to an end. APL-based languages have a different means to that end.

If APL-style programs were to use long expressive names like other languages, the shape of their operator strings—the most important thing—would be obscured, and you would lose comprehensibility rather than gain it. The role that names play in such programs is different. They are placeholders. Like colored beads, they occupy certain positions in the operator strings and demarcate what the code is doing. If these names were even half as long as what you use in conventional languages, they would overwhelm the code so much that it would consist of nothing but names with a few operators scattered here and there. The program's structure would then be less accessible.

Another way of saying this is that names are so much shorter because everything is so much shorter, which is what makes the operator-oriented style so powerful.

It's true that such a language is symbolic, even cryptic, compared to most. But that is a bad reason to dismiss it, especially before one's eyes have adjusted. All programming languages are symbolic and cryptic before one has learned any. The reason why programmers take for granted that conventional languages are more "readable" is that these languages are related to each other and we all know one of them. We are like Spanish speakers saying that French is more readable than Russian. Since we all (to extend the analogy) know at least one Latin language, we take this view for granted when it's really just relative and—if one wants to push the point—false.

Now where are beagle3 and silentbicycle to back me up.

Lots of things on HN have to do with neither hacking nor news. That's part of its charm, always has been. If PG can post about the margins of medieval manuscripts, then anything goes, so long as it isn't dumb. The only sin is to be uninteresting.

Just like a cat to save itself after years with the crew. I like that touch. It adds credibility.

It is probably the most astonishing combination of simplicity, efficiency, and beauty that I've seen in computing.

Unfortunately, it's so out-there that nearly everyone dismisses it as unreadable and daft. In a better world, it would be taught and studied as an exemplar of design. (On the other hand, they've succeeded financially so how cool is that.)

I've noticed two interesting things about Emacs over the years. One is that it's an order of magnitude easier to write tools in Emacs than in other environments. It's also more satisfying, because Emacs lacks the arbitrary hoops you typically have to jump through when writing plug-ins—hoops that come from internal limitations of the host system and give you that annoying "why can't I do it this way" feeling. Emacs, despite its high learning curve, has little such systemic friction. Because making tools is an order of magnitude easier and more satisfying, people do it more, which is why Emacs has so many tools, as well as sophisticated things (e.g. Slime) that show up more rarely elsewhere.

The other thing is that the core of Emacs is a masterful piece of domain-driven design, where the domain is "text editing and windowing". Its conceptual model is clear, simple, and consistent. (Some of the later additions don't have this quality, but fortunately they mostly stay out of the picture.) It has a rich language for its concepts—'buffers', 'text properties', and so on—and uses that language everywhere through documentation and code. This tremendously eases the burden of writing programs that interoperate, because everything is based on the same conceptual model and thus makes sense in the same way. Not all Emacs programs follow identical conventions—far from it—yet it's amazing how close they get, given how many there are. It's Emacs' exemplary domain model, as much as its Lisp character, that creates this conceptual unity.

So while Emacs rightly gets a lot of credit for the technical aspects of its extensibility, we should hear more about the design aspects. Its core design is a masterpiece and ought to be studied as an example of the power of software design itself—something we're mostly still pretty bad at. It might be hard to get that taken seriously, though, since on the surface Emacs is obtuse, clunky, and old. Only when you dive underneath does it become orderly and beautiful.

That's fascinating. What did you leave science to do?

That's a really good name.

Depends on the neighbor.

In any case, filters that happen to be shared don't thereby become the "true nature of reality".

"True nature of reality"? Highly debatable! Maybe in legal offices. :)

Everybody sees that concept through their own filter. I suppose to a cobbler the true nature of reality is surfaces that wear out over time.

You speak only of the letter and not of the spirit of the thing. This has nothing in common with the mentality that created the internet in the first place, which was cosmic and adventurous and poetic.

It reminds me rather of cutting the perforations off of postage stamps. I doubt that J.C.R. Licklider would approve.

Hey, you just solved my dread problem. If Canada gets rid of the time switch they won't do it in a way that forces Saskatchewan to change. (I'm in Alberta.)

Thanks!

That explanation isn't very convincing. People in other relatively poor countries didn't develop that distinctive pattern.

I so agree. Whenever I hear people say "changing the time twice a year sucks, we should stop doing that," I wonder whether they mean "let's ruin everything" (stay on 'standard' time all year) or "let's have daylight in winter too". This is rather a huge difference, and I wish they would always make it clear so I could tell whether to completely oppose or joyfully support them. :)

I think they mostly mean making daylight saving permanent, but have a recurring dread that maybe they don't.

No, it was a traditional job title that existed before they put it on the TN list. I think, but am not sure, that it would be something like "business analyst" today.

I wonder if Spaniards used to stay up late before Franco changed their time zone in the 1940s. Does anybody know?

Your argument is really that syntax is nothing and semantics everything. I sympathize, but it's not how most people see it.

As long as we accept syntax as a significant part of what defines a programming language, "visual language" is a reasonable concept.

Edit: Reasonable implementations are another matter. :)

Those aren't superlatives. We'd need to find something like "wicked" or "sick", but from food. The ones I can think of all come from religion or sex.

You've made this point before and it seems like a good one, but it raises a question. If you don't have a trial period, does that not make it harder to correct mistakes? The barrier to quickly firing someone who (perhaps through no fault of their own) turns out to have been a bad choice is surely higher than allowing a trial to expire or whatnot.

Since bad hires are one of the worst things that can happen and no one is perfect at hiring, I'm curious what you do about this problem. Do you just work harder at getting closer to perfect?

It seems to me that there's always an implicit trial period anyway—the question is how you encode it. The best people, who have many options, won't want to stick around if they made a mistake either, right?

How interesting that the French use food for superlatives. Do we have anything like that in English? It feels weird to me, so I'm guessing no.

That "substitute 'damn'" quote is damn good, but the attribution to Twain is damn bogus:

http://quoteinvestigator.com/2012/08/29/substitute-damn/

He never said that the coldest winter he spent was a summer in San Francisco either. Damn.