[kamaal]

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 programmers in the world.

No serious company until its absolutely unavoidable(and situation gets completely unworkable without it) will ever use a language like Erlang or Lisp. Because every one knows the number of skilled people in market who know Erlang, are close to zero. And those who can work for you are going to be crazy expensive. And not to mention the night mare of maintaining the code in this kind of a language for years. There is no friendly documentation or a easy way a ordinary programmer can use to learn these languages. And there is no way the level of reusable solutions available for these languages as they are for other mainstream C based languages.

In short using these languages attracts massive maintenance nightmares.

The concurrency/parallelisation problem today is very similar to what memory management was in the 80's and 90's. Programmers hate to do it themselves. These are sort of things that the underlying technologies(Compilers/VM's) are supposed to do it for us.

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.

[alberich]

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

[coldtea]

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

[alberich]

> 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? Then you're stuck and there's nothing you can do except waiting for the language desingers to release a new version of your language with, hopefully, the changes you need.

[coldtea]

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

[coldtea]

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

[smosher]

This is total disregard for that the rest of the world considers valuable to them.

Yes and no. Where it's true, sure, arrogant jerks.

But the Lisp weenies have realized they know something the rest of the world doesn't. They think it's important, and it is in a sense. If only you knew that... you'd agree. (Ok, try not to take that too seriously.)

Unlike the impossibly abstract Lisp Truth™, this Erlang bit is centered in a very concrete fact that affects all of us. If you don't care about it today, it will affect you tomorrow all the same. You might as well argue that you never much cared for oxygen and who cares if the atmosphere is slowly turning to methane?

Joe wasn't saying you have to write Erlang, he was saying you need to write concurrent programs. If another language eats his lunch, it will probably do it in the same way that would be done in Erlang. There are alternatives, but the actor model is by far the most programmer-friendly that I have ever seen.

[ankurdhama]

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.

[kamaal]

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.

[ankurdhama]

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

[kamaal]

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

[eliasmacpherson]

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.

[wtetzner]

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