
Programming languages, operating systems, despair and anger (2009) - astigsen
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html
======
scott_s
I almost flagged this, as I feel that the author is disingenuous; I don't feel
he wants to engage in a productive discussion of these issues, makes no
concessions to the technologies he brings up, confuses his domain with all
domains, and falls back on superficial criticisms.

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](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.

~~~
jpsim
Yes, the article is very much of a rant, which is necessary every now and
again to prove a point.

I also feel that many of the points the author had aren't strictly related to
the language, but rather its standard library. Which could be argued that you
can't benefit from one without the other, but still. Most of his concerns seem
to be easily fixable through a more versatile stdlib, but there are certainly
cases to be made against that.

For example, I'm not sure I want a language's standard library to know about
JSON and HTML parsing, features that seem to be a better fit for non-standard
frameworks and libraries.

~~~
emanuelez
I surely prefer a language that comes with HTML/JSON parsing in the standard
library, as opposed as trying to find which library is better implemented,
hoping it will keep being maintained.

~~~
wtetzner
I can see wanting JSON parsing built-in, but HTML is another problem. There
isn't an obvious way to parse broken HTML, and every HTML parser does it
differently. When you need to parse some HTML, you need to think about the
differences, instead of just choosing the standard library one.

~~~
vilhelm_s
HTML5 aims to specify how to parse broken HTML as well
([http://www.whatwg.org/specs/web-apps/current-
work/multipage/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/parsing.html)), and there should ideally not be any differences
between different parsers.

The HTML5 specification explicitly asks you to not think about this yourself:
"for security reasons, it is imperative that those rules be followed
precisely. Differences in how invalid byte sequences are handled can result
in, amongst other problems, script injection vulnerabilities ("XSS")".

------
AceJohnny2
Bah humbug. It looks like the author is hoping for some fantasy world where
perfect programming languages would instantaneously be created and be used by
everyone.

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](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).

------
noir_lord
> it's pretty damn sad that something as limited and now - ancient as bash
> represents some kind of optimum of productivity for many real-world
> "everyday programming" tasks

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).

~~~
AceJohnny2
I disagree with his premise. I don't know which people he interacts with that
consider Bash to be some sort of "optimum of productivity".

I finally appreciated Perl after spending a couple hours trying to write a
non-trivial Bash script.

------
curtis
I don't think languages like Go and Scala deserve the author's scorn, simply
because they're not supposed to solve the author's problem. But in the context
of a no-holds barred rant, maybe that's forgivable (and who doesn't love a
good rant now and then?).

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.

~~~
eeperson
Agreed. I'm kind of amazed that nothing dramatically better than Bash has come
along on *nix (sure Zsh is better but only incrementally so). It seem like we
could create a command line oriented programming language that would be miles
ahead of Bash by incorporating the last 25 years of language design. I would
love a shell with the following:

\- Real functions instead of having to use 'echo' to return values

\- Parsing script params also defines autocompletion (think completion parser
combinators such as those found in SBT (Simple Build Tool))

\- Support for FRP (funtional reactive programming) would make interacting
with streams and sockets much easier

\- Support for JSON streams as well as plain text

Maybe one day I will finally get the time to write such a shell.

------
tailrecursion
As rants go this one is good because it identifies some language features and
misfeatures that are important, such as type system complexity. But Will
Yager's recent article was much better: partly because it was not a rant, and
partly because it succinctly covered all the bases.

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.

------
timanglade
His “If…” observations could easily be condensed into a Bechdel-style test.
Easy to game, not entirely accurate but starts painting a picture of the
maturity & productivity of the language.

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.

~~~
jpsim
Funny that all of these, minus the first one, have next to nothing to do with
the language itself, and everything to do with its standard library and
external tooling.

~~~
timanglade
Yes, first point, and datatypes as well. And to be fair, the author does state
clearly that some of the features & benefits he lists can come from a mix of
language/standard libraries, OS, runtime or third-party. At the end of the
day, you just have to be able to be productive with the language.

If you’re coming up with a brand new language, you have to do a damn good job
of compensating for it by piggybacking on existing VM/Libraries/third-party
tools (which Swift largely does), building it in your language and standard
lib (e.g. Ruby), or doing a good job at attracting a new community to build
that for you.

~~~
emanuelez
I guess that's what attracted people to Python some ten years ago, as opposed
to Perl. One can be sure that CPAN has a Perl library fit for your needs, but
having such features in the standard library makes a big difference for a
newcomer.

The same could be said in the devops context with Ansible vs Chef/Puppet.
Ansible joined the game pretty late, but it's attracting a lot of users
because of its "batteries included" philosophy. But this battle is still
ongoing and only history will tell us the winner.

~~~
ef4
> having such features in the standard library makes a big difference for a
> newcomer.

And not just for the newcomer. The biggest benefit is that your dependencies
and your dependencies dependencies can all compose better when they're all
using the same standard implementation of feature X.

The extreme case of this problem was c++ in the bad old days when lots of
organizations were writing their own String libraries. Inevitably, you'd add a
dependency that pulled in yet another incompatible string implementation.

------
tdees40
I started programming using a copy of vintage 1998ish Visual Basic that my dad
had on our computer. I drew a button, and then I clicked it, and I added code
that gets run when the button is clicked. That was awesome! I built useful,
visual programs in a matter of hours from when I started.

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.

~~~
thinkpad20
The issue is not that you can't do that anymore; it's that the things you (and
presumably, your friend) want to _do_ have gotten more complex. That's just a
fact of life. It's going to take a lot more effort to write Wolfenstein: The
New Order than Wolfenstein 3D.

------
Chinjut
The ignorant swipe at Haskell irked me, but "programmers have become plumbers
and documentation-archaeologists mostly, which is sad and uninteresting"
resonated strongly as a description of much of the workday grind.

------
zackmorris
I was thinking about how programming has become plumbing when I was under our
crawlspace last week replacing a rusted out galvanized pipe with ABS plastic.

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!

~~~
tinco
Your analogy sounds nice, but your examples of epic failures do not hold up at
all, they just show a lack of familiarity with their respective fields.

AAA game studios spending tens of millions of dollars on extremely complex
game engines. The rendering part of it is significant but not nearly the
largest part of it. You can take the Unreal Engine 4 for a spin now for just
$20, and you'll see the incredible engineering feat that it is, and that's
just the core engine. Almost every AAA title is an engineering marvel the
industry as a whole can be proud of.

Demoscene demos can be brilliant and intricate, but they are just tricks in
comparison.

I'm not expert on database technology, but it is a field worth millions in
investments no doubt. Yes, open source technology is giving the big corps a
run for their money, but you can't be seriously thinking CouchDB comes even
close to the breadth of features and business solutions Oracle offers its
customers.

I'm not an IC designer either, but have you ever seen a graphics card run
Linux? FPGA's and GPU's can't do what CPU's do, and there's good reasons for
it, again these products just don't compare in complexity. Besides, Intel's
CPU's nowadays integrate GPUs that can render a mean scene.

So I'm not sure what your point is anymore. In my opinion these are not the
plumbers, these are the ones designing the new materials and techniques that
enable the plumbers to do their thing.

------
jokoon
well, before computing involved massive business interests, I guess things
were a little healthier.

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.

------
rwmj
Cached version:
[http://web.archive.org/web/20130213090917/http://www.xent.co...](http://web.archive.org/web/20130213090917/http://www.xent.com/pipermail/fork/Week-
of-Mon-20091109/054578.html)

------
peterashford
You know, the last thing I care about is whether hello world is a one liner. I
care whether I can maintain my large code base with dozens of other
developers.

------
thomasvarney723
What were the technologies the author references when he mentions Eric Meijer
and Alan Kay?

~~~
astigsen
Eric Meijer - Unifying Documents:
[http://research.microsoft.com/apps/pubs/?id=79586](http://research.microsoft.com/apps/pubs/?id=79586)

Alan Kay - Worlds:
[http://www.vpri.org/pdf/tr2011001_final_worlds.pdf](http://www.vpri.org/pdf/tr2011001_final_worlds.pdf)

------
joaomoreno
this guy seems pretty pissed

