The forced moratorium of 2001-2006 was also prime time for innovation in Flash. It’s going to happen one way or another.
I’ve got a lot of respect for Haskell, but this seems like a truly complicated way to solve a simple problem.
Never mind that as soon as you want to add some tuning parameter to your config file, you’re going to need to either thread an effect type through your entire program or perform some other equally non-trivial refactor. Double nevermind having to compose monads with a transformer stack.
At least Idris offers the bang! effect notation (which probably requires strictness to be sane) built on extensible effects. Haskell version of the Eff type here: http://www.cs.indiana.edu/~sabry/papers/exteff.pdf - That’ll at least alleviate the monad transformer stack madness.
yeah, i think this is also a really bad example; it seems infinitely nicer to not pass a big amount of state to various functions, but simply the little bits and pieces that each small function needs in order to do its work (in this case).
Forgive me, I didn’t read the article but I have used extensible-effects in Haskell and I highly recommend it.
We’re seeing again and again that we’re not seeing Lisp as the language for object-oriented programming, or Haskell, or Erlang, which are all incredible languages on the server, but haven’t fit well to these ideas.
The problem OOP solves is code organization. It gathers like functions and data together in the same place. It’s somewhat intuitive because real world objects mostly work this way - alike things are usually gathered together. There are many downsides to this approach as well, but we as programmers have become used to them. Not knowing any other way we assume these difficulties are intrinsic to programming. There’s nothing keeping functional systems from comprising graphical interfaces, but organizing code as objects makes less sense in functional languages. I think Aaron misses a bit on that note.
Modern GUIs were invented in imperative languages and all the tactics and patterns used to create GUIs are tightly coupled with OOP. I think we are in functional GUI’s infancy right now and in the next coming years we’ll see functional solutions that are easier to work with than their OO counterparts. The biggest hurdle is lack of supporting libraries in computational geometry (spatial maps, triangulating/decomposing polygons, etc). We’re getting there though and the concepts are new and exciting, at least in my opinion.
This sounds really cool. I wish there were some more examples though.
Oh, and I know if anyone actually reads this post, they are going to ask “Why not Haskell?”, and my response is that Haskell is a great language but it isn’t going to become a mainstream language any time soon (or ever).
The author started the paragraph with “So I’ve been looking for a language to replace Python” however near the middle of the paragraph it seems they are actually looking for Yegge’s NBL. Even then, later in the article the author considers Smalltalk and Scheme as “big” and “mainstream” languages.
In case the author seriously doesn’t consider Haskell a viable language because it isn’t mainstream: since when does a language need to be mainstream to be usable?
Yes, and how many people have to use a Lang for how long before the author considers it mainstream?
Good post :)
I’ve been learning going on 3 years. I started with the 99 Haskell problems, LYAH and RWH. I think the biggest help I’ve had so far has been getting on irc.freenode.net’s #haskell, #haskell-game and #haskell-beginners. Actually being able to talk to someone helps a lot. Thanks guys!