drobilla

Yet another fine example of why ESR seriously needs to stop pretending to be the arbiter of "hacker culture" as if he speaks for all of us.

I'm very happy to see Rust stabilize, about time we get a systems(ish) programming language with a half decent type system. With that said... I need to get some bikeshedding off my chest:

I hate to let such a triviality lower my enthusiasm for a language so much, but I just can not get over that awful inconsistent closure syntax :/

I don't get it. Most everything else has a nice unique keyword syntax, fn uses (args, in, parenthesis), proc syntax made consistent sense, then lambda is this crazy || linenoise thing that doesn't fit in at all. The "borrow the good ideas from other languages" approach has resulted in a great language, but "cram random syntax from other languages that doesn't fit" doesn't work out so well.

I'll take "fighting with syntax" over fighting with a GUI any day.

I will never understand the tendency, especially in the web community, to consider complicated, ambiguous, inconsistent, and difficult to parse syntaxes as "friendly".

It might seem like a good idea at first, but over time it just results in a culture that publishes horrifically broken markup, and increasingly baroque implementations that try to work around every possible screw-up instead of simply flagging errors. This is, in my opinion, the biggest screw-up of the web: if early browsers simply flagged errors and pointed out where and what they are clearly, the web would be a much nicer place. Instead, actually writing a parser for web markup is a nearly impossible task, and not the weekend hack it should be.

One of the, if not the, great thing(s) about JSON is its beautifully simple syntax. 5 images on json.org precisely explain what it is, and that's that. You can write a parser for it in basically any language without any fancy libraries or frameworks in a few hours. That is a good thing, regardless of whether you personally would ever have to do such a thing, because it keeps the barrier of entry low and trickles through the ecosystem in positive ways.

Missing the point of JSON? Yes, but missing much more, including lessons that should have been learned.

That said, a few of the ideas are good ones (comments and such), but the bad ones (making crucial delimiters optional) are so bad they more than outweigh the benefits.

This guy is so biased he can't even see straight.

Not quite as easily solvable with software as you might think. Most such scheduling problems are NP-hard.

Engineers generally already have such things.

I don't think "programmer" is a well-defined enough concept to be associated with an oath. You can't go around calling yourself a Medical Doctor or an Engineer if you aren't, but pretty much anybody who codes at all can reasonably call themselves a programmer.

Even with all that aside, such oaths only really work for things like causing blatant harm. Unqualified "freedom" and "liberty" (especially in the USA) are so nebulous they mean almost nothing at all. The overwhelming majority of programmers work for organisations whose goals (e.g. profit, power) are not - and are often directly opposed to - "freedom" by any reasonable definition.

In short, I don't think the answer to your question is "no, there shouldn't" so much as "no, there couldn't".

The Littler Guide to HTML Email:

Don't.

> I could either have another expensive piece of paper, or add more code to my github account for future employment...

You could always do both. Academics who can actually write good code are a pretty rare commodity.

Someone needs to write a "why getting a job in industry is a waste of time" rebuttal to this tired argument to illustrate how ridiculous it is to evaluate everything with a single (and shallow) goal structure. After all, it typically doesn't contribute anything new or meaningful to scientific knowledge, therefore it is a waste of time (...).

I guess I shouldn't expect any better from The Economist, but not everyone in the world just does whatever they can to make the most money possible, ignoring all other considerations.

Assuming I'm making enough money to survive comfortably (which is essentially guaranteed with computer anything, including grad school itself), I don't care. What I get to work on, and what environment I get to work on it in, is far, far, more important. Overridingly important.

This mentality (though usually not so extreme) is pretty common among math and computing people, which is probably why industry is finally starting to notice that workplace perks are very important. There are plenty of extremely talented people who'd gladly take a 50% pay cut to work in a less shitty environment...

Painters paint, hackers hack

"Ha ha ha, I intentionally cause huge legal problems for the Open Source world and the software world in general, hilarious, right?"

This stupid little license game of Crockford's is childish and inappropriate. The more he jokes about it the less respect I have for him. Grow up.

Short circuiting AND isn't a very good example of the advantages of pure functions. Most languages, including those heavily based on mutation (e.g. C and its descendants), do this.

Never say never. This only applies to WYSIWG. When writing in plain text source formats, the two spaces enable tools to distinguish the end of a sentence from abbreviations and other uses of the period. For example, emacs uses this distinction for column filling and other text manipulations.

Using a single space is ambiguous; ambiguous is bad. Therefore two spaces is best in place text.

No offence, but this is incredibly naïve, and it's kind of obviously an opinion that simply stems from working on things that just aren't that conceptually complicated. Some things are actually conceptually complicated, and the why is not at all obvious from the what, no matter how finely you slice the what. Code, inherently, describes what. A sparse set of higher level proper sentence comments describing the purpose of the overall goal for the next part is practically required to make code like this actually comprehensible. For some things, something approaching Literate Programming is best, which is nearly the polar opposite of "comments are bad".

Implementing an advanced data structure is a good example of this. Things that took theoreticians some time to discover, and write/publish in a paper, are not things a random programmer is just going to inherently know from a completely uncommented implementation.

Extrapolating "all comments are bad" from a few examples of pointless comments on mind-numbingly simple and obvious code (which are indeed bad) is silly.