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

81–90 of 90 posts

Re: Joe Armstrong on Programmer Productivity

#81

Post by GFischer »

jefffoster wrote: post #72
colanderman wrote: post #55

Earlier quoted context omitted.

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.

Thanks for the link, it expresses part of what I struggle to explain quite well.

One problem I have, which Norvig doesn't talk about, is that I'm currently moving from one ecosystem (Microsoft) to another (the Java world), and it's not just about the language, it's everything, all the toolchain is different and unfamiliar.

The way of doing things is quite different too.

Re: Joe Armstrong on Programmer Productivity

#82

Post by colanderman »

jefffoster wrote: post #72
colanderman wrote: post #55

Earlier quoted context omitted.

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.

Without knowing any other language? Sure.

Coming from a strong background of similar languages? Sorry, you're wrong there. Perhaps you aren't familiar with Erlang; it is the "everyman" of functional languages. The things I think you'd call "idioms" (not really sure what you mean as that's a very loose term), let's say recursive programming, pattern matching, carry over as-is from any number of other functional languages. Pattern matching? It's a mix of OCaml and Prolog. Terms? Imagine Scheme had tuples in addition to lists. Etc. The only "new" concept is the message system, which if you know anything about networking, is pretty straightforward.

In other words, if you know pretty much any other functional language, it's almost trivial to translate basic programs to & from into Erlang knowing little more than its syntax, which as you concede, is simple.

OTOH, if you're coming from, say, PHP, sure, learning Erlang will be difficult as first you have to understand functional programming. But you're asserting impossibility, so counter-examples are moot.

Ten Years… I've been coding over twenty years in more languages than I can count… I have a good idea how long it takes to learn a language well. Maybe I'm biased because it's the latest language I've studied, but Erlang was the first non-toy language where I skimmed the reference manual, said "huh, that was all unsurprising", and started coding effectively.

Re: Joe Armstrong on Programmer Productivity

#83

Post by colanderman »

GFischer wrote: post #80
testrecord wrote: post #60

Earlier quoted context omitted.

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…

This roughly corresponds to my experience with Erlang; keeping in mind that "D" in Erlang relies heavily on its OTP ecosystem, which is fairly complex and different from most other languages.

Ignoring OTP, my ability to use the language proper was pretty much complete within a week, owing to its simplicity and my prior background in functional languages.

This is in contrast to C, which I have been using for around 15 years now, yet am still learning nuances of the language. (Things like: which integer operations are undefined on negative numbers; how integer promotion works with shift operators; how "restrict" interacts with scope.)

C is almost a fractal of nuance that does take years of experience to comprehend; Erlang has no nuance. (The closest thing to nuance I can think of is the relationship between integers and floats; and even then the takeaway is "it just works; don't worry about it". The only language in which I've seen the number hierarchy handled more cleanly is Racket.)

Re: Joe Armstrong on Programmer Productivity

#84

Post by colanderman »

ams6110 wrote: post #65
testrecord wrote: post #60

Earlier quoted context omitted.

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.

This was actually the biggest syntactic stumbling block for me, but because I know Prolog. It's definitely not Prolog semantically, and differs syntactically as well (e.g. clauses are separated by "." in Prolog but ";" in Erlang); to this day I sometimes find myself writing Prolog in Erlang.

Re: Joe Armstrong on Programmer Productivity

#85

Post by gruseom »

arh68 wrote: post #76
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),…

Good point—there are more effects than just "learning about the problem" that carry over to the next time you write the program. Once your brain has imprinted on a particular design for solving the problem, you'll probably carry that over to the next implementation. It may not be the design you'd have come up with if you were thinking in B in the first place and, short of erasing your memory and starting over, there's no way to test that.

Re: Joe Armstrong on Programmer Productivity

#86

Post by gtani »

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.

You can compress a lot of ruby code a few %age points by mashing the bottoms of the functions into "end;end;end;end;", same with C code that has curly braces on their own lines.

So this is similar to benchmarks: if you don't write a long paragraph about methodology, SLOCs and benchmarks are misleading

Re: Joe Armstrong on Programmer Productivity

#87

Post by andrewflnr »

gruseom wrote: post #70
andrewflnr wrote: post #69

Earlier quoted context omitted.

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.

Uh, heh, development length is probably a better thing to measure. They are somewhat correlated, and you can measure them both at the same time.

Re: Joe Armstrong on Programmer Productivity

#88

Post by dreamfactory »

Karellen wrote: post #74
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…

So tell a big enough lie and everybody believes it but a big enough truth and nobody does...

Re: Joe Armstrong on Programmer Productivity

#89

Post by dreamfactory »

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 always did this, it's just how I code. Trick is to keep them short and fixed duration under a day, preferably under half. a) that's where all the value is (longer and you're just going down the rabbit hole), and b) gives you time to quickly write production code based on the spike/prototype.

Re: Joe Armstrong on Programmer Productivity

#90

Post by Dewie »

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.

To me, agility has connotations with being quick (reflexes) and adaptable. It's probably from the RPG's that I've played.
Post reply on HN