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

61–70 of 90 posts

Re: Joe Armstrong on Programmer Productivity

#61

Post by t1m »

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 too am a slow programmer.

I have seen so many furious sprints towards the 'finished' system with so little knowledge of what actually needs to be built. The only part that has changed recently is that there is now typically a unit test suite along side that correctly tests the wrong thing.

Re: Joe Armstrong on Programmer Productivity

#62

Post by t1m »

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…

It could be argued that rapid prototyping is modern software development.

In the late 80's and early 90's, rapid prototyping was very fashionable in the 'anti-waterfall' software engineering schools of thought. The idea was to use dynamic languages with good development tools (various Lisps, Tcl/Tk, Smalltalk) to rough out the idea, which would then be rewritten in 'real' languages.

Of course this tactic failed successfully! We shipped the prototype. Nowadays, it would seem absurd to develop a web application (for example) written in a 'real' language like C++ or PL/1.

Re: Joe Armstrong on Programmer Productivity

#63

Post by Chris_Newton »

nnq wrote: post #31
andyl wrote: post #15

Earlier quoted context omitted.

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…

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.

I can think of at least two further difficulties that come with the explosion of available tools:

1. It’s hard to know whether a tool is actually worth using at all. Many tools sound appealing because you’re familiar with the problem they aim to solve but not yet familiar with all the quirks and edge cases and hidden costs of using the tool instead.

2. Many tools look promising in their early days, when they are prime examples of enthusiasm driven development. It’s another thing to ask whether the tool is still going to be in active development five years down the line, when there are newer and shinier things to work on. Even if there are, your 100,000 line code base might still need that security fix or one of the 10% of missing features that were on the roadmap when you first started integration.

I’m all for using the right tool for each job, and I’m certainly in favour of using good tools rather than doing everything the hard way, but figuring out which tools those are gets harder as tools proliferate.

Re: Joe Armstrong on Programmer Productivity

#64

Post by gruseom »

benaiah wrote: post #59
gruseom wrote: post #58

There's a problem with language productivity comparisons that Armstrong mentions: it's impossible to write the same program in two different languages. If you have the same team write it, their second try will benefit from everything they learned the first time, and that is so huge a part of programming that it is sure to distort the outcome and may even dwarf any language effects. But if you use different teams inst…

If you want to compare languages A and B, have them write it in language C first for the domain knowledge, then the two languages. That seems like a better option than giving one a bias on purpose.

But that doesn't account for the pet language effect.

Also, whichever of A or B goes third would still have an advantage over the one that went second.

Re: Joe Armstrong on Programmer Productivity

#65

Post by ams6110 »

testrecord wrote: post #60
aaronbrethorst wrote: post #56

Earlier quoted context omitted.

You can learn Objective-C in a couple hours if you have experience with similar languages. Learning Cocoa or Cocoa Touch, otoh...

I picked up c# within a day or two with a working knowledge of Java. Some languages are easy to pick up given the right background. I'll have to check erlang out. I only hear good things.

Erlang has a few syntactic conventions that will probably seem familiar only if you've used Prolog. But, like any other language syntax, you learn it pretty quickly and within itself it starts to makes sense.

Re: Joe Armstrong on Programmer Productivity

#67

Post by ams6110 »

Chris_Newton wrote: post #63
nnq wrote: post #31

Earlier quoted context omitted.

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…

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. I can think of at least two further difficulties that come with the explosion of available tools: 1. It’s hard to know whether a tool is actually worth using at all . Many tools sound appealing because you’re familiar with the problem they aim to solve but not yet familiar with…

I'm feeling this way about JavaScript now. So much so I almost don't want to use JavaScript at all. There are so many JS frameworks and libraries right now; they can't possibly all survive but who knows which ones will?

Re: Joe Armstrong on Programmer Productivity

#68

Post by FormerPhysicist »

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…

I had a paid internship in college, many years ago, where I basically spent three months twiddling my thumbs waiting for a project, and when I finally got one, it was creating an MS Access database to count SLOCs. If they were that concerned with productivity, perhaps they could have given me something useful to do.

Re: Joe Armstrong on Programmer Productivity

#69

Post by andrewflnr »

gruseom wrote: post #58

There's a problem with language productivity comparisons that Armstrong mentions: it's impossible to write the same program in two different languages. If you have the same team write it, their second try will benefit from everything they learned the first time, and that is so huge a part of programming that it is sure to distort the outcome and may even dwarf any language effects. But if you use different teams inst…

Write the program several times, alternating languages. Eventually, both the programs in both languages should converge on their respective optimal lengths.

(I say "optimal" rather than "shortest" so we're not tempted to sacrifice clarity for concision.)

Re: Joe Armstrong on Programmer Productivity

#70

Post by gruseom »

andrewflnr wrote: post #69
gruseom wrote: post #58

There's a problem with language productivity comparisons that Armstrong mentions: it's impossible to write the same program in two different languages. If you have the same team write it, their second try will benefit from everything they learned the first time, and that is so huge a part of programming that it is sure to distort the outcome and may even dwarf any language effects. But if you use different teams inst…

Write the program several times, alternating languages. Eventually, both the programs in both languages should converge on their respective optimal lengths. (I say "optimal" rather than "shortest" so we're not tempted to sacrifice clarity for concision.)

For some reason I assumed that the experiment was to measure development time rather than program length. Obviously that wasn't specified, since you assumed the opposite.
Post reply on HN