Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Joe Armstrong on Programmer Productivity

groups.google.com

Post reply on HN
Print view View original

41–50 of 90 posts

Re: Joe Armstrong on Programmer Productivity

#41

Post by craigyk »

GuiA wrote: post #37
ricardobeat wrote: post #35

> 30 years ago there was far less software, but the software there was usually worked without any problems - the code was a lot smaller and consequently easier to understand Pardon the intermission, but this is one of the areas where node.js shines IMO. I can read the complete source code for a very complex application, or at least know that each module has a reasonably-sized source and is readable if the need arises…

Never used nodejs before - is node's packaging system different from Python's or Ruby's?

node's packaging system is easily one of it's best features, IMO. They've clearly learned from the mistakes of others.

Now if only npm could shadow repositories...

Re: Joe Armstrong on Programmer Productivity

#42

Post by lkrubner »

This one sentence sums up the sociological and psychological problems that retard progress in the tech industry:

"Experiments that show that Erlang is N times better than "something else" won't be believed if N is too high."

That is exactly it. I've had those arguments where I was forced to tell a manager about another project I did for another company, a similar project where things went quickly and smoothly, using technology the manager was not familiar with. And every word I spoke was met with disbelief.

Re: Joe Armstrong on Programmer Productivity

#43

Post by apalmer »

jeffdavis wrote: post #28

I've often wondered what the software development world would be like if we used prototypes. Experimental hacking seems like a cut-down version of this concept. But what if we actually built things that we already agree in advance to throw away? Maybe even start from two or three different plausible designs, and push on each one for a while until one seems to be winning? Then rewrite it, learning from the other conte…

problem is any prototype that provides say 75% of the functionality will end up being pushed to production as soon as someone above developer level gets wind of it.

Re: Joe Armstrong on Programmer Productivity

#44

Post by grncdr »

GuiA wrote: post #37
ricardobeat wrote: post #35

> 30 years ago there was far less software, but the software there was usually worked without any problems - the code was a lot smaller and consequently easier to understand Pardon the intermission, but this is one of the areas where node.js shines IMO. I can read the complete source code for a very complex application, or at least know that each module has a reasonably-sized source and is readable if the need arises…

Never used nodejs before - is node's packaging system different from Python's or Ruby's?

Yes. The biggest difference is that there is no global namespace for modules.

    require('my-dependency')
returns a value, rather than aliasing identifiers into the current scope. So you end up with code like:

    var myDep = require('my-dependency')
    exports.doSomething = function (x) {
      myDep.doSomethingToAnX(x);
      // more code here
    }
The Python import (and Go and probably others) works in a similar way, except that in node, even the module names (the argument to require) are local to each module. That is: `require('my-dependency')` can return different values depending on the location of the file that called it. This means your project can depend on two different libraries that both depend on conflicting versions of "my-dependency". The mechanism by which this is accomplished is simple and straightforward. Another nice side-effect (as compared to Ruby) is that you can easily isolate a copy of any given dependency to monkey-patch or otherwise modify it, without affecting anybody else. (Not true of built-in globals such as String or Function, but that's a shortcoming of JavaScript, not Node)

Of course, the event+callback architecture and preference for writing everything in a manual continuation-passing-style makes working in Node suck for a host of other reasons, but the module system is really quite nice.

Re: Joe Armstrong on Programmer Productivity

#45

Post by loup-vaillant »

lkrubner wrote: post #42

This one sentence sums up the sociological and psychological problems that retard progress in the tech industry: "Experiments that show that Erlang is N times better than "something else" won't be believed if N is too high." That is exactly it. I've had those arguments where I was forced to tell a manager about another project I did for another company, a similar project where things went quickly and smoothly, using…

Partial remedy: stick to easily measurable facts: number of people, budget, time to completion, number of detected bugs…

Then, when your manager inevitably does not believe you, ask him if he thinks you missed something (no), then ask him if he trusts you (yes), then contemplate the face of cognitive dissonance.

Re: Joe Armstrong on Programmer Productivity

#46

Post by greenyoda »

LnxPrgr3 wrote: post #34
jeffdavis wrote: post #23

Earlier quoted context omitted.

Good point, but it's also not quite a fair comparison to go back and forth between implementation languages. Changing the language changes your thinking about the problem. If you translate a program from erlang to C++, the result might be shorter and more reliable than if the first version is in C++ and you rewrite it in C++. It also might not be, of course, but the fact that it could be muddles the comparison.

In my own experience, programmers vary more than languages do. I worked with someone who produced very elaborate designs for the most trivial tasks. Unfortunately, his code was more clever than he was, so it often didn't actually work. Whenever I re-wrote something he'd written in the same language, I managed to do it in 1/10th to 1/15th the number of lines, while adding the "actually works" feature.

One of the big differences I've seen between better and worse programmers is that the better ones have much greater abilities to create useful abstractions. I've also seen massive decreases in the number of lines of code when rewriting other peoples' code in the same language, and it frequently comes down to the original programmer not having seen that the dozen cases that the code needs to handle are really just the same case with minor differences, and the common behavior can be factored out. The extreme case of this kind of redundancy is copy-and-paste programming, where absolutely identical code is replicated all over the place.

Re: Joe Armstrong on Programmer Productivity

#47

Post by metabrew »

Jakob wrote: post #18
metabrew wrote: post #12

I rewrote a (~10k lines) C++ app to erlang back when I was learning erlang, and saw a ~75% reduction in lines of code. http://www.metabrew.com/article/rewriting-playdar-c-to-erlan... I expect the 'N' value varies wildly depending on what you are building, and whichever language you are comparing against.

Did you try to rewrite the app in C++ and look on how many percent reduction you get from that second try? I think it’s fair to compare that second app in C++ with the rewrite in another language since a rewrite will likely always be shorter independent of the language.

I understood the problem pretty well before writing the C++ version, having done some prototypes beforehand. The C++ version went through some reasonable refactoring too, so it's not like that code was just the first working version that g++ would accept.

I didn't do a full C++ rewrite of course. I think it's fair to say that whenever you are doing lots of concurrency/multithreading/evented stuff in a language like C++, the savings will be enormous when you switch to a language that has a nice concurrency model (ie, not just threads and shared mem and mutexes).

Re: Joe Armstrong on Programmer Productivity

#48

Post by metabrew »

mightybyte wrote: post #39
metabrew wrote: post #12

I rewrote a (~10k lines) C++ app to erlang back when I was learning erlang, and saw a ~75% reduction in lines of code. http://www.metabrew.com/article/rewriting-playdar-c-to-erlan... I expect the 'N' value varies wildly depending on what you are building, and whichever language you are comparing against.

At a previous job I rewrote a (~9k lines) Java app in Java and ended up with a 77% reduction in lines of code! So it would appear that the "smart programmer effect" is likely larger than the effect of most languages.

In this case, I was re-implementing the C++ app I had written - so it was the same programmer authoring both codebases.

I expect if I rewrote either codebase again, it might shrink even more.

Re: Joe Armstrong on Programmer Productivity

#49

Post by MartinCron »

lifeisstillgood wrote: post #16

this is partly why I advocate a slow code movement similar to the slow food movement. instead of sprinting I would like to walk to the destination, avoid the pains of broken ankles and repairing shoes whilst running in them. I would like to explore to find a sane and reasonable approach and not be driven by artificial deadlines guessed at three months ago but by todays business need. i would like to actually be measu…

Related: I've stopped using the term "sprint" as it is, by definition, a non-sustainable pace.

Re: Joe Armstrong on Programmer Productivity

#50

Post by MartinCron »

jeffdavis wrote: post #28

I've often wondered what the software development world would be like if we used prototypes. Experimental hacking seems like a cut-down version of this concept. But what if we actually built things that we already agree in advance to throw away? Maybe even start from two or three different plausible designs, and push on each one for a while until one seems to be winning? Then rewrite it, learning from the other conte…

I throw away prototypes pretty often. Spending a short time thinking through a problem by experimenting with it is more in line with my kind of thinking than writing detailed design documents or UML diagrams.

The key is to not be ashamed of it.

Post reply on HN