Joe Armstrong: Solving the wrong problem • Hacker News Board

Re: Joe Armstrong: Solving the wrong problem

#161

Post by reeses » Fri, Mar 29, 2013, 10:06 AM UTC

seanmcdirmid wrote: post #150

reeses wrote: post #142

Earlier quoted context omitted.

I think in this case they're relatively interchangeable terms. Rather than a SIMD vectorization of a task, you are applying a MIMD solution to various parts of a task. You can typically get more of an immediate boost with SIMD on current hardware (especially if you can effectively cast it to GPGPUs), but MIMD is more easily applied. Almost any application can be refactored to spawn lightweight threads for many calcul…

> but MIMD is more easily applied. Almost any application can be refactored to spawn lightweight threads for many calculations without any explicit knowledge of the π-calculus. MIMD hasn't been shown to scale, and its not locking that is the problem, but I/O and memory. > To your point and for a well-understood example, make -j doesn't always result in faster compilations. It may if you have the ability to leverage i…

"MIMD hasn't been shown to scale, and its not locking that is the problem, but I/O and memory."

We're going to have to disagree on this one, as we have some obvious examples in favor of MIMD scaling on the TOPS 500. SIMD is just a tool for a subset of parallelizable problems.

Re: Joe Armstrong: Solving the wrong problem

#162

Post by uwiger » Fri, Mar 29, 2013, 8:30 PM UTC

To say that Erlang fails to deliver what most programmers need misses the point. If you have a mainstream problem, use a mainstream language!

I've spent many years developing and reviewing products in the telecoms realm, and have found that failing to realize when something like Erlang brings life-saving concepts to your project may well make the difference between delivering on time and disappearing into a black hole of endless complexity. It's not for everyone, but when it fits, boy does it help!

Re: Joe Armstrong: Solving the wrong problem

#163

Post by digitalzombie » Sat, Mar 30, 2013, 2:48 AM UTC

tieTYT wrote: post #15

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…

I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.

http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-...

It's also preemptive too. I don't believe JVM have this nor any other languages.

Re: Joe Armstrong: Solving the wrong problem

#164

Post by digitalzombie » Sat, Mar 30, 2013, 3:00 AM UTC

wtetzner wrote: post #154

kamaal wrote: post #82

Earlier quoted context omitted.

>>Just because Erlang isn't immediately accessible to you, it doesn't mean it isn't any good for shipping in 48 hours. No, that is not the problem. The problem is total disregard to what most people consider valuable to them. And if they don't get it, framing that as their stupidity rather admitting the fact that the syntax is a little strange to wrap your head around(which is true). >>Perhaps if you spend 24 hours s…

> In all fairness sharpening your erlang axe might take 24 months not 24 hours. In all fairness it won't. Erlang is not a difficult language to learn, and honestly, it doesn't take that much effort for the syntax to become familiar. The semantics of Erlang are different from that of C-like languages, and therefore I think it's good that it has different syntax. You could give it C-like syntax, but that might be just…

>Erlang is not a difficult language to learn

I'd like confirm this. It doesn't even have loops, you have to use recursion (and only recursion).

Re: Joe Armstrong: Solving the wrong problem

#165

Post by digitalzombie » Sat, Mar 30, 2013, 3:05 AM UTC

acqq wrote: post #47

djvu9 wrote: post #37

We used Erlang several years ago. The code base has ~100k lines of code so it should be representative. We abandoned it later and switched to C++ because of performance (mostly in mnesia) and quality issues (some drivers in OTP). We didn't expect too much from performance considering it is functional (which seldom does in place update) but it is still below expectation. It is understandable though. Just think about h…

The tests here confirm your experience, Erlang is for many algorithms significantly slower, even when more cores are used: http://benchmarksgame.alioth.debian.org/u64q/erlang.php

Do not use Erlang for number performance. I tried with EulerProject and create some prime number generators in Erlang. It is slow as hell.

Use it for what it is built for!

Re: Joe Armstrong: Solving the wrong problem

#166

Post by burntsushi » Sat, Mar 30, 2013, 4:33 AM UTC

kenko wrote: post #155

burntsushi wrote: post #140

Earlier quoted context omitted.

> 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. Fine. That's what I meant. > Do you really not see why that's annoying? I can if you believe in purity over all else. > That's not a matter of tradeoffs, because they've already made generics possible---for themselves. Sorry, but what? Are you really trying to claim that adding generic…

Honestly, I don't know what you even mean by purity.

The context of this discussion started when people were complaining about the language designers being able to build in special functions that are type parametric. The implication was: if the language designers can do it, why won't they allow me to do it?

i.e., purity for purity's sake. It ignores legitimate trade offs between allowing a few special functions and building an entire generics system into the language.

Re: Joe Armstrong: Solving the wrong problem

#167

Post by coldtea » Sat, Mar 30, 2013, 11:59 AM UTC

alberich wrote: post #138

coldtea wrote: post #125

Earlier quoted context omitted.

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

> Why you'd "manipulated code as data"? To write DSLs? You cannot use JSON to create new syntax for your language. The whole idea of DSLs is to extend the language for the problem at hand. How would you do that with JSON? Say... how would you write something like CLOS, for instance, using the alternative mentioned by you? Maybe your option is good enough for a lot of use cases. But what when it is not good enough? Th…

>To write DSLs? You cannot use JSON to create new syntax for your language. The whole idea of DSLs is to extend the language for the problem at hand.

I'm not that sold on DSLs. I have a language (the base language) that people know, has certain semantics, etc.

Now I suddenly go on and add a new mini-language on top of it, with my ad-hoc semantics for the "problem domain"? Why multiply the languages used, so that someone would have to reason and understand both, instead of just one?

I could just use the functionality of the base language, AND it's syntax/semantics, to model the problem. I.e with objects in an OO design, with functions, in a procedural design, data and first class function in a functional design etc.

I don't really like all those Ruby DSLs for example, like for testing, were you have to learn each one ON TOP or knowing the core language.

Re: Joe Armstrong: Solving the wrong problem

#168

Post by kenko » Sat, Mar 30, 2013, 3:00 PM UTC

burntsushi wrote: post #166

kenko wrote: post #155

Earlier quoted context omitted.

Honestly, I don't know what you even mean by purity.

The context of this discussion started when people were complaining about the language designers being able to build in special functions that are type parametric. The implication was: if the language designers can do it, why won't they allow me to do it? i.e., purity for purity's sake. It ignores legitimate trade offs between allowing a few special functions and building an entire generics system into the language.

I still don't know what you mean by "purity". Saying "i.e., purity" doesn't help, since I already knew that you think purity has something to do with generics being definable by people other than the language designers.

"If the language designers find it useful to occasionally use type-parametric functions, why won't they recognize that other people might also find it useful, too, and for other functions?" doesn't strike me as a demand for purity in any sense. Consistency, maybe; recognition that the designers are giving themselves special treatment, sure. What's pure about the desired state of affairs, or impure about the present?

Honestly, sometimes it seems as if someone who wants to defend Go against a criticism immediately claims that the critic is just obsessed with purity. Why else would you criticize Go?

Re: Joe Armstrong: Solving the wrong problem

#169

Post by burntsushi » Sun, Mar 31, 2013, 2:19 AM UTC

kenko wrote: post #168

burntsushi wrote: post #166

Earlier quoted context omitted.

The context of this discussion started when people were complaining about the language designers being able to build in special functions that are type parametric. The implication was: if the language designers can do it, why won't they allow me to do it? i.e., purity for purity's sake. It ignores legitimate trade offs between allowing a few special functions and building an entire generics system into the language.

I still don't know what you mean by "purity". Saying "i.e., purity" doesn't help, since I already knew that you think purity has something to do with generics being definable by people other than the language designers. "If the language designers find it useful to occasionally use type-parametric functions, why won't they recognize that other people might also find it useful, too, and for other functions?" doesn't st…

This was the original comment that I responded to:

> and having the interpreter get special status in breaking them, see generics

It's a whine that the interpreter gets "special status." It's implicit in the complaint that special status is somehow bad. It ignores any trade offs that go into the design decision.

Purity in this context means: the language gets no extra special power that users of the language can't tap into themselves.

> Honestly, sometimes it seems as if someone who wants to defend Go against a criticism immediately claims that the critic is just obsessed with purity.

And sometimes it seems as if someone criticizes Go just because they are obsessed with stuffing as many features as possible into a programming language. Shit happens.