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

31–40 of 90 posts

Re: Joe Armstrong on Programmer Productivity

#31

Post by nnq »

andyl wrote: post #15
tom_b wrote: post #2

FTA (favorite part for me) Most time isn't spent programming anyway - programmer time is spent: a) fixing broken stuff that should not be broken b) trying to figure out what problem the customer actually wants solving c) writing experimental code to test some idea d) googling for some obscure fact that is needed to solve a) or b) e) writing and testing production code e) is actually pretty easy once a) - d) are fixed…

For me there is another time-consuming step: c') tooling: learning/debugging the latest test tool, test runner, deploy tool, source management system, CI system, etc. etc.

Indeed, now there are so many tools that you can't just expect a reasonably experienced programmer to just know the tools that you're using.

You have to either:

a. stick to old and/or boring and/or obviously inferior tools and programming languages, or

b. expect to pay the price of the time lost by programmers joining your team to learn the tools that you have chose or "worse", to actually survey all the options and pick the best tools for the project

...I know, the evolution of technology needs diversity in everything, including tools, so that some form of "selection" can actually push forward the best alternatives, but just as in nature and biology, "evolution" has huge prices to pay (in biology the most tragic prices are mortality and cancer, in software engineering I don't know what their analogues are, but I dread to think that we're already close to facing these "prices"...).

Re: Joe Armstrong on Programmer Productivity

#32

Post by nnq »

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…

Just as "fast food" in not unhealthy because of the "fast" part (there's actually a ton of healthy "fast food" if you actually look for it), but because moving fast is hard and cool, so people cut corners instead of accepting that "slow is how they go" (like re-re-...-re-frying in the same oil as a way for "faster profit" for the fast food industry, or writing code with no/bad tests/documentation).

People should try and find their "natural speed" when coding, and figure out other personal special abilities they have instead of "speed", stead of trying to keep up with the fastest guy in the room and being afraid to give estimates that are x times longer than his, and managers should accept that people work and think at different speeds and "slow" != "stupid", as most Americans tend to use "slow" in everyday lingo.

Re: Joe Armstrong on Programmer Productivity

#33

Post by jeffdavis »

Kronopath wrote: post #30
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…

This is a well-discussed concept already - see the concept of "Spikes" in Agile development, or to a lesser extent, the idea of "Tracer Bullets" from The Pragmatic Programmer . Of course, what's done in practice tends to differ, unfortunately.

"Of course, what's done in practice tends to differ, unfortunately."

Exactly... I've never really seen this happen beyond what I would consider "experimental hacking". Maybe it happens somewhere.

Re: Joe Armstrong on Programmer Productivity

#34

Post by LnxPrgr3 »

jeffdavis wrote: post #23
Jakob wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: Joe Armstrong on Programmer Productivity

#35

Post by ricardobeat »

> 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. Very small modules and using composition is encouraged, not restricted to a fringe community, and you also get to share tooling and libraries with the browser. All that on top of a friendly, functional language. It really feels like a step forward.

Re: Joe Armstrong on Programmer Productivity

#36

Post by lifeisstillgood »

mbrock wrote: post #19
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…

I think that is entirely in line with the true values of agile, which haven't really gotten through. Slow food isn't about slowness for the sake of slowness. It's just about being realistic and interested in the long-term. It's about saving energy and mental stress. One beautiful expression of this ideal is in "Domain-Driven Design."

I'm not disagreeing - just it's pretty clear the main concept that got through was "sprint".

had a rant recently on

Re: Joe Armstrong on Programmer Productivity

#37

Post by GuiA »

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?

Re: Joe Armstrong on Programmer Productivity

#38

Post by lifeisstillgood »

jeffdavis wrote: post #33
Kronopath wrote: post #30

Earlier quoted context omitted.

This is a well-discussed concept already - see the concept of "Spikes" in Agile development, or to a lesser extent, the idea of "Tracer Bullets" from The Pragmatic Programmer . Of course, what's done in practice tends to differ, unfortunately.

"Of course, what's done in practice tends to differ, unfortunately." Exactly... I've never really seen this happen beyond what I would consider "experimental hacking". Maybe it happens somewhere.

I like Fred George's developer anarchy in this regard - especially the concept of micro-web-services. they are the equivalent of a unix command - do one thing (well) and join up with MQ. if you make a service small enough you can be confident of putting it up as a prototype and rewrite it next weekend in node.js

Re: Joe Armstrong on Programmer Productivity

#39

Post by mightybyte »

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.

Re: Joe Armstrong on Programmer Productivity

#40

Post by lifeisstillgood »

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.

it's not that programmers vary - its that the same mistakes are made across the board:

1. memory management is hard - this is mostly a solved problem because the difference between C and $GARBAGECOLLECTEDLANG was great enough that it outweighed most differences in programmer ability. The mass move to web servers put paid to the need to develop for Windows APIs and Linux Syscalls and the a erage software project actually got better. (well ... worked)

1.a. business rules work better in languages that treat functions as first class objects and even better in languages that are logic based and really well in DSLs. most programmers don't reach the first so ... well we await the next mass change if languages.

2. Choice of algorithm. For loops are nice. just not everywhere. O(n^2) hurts. You can see the same in Unindexed table scanning queries.

3. Metrics. measure your own programs. write dynamic do s that update profile information in them. if you are not measuring then ... how do you know you improved? passing another hundred tests does not tell you if those tests measure what is valuable. tests are regression. metrics are progression.

4. I'm ranting too much today, blood pressure is rising :-)

Post reply on HN