Programming languages, operating systems, despair and anger (2009)

I did not flag it because his frustrations can still be the starting point to useful discussion. Something I would like to point out is that Go was designed with programmer productivity in mind. The author writes this off as "designing for the compiler," and the Go team did purposefully design Go to be quick to compiler. But that was not an end in itself. They designed Go to be quick to compile to make build times faster, so that programmers would spend less time waiting for builds. Rob Pike gave a keynote talk at SPLASH 2012 where he explained all of this in-depth: http://talks.golang.org/2012/splash.article I think it's worth noting that the talk is even entitled, "Language Design in the Service of Software Engineering."

So, back to one of my criticisms of the post: the Go team clearly tried to design Go with the programmer in mind. In particular, they were designing for a programmer who works on a code-base of millions of lines who works with dozens (or hundreds) of other developers. If the author wants to claim that the Go team failed at this goal, then that's fair. But I don't think it's fair to claim that this is not their goal.

The rest of the rant feels the same to me. The dig about category theory is clearly aimed at Haskell. I am not fluent in Haskell, but I have been convinced by those that are that being fluent in category theory is not necessary to be fluent in Haskell. Saying so is a boring way to dismiss a language.

Overall, the rant reminds me of an exchange I had with a fellow grad student many years ago. This was back when it was just starting to become clear that single-threaded processor performance was going to hit a wall, and we were going to have to go multicore. When trying to explain this, I was hit with, "I don't care, it's their job, they just need to make it faster!"

The authors goals may be good ones, but he refuses to acknowledge the hard problems people are encountering when trying to build the infrastructure necessary to even start to address those goals. Not granting people their incremental successes just because they did not solve the whole problem is, I feel, disingenuous.

It looks like he either hasn't read, doesn't understand, or won't accept the conclusions of Richard Gabriel's "Worse is Better" essay (http://www.jwz.org/doc/worse-is-better.html)

He complains multiple times that languages are written for compilers first and programmers second. Yes, if you want good language adoption, the first step is that tools must be readily available and not get in the way of work. If you make your language hard to write a good compiler for it, you're increasing the cost (and thus availability) of the tool, and decreasing number of implementations. "I'm sorry, $LANG can't be used on Mac because no-one wrote a compiler for it yet."

I also take issue with "programmers have become plumbers and documentation archeologists, which is sad and uninteresting". Granted, I'm probably unaware of language/systems where the programmer is magically cognizant of available libraries(/modules/packages/whatever), their API and their use. But in the world I live in, I see this as unavoidable.

...I could go on, but the rest doesn't seem to get any better and I don't want to spend more time arguing the issue(s).

I absolutely agree with him on that bit, in it's day the ability to pipe the output of one command to another and the composability that gives you was incredible.

bash is undeniably useful (I use it every day) but I've been transitioning to python/envoy/docopt for a lot of things because despite more than a decades usage with bash I immediately have to hit google as soon as I want to do anything more complex than an if statement, it is just a horrible language (imo).

I like python for this as small single purpose programs are replaced by small (in terms of usage interface not nescessarily complexity) modules but the overall coherence feels better.

There is so much inertia around the tools and approaches I'm not sure how we'll ever move past this stage (Microsofts PowerShell had some promise as an approach for a while).

What it sounds like is that the author wants a superior replacement to Bash. Having recently written hundreds of lines of Bash script, I feel the author's pain there. I've used Python for other things, and it made some things better and some worse. In particular, Python could make calling external programs and parsing their output easier, but I don't think that was ever a design goal for the language.

I think the language that comes closest to addressing the author's vision might be Powershell, but it's stuck in the Windows ghetto and doesn't seem to have had any influence on other languages and certainly not on any Unix/Linux-friendly languages. That's probably too bad.

And as a final note, I'd love it if there were a standard option to get JSON output out of your typical Unix command-line tool. This might be of limited utility in Bash, but when calling tools from Python, for example, it would make many things a lot easier.

We've reached a point in time where there is a wider consensus regarding the importance of stateless programming, option types, code re-use, and the productive people are not complaining anymore and instead are doing something about it. There are many new or recent PL projects ongoing, where people are designing new languages.

In the mean time, for those people who roll their eyes at missing GUIs or support for email addresses -- it seems to me they've identified an opportunity.

There is a rich set of choices out there and the hard thing (for people who aren't designing their own language) is shopping. Those people who can make effective decisions and exercise good judgement are going to have an advantage, whereas other people who expect others to deliver popular platforms into their hands for free, will remain below average.

It’s funny to consider how poorly Swift does against this “Bone Test” (mostly due to all the Objective-C/Foundation heritage):

- Hello World in < 5 lines: pass

- Sending email in 1 line: fail

- GET/POST to web page in 1 line: fail

- Number of days between 2 dates: pass

- JSON: fail

- Modern datatypes: mostly passes but no REGEX in Swift is a big fail. The matching Foundation class NSRegularExpression doesn’t count because Jeff is clearly asking for native, in-language support.

- Package distribution: fail (although now you can finally build Frameworks for iOS, not just Mac OS, and if we’re counting third-party, it’s likely that CocoaPods will support Swift soon)

So final score 2/7 on the Bone Test, although I’m sure by the time Swift goes GA a lot of them should be fixed.

Now, I want to teach a friend, and it's Python + HTML + CSS + JavaScript to get anything cool going. That's a high bar, and a huge part of me misses the sweet simplicity of VB. I can't imagine breaking in today.

When we bought the house, the inspection said that there was an "undetermined" leak somewhere. There had been kind of a rotten egg smell the last few weeks (hydrogen sulfide) so I decided to crawl underneath and take a look. The pipe from our kitchen sink had what looked like stalactites hanging from it, so I took a wire brush to one and when we tried running the water, a six inch wide waterfall cascaded down. So first I bought a bunch of PVC at the hardware store, then realized I needed a special Y connector with a nut on the end that plumbers use to snake bad clogs (that isn’t made for PVC). So went back, returned it all for ABS, and then spent about 4 hours cutting the galvanized pipe ends with a dremel and using a special shielded rubber junction to connect everything up. It was grueling, exhausting work. I would have threaded the ABS into the old fittings, but they were cast iron and remarkably use a kind of lead paste to merge with the galvanized pipe (besides, cast iron rusts around plastic so it can’t be threaded that way). When I pulled the old pipes out into the yard, one of them had a six foot split running down the length of it. Our kitchen sink and dishwasher had been dumping directly onto the ground for years. We never even knew.

Compare this with programming and the similarities are uncanny. We are dealing with remarkably over engineered systems to, well, move bits of stuff around. Where it once made sense to melt lead around a pipe that was designed to last 50 years, today anyone can glue two ends of plastic together that lasts basically forever. The aging infrastructure of TCP, DNS, Apache, UNIX, etc creates millions of jobs but costs us incalculably by making us think we need a blowtorch when a brush and a little glue does a better job.

I really feel that my passion for understanding the intricacies of programming died the day I learned php and realized that the vast majority of it isn’t necessary. No amount of well structured code or best practices can make up for the humbling truth that if computers were better at doing what we wanted, then programming wouldn’t be necessary. In the 90s, it took me 12 pages of C++ code to create a window in Mac OS and draw “hello, world”, but today I can do it in 12 characters of HTML. I’m not sure I even care anymore what language I’m using - if it takes more than a one liner to accomplish a common task, then I feel the precious moments of my life being drained away. The code is a distraction from the goal I’m trying to accomplish.

Every day, as I thread that next piece of galvanized code into place, knowing full well that it not only WILL fail, but in unpredictable ways at some unknown point in the future, I wonder when and how it will all end. I sometimes think to myself that maybe it needs to end, like maybe I should be focussing more on inventing plastic than plumbing.

Everywhere I look, I see examples of epic failure: AAA game studios spending $10 million dollars on games with graphics bested by ray marching in Demoscene, or Oracle investing millions on database technology that will be supplanted by things like CouchDB, or Intel spending billions on incrementally better chips than can’t hold a candle to even the cheapest video cards or FPGAs. Only it’s not failure, because they are making money. There is so much money in plumbing!

Now all companies start something, grab a piece of market share, and lock up everything to make sure programmers will only extend their market share, not the one of competitors. There might be research, but nothing really new lands into the hands of programmers so that they can improve their productivity.

It's like the screwdriver, the hammer were invented, made popular, but other new, time saving tool really appears for a century after.

In my view there is a gap between the goal of investors, and the role of engineers. It's a common situation in any industry. When something is invented, it rarely evolves out of a well oiled business model. Once the technology becomes popular, you can't improve it anymore, it's too late because it's just too hard to bring new things to large markets.