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

41–50 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#41

Post by pessimizer »

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…

Nitrogen is particularly confusing because it is largely an ajax/comet abstraction.

Try Webmachine and erlydtl w/Mochiweb. Webmachine is like Sinatra, but more, and erlydtl is just Django templating.

Erlang is absurdly easy to read, but it doesn't look like algol, it looks like prolog. You get used to it, and after you do, coding in it is really fast.

Re: Joe Armstrong: Solving the wrong problem

#42

Post by eksith »

rcfox wrote: post #40
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…

> 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. I had the same problem with Lisp (Scheme, to be more specific) and I thought that it'd be impossible to reason about run-times and such. That is, until I learned the language and the standard libraries. I've never looked at Erlang, but I'd b…

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 that it was PHP and JavaScript. At no point did I stop in the language I'm currently working in to start learning another.

Until that changes, I don't see how it will help me.

Re: Joe Armstrong: Solving the wrong problem

#43

Post by jarrett »

eridius wrote: post #2

If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.

One certainly could. But to obtain the same properties you get with Erlang, you'd have to reimplement some features of the Erlang VM: Lightweight threads, message passing, etc.. Erlang is opinionated. It imposes a very specific model of concurrency. If you buy into that model, the language/VM gives it to you for free. If you don't, then you pretty much can't use Erlang.

By contrast, C is a very low-level language that can do anything. You can implement any model of concurrency in C. But you'll be doing all the plumbing yourself, or using a library that does the same. Erlang's model is not the only possible way to be lock-free, and you can pursue other options in C, if you want to.

Re: Joe Armstrong: Solving the wrong problem

#44

Post by eksith »

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…

Thank you for this. I fear I'll be an old man by the time I fully grasp thinking in Lisp, but I hate being defeated by my the limits of my own imagination.

Very nice video.

Re: Joe Armstrong: Solving the wrong problem

#45

Post by stelonix »

eridius wrote: post #23
transitorykris wrote: post #13

Earlier quoted context omitted.

Lock-free-ness is a consequence of data being immutable in Erlang

You can avoid mutating data in C if you want to. People just don't, because mutation is so convenient and fast.

Yes, but standard C has no way to tell the compiler a variable is immutable (immutability != constness), so unless you go non-standard (and very verbose at it) Erlang is still a better tool for the job.

Re: Joe Armstrong: Solving the wrong problem

#46

Post by dvt »

banachtarski wrote: post #36
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…

> memory management isn't handled that well. So... how would you have handled it, out of curiosity.

> So... how would you have handled it, out of curiosity.

Imo separate heaps is the first big mistake. Even implementations like Erjang (Erlang on the JVM using the Kilim microthreading library -- which I've also contributed to) improve on the copy-from-heap mechanism prevalent in vanilla Erlang. Not only that, but Erlang's memory allocator isn't that well-suited for multi-threaded allocations, which also means that Erlang doesn't (can't?) take advantage of tcmalloc, umem, hoard, etc.

Re: Joe Armstrong: Solving the wrong problem

#47

Post by acqq »

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

Re: Joe Armstrong: Solving the wrong problem

#48

Post by abc_lisper »

eksith wrote: post #44
abc_lisper wrote: post #38

Earlier quoted context omitted.

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…

Thank you for this. I fear I'll be an old man by the time I fully grasp thinking in Lisp , but I hate being defeated by my the limits of my own imagination. Very nice video.

You can start by watching SICP lectures freely available online :)

Re: Joe Armstrong: Solving the wrong problem

#49

Post by pnathan »

eksith wrote: post #42
rcfox wrote: post #40

Earlier quoted context omitted.

> 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. I had the same problem with Lisp (Scheme, to be more specific) and I thought that it'd be impossible to reason about run-times and such. That is, until I learned the language and the standard libraries. I've never looked at Erlang, but I'd b…

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 am not condemning you, mind. It is what it is. Rewiring your head is hard, and often doesn't have direct results.

I can, however, ship with Common Lisp, because I've spent on the order of 5 years learning it and writing it most evenings. I am learning Clojure and am preparing to ship a (excruciatingly minor) product with that after only maybe two months of dabbling. This is possible because I've bent my head around into Lisp shapes.

It's also been said that some people have the shape of Lisp in their head, and when they learn Lisp, their heads fit it by nature, and other people don't have that innate meshing. I certainly found Lisp to mesh with my head well.

Oh yes. It can be hard to get started with Common Lisp, just in terms of getting an environment working. I have a tutorial site to help with that(plug plug plug): http://articulate-lisp.com/

Re: Joe Armstrong: Solving the wrong problem

#50

Post by acdha »

zlib is fine as long as you don't give an non-threadsafe memory allocator - see http://www.gzip.org/zlib/zlib_faq.html#faq21. As far as I can tell, it either means that the summary was imprecise and the slowdown was in the image processing code and not zlib or that they chose to rewrite (and debug) a big chunk of code rather than read the zlib documentation.

Ignoring that point, this seems like a poor point for comparison as it's a trivially parallelized task because zlib operates on streams and shouldn't have any thread contention. There's very little information in the description but unless there are key details missing, this doesn't sound like a problem where Erlang has much interesting to add. The most interesting aspect would be the relative measures for implementation complexity and debugging.

Post reply on HN