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

Joe Armstrong: Solving the wrong problem

joearms.github.com

Post reply on HN
Print view View original

101–110 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#101

Post by fulafel »

masklinn wrote: post #95
burntsushi wrote: post #51

Earlier quoted context omitted.

> Go will share memory, by default, and special attention must be taken preventing or avoiding it. Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes, even if channels are implemented using shared memory under the hood. That is, the default concurrency model militated by Go is not shared memory, but that of CSP. It's disingenuous to affix Go w…

> Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes Except since Go has support for neither immutable structures not unique pointers, the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this. > That is, the default concurrency model militated by Go is not shared memory, but that…

> since Go has support for neither immutable structures not unique pointers, the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this.

Channels are pass-by-value. If you pass a struct, it's copied, and both sides can mutate their own copies as much as they want.

You can get still bugs if you make channels of pointers (or have pointers in your message structs etc).

Re: Joe Armstrong: Solving the wrong problem

#102

Post by InclinedPlane »

People have been thinking this, that it's vastly better to design for concurrency upfront, for literally decades. And every single time there has been a big sea change in processor technology it's always been the next generation which will see things like VLIW or Erlang and so forth come to the fore while what I will call "iterative advancements" and "patched solutions" turn out to have too many weaknesses to be competitive. In reality the reverse has happened, and new specialized languages and instruction sets have been relegated to niches.

It'll be the same over the next 20 years as well.

I predict that we'll see a lot of technological leaps which will serve as much to maintain the ability to run "old code" in new and interesting ways as to enable a brave new world of purpose-built languages.

In the next few decades we'll see advances in micro-chip fabrication and design as well as memory and storage technology (such as memristors) which will result in even handheld battery powered devices having vastly more processing power than high-end workstations do today.

Is that an environment in which one seeks to trade programmer effort and training in order to squeeze out the maximum possible efficiency from hugely abundant resources? Seems unlikely to me, to be honest.

Indeed, it seems like the trend of relying on even bloatier languages (like Java) will continue. Do you think anyone is going to seriously consider rewriting the code for a self-service point-of-sale terminal in Erlang in order to improve performance? That's not the long pole, it never has been, and it's becoming a shorter and shorter pole over time.

In the future we'll be drowning in processor cycles. The most important factor will very much not be figuring out how to use them most efficiently, it'll be figuring out how to maximize the value of programmer time and figuring out how to use any amount of cycles to provide value to customers effectively.

(I think that advancements in core, fundamental language design and efficiency will happen and take hold in the industry, but mostly via back-door means and blue sky research, rather than being forced into it through some impending limitation due to architecture.)

Re: Joe Armstrong: Solving the wrong problem

#103

Post by paganel »

pnathan wrote: post #49
eksith wrote: post #42

Earlier quoted context omitted.

I used hyperbole of course, but in fairness, I've spent on the order of several months getting into Lisp. Mabye it's because I didn't work with it exclusively (I've been told here on HN that you need to be immersed in it completely and continously) that I still didn't become OK in any semblance of the term. But here's the thing: I switched to C# from VB.Net. Before that, it was VBScript (ASP pages) and even before th…

Basically, I would say that what you are suffering from is a kind of mental block syndrome: you think in a procedural/imperative paradigm. All your listed languages operate in that paradigm. It's a very transferable paradigm, as it so happens. I can come up to (some approximation of) speed in an imperative language in under 2 weeks. In order to ship Lisp(Prolog, Haskell...), you have to break out of that paradigm. I…

> you have to break out of that paradigm.

That's why I never regretted trying to learn Common Lisp some time ago, even though I didn't ship anything into production, and why I really do enjoy doing the same thing with Erlang right now, i.e. trying to understand it and getting as comfortable with it as I can get (and preferably this time maybe putting something out there).

Both these experiences helped me see programming differently, a change of "paradigm" as you very well put it, so now even when I get back to Python or PHP I feel like I'm a better programmer. Plus, there's something to be said about the fact that always trying to learn new and interesting stuff and not only focusing on "shipping code" is what keeps one's passion at higher levels. After almost 10 years in this trade I've found that passion at what you're doing is a very valuable and in the same time very volatile resource.

Re: Joe Armstrong: Solving the wrong problem

#104

Post by lifeisstillgood »

InclinedPlane wrote: post #102

People have been thinking this, that it's vastly better to design for concurrency upfront, for literally decades. And every single time there has been a big sea change in processor technology it's always been the next generation which will see things like VLIW or Erlang and so forth come to the fore while what I will call "iterative advancements" and "patched solutions" turn out to have too many weaknesses to be comp…

Can I rephrase slightly (and take the odd strawman liberty)

The "mainstream" has been relying on incremental improvements for decades, and in doing so avoided rewriting legacy code until last possible moment

Some people have taken concurrency upfront and anecdotally seen cost / performance benefits plus more modern codebases and have anecdotally enjoyed competitive advantages in areas where concurrency makes a difference

We will never see the average, user interface bother with concurrency and legacy rewrites because the competitive advantages are low.

There are likely to be areas where the concurrency advantage is great enough - if you like erlang look for those niches

Re: Joe Armstrong: Solving the wrong problem

#105

Post by peerst »

Peaker wrote: post #73
rdtsc wrote: post #63

Earlier quoted context omitted.

> The syntax is outdated and stupid (Prolog lol), How is it any more or less stupid than curly bracket. Show me another production ready language that has the same level of pattern matching as Erlang. > Often times, algorithms simply cannot be parallelized. Who cares. How many people here have implemented individual algorithms and delivered them as units of execution. Sure middleware companies maybe sell a cool imple…

Haskell has nicer pattern matching capabilities.

No it hasn't :-) Just to stay on your level of detail

Re: Joe Armstrong: Solving the wrong problem

#106

Post by InclinedPlane »

lifeisstillgood wrote: post #104
InclinedPlane wrote: post #102

People have been thinking this, that it's vastly better to design for concurrency upfront, for literally decades. And every single time there has been a big sea change in processor technology it's always been the next generation which will see things like VLIW or Erlang and so forth come to the fore while what I will call "iterative advancements" and "patched solutions" turn out to have too many weaknesses to be comp…

Can I rephrase slightly (and take the odd strawman liberty) The "mainstream" has been relying on incremental improvements for decades, and in doing so avoided rewriting legacy code until last possible moment Some people have taken concurrency upfront and anecdotally seen cost / performance benefits plus more modern codebases and have anecdotally enjoyed competitive advantages in areas where concurrency makes a differ…

Yes, precisely.

It's like designing a race car, or a fighter jet. Sure, they are amazing things. But are people ever going to commute to work in anything resembling a Bugatti Veyron or an F-22? Of course not. Neither maximum automotive performance nor air combat effectiveness are the sorts of things that are normally necessary to optimize for in daily life. Some time in the far future we're going to have both the tools to write amazingly efficient programs and to do so with a minimal amount of fuss from the programmer's perspective, but it'll be a long time getting there. And in the meantime there are going to be plenty of cycles of figuring out how to produce performance gains with the least disruption to existing ways of doing things.

Re: Joe Armstrong: Solving the wrong problem

#107

Post by konstruktor »

fulafel wrote: post #100
konstruktor wrote: post #22

> At this point in time, sequential programs started getting slower, year on year, and parallel programs started getting faster. The first part of this statement is plain wrong. Single thread performance has improved a lot due to better CPU architecture. Look at http://www.cpubenchmark.net/singleThread.html and compare CPUs with the same clock rate, where a 2.5 GHz. An April 2012 Intel Core i7-3770T scores 1971 point…

If you want to refute the point you can't arbitrarily restrict the comparison to processors with the same clock rate.

The current Core iX CPUs offer higher clock rates than the Core 2 CPUs from 2008? Using the highest clock available would have skewed the result against Armstrongs argument.

Re: Joe Armstrong: Solving the wrong problem

#108

Post by konstruktor »

jd007 wrote: post #55
konstruktor wrote: post #22

> At this point in time, sequential programs started getting slower, year on year, and parallel programs started getting faster. The first part of this statement is plain wrong. Single thread performance has improved a lot due to better CPU architecture. Look at http://www.cpubenchmark.net/singleThread.html and compare CPUs with the same clock rate, where a 2.5 GHz. An April 2012 Intel Core i7-3770T scores 1971 point…

Your point is absolutely correct, but your example could be better IMO. It's not fair to compare a desktop chip with 45W TDP with a laptop chip rated at 35W. Not to mention that the newer i7 actually goes up to 3.7Ghz turbo (vs. 2.5Ghz constant for the C2D) for single threaded loads, so the clock rate is not really comparable in that benchmark (even though base clocks are the same). A better example would be C2D E860…

True, good point. I tried to find something with a similar nominal clock speed and forgot about Turbo. But then, Turbo is a good example why single threaded performance is getting better even in the age of multicores.

Re: Joe Armstrong: Solving the wrong problem

#109

Post by lifeisstillgood »

InclinedPlane wrote: post #106
lifeisstillgood wrote: post #104

Earlier quoted context omitted.

Can I rephrase slightly (and take the odd strawman liberty) The "mainstream" has been relying on incremental improvements for decades, and in doing so avoided rewriting legacy code until last possible moment Some people have taken concurrency upfront and anecdotally seen cost / performance benefits plus more modern codebases and have anecdotally enjoyed competitive advantages in areas where concurrency makes a differ…

Yes, precisely. It's like designing a race car, or a fighter jet. Sure, they are amazing things. But are people ever going to commute to work in anything resembling a Bugatti Veyron or an F-22? Of course not. Neither maximum automotive performance nor air combat effectiveness are the sorts of things that are normally necessary to optimize for in daily life. Some time in the far future we're going to have both the too…

Puuuuhhhleeeeaaaseeee can I commute to work in a Bugatti Veyron??

Please please please :-)

Edit: sorry unable to resist. However I am on Joe Armstrongs side - I would far rather make a decent living doing fun Erlang work than be in a java shop making the next generation of POS

Added to that I think not using Erlang or some STM based concurrency language must be an informed decision - if the CTO of big bank says we have tried two pilot projects rewriting the ATM network in Erlang and the projected costs do not add up, fine. If he says "I have two hundred java coders, we aren't moving". I don't think that's valid

Re: Joe Armstrong: Solving the wrong problem

#110

Post by konstruktor »

stiff wrote: post #93
konstruktor wrote: post #22

> At this point in time, sequential programs started getting slower, year on year, and parallel programs started getting faster. The first part of this statement is plain wrong. Single thread performance has improved a lot due to better CPU architecture. Look at http://www.cpubenchmark.net/singleThread.html and compare CPUs with the same clock rate, where a 2.5 GHz. An April 2012 Intel Core i7-3770T scores 1971 point…

I think your argument doesn't hold up all that well, you said that the improved architecture of the individual cores improved single-threaded performance (despite, I assume, the decreased clock rates), so I think Dr. Armstrongs point that the shift to multicore made sequential programming less profitable holds at least to an extent - if the CPU manufacturers used the same architecture but used just one core and the h…

The part of Armstrong's argument I was (explicitly) referring to was not about relative gains of multi-threading but about presumed absolute losses of single-thread performance. My argument against this is not refuted by relative gains of multi-threading..

Of course you realize even bigger gains on many common workloads using parallelism, but this part of his argument doesn't need the first part, which was wrong.

Post reply on HN