7 ms·

Your "-fu" should be considered harmful.

46 points by enneff 15y ago

duncan_bayne 15y ago
I actually spiked an idea like this a while back ... basically the idea was an in-browser Scheme REPL with something like SBCL's save-lisp-and-die. Stumbling blocks were my painful lack of familiarity with Lisp development in general, and BiwaScheme's lack of environment reflection. I tried hacking a macro wrapper for definition that saved the definition somewhere serializable but ... yuck. Perhaps ClojureScript could be a good basis for this (once it's out of alpha and features reflection and whatnot)? One could build a REPL-based development environment (_not_ an IDE!) that behaved somewhat like SLIME, and integrated with all the new hotness (GitHub, Heroku etc. etc.) Mightn't need much in the way of new technology, so much as a whole lot of nice glue to hold it all together.
- mahmud 15y ago
  You listed potential tools but haven't explained what you're trying to do.
  - duncan_bayne 15y ago
    Well, to be honest, I didn't really know ... my plan was to hack around and see what was possible :-) The vague idea I had was for some sort of modern Lisp-based development environment. REPL-based, rather than an IDE. Targetting HTML5 web browsers (maybe only one to start with?). Social coding baked right in, so it'd be trivial to start projects, fork them, share gists, etc. etc. And then the final step would be publishing to Heroku from within the REPL. So, maybe start off with an in-browser REPL. Add serialization of state. Then plug that into GitHub. Then some sort of deploy step to Heroku. Lots and lots of keyboard accelerators, help goodness and a decent debugger. But for the moment, it seems to be beyond my ability and / or beyond existing browser-based Lisp technologies.
tikhonj 15y ago
I think the main idea here is wrong. There is nothing wrong with technologies that require significant experience to master; the issue is with technologies that require significant experience but are still inefficient. Plenty of the best tools are moderately difficult to learn: Emacs, Vi, the command line, Linux, Haskell...etc. However, once you learn them well, you become more efficient than you could be on a tool that's easier to learn. And this is good: sacrificing a bit of extra time to learn a technology that will make you more efficient is usually a good trade because learning takes a constant amount of time while being more efficient is at least linear. The real issue is with tools that are arbitrarily complex. The DOM is a great example: its poor API, browser inconsistencies, weird layout rules...etc do not help you, but are difficult to learn and use. So the real issue is that the parts that are difficult to learn present no advantages over a simpler, easier to learn version.
- rsanchez1 15y ago
  The browser inconsistencies is the main obstacle, for the DOM, CSS, JS, and ny other web technology dependent on the browser.
  - duncan_bayne 15y ago
    I disagree. One could make the same argument about CPUs - look at all the different architectures out there. However, a good toolset (ISO C + autoconf) allows for fairly easy development of code that runs on a very wide range of platforms.
drivebyacct2 15y ago
I don't know that JavaScript is so much hard as just different. It's easily to be very expressive in JavaScript and the prototype nature of the language adds power. I think the idea that JavaScript is hard comes from developers that didn't learn it properly or just hack (not in a flattering sense) on it without understanding it. That having been said, I "understand" CSS, and always feel like I'm hacking on it no matter what I do.
- tikhonj 15y ago
  The issue isn't really with JavaScript, which is a great language, but with the DOM. The DOM is rather clumsy and you endlessly have to worry about browser incompatibilities. And if you have to support IE6...
- enneff 15y ago
  CSS is by far the worst of the technologies I listed, but JavaScript is full of bizarre stuff that can trip you up. The most obvious example is the global variable declaration thing. I've seen highly JS programmers with years of experience screwed by simply leaving out a "var" (in fact, I think something like this was posted to HN not that long ago), but this is something that could easily have been avoided were the language better designed.
krig 15y ago
I don't like this statement at all, sorry. It's a very anti-intellectual statement. Are any concepts that are difficult to grasp inherently worth less? That would make all of logic and math bad. Logic is not inherently easy for humans. We are a very emotional and irrational bunch. I don't agree that technologies are bad just because they are difficult to master. The learning curve is utterly irrelevant to their inherent value. There are lots of things that are both incredibly difficult and amazingly valuable. I also think this statement betrays an incredible short-sightedness. You are looking at the technology you know and think "Wow! This is so simple! Why aren't those things I don't know this simple?" Your technology appears simple to you primarily because it is yours. That's not a relativistic statement to imply that all technology is equally difficult to learn, it's just how our perspective shifts as we internalize new concepts. To me, C++ is a lot simpler than Go. I've tried to grasp how to use things like interfaces and channels in Go, but I haven't quite figured it out yet. C++, on the other hand, has been my primary tool for over two decades. The things that appear unreasonably complex to you make sense to me because I am familiar with the reasons they are there. Does that mean that Go is difficult and C++ is simple? Of course not. To someone who doesn't know a thing about programming, they are both absolutely arcane. Even the concept of variables is fundamentally difficult for people to grasp. It's an entirely abstract concept, and abstraction is not easy. A better measure for the utility of the technology would be to ask how well it solves the problems it is intended for. Empirically, it would seem that C and C++ are both the best tools available for different sets of problems. Go is new, but I don't see it being adopted anywhere outside Google yet. I've looked at it, and while it has some attractive traits, it is fundamentally shaped by a different set of priorities than my own. I just don't find the problems it claims to solve all that problematic.
- DannoHung 15y ago
  I think there is a distinction to be made: While there is value in grasping things that are complicated or hard to understand, there is little value in designing something that is intentionally complicated or hard to understand. In a certain sense, the problem that a tool maps to must reflect the inherent nature of what it works upon, but the designer of the tool should always intend to make the tool a map more fit for human use. Many of the things Gerrand cites were not created full form with the problems and uses clearly understood. This led to iteration and backwards compatibility, which introduced complications because now there were many ways to do things and not all suited for each other. I don't think his argument is that everything should be simple, but that the design should not feel iterative and piled upon. Instead it should reflect a consistency of vision for a problem and its solution. If I may offer an example: In Haskell, the Prelude defines many types and functions which are imported into all modules (sort of similar to namespaces). Many of these functions have commonly understood names but only apply to certain data types. Within the extended set of libraries available in Haskell, there are many other implementations of these functions in terms of more general data types. The types represented are not simple, really, though they are limited and isolated in purpose. Ideally, if one could go back and rewrite history, these more general functions and data types would be the ones exposed by the Prelude. Instead, the Prelude provides an earlier and less consistent view of common functions and datatypes, while the more consistent view is somewhat obscured inside of a number of neatly organized libraries. Both the Prelude and the hierarchy of libraries seek to solve the solution of common tools for working with data and functions, but one has a more clear cut and comprehensible perspective while the other has an older, less consistent view.
atdt 15y ago
CSS is a bit of a hobby horse, no? The specifications and implementations have matured considerably over the past few years, making the ugly hacks of yore unnecessary. If you can afford a somewhat degraded experience on IE7, the experience of writing CSS can be pleasurable and hassle-free. As to JavaScript: it has also seen massive improvements, but I'd like to emphasize a different point: namely that JavaScript's quirks, while annoying, are hardly arcane. They are very well known, and ably covered by any respectable introduction to the language. Most have established workarounds that are trivial to master (always providing the optional radix parameter to parseInt, for example), and the existence of excellent linters like jslint and jshint (the latter a community-driven fork of the former) makes it trivially easy to remember to do the right thing.
Tichy 15y ago
Weird that he mentions JavaScript, because it seems to me the simplest language of all. Except for a few quirks that you can usually ignore, what other language is so small and logical (everything builds on hashes and closures, basically)? If I think of Ruby, I think "ok, I can get things done, but don't get me started with the metaprogramming". It can get seriously metaphysical... Not so in JavaScript.
mrspeaker 15y ago
Maybe it's me who missed the point - but I think the author isn't saying "hard things aren't worth it" (as all of the comments here seem to suggest), but he's saying that truly mastering the warts of a technology that is full of warts is a waste of time. I think the faulty logic there is that _every_ technology over a certain age is going to seem full of warts... so the alternative it keep moving on to trying to master the latest and greatest buzzwords.
- enneff 15y ago
  Yes, that is what I meant. Thanks for re-stating it so clearly. To your point, I have two reactions. The first is that I feel you are being pessimistic. To some appearances software seems to be getting worse, but if you step back we actually have some pretty amazing tools these days. I personally find Go a better language than any other I've used. (disclosure: I'm part of the Go team.) My second reaction is: sure, of course we should move on to new things. We don't drive the same cars we did 40 years ago, yet software moves way faster than the auto industry and we're still using C for a lot of stuff. Programmers should be more adept at re-skilling for new languages and tools. The best ones already are.
andreadallera 15y ago
Hm. If you look at the problems C++ is out to solve, they're complex. Why shouldn't C++ be complex too then? A tool shouldn't hide complexity - look at VB and the monsters it created.
shadowmint 15y ago
Seriously HN? So now a casual 88-word status post is number 16 on the list? Correct me if I'm wrong but isn't this list for _hacks_? What is this? Andrew moping about disliking c++? I couldn't care less. The quality of HN articles just seems to drop week by week.
- xd 15y ago
  I voted you up. Not sure why you are being voted down as you've made a valid point. I found many of the replies awful, for instance one guy states: "Our children will laugh and wonder how we got anything done with the primitive tools at our disposal." There are far to many people out there that want to be developers, mechanics, artists, musicians etc etc but give up at the first hurdle and look for something to blame for their failure .. it's a very common human trait and not one I expected to see entertained on HN, either.
  - enneff 15y ago
    I think it's reasonable for my post to be the subject of discussion. As evidenced by the discussion here, there are many views on the subject. As for that specific comment, I don't know that I agree with it or that you are taking it in the right spirit. It seems to me a light-hearted take on the fact that things that seemed advanced to us 30 years ago seem primitive to us now, and that our descendants might feel the same way in another 30 years. Again, that's not my point, merely a more charitable reading of that comment. The point of my post was not to blame any of my tools for anything. It was an observation that we shouldn't praise ourselves for mastering the minutiae of environments that suck. We should recognize design failings and try to build better tools. I've personally had great success writing software in JavaScript, among other languages, but that doesn't mean I have to like it.
LefterisJP 15y ago
This statement is just wrong. No matter how many abstraction layers you put on top of a computer, it will be complicated. Yes they are good, and it's great to be able to do simple tasks with just one line of code but there are points where you can't, or you need better performance, or ,or , or ... In that case you would need to delve deeper, behind the abstraction layer and you would need to atually understand what's happening down there. If all you know is programming with all these abstractions without understanding what's actually happening underneath then you would be in for a surprise. And with new technologies coming out on the hardware side all the time, more parallelization, 3D graphics, quantum computing (?maybe), the APIs to use them in software will also be complicated. Nobody said that IT is an easy field.
- nailer 15y ago
  The poster is discussing technologies known for inconsistency and irrelevant design considerations. Sendmail pre sendmail X is full of what is now useless code to handle UUCP and X400 mail. JS has a bunch of rarely used cases where objects of different types can be added together to reduce usually unwanted results. Postfix, Python, and Coffeescript are close to as simple as possible, but no simpler. This is an excellent design goal.

46 points by enneff 15y ago

I actually spiked an idea like this a while back ... basically the idea was an in-browser Scheme REPL with something like SBCL's save-lisp-and-die. Stumbling blocks were my painful lack of familiarity with Lisp development in general, and BiwaScheme's lack of environment reflection. I tried hacking a macro wrapper for definition that saved the definition somewhere serializable but ... yuck. Perhaps ClojureScript could be a good basis for this (once it's out of alpha and features reflection and whatnot)? One could build a REPL-based development environment (_not_ an IDE!) that behaved somewhat like SLIME, and integrated with all the new hotness (GitHub, Heroku etc. etc.) Mightn't need much in the way of new technology, so much as a whole lot of nice glue to hold it all together.

mahmud 15y ago
You listed potential tools but haven't explained what you're trying to do.
- duncan_bayne 15y ago
  Well, to be honest, I didn't really know ... my plan was to hack around and see what was possible :-) The vague idea I had was for some sort of modern Lisp-based development environment. REPL-based, rather than an IDE. Targetting HTML5 web browsers (maybe only one to start with?). Social coding baked right in, so it'd be trivial to start projects, fork them, share gists, etc. etc. And then the final step would be publishing to Heroku from within the REPL. So, maybe start off with an in-browser REPL. Add serialization of state. Then plug that into GitHub. Then some sort of deploy step to Heroku. Lots and lots of keyboard accelerators, help goodness and a decent debugger. But for the moment, it seems to be beyond my ability and / or beyond existing browser-based Lisp technologies.

tikhonj 15y ago

I think the main idea here is wrong. There is nothing wrong with technologies that require significant experience to master; the issue is with technologies that require significant experience but are still inefficient. Plenty of the best tools are moderately difficult to learn: Emacs, Vi, the command line, Linux, Haskell...etc. However, once you learn them well, you become more efficient than you could be on a tool that's easier to learn. And this is good: sacrificing a bit of extra time to learn a technology that will make you more efficient is usually a good trade because learning takes a constant amount of time while being more efficient is at least linear. The real issue is with tools that are arbitrarily complex. The DOM is a great example: its poor API, browser inconsistencies, weird layout rules...etc do not help you, but are difficult to learn and use. So the real issue is that the parts that are difficult to learn present no advantages over a simpler, easier to learn version.

rsanchez1 15y ago
The browser inconsistencies is the main obstacle, for the DOM, CSS, JS, and ny other web technology dependent on the browser.
- duncan_bayne 15y ago
  I disagree. One could make the same argument about CPUs - look at all the different architectures out there. However, a good toolset (ISO C + autoconf) allows for fairly easy development of code that runs on a very wide range of platforms.

drivebyacct2 15y ago

I don't know that JavaScript is so much hard as just different. It's easily to be very expressive in JavaScript and the prototype nature of the language adds power. I think the idea that JavaScript is hard comes from developers that didn't learn it properly or just hack (not in a flattering sense) on it without understanding it. That having been said, I "understand" CSS, and always feel like I'm hacking on it no matter what I do.

tikhonj 15y ago
The issue isn't really with JavaScript, which is a great language, but with the DOM. The DOM is rather clumsy and you endlessly have to worry about browser incompatibilities. And if you have to support IE6...
enneff 15y ago
CSS is by far the worst of the technologies I listed, but JavaScript is full of bizarre stuff that can trip you up. The most obvious example is the global variable declaration thing. I've seen highly JS programmers with years of experience screwed by simply leaving out a "var" (in fact, I think something like this was posted to HN not that long ago), but this is something that could easily have been avoided were the language better designed.

krig 15y ago

I don't like this statement at all, sorry. It's a very anti-intellectual statement. Are any concepts that are difficult to grasp inherently worth less? That would make all of logic and math bad. Logic is not inherently easy for humans. We are a very emotional and irrational bunch. I don't agree that technologies are bad just because they are difficult to master. The learning curve is utterly irrelevant to their inherent value. There are lots of things that are both incredibly difficult and amazingly valuable. I also think this statement betrays an incredible short-sightedness. You are looking at the technology you know and think "Wow! This is so simple! Why aren't those things I don't know this simple?" Your technology appears simple to you primarily because it is yours. That's not a relativistic statement to imply that all technology is equally difficult to learn, it's just how our perspective shifts as we internalize new concepts. To me, C++ is a lot simpler than Go. I've tried to grasp how to use things like interfaces and channels in Go, but I haven't quite figured it out yet. C++, on the other hand, has been my primary tool for over two decades. The things that appear unreasonably complex to you make sense to me because I am familiar with the reasons they are there. Does that mean that Go is difficult and C++ is simple? Of course not. To someone who doesn't know a thing about programming, they are both absolutely arcane. Even the concept of variables is fundamentally difficult for people to grasp. It's an entirely abstract concept, and abstraction is not easy. A better measure for the utility of the technology would be to ask how well it solves the problems it is intended for. Empirically, it would seem that C and C++ are both the best tools available for different sets of problems. Go is new, but I don't see it being adopted anywhere outside Google yet. I've looked at it, and while it has some attractive traits, it is fundamentally shaped by a different set of priorities than my own. I just don't find the problems it claims to solve all that problematic.

DannoHung 15y ago
I think there is a distinction to be made: While there is value in grasping things that are complicated or hard to understand, there is little value in designing something that is intentionally complicated or hard to understand. In a certain sense, the problem that a tool maps to must reflect the inherent nature of what it works upon, but the designer of the tool should always intend to make the tool a map more fit for human use. Many of the things Gerrand cites were not created full form with the problems and uses clearly understood. This led to iteration and backwards compatibility, which introduced complications because now there were many ways to do things and not all suited for each other. I don't think his argument is that everything should be simple, but that the design should not feel iterative and piled upon. Instead it should reflect a consistency of vision for a problem and its solution. If I may offer an example: In Haskell, the Prelude defines many types and functions which are imported into all modules (sort of similar to namespaces). Many of these functions have commonly understood names but only apply to certain data types. Within the extended set of libraries available in Haskell, there are many other implementations of these functions in terms of more general data types. The types represented are not simple, really, though they are limited and isolated in purpose. Ideally, if one could go back and rewrite history, these more general functions and data types would be the ones exposed by the Prelude. Instead, the Prelude provides an earlier and less consistent view of common functions and datatypes, while the more consistent view is somewhat obscured inside of a number of neatly organized libraries. Both the Prelude and the hierarchy of libraries seek to solve the solution of common tools for working with data and functions, but one has a more clear cut and comprehensible perspective while the other has an older, less consistent view.

atdt 15y ago

CSS is a bit of a hobby horse, no? The specifications and implementations have matured considerably over the past few years, making the ugly hacks of yore unnecessary. If you can afford a somewhat degraded experience on IE7, the experience of writing CSS can be pleasurable and hassle-free. As to JavaScript: it has also seen massive improvements, but I'd like to emphasize a different point: namely that JavaScript's quirks, while annoying, are hardly arcane. They are very well known, and ably covered by any respectable introduction to the language. Most have established workarounds that are trivial to master (always providing the optional radix parameter to parseInt, for example), and the existence of excellent linters like jslint and jshint (the latter a community-driven fork of the former) makes it trivially easy to remember to do the right thing.

Tichy 15y ago

Weird that he mentions JavaScript, because it seems to me the simplest language of all. Except for a few quirks that you can usually ignore, what other language is so small and logical (everything builds on hashes and closures, basically)? If I think of Ruby, I think "ok, I can get things done, but don't get me started with the metaprogramming". It can get seriously metaphysical... Not so in JavaScript.

mrspeaker 15y ago

Maybe it's me who missed the point - but I think the author isn't saying "hard things aren't worth it" (as all of the comments here seem to suggest), but he's saying that truly mastering the warts of a technology that is full of warts is a waste of time. I think the faulty logic there is that _every_ technology over a certain age is going to seem full of warts... so the alternative it keep moving on to trying to master the latest and greatest buzzwords.

enneff 15y ago
Yes, that is what I meant. Thanks for re-stating it so clearly. To your point, I have two reactions. The first is that I feel you are being pessimistic. To some appearances software seems to be getting worse, but if you step back we actually have some pretty amazing tools these days. I personally find Go a better language than any other I've used. (disclosure: I'm part of the Go team.) My second reaction is: sure, of course we should move on to new things. We don't drive the same cars we did 40 years ago, yet software moves way faster than the auto industry and we're still using C for a lot of stuff. Programmers should be more adept at re-skilling for new languages and tools. The best ones already are.

andreadallera 15y ago

Hm. If you look at the problems C++ is out to solve, they're complex. Why shouldn't C++ be complex too then? A tool shouldn't hide complexity - look at VB and the monsters it created.

shadowmint 15y ago

Seriously HN? So now a casual 88-word status post is number 16 on the list? Correct me if I'm wrong but isn't this list for _hacks_? What is this? Andrew moping about disliking c++? I couldn't care less. The quality of HN articles just seems to drop week by week.

xd 15y ago
I voted you up. Not sure why you are being voted down as you've made a valid point. I found many of the replies awful, for instance one guy states: "Our children will laugh and wonder how we got anything done with the primitive tools at our disposal." There are far to many people out there that want to be developers, mechanics, artists, musicians etc etc but give up at the first hurdle and look for something to blame for their failure .. it's a very common human trait and not one I expected to see entertained on HN, either.
- enneff 15y ago
  I think it's reasonable for my post to be the subject of discussion. As evidenced by the discussion here, there are many views on the subject. As for that specific comment, I don't know that I agree with it or that you are taking it in the right spirit. It seems to me a light-hearted take on the fact that things that seemed advanced to us 30 years ago seem primitive to us now, and that our descendants might feel the same way in another 30 years. Again, that's not my point, merely a more charitable reading of that comment. The point of my post was not to blame any of my tools for anything. It was an observation that we shouldn't praise ourselves for mastering the minutiae of environments that suck. We should recognize design failings and try to build better tools. I've personally had great success writing software in JavaScript, among other languages, but that doesn't mean I have to like it.

LefterisJP 15y ago

This statement is just wrong. No matter how many abstraction layers you put on top of a computer, it will be complicated. Yes they are good, and it's great to be able to do simple tasks with just one line of code but there are points where you can't, or you need better performance, or ,or , or ... In that case you would need to delve deeper, behind the abstraction layer and you would need to atually understand what's happening down there. If all you know is programming with all these abstractions without understanding what's actually happening underneath then you would be in for a surprise. And with new technologies coming out on the hardware side all the time, more parallelization, 3D graphics, quantum computing (?maybe), the APIs to use them in software will also be complicated. Nobody said that IT is an easy field.

nailer 15y ago
The poster is discussing technologies known for inconsistency and irrelevant design considerations. Sendmail pre sendmail X is full of what is now useless code to handle UUCP and X400 mail. JS has a bunch of rarely used cases where objects of different types can be added together to reduce usually unwanted results. Postfix, Python, and Coffeescript are close to as simple as possible, but no simpler. This is an excellent design goal.