9 ms·

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

73 points by astigsen 12y ago

joaomoreno 12y ago
this guy seems pretty pissed
- deleted 12y ago
  [deleted]
rwmj 12y ago
Cached version: http://web.archive.org/web/20130213090917/http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html http://web.archive.org/web/20130213090917/http://www.xent.co...
noir_lord 12y ago
> 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 12y ago
  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.
scott_s 12y ago
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 12y ago
  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.
timanglade 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
thomasvarney723 12y ago
What were the technologies the author references when he mentions Eric Meijer and Alan Kay?
- astigsen 12y ago
  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
AceJohnny2 12y ago
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).
tailrecursion 12y ago
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.
curtis 12y ago
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.
- dllthomas 12y ago
  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.
- eeperson 12y ago
  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.
zackmorris 12y ago
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!
tdees40 12y ago
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 12y ago
  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.
jokoon 12y ago
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.
Chinjut 12y ago
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.
peterashford 12y ago
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.

73 points by astigsen 12y ago

joaomoreno 12y ago

this guy seems pretty pissed

deleted 12y ago
[deleted]

rwmj 12y ago

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

noir_lord 12y ago

> 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 12y ago
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.

scott_s 12y ago

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 12y ago
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.

timanglade 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.

thomasvarney723 12y ago

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

astigsen 12y ago
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

AceJohnny2 12y ago

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

tailrecursion 12y ago

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.

curtis 12y ago

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.

dllthomas 12y ago
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.
eeperson 12y ago
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.

zackmorris 12y ago

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!

tdees40 12y ago

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 12y ago
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.

jokoon 12y ago

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.

Chinjut 12y ago

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.

peterashford 12y ago

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.