3 ms·
> The objects are an interesting touch. Not sure how they'll work out in the grand scheme of things, but it's an interesting idea. Erlang already has objects.
by hassy 18y ago
> The objects are an interesting touch. Not sure how they'll work out in the grand scheme of things, but it's an interesting idea.
Erlang already has objects. They are just called processes.
Trying to bolt on a class system on top is just going against the grain.
> Single assignment? There are certainly some good reasons why Erlang is what it is, but perhaps this language might make it easier to do other things with Erlang as well. For instance I would never use it for sysadmin type tasks as it stands now
You would not use C or Java for sysadmin tasks either. You would not use Ruby to write a 3D game engine. Erlang was not designed to be a general-purpose language, much less a scripting one. Right tool for the right job...
- davidw 18y ago"Programming languages are not like hand tools": http://journal.dedasys.com/articles/2007/12/12/programming-languages-are-not-like-hand-tools http://journal.dedasys.com/articles/2007/12/12/programming-l... The key point is that yes, some things are better than others, but each language is a toolbox that is potentially capable of solving a wide variety of problems. If you can broaden the range of tasks your toolbox handles without sacrificing anything important, that's a big win. Also: > Erlang already has objects. They are just called processes. Trying to bolt on a class system on top is just going against the grain. Did you read about the language? The objects are processes, so rather than bolting on something that doesn't work, it's providing an easier, more familiar way to access something that often requires a fair amount of boilerplate in Erlang itself.