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

91–100 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#91

Post by burntsushi »

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

for i:= range list { go func() { foo(i) } } (This is a bug in the spec, but will not be fixed before Go 2 because Go 1.0 is frozen.) Shared memory by default.

You've completely missed my point. I wasn't claiming that Go did anything to stop you from sharing memory. I was claiming that its concurrency model is CSP, not shared memory.

> (This is a bug in the spec, but will not be fixed before Go 2 because Go 1.0 is frozen.)

Could you kindly link me, please?

Re: Joe Armstrong: Solving the wrong problem

#92

Post by alberich »

kamaal wrote: post #83

This blog post shows everything that is wrong with languages like Lisp and Erlang. This is total disregard for that the rest of the world considers valuable to them. The problem with these languages remain unchanged. The syntax is so strange and esoteric, learning and doing anything basic things with them will likely require months of learning and practice. This lone fact will make it impractical for 99% for all prog…

>> I bet most of these super power languages will watch other pragmatic languages like Perl/Python/Ruby/Php etc eat their lunch over the next decade or so when they figure out more pragmatic means of achieving these goals.

You know, Lisp's syntax is weird but it is exactly this what makes it so flexible. It's easy to manipulate code as data, because the syntax is very regular. Try to do that with C's syntax...

So, unless someone knows how to solve this in a easy way, I'd say that the lot's of parentheses are actually a pragmatic decision (i.e. you want easy macros... so you have to use this uncommon syntax).

If popularity is the goal, then maybe those languages were not pragmatic. However, It seems the language designers of such powerfull languages (e.g. Lisp, Erlang, Haskell) were looking to solve other problems where popularity is really not a concern.

Re: Joe Armstrong: Solving the wrong problem

#93

Post by stiff »

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 higher clocks th single-threaded apps would run still faster, but instead the multi-threaded apps benefit more from the improvements in the CPU.

Re: Joe Armstrong: Solving the wrong problem

#94

Post by Uchikoma »

Because the lock-free Erlang meme doesn't die:

  1. Erlang has locks and semaphores [1], receive is a lock, actors are semaphore. Erlang chose a 1 semaphore/ 1 lock per process model
  2. Erlang scales better not because of being lock-free (see above), but because it easily uses async compared to other languages
  3. Async prevents deadlocks not Erlang being lock-free (see above)
Some 4year old reading http://james-iry.blogspot.de/2009/04/erlang-style-actors-are...

[1] http://en.wikipedia.org/wiki/Semaphore_(programming)

Re: Joe Armstrong: Solving the wrong problem

#95

Post by masklinn »

burntsushi wrote: post #51
masklinn wrote: post #30

Earlier quoted context omitted.

> Go allows you to share memory between goroutines (i.e. concurrent code). Go will share memory, by default, and special attention must be taken preventing or avoiding it. It's not an allowance. > In fact, the Go team explicitly tells you not to do that And yet they have refused to implement a correct model, even though they have no problem imposing their view when it fits them (and having the interpreter get special…

> 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 of CSP. It's disingenuous to affix Go with the same kind of concurrency model used in C.

It's not, go passes mutable objects over its channel and all routines share memory, you get the exact same model by using queues in C.

> What's your point? Purity for purity's sake?

That the Go team has no issue breaking the rules they impose on others, so that point is irrelevant.

Re: Joe Armstrong: Solving the wrong problem

#96

Post by ankurdhama »

kamaal wrote: post #83

This blog post shows everything that is wrong with languages like Lisp and Erlang. This is total disregard for that the rest of the world considers valuable to them. The problem with these languages remain unchanged. The syntax is so strange and esoteric, learning and doing anything basic things with them will likely require months of learning and practice. This lone fact will make it impractical for 99% for all prog…

You sounds like a typical "manager". I have heard this comment millions of time from management people. These so called pragmatic languages are good to build "applications" which are just a bunch of API calls bound together and most of the so called programmers are building "applications", they have no idea of how to build real "systems" which are distributed, robust etc. Try to build "systems" in your so called pragmatic language and you will find what I mean.

Re: Joe Armstrong: Solving the wrong problem

#97

Post by davidw »

rdtsc wrote: post #63
dvt wrote: post #27

Same old hype. Erlang is good I guess, and I've used it in production a couple of times. But it's just a language that solves 3 problems but creates another 30. Just like C++11, Dart, Go, etc. This kind of belligerent rhetoric (we're solving the right problems, everyone else is dumb) is the kind of drivel that gives momentum to language zealots that think language X is better than language Y. I've contributed to Goog…

> 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…

> How is it any more or less stupid than curly bracket.

When you move a few lines around to refactor, you have to pay a lot of attention to the "ant turd token" line endings. I like Erlang, but still find this aspect of it annoying.

Re: Joe Armstrong: Solving the wrong problem

#98

Post by kamaal »

ankurdhama wrote: post #96
kamaal wrote: post #83

This blog post shows everything that is wrong with languages like Lisp and Erlang. This is total disregard for that the rest of the world considers valuable to them. The problem with these languages remain unchanged. The syntax is so strange and esoteric, learning and doing anything basic things with them will likely require months of learning and practice. This lone fact will make it impractical for 99% for all prog…

You sounds like a typical "manager". I have heard this comment millions of time from management people. These so called pragmatic languages are good to build "applications" which are just a bunch of API calls bound together and most of the so called programmers are building "applications", they have no idea of how to build real "systems" which are distributed, robust etc. Try to build "systems" in your so called prag…

Sounds?

>>I have heard this comment millions of time from management people.

Really?

>>These so called pragmatic languages are good to build "applications" which are just a bunch of API calls bound together

Guess what?

All software is building on top of something. Every heard of system calls?

>>and most of the so called programmers are building "applications", they have no idea of how to build real "systems"

May be you being such a great programmer can show us how to build a "real system", without ever using a API of anything ever.

>> Try to build "systems" in your so called pragmatic language and you will find what I mean.

Something like 99.99% of the world does that. Erlang is not even in the list top 10 languages in the world today.

Re: Joe Armstrong: Solving the wrong problem

#99

Post by eliasmacpherson »

kamaal wrote: post #83

This blog post shows everything that is wrong with languages like Lisp and Erlang. This is total disregard for that the rest of the world considers valuable to them. The problem with these languages remain unchanged. The syntax is so strange and esoteric, learning and doing anything basic things with them will likely require months of learning and practice. This lone fact will make it impractical for 99% for all prog…

You can learn Erlang and get a basic program done in it, faster than it will take you to get something equivalent up in C++. In Europe at least, I know of plenty of companies using Erlang.

Re: Joe Armstrong: Solving the wrong problem

#100

Post by fulafel »

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.
Post reply on HN