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

151–160 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#151

Post by willvarfar »

seanmcdirmid wrote: post #148
willvarfar wrote: post #147

Earlier quoted context omitted.

http://talks.golang.org/2012/waza.slide "Once we have the breakdown, parallelization can fall out and correctness is easy." Joe is saying this too. And he's saying that because Erlang is a concurrent language, parallelism (he's thinking MIMD not SIMD) is easy. He says: > Now Erlang is (in case you missed it) a concurrent language, so Erlang programs should in principle go a lot faster when run on parallel computers,…

My main issue here is that people here "parallelism" and "a lot faster" they automatically think "scaling." But just hardware threading doesn't get us anywhere near that goal, even if we write our C-style multi-threaded code by hand very carefully. The PL community is still not having honest up-to-date conversations about parallelism; they are about 20 years behind other fields.

Ok, you have to describe what you think the honest and up-to-date conversation about parallelism is then.

Re: Joe Armstrong: Solving the wrong problem

#152

Post by seanmcdirmid »

willvarfar wrote: post #151
seanmcdirmid wrote: post #148

Earlier quoted context omitted.

My main issue here is that people here "parallelism" and "a lot faster" they automatically think "scaling." But just hardware threading doesn't get us anywhere near that goal, even if we write our C-style multi-threaded code by hand very carefully. The PL community is still not having honest up-to-date conversations about parallelism; they are about 20 years behind other fields.

Ok, you have to describe what you think the honest and up-to-date conversation about parallelism is then.

Well, look at how people like Google's Jeff Dean, originally a PL person, became a systems person to basically attack parallelism problems head on. That is, look at the problems that NEED parallel computing, don't think of parallelism as a transparent benefit that is nice to have if it happens, and if it doesn't, its not the end of the world.

Once you accept that parallelism is needed, you realize that it is much more complex than just dividing things up onto multiple cores. That locking is never really the big problem, which really is one of concurrency, the problem becomes all about pumping data to the right place at the right time.

Re: Joe Armstrong: Solving the wrong problem

#153

Post by wtetzner »

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…

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

There are plenty of companies that already use Erlang and/or Lisp. In fact, Erlang comes from industry, designed to solve Ericsson's business problems.

Re: Joe Armstrong: Solving the wrong problem

#154

Post by wtetzner »

kamaal wrote: post #82
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…

>>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 as confusing, if not more so, since it wouldn't mean the same thing it did in C.

Re: Joe Armstrong: Solving the wrong problem

#155

Post by kenko »

burntsushi wrote: post #140
kenko wrote: post #130

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

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

Re: Joe Armstrong: Solving the wrong problem

#156

Post by ankurdhama »

kamaal wrote: post #98
ankurdhama wrote: post #96

Earlier quoted context omitted.

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

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

Yup, heard about them. My point is the focus of these "applications" is meshing API calls rather than algorithm and data structures.

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

I ain't a great programmer at all, far far away from that. As far as "real system" is concerned, what about IBM watson?

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

I wasn't talking about Erlang specifically. I was pointing to the so called niche languages that you mentioned that very few people uses.

Anyway, there is no point discussing this because we have different point of view. Mine is "what should be done to further progress computer science - the progress is too slow", yours being "lets build applications and earn some bucks".

Re: Joe Armstrong: Solving the wrong problem

#157

Post by kamaal »

ankurdhama wrote: post #156
kamaal wrote: post #98

Earlier quoted context omitted.

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

>> All software is building on top of something. Every heard of system calls? Yup, heard about them. My point is the focus of these "applications" is meshing API calls rather than algorithm and data structures. >> 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. I ain't a great programmer at all, far far away from that. As far as "real syste…

>>yours being "lets build applications and earn some bucks".

You are a in a wrong forum. This forum is for entrepreneurs and other programmers alike who are working to 'getting stuff done'.

Re: Joe Armstrong: Solving the wrong problem

#158

Post by querulous »

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

whatsapp is approaching 3 million simultaneous connected users on a single server using erlang

Re: Joe Armstrong: Solving the wrong problem

#159

Post by ternaryoperator »

Joe Armstrong: "The problem that the rest of the world is solving is how to parallelise legacy code."

Donald Knuth: "During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading."

Re: Joe Armstrong: Solving the wrong problem

#160

Post by pjmlp »

burntsushi wrote: post #139
masklinn wrote: post #95

Earlier quoted context omitted.

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

> 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. I never claimed otherwise. But I do think you underestimate the utility of idioms. > you get the exact same model by using queues in C. No, you don't. C doesn't have lightweight threads, which means it can't suppor…

> No, you don't. C doesn't have lightweight threads, which means it can't support a useful CSP model of concurrency.

Well there are a few libraries available for it.

And Windows C developers can make use of fibers.

Post reply on HN