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

121–130 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#121

Post by lmm »

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…

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

If go couldn't even implement its own interpreter in vanilla go, that's a sign that it's going to be a bad language.

Re: Joe Armstrong: Solving the wrong problem

#122

Post by willvarfar »

seanmcdirmid wrote: post #120
willvarfar wrote: post #113

Earlier quoted context omitted.

Isn't Joe's post specifically about parallelism and how Erlang is designed for it?

The post is about concurrency, but the word parallelism is used instead. To be fair, task level parallelism makes concurrent code run faster, but doesn't really scale if done for its own sake.

I think the post is about parallelism. Its about how Erlang naturally scales to many cores by running in parallel. If Erlang had only concurrency, as Javascript does, it would not be solving the "right problem".

Re: Joe Armstrong: Solving the wrong problem

#123

Post by coldtea »

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…

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

I can't speak for Erlang, but Lisp, really? Strange syntax? It's about as straightforward as it gets. And you can learn it in a day, a week tops.

>No serious company until its absolutely unavoidable(and situation gets completely unworkable without it) will ever use a language like Erlang or Lisp.

Lots of serious companies used both. Lisp was widely used in academia and in places like the JPL. AutoCAD worked with Lisp. Heck, even more obscure languages like OCaml are widely used in the financial domain. And today, lots of startups use Clojure. This very site (HN) is made in a Lisp.

Sure, using LISP has some drawbacks and is avoided by the mainstream enterprises today, because of lack of developers and commercial support (compared to C, Java, .NET etc).

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

I'm sorry to break it to you, but Perl, Python, PHP and even Ruby have already peaked. They are not going anywhere (upwards) in the next decade or so.

Re: Joe Armstrong: Solving the wrong problem

#124

Post by seanmcdirmid »

willvarfar wrote: post #122
seanmcdirmid wrote: post #120

Earlier quoted context omitted.

The post is about concurrency, but the word parallelism is used instead. To be fair, task level parallelism makes concurrent code run faster, but doesn't really scale if done for its own sake.

I think the post is about parallelism. Its about how Erlang naturally scales to many cores by running in parallel. If Erlang had only concurrency, as Javascript does, it would not be solving the "right problem".

Again, even if Erlang supports hardware threading properly, it doesn't magically become a good platform for parallel computing, there is no guarantee it will scale at all.

Its funny actually: a PL person thinks the key to scalable parallelism is hardware threading; a graphics or systems person thinks the key is a well planned pipeline.

Re: Joe Armstrong: Solving the wrong problem

#125

Post by coldtea »

alberich wrote: post #92
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, un…

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

Why you'd "manipulated code as data"? To write macros? A good template system can help with that (if you need it) without homoiconicity.

For me, the level of manipulation of "code as data" (and vice versa) you get with JSON/JS is enough for a lot of use cases.

Re: Joe Armstrong: Solving the wrong problem

#126

Post by coldtea »

surferbayarea wrote: post #34

Have you even used zlib in c++? The largest ecommerce site out there uses zlib in a multitreaded c++ application(24 cores, 100s of threads, 1000s requests/sec/server) and it works just fine! Bet you erlang can't come within a tenth of the performance of c++...

>1000s requests/sec/server

That's not particularly impressive you know.

Re: Joe Armstrong: Solving the wrong problem

#127

Post by Shish2k »

abc_lisper wrote: post #38
eksith wrote: post #32

There's one big problem Erlang couldn't solve that I live with to this day : Unlike another general purpose language (like say, C++ or C#) allow me to grasp what's happening after staring at it for 30 seconds. This is the same problem, I have with Lisp. Maybe I'm just dyslexic, but these rhetoric pieces for one language or another that says it's concurrent (which it is), fast (obviously), more C than C, will bring th…

Now, I have never read or written PHP. Here's the thing. PHP fills a niche. That niche is being super-productive early on. There are other goals, like, the code being readable, ease of being reasoned about, fast and so on. And there are languages that fill those niches. When people say crappy language, more often than not, crappy for their needs(or sometimes their expertise). There is no need to fight about it; its l…

Personally I call PHP crappy because it could easily have been much better at its main goal without sacrificing anything from its other goals, but for some reason it wasn't, and now we have to live with the stupid early decisions for compatibility reasons (eg there's no good reason for the mess of strFunc, str_func, string_func, funcstr, needle/haystack, haystack/needle, etc. When the main goal is being super-productive early on, being able to use the most basic functions without constantly looking up their order of parameters would be a great help)

Re: Joe Armstrong: Solving the wrong problem

#128

Post by lifeisstillgood »

InclinedPlane wrote: post #117
lifeisstillgood wrote: post #109

Earlier quoted context omitted.

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

Of course, most people would like to be working on race cars, or spacecraft, or fighter jets, but that just isn't an option for every body. And it's not as though there's no in between. The choice isn't just between some soul sucking blub-job in the enterprise trenches or using Erlang, there are lots of languages, lots of development patterns, lots of products.

I would agree, but with the proviso that the spectrum between soul-sucking and cool-space-tech is not a nice linear graph - in my experience its step-gradients, some companies are entirely on one level, and then they have to make a real effort to climb to the next (i.e. From manual deploys to CI)

Its actually a consultancy opportunity (I hope :-0)

Re: Joe Armstrong: Solving the wrong problem

#129

Post by daleharvey »

rdtsc wrote: post #61
daleharvey wrote: post #11

I cant help but read a lot of irony in this. Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealing with concurrent programming. (I havent tried go or dart yet) and I owe a lot of what I know to the very smart people building erlang. However it has barely evolved in the last 10 years, will 2013 be the year of the structs? (I doubt it), every new release com…

> However it has barely evolved in the last 10 years, will 2013 be the year of the structs? Eh... It is not perfect but considering everything else it brings to the table (fault tolerance, distribution, concurrency) I can easily overlook its warts. There is always Elixir or some LISP like dialects running on the BEAM VM as an alternative. I for one like its syntax. It makes sense to me somehow. I which maps were ther…

The syntax is a fairly minor point, and although its ridiculous there isnt first class dictionary support in 2013 there are parts of it I really like.

But Ericcson dont know how to manage an open source ecosystem, I dont think they particularly want to. It only started using an open source control a few years ago, still no open bug tracker, half the standard library is in terrible shape, there is no good support for 3rd party library integration.

A few years ago I wrote a UI to the documentation that most of the community seemed to massively prefer (http://erldocs.com). Every year I asked the OTP manager how to get it merged but instead they wrote their own (imo) sub par version while every release changing the documentation format which broke mine without warning.

Re: Joe Armstrong: Solving the wrong problem

#130

Post by kenko »

burntsushi wrote: post #90
kenko wrote: post #88

Earlier quoted context omitted.

>> (and having the interpreter get special status in breaking them, see generics) >What's your point? Purity for purity's sake? I assume the point is that the Go developers are saying "purity for thee, but not for me" (if you think generics are impure or unnecessary), or "generics for me, but not for thee", which is just annoying.

> which is just annoying I got that. I'm asking, why ? The decision to use generics or not has nothing to do with purity. It's about trade offs . If a decent balance can be struck with special privileged functions built into the language, I don't see how that is intrinsically bad.

It's not a decision about whether or not to use generics, it's a decision about whether or not to make it possible to use generics.

The developers have decided that they should make it possible for themselves to use generics, but impossible for you to use generics. Do you really not see why that's annoying? That's not a matter of tradeoffs, because they've already made generics possible---for themselves. At best they might be thinking something like "only WE are capable of grokking when generics are appropriate; everyone else would abuse them", which is rather arrogant, no? Lots of people have been saying that go is "missing" generics. The official response seems to be "no it isn't, you don't really need them." The unoffical response (evidenced by the use of generics in the compiler) is apparently "you're right, go is missing generics, so we'll include them, but just for ourselves".

Post reply on HN