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.

Funny, that's how pretty much everyone else feels about visual programming.

Except the UNIX way of things runs the Internet, and visual programming tools run practically nothing of relevance at all.

Time.

I find the cognitive dissonance of Americans commenting on such things while still claiming silly titles like "the greatest country in the world" fascinating.

This one has a "besides Canada" footnote disclaimer. Why, because Canada does have a decent health care system? Sort of like... almost every single other first world nation except the USA?

Well, this is true, but it's also hyperbole. It's not really everybody misunderstanding the problem so much as simply not caring. People are sloppy with the terms "NP-hard" and "NP-complete" and use them interchangeably because it's usually not important. Usually they mean "NP-hard", and that is the significant thing.

Yes, it's wrong to use "NP-complete", but plenty of people who thoroughly understand the problem do so. Welcome to Computer Science, sloppy is par for the course.

A more accurate title would be "The Sorry State of Microsoft's C++ Compiler".

As usual with native code, portability is actually quite easy to achieve - except to Windows using MS's native tools.

It isn't. That figure is more like the size of everything there is to do with LaTeX, uncompressed, than the size of LaTeX itself.

For half a century, especially in America, we've been hearing about the "future of transportation" in the form of some car, or car-like non-mass transit device.

The numbers don't work out, the logistics don't work out, and the infrastructure doesn't work out. The future of transit is obviously not cars: not normal 4 wheeled cars, not flying cars, not fancy gyro stabilized two wheeled cars.

Ideas otherwise are quaint turn of the century throwbacks that ceased making sense anywhere in non-rural a very long time ago.

Significant whitespace in a live coding language? I like and use Python, but that seems like a show-stopper of a bad idea for a language designed for throwing code around in real time.

What you just explained is simply your arbitrary and subjective personal belief system about technology that makes one system inherently "better" / "superior" to another.

Proprietary software - i.e., software you can not modify to suit your needs - can actively inhibit your ability to "GSD". That's kind of the point.

This is a very cool effort and method to teach a very silly font/language idea.

I have always maintained that if you have an unqualified "favourite" thing, you are probably not very in to that type of thing :)

I use C the most because it is the most appropriate tool for the job at hand for most of the jobs I do. I appreciate the simplicity and elegance of Scheme, and wish I could use it more. I envy Haskell's type system.

None are my favourite. After all, all programming languages suck.

Two-finger scrolling on both axes works well here on my Thinkpad T520, which is at least a massive improvement over edge scroll IMO, especially with limited space. Unfortunately the touchpad is quite small.

I have some projects with extremely thorough test suites, and some projects with no automated testing at all.

I find my desire to work on those projects directly proportional to test suite coverage. Once you start writing against automated tests, there's no going back...

Making a modern condensed character set is a nice idea, but this is a really, really bad execution.

Many letters are the exact same shape, shifted vertically 1/5th of a character height? A-E are completely identical but for position. This is terrible enough to be a show-stopper on its own.

Braille has all the advantages of this, but is FAR more readable, since each letter has its own distinct shape. You say in a different thread that "Braille has the same proportional shortcomings as normal text". This is false. Braille characters are a grid of a fixed number of dots (6 or 8), and every character is the same size. It also has numbers, punctuation...

Hilarious, though not strictly correct. There is no guarantee 'sleep n' sleeps for n seconds, or that 'sleep n' wakes up before 'sleep n+1'. Granted, in reality if scheduling is so far off that things like this on the order of seconds become a problem, you've probably got bigger problems...