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

71–80 of 90 posts

Re: Joe Armstrong on Programmer Productivity

#71

Post by informatimago »

Finster wrote: post #8
scotch_drinker wrote: post #3

The corollary to a) that I deal with all the time is third party integrations that are poorly documented and that after some time X start magically working even though the third party changed nothing on their side (according to them). Management always thinks "We've integrated things with this vendor before, it will be a snap to do again on a totally different endpoint" and this is never the case.

Then there's Facebook. "We integrated with Facebook a few months ago, it should be easy to do it again." Famous last words. I've lost count of how many times I've become an "expert" at some aspect of Facebook integration to have it be completely different just a few months later. Google is also really bad about this, at least in the past year or so. It almost makes me want to quit webdev and be a dba or something.

This is done on purpose. While others are trying to play catch upmwith their API, they're busy advancing things like robotcars with no competition.

Re: Joe Armstrong on Programmer Productivity

#72

Post by jefffoster »

colanderman wrote: post #55
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…

Ya, I had a manager laugh at me when I told him I had learned Erlang over the weekend (I am the resident "language lawyer", and Erlang's really not that complex). He didn't seem to be able to grok that a language could be so simple…

Languages are simple syntactically, but I'd have a hard time believing that anyone could pick up the set of idioms necessary to effectively use a new language in a few days.

Norvig it covers this well in his Teach Yourself Programming in Ten Years (http://norvig.com/21-days.html) essay.

Re: Joe Armstrong on Programmer Productivity

#73

Post by droidist2 »

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…

True, this is why I prefer old tried and true languages and tools, as much as I'd love to live on the bleeding edge. The day is just too short to use CoffeeScript/Dart/Haxe when there's JavaScript. Completing projects that seem "easy" is hard enough to begin with.

Re: Joe Armstrong on Programmer Productivity

#74

Post by Karellen »

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…

"And I hadn't even told him the truth. Actually, the shit coming out of Basco's pipes was a hundred thousand times more concentrated than was legally allowed. ... That kind of thing goes on all the time. But no matter how many diplomas are tacked to your wall, give people a figure like that and they'll pass you off as a flake. You can't get most people to believe how wildly the eco-laws get broken, but if I say "More than twice the legal limit," they get comfortably outraged."

-- Neal Stephenson, Zodiac (1988) http://en.wikiquote.org/wiki/Neal_Stephenson#Zodiac_.281988....

(I'd include the previous paragraphs in the quote, to show the conversation the protagonist actually has about this, if my copy wasn't on loan to a friend right now, dammit! If anyone else can post that, that's be cool.)

Re: Joe Armstrong on Programmer Productivity

#76

Post by arh68 »

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…

This approach strikes me as the most realistic. If there is an existing codebase in the preferred language A, the obvious question, if B wins, is "Do we rewrite the code in B?"

The only downside, and I think adding the language C tries to defuse it, is that whatever the team writes first will always stick. For example: if I wrote a version with dynamic typing (say in Ruby), then redid it with static typing (Haskell), of course I'm going to try to reuse types. The extreme example (Greenspun's rule) is if my pet language A is Lisp: regardless of what B is, the team could try to write a half-baked lisp runtime on top of B. The style carries over, and sometimes it doesn't translate exactly. I don't know how to solve this.

Re: Joe Armstrong on Programmer Productivity

#77

Post by jamii »

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…

That doesn't take into account how good a language is for prototyping and experimenting. Even if I have to write in $blublang, I'll probably still prototype it in $petlang for the increased productivity and then port it once I have the architecture nailed down.

Re: Joe Armstrong on Programmer Productivity

#78

Post by jamii »

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'm doing this at the moment. We have a gnarly ball of legacy code that is burning out devs. It actively resists any attempt to disentangle its parts and after years of attempts at refactoring it's gnarliness is barely reduced. I'm of the opinion that the actual problem it is solving is not nearly as complex as the code. We've extracted a smaller problem that contains all the hardest parts and are solving it with 2-3 different approaches. A completely naive implementation of the core functionality took only a few days and is already faster than the original.

The trouble at the moment is convincing the management that a) this is productive work and b) it really is time to (incrementally) rewrite this code - it's beyond saving. From their point of view it looks like we want to scrap something that sort-of works most of time and do all the work from scratch. It's difficult to convey just how much psychic damage the current code is causing to someone who isn't buried in it day-to-day.

Re: Joe Armstrong on Programmer Productivity

#79

Post by tetha »

ams6110 wrote: post #52
mbrock wrote: post #19

Earlier quoted context omitted.

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

Agile in the sense you are describing really has the wrong name. Agile implies fast; from Apple's Dictionary: able to move quickly and easily; able to think and understand quickly Agile should have been called Adaptable or some other name that has less implication of speed and more implication of accomodation of unknown or changing requirements. No putting that toothpaste back in the tube at this point though.

Though this has the same problem as "cheap". People always equate "fast" or "quick" with "quick right now" and "cheap" as "cheap right now". There are enough examples in long-term projects that this is not true (though the converse is true, as well. And those problems which transist from short-term to long-term are just nasty)

Re: Joe Armstrong on Programmer Productivity

#80

Post by GFischer »

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.

What's your definition of "picking up" a language?

A) Writing a "Hello, World"?

B) being able to fix a simple bug in a program?

C) Writing a small program that solves some domain problem

D) Writing a program that solves a "real world" problem, making use of the programming languages' strengths and conforming to standards (something that other people would let you commit into a repository unchallenged :) )

I'm certain A) takes only a few hours, and B) can be done in a day.

As Norvig says, you can do C) if you write in the new language like you would in a language you already know (not much of a problem if we're talking C# vs Java).

But D) IMO takes weeks/months.

Post reply on HN