Programming languages, operating systems, despair and anger (2009)(xent.com)
xent.com
Programming languages, operating systems, despair and anger (2009)
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html
14 comments
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.
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.
> Yes, the article is very much of a rant, which is necessary every now and again to prove a point.
How is a rant sometimes necessary to prove a point? Valid points of criticism would serve this article better than its "rantness".
How is a rant sometimes necessary to prove a point? Valid points of criticism would serve this article better than its "rantness".
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.
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.
HTML5 aims to specify how to parse broken HTML as well (http://www.whatwg.org/specs/web-apps/current-work/multipage/...), 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")".
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")".
I don't think they have html parsing in the standard library for this reason:
http://golang.org/pkg/
They have HTML templating (which is pretty useful), but AFAIK html parsing is in an experimental module which may never be included in the stdlib because of the reasons you mention, it is over here:
code.google.com/p/go.net/html
But I don't see this mentioned in the rant.
Re the rant linked, it doesn't strike me as very useful or informative. Compile time is a huge issue on many projects, even ones which are relatively simple - I've worked on a few involving C++ and many of them had compile times in the minutes, which was pretty dispiriting and definitely got in the way - on much larger projects of course this is a bigger problem. That golang compiles far faster even on large projects is a definite plus. Bash isn't the only choice at all for systems programming or munging data as he implies, there are lots of other better tools.
Re his call for SIMPLE GUI PROGRAMMING I really can't agree at all - the best ecosystems let the tooling get out of the way, and some of the worst tools make a point of making you click around a confused trainwreck of a UI to perform simple tasks (Apple's Xcode or Eclipse come to mind). That's not progress.
The section on operating systems is similarly wrong-headed; talking about adding a huge number of abstractions (and APIs to go with them), which would lock programmers in to the ecosystem they choose even more completely and be a huge block to cross-platform work. That's a rather dystopian future - I'd rather leave the OS as a collection of badly debugged device drivers (to quote Andreessen), and let other systems build on top of it. There are some really good ideas in unix, and some nice ideas in golang, and the focus on simplicity is not only for the compiler writers, I think that's an incorrect assumption.
It's much easier to denigrate than to actually create, and if the author really cared about any of this, he'd take the time to do something about it, but has he attempted any of the points on his list himself since?
http://golang.org/pkg/
They have HTML templating (which is pretty useful), but AFAIK html parsing is in an experimental module which may never be included in the stdlib because of the reasons you mention, it is over here:
code.google.com/p/go.net/html
But I don't see this mentioned in the rant.
Re the rant linked, it doesn't strike me as very useful or informative. Compile time is a huge issue on many projects, even ones which are relatively simple - I've worked on a few involving C++ and many of them had compile times in the minutes, which was pretty dispiriting and definitely got in the way - on much larger projects of course this is a bigger problem. That golang compiles far faster even on large projects is a definite plus. Bash isn't the only choice at all for systems programming or munging data as he implies, there are lots of other better tools.
Re his call for SIMPLE GUI PROGRAMMING I really can't agree at all - the best ecosystems let the tooling get out of the way, and some of the worst tools make a point of making you click around a confused trainwreck of a UI to perform simple tasks (Apple's Xcode or Eclipse come to mind). That's not progress.
The section on operating systems is similarly wrong-headed; talking about adding a huge number of abstractions (and APIs to go with them), which would lock programmers in to the ecosystem they choose even more completely and be a huge block to cross-platform work. That's a rather dystopian future - I'd rather leave the OS as a collection of badly debugged device drivers (to quote Andreessen), and let other systems build on top of it. There are some really good ideas in unix, and some nice ideas in golang, and the focus on simplicity is not only for the compiler writers, I think that's an incorrect assumption.
It's much easier to denigrate than to actually create, and if the author really cared about any of this, he'd take the time to do something about it, but has he attempted any of the points on his list himself since?
> There isn't an obvious way to parse broken HTML, and every HTML parser does it differently
At least with HTML 5 we have both a spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/) and a library to parse it (https://github.com/google/gumbo-parser)
At least with HTML 5 we have both a spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/) and a library to parse it (https://github.com/google/gumbo-parser)
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)
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).
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).
> 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).
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).
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.
I finally appreciated Perl after spending a couple hours trying to write a non-trivial Bash script.
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.
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.
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.
- 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.
Yeah, I love Bash as a UI, and I love the ability to capture what I'm saying and trivially preserve it in a script (check out the edit-and-execute-command readline function, if you're not familiar with it - ctrl-x ctrl-e in emacs mode, v in vi mode). But once a script gets to be more than 10 lines it's time to think about rewriting it. By 100, you almost definitely want something else. Mind you, I say this as someone who's spent a year working on a >100kLOC bash project. There's stuff to love, but it's not a language to build systems in.
Recently, I've become somewhat enamoured of the Shelly library for Haskell, for my "bash that's grown too big".
"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."
Tooling up Bash to deal happily (generating, processing, consuming) with JSON would be fantastic - it would help make all the world's JSON API's available first-class! It seems that jq is a great start here.
Recently, I've become somewhat enamoured of the Shelly library for Haskell, for my "bash that's grown too big".
"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."
Tooling up Bash to deal happily (generating, processing, consuming) with JSON would be fantastic - it would help make all the world's JSON API's available first-class! It seems that jq is a great start here.
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.
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.
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.
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.
"mostly due to all the Objective-C/Foundation heritage".
Huh?
Objective-Smalltalk (http://objective.st) is also based on Objective-C/Foundation:
1. Hello World
2. Sending e-mail
Have to admit I haven't implemented the mailto scheme yet, but will be 1 line or close to it once it's in. Can probably get there
3. GET/POST
4. Days between dates
Whatever you did with NSDate ...
5. JSON
The http and file URL scheme handlers have cooked versions that will figure out the MIME type and translate for you, but I haven't full figured out complex literal syntax yet.
6. Modern Datatypes
Actually, Swift has a big fail here for the single numeric type. Objective-Smalltalk currently just inherits to Objective-C stuff (so fail), but a real numeric tower is in other Smalltalks and both a goal and achievable in ObjST.
Why they didn't do this in Swift is puzzling.
7. Package distribution
ObjST has always been heavily framework based, for example 'framework:' is one of the supported URL schemes. Now that we have frameworks for iOS, it's time to start thinking about a "cooked" framework scheme that can do name mapping to URIs for the source of that framework etc.
8. HTTP server
This serves the directory passed as an argument:
Huh?
Objective-Smalltalk (http://objective.st) is also based on Objective-C/Foundation:
1. Hello World
stdout println:'Hello World'.
'Hello World'.
2. Sending e-mail
Have to admit I haven't implemented the mailto scheme yet, but will be 1 line or close to it once it's in. Can probably get there
3. GET/POST
page := http://objective.st
file:objet-home.html := http://object.st
http://objective.st/index.html := file:newHomePage.html
4. Days between dates
Whatever you did with NSDate ...
5. JSON
The http and file URL scheme handlers have cooked versions that will figure out the MIME type and translate for you, but I haven't full figured out complex literal syntax yet.
6. Modern Datatypes
Actually, Swift has a big fail here for the single numeric type. Objective-Smalltalk currently just inherits to Objective-C stuff (so fail), but a real numeric tower is in other Smalltalks and both a goal and achievable in ObjST.
Why they didn't do this in Swift is puzzling.
7. Package distribution
ObjST has always been heavily framework based, for example 'framework:' is one of the supported URL schemes. Now that we have frameworks for iOS, it's time to start thinking about a "cooked" framework scheme that can do name mapping to URIs for the source of that framework etc.
8. HTTP server
This serves the directory passed as an argument:
#!/usr/local/bin/stsh
#-<void>fileserver:<ref>dir
framework:ObjectiveHTTPD load.
httpserver := (MPWSchemeHttpServer serverOnPort:8081).
server := dir ⇨ (MPWCopyOnWriteScheme memoryCache) ⇨ httpserver.
server start.
#!/usr/local/bin/stsh
framework:ObjectiveHTTPD load.
scheme:site := MPWSiteMap scheme.
server ← MPWSchemeHttpServer serverOnPort:8081
site:/hi := 'Hello World!'.
server start.Ooh, I'm seeing some non-ASCII characters here. How are you handling that? Can I use => instead of ⇨ and <- instead of ←? How do you usually type those? Is there a way of ASCII-ifying or de-ASCII-ifying source files?
Yep, the non-ASCII chars have ASCII equivalents.
They aren't finalized yet, as the whole "architecture connection/configuration" part of the language has barely been begun.
In fact, the non-ASCII chars are a recent experiment, but so far I like it a lot. Now that even shells and vi know about Unicode/UTF8, maybe it's time to take advantage of the rich typography we have.
I am typing those characters using a keyboard map I created in Ukelele.app (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=...).
The left arrows are mapped to Alt-[ and Alt-{ , the right arrows to Alt-] and Alt-}.
They aren't finalized yet, as the whole "architecture connection/configuration" part of the language has barely been begun.
In fact, the non-ASCII chars are a recent experiment, but so far I like it a lot. Now that even shells and vi know about Unicode/UTF8, maybe it's time to take advantage of the rich typography we have.
I am typing those characters using a keyboard map I created in Ukelele.app (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=...).
The left arrows are mapped to Alt-[ and Alt-{ , the right arrows to Alt-] and Alt-}.
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.
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.
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.
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.
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.
> 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.
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.
Notice that there is no difference to the programmer. Whether the problem lies in the library or language itself is irrelevant.
It sounds like what he wants is more "wolfram language" than an actual programming language. So there are efforts in that direction.
(Personally, I'm working on large systems, programming rather than plumbing. What matters is not what datatypes are built in but how easy it is to add new ones in library fashion. So I'm very happy with Scala; look at what Spray does with HTTP to show how a really powerful, flexible language can express domain constructs).
(Personally, I'm working on large systems, programming rather than plumbing. What matters is not what datatypes are built in but how easy it is to add new ones in library fashion. So I'm very happy with Scala; look at what Spray does with HTTP to show how a really powerful, flexible language can express domain constructs).
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.
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.
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.
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.
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!
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!
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.
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.
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.
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.
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.
What were the technologies the author references when he mentions Eric Meijer and Alan Kay?
Eric Meijer - Unifying Documents: http://research.microsoft.com/apps/pubs/?id=79586
Alan Kay - Worlds: http://www.vpri.org/pdf/tr2011001_final_worlds.pdf
Alan Kay - Worlds: http://www.vpri.org/pdf/tr2011001_final_worlds.pdf
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.