> if I wanted a language built around concurrency I’d use Erlang or Haskell.
And if you wanted a concurrent language that wasn't a functional language what would you use?
And if you wanted a concurrent language that wasn't a functional language what would you use?
In my day job I use Haskell to "just get shit done". However when it comes time to refactor I can do it much faster and safer in Haskell.
The ease of refactoring creates an incentive to improve code.
At least that seems to be what has happened in my case.
In the interest in figuring out which, what problems do you work with and what are your principles/beliefs/guiding principles in software? :P
Of course, the elephant in the room is needing a windows-based infrastructure ... but if that's not a huge barrier, it's not an unreasonable choice.
With Clojure, Scala or F# you need to be disciplined and don't really get many guarantees, but you can reuse lots of imperative code.
It kind of depends what your priorities are, if it's correctness or development speed.
Well yes, I can just live without imperative libraries because it is so natural to have single assignment (in the same scope) that I do it even in other languages. Accessing imperative libraries is possible though, just think about the C libs. What would you implement in Erlang the imperative way or which library do you miss exactly? The ecosystem is definitely smaller, but you can get support, some of the smartest software guys hang out on the mailing lists and IRc as well. I got absolutely amazing help from both when we worked on a Erlang project.
> It kind of depends what your priorities are, if > it's correctness or development speed.
Yeah and also how much fun you want to have. :)
Using Erlang is great but not many devs out there for hire, on the other side you have two seasoned Erlang devs they can do a lot. Contractors FTW!
Btw. what about using ASN.1 with Erlang? How does that change the correctness / development speed?
In my experience creating Haskell bindings to say imperative c libraries is pretty easy. What imperative libraries have been hard to access for you personally?
As far as I know Erlang doesn't give you any guarantees about side effects. You can call side-effecting functions at any point in your program, just like in Clojure or OCaml.
What makes you say this?
Being a "boring" simple language with limited options for implementation means more focus on the problem and less on the infinite number of ways to solve the problem "elegantly". But there are a lot of other factors too. Static typing helps once the code base gets above 5000 lines, for example. Fast iteration from making a change to running the tests again also helps.
And it's true because its creator says so right here, in this link!
And I bet you're going to say "But he coined the term!". Yes. He's still making up his own definition twenty years after the industry gave its own, so whatever he says on the topic is moot.
Firstly, I don't know at what exact point did Kay come out in demystifying OO (1998 or so?), but the design principles of Smalltalk and messaging date back to publishing in 1974, with many references to it afterwards.
Secondly, the idea that there is one singular definition of OO that the industry has standardized on is absurd. Object models differ semantically from language to language, even if some general motif of "encapsulation/inheritance/polymorphism" is present (though again, important subtleties abound - is encapsulation enforced or merely convention, how structural and nominal subtyping are modeled [mixins], etc.).
But would you say that's the definition of OO? In fact, Kristen Nygaard who was the creator of the Simula language, an ALGOL extension, and now considered to be the first OO language (semantically in that it beefed up structs and other procedural nuances) considered object orientation to be a property of any system in general as opposed to language constructs. Thus, Erlang definitely does count as OO under that, too.
So what definition do we follow, then? Who do we trust?
Apparently this is a difficult problem: http://c2.com/cgi/wiki?DefinitionsForOo
But by all means, Erlang embodies many OO design principles by certain important taxonomies - both Nygaard's and Kay's. If you're going to reject both, then you're going down murky waters.
That's interesting because Armstrong himself thinks that OO sucks:
http://harmful.cat-v.org/software/OO_programming/why_oo_suck...