2 ms·

Why bother doing that when you're still fiddling with the language? To me, that sounds entirely backward :) I've never implemented a language I haven't alread

Why bother doing that when you're still fiddling with the language? To me, that sounds entirely backward :) I've never implemented a language I haven't already designed "on paper". (Why bother? With a good reference document, you can write and test programs in your head. Implementation is tedious; I only want to do that once.) In terms of CS friendliness, I get the impression that Haskell is far more popular […] It is. I don't really know why. Haskell has a lot of libraries and a good compiler, but it's otherwise pretty boring. Its type system is nothing special (OCaml and Mercury have very similar but more interesting systems, notably w/r/t subtyping), monadic I/O is one of the silliest contortions I've seen (uniqueness types in Mercury and Clean are much easier to work with), and laziness isn't all that useful (it is useful but I've never missed not having it). (I say this with all respect to the Haskell designers: it's a very good language, and they successfully met their self-imposed goal of being fully functional; I just happen to think that that goal led to Haskell being ultimately boring.) Erlang has "functional" and "actors", but not a lot of other stuff that seems to be of interest to the CS crowd, like types. That's exactly it. It doesn't have a lot of stuff. The language is incredibly simple, EVERYTHING is explicit, it doesn't encourage first-class metaprogramming, and it ships with its own parser and pretty-printer. That's a CS researcher's dream. That's why Dialyzer (which is better than many, if not most, built-in type systems) can exist. You don't need a built-in type system if your language is simple and analyzable enough to admit a 3rd-party one. No way at all? I think you can tell a lot about a language without some kind of formal documentation. Sadly, all I can tell from the tutorial and front page is "Elixir has some kind of metaprogramming that's probably based on Ruby or Javascript". Like I said, I'm a huge fan of metaprogramming done right, but that hinges on lots of specific language details that aren't clearly documented. Without specifics, any discussion about Elixir's metaprogramming features might as well be a discussion about Javascript's or Ruby's, because that's all I have to go on.

davidw 14y ago
> To me, that sounds entirely backward :) I've never implemented a language I haven't already designed "on paper". (Why bother? With a good reference document, you can write and test programs in your head. Implementation is tedious; I only want to do that once.) The answer in this case seems likely to be: Jose started fiddling around with it, and at the same time was learning what he could and could not do on Erlang's VM. I guess I take a favorable view of experimentation and a dimmer view of being able to plan everything ahead of time. At some point in time, things need to be stabilized, but at the beginning, some contact and pushback from the real world and real usage may well impact the design of a system.
aninhumer 14y ago
> monadic I/O is one of the silliest contortions I've seen (uniqueness types in Mercury and Clean are much easier to work with) As far as I can see they're all basically the same thing. You enforce sequence by creating a chain of notional "real world" values. I can't say I've used Clean or Mercury extensively, but as far as I can see they just make you pass around that value explicitly. That doesn't really seem like it would be "easier to work with".
- ralfn 14y ago
  > That doesn't really seem like it would be "easier to work with". 1. You dont need monadic versions of all non monadic functions. You dont need fmap, you can just use map. 2. It means there is a well defined order of execution (i.e. The order does not "emerge" as in Haskell, instead it is defined and verified by type system) It is much much easier to work. In Haskell you feel forcedto separate io from transformation as much as posible. Often you end with either repeating ourself a lot (writing oth mondic as non monadic versions) ir you venture out in monad transformers, which imho is the "goto" of Haskell. (How to turn your code in unreadable unmaintainable spagetti). The cognitive overload is never worth it. Ps. Uniqueness types are not just about IO. Rust uses them as well. They are about sharing. Haskells needs an IO () type because without a monad it has no defined order of execution, and it cant prevent you from "forking the world" when working with outside references. If Haskell could prevent you (by using uniqueness) i doubt they would have used monads for IO. (Although they can be usefull in other areas).

davidw 14y ago

> To me, that sounds entirely backward :) I've never implemented a language I haven't already designed "on paper". (Why bother? With a good reference document, you can write and test programs in your head. Implementation is tedious; I only want to do that once.) The answer in this case seems likely to be: Jose started fiddling around with it, and at the same time was learning what he could and could not do on Erlang's VM. I guess I take a favorable view of experimentation and a dimmer view of being able to plan everything ahead of time. At some point in time, things need to be stabilized, but at the beginning, some contact and pushback from the real world and real usage may well impact the design of a system.

aninhumer 14y ago

> monadic I/O is one of the silliest contortions I've seen (uniqueness types in Mercury and Clean are much easier to work with) As far as I can see they're all basically the same thing. You enforce sequence by creating a chain of notional "real world" values. I can't say I've used Clean or Mercury extensively, but as far as I can see they just make you pass around that value explicitly. That doesn't really seem like it would be "easier to work with".

ralfn 14y ago
> That doesn't really seem like it would be "easier to work with". 1. You dont need monadic versions of all non monadic functions. You dont need fmap, you can just use map. 2. It means there is a well defined order of execution (i.e. The order does not "emerge" as in Haskell, instead it is defined and verified by type system) It is much much easier to work. In Haskell you feel forcedto separate io from transformation as much as posible. Often you end with either repeating ourself a lot (writing oth mondic as non monadic versions) ir you venture out in monad transformers, which imho is the "goto" of Haskell. (How to turn your code in unreadable unmaintainable spagetti). The cognitive overload is never worth it. Ps. Uniqueness types are not just about IO. Rust uses them as well. They are about sharing. Haskells needs an IO () type because without a monad it has no defined order of execution, and it cant prevent you from "forking the world" when working with outside references. If Haskell could prevent you (by using uniqueness) i doubt they would have used monads for IO. (Although they can be usefull in other areas).