For information rich applications (ie. B2B-ish), definitely ExtJS. Pretty steep learning curve since, unlike jQuery UI, you sorta have to take all of nothing. We use ExtJS everywhere where using data/information is more important than look-n-feel. Put together CoffeeScript (http://jashkenas.github.com/coffee-script/) with ExtJS and you'll be in RIA dev heaven. Fast and very productive.
For applications where look-n-feel, customization, etc is more important (ie. B2C-ish or consumer internet), HTML/CSS/jQuery is the way to go.
IANAL but it seems as though a lawsuit would be filed pretty quickly if Apple blocked Adobe's interpreted apps and didn't block Rhomobile/Unity3D/MonoTouch interpreted apps. Seems fair to block possibly harmful technologies, not competitive competitors.
We all got pissed at Microsoft when they were giving themselves preferential treatment, but what if Microsoft had said "eeerrrrmmm, Wordperfect is no longer welcome on Windows, but AbiWord is okay".
Okay, I'll bite. What law is being violated by Apple deciding who they wish to partner with and selectively give advantages (and disadvantages) to.
What an amazing number of people (hackers included) don't understand from the 1999 ruling against Microsoft, is that Microsoft was ruled a Monopoly. Now that, per se, is certainly not illegal, but once you are a Monopoly, a large number of activities that previously were allowed, all of a sudden are now restricted. In the case of Microsoft, it was attempting to leverage a Monopoly in one market (Operating Systems) to takeover another one (Browsers).
Apple is so, so, far away from being a Monopoly in any market that it's laughable. Profitable - yes. But I think they have like something of 25% of Market Share for Smart Phones, and less than 3% of the market for Mobile phones. And Android is aggressively courting developers/users who are interested in their Open and flexible platform.
So, no - Apple is completely free to disallow competitors, and put them at a disadvantage, while allowing the Unity/Rhomobile's of the world.
Agreed that, in some senses, I was trying to force a square peg into a round hole, but the comments on my blog suggest that others share my experience and they're mostly from planet.haskell.org. So I think something is missed if my experience is entirely chalked up to ignorance.
My post was written fairly quickly and got more attention than I expected. Looking at it again and looking at Turbinado's code, I can see how you could suggest that I don't understand monads. And I probably don't understand them to your level, but the code reflects the result of trying to compose together a number of libraries into a sensible system. Wrapping those libraries in composed monad transformers was vastly more complicated than just dropping down to the IO monad, so I stripped down...
w.r.t monads: they're lovely for constraining code behavior and for building DSLs, so other languages have added monad libraries. They haven't forced the entire language to live within monads...
w.r.t incremental data structures: I mentioned in my post that I wasn't happy with multiple data types. Multiple constructors sound even less productive. Currying is a solid suggestion.
I don't disagree that the reasons are shallow, but it turns out that solving some problems in Haskell is just plain hard. It's precisely because the issues/reasons are basic that it's hard...
Also, I'm confused by your comment about the IO monad & logging... How would you log outside of the IO monad?
Would also be cool if you'd point me to your Haskell repo. I'd be curious to see how you solve these problems.
Can you clarify? I thought that keeping separate streams of side effects is not possible when one stream influences the other. The logging process depends on what actions happen in the IO sequence though not the other way around. Are you talking about keeping the normal IO actions in one monad, logging actions in another & then composing the two into an outer IO monad?
It depends on what you're logging. Pure code can keep its own log in Writer and then depose the whole thing to the IO logger later. Since there's no guarantee of the timing or synchronicity on non-IO code, this works well.
That's what I agree with: Haskell nearly requires programmers to read papers each time they want to solve a new problem [1]...
For the logging, I mean of course you can't be ultimately outside the IO Monad, but I don't like putting many things directly into it, if so I would prefer using the writer monad, or an additional argument, or something... I'm sorry though i don't have any public repo, I'm more of a lazy tinkerer...
Edit: [1] But I would like to add that there is also cultural bias of our comp-sci education, otherwise C++ can sometimes also be quite harsh...
Because it's conceptually different from what we learn, and semantically very rich. You have many 'aha!' moments, seeing that an abstraction corresponds to a really better way to solve a problem.
And because it's research oriented: maybe a simpler language with 80% of Haskell benefits will emerge out of it once those concepts have matured in Haskell.
And maybe mostly because people learning Haskell do it by curiosity, so they'd like to explore the best way to do it, not being under their boss/client 's pressure.
For applications where look-n-feel, customization, etc is more important (ie. B2C-ish or consumer internet), HTML/CSS/jQuery is the way to go.