It seems to me that strongly-typed languages—functional or not—are going to make a strong comeback to web development. The current trend is to narrow down your webapp to a REST[ful] API. Any HTML you generate is only to bootstrap your client-side application (and load initial state) and to accommodate non-JS-enabled clients, which in this date and age should only mean search engine spiders.
The advantage is a uniform interface, like a file-descriptor in Plan-9 (an analogy used in latest InfoQ interview with GO/Newsqueak creator), the HTTP protocol.
And for that, languages like OCaml or Haskell should flourish. Especially functional languages, since typical REST API request should be nothing but data+auth token (whether that's cookie or oauth token).
Applications developed in that model—besides being much simpler to write and test—are easily cacheable and more secure by default. The added bonus is that object oriented languages, that have been most successful in GUI programming, can be once again utilized purely for that.
If not embracing this model one is left with little appealing options: 1) continue to process text in perl-like manner with RoR/Django/etc., coping with nondeterministic behavior and security 2) to invest in frameworks that hide HTTP at all, coding to widgets instead of pages, and to let framework decide how to push that over the wire, which usually means that some sort of continuations are employed, which are inherently HTTP-unfriendly and uncacheable outside of the app's context 3) to replace HTTP with something else, probably some sort of RPC
It would be really nice if significant resources went into web development into functional languages. I think it's clear that the rigor enforced by Haskell's type system (for instance) solves a ton of real world problems; and if enough resources were dedicated to it that it could dramatically increase the quality of web software without paying a huge premium in development time.
But the opposing force is the need to ship quickly, and languages like Ruby are highly optimized to this goal, and thus they attract a lot of the best developers who spend time increasing the ability to ship quickly with Rails. This gives an ongoing advantage, where new startups have to look at the potential library and framework disadvantage when they're evaluating more powerful functional languages. The cost of the extra bugs is hard to factor in, partially because you never see all of them, and much of that code may be discarded before you have to pay the price of a bug anyway.
Due to this dynamic, as well as the fact that imperative programming requires less training and mental rigor, I think functional languages have an uphill battle. I hope I'm wrong, which may happen if enough Rails apps flame out spectacularly enough to bring down their companies, and people realize what a ticking time bomb you can create with loosely-typed languages if you're not careful.
Exactly right. Saying it another way: the market doesn't demand what ocaml offers.
The market demands different qualities at different times (and in any market, there will often be niches that need different qualities from the rest of the market). The "market" is probably best represented by paying customers, but other parties (managers, developers and users in general) also have an effect. What does the market demand at the moment?
It seems that at the moment, time-to-market (i.e. fast development) is most in demand. This includes being "agile": able to add features quickly, improve them or change them, and to debug them. This is driven by development speed, which can decrease both time-to-market and development costs (and therefore customer price). Other qualities, like performance (runtime speed) and memory usage seem less important. Reliability seems less important.
However, there are different parts of the market that value these differently. For example, the financial market value correctness, so it's not surprising that ocaml has found a home in janestreet. Space shuttle software also does. I would say that in desktops, quadcore, 4GB RAM performance now outstrips what many people need, resulting in the hiccup of "netbooks", and finally the smartphones - much less powerful, but customers are willing to buy them because they offer convenience.
Within smartphones, performance of software became important again, because within the category (given convenience) the hardware hasn't yet outstripped demand for it.
Another example is in MS Windows, when it first got an adequate GUI interface in windows 95, people bought it in droves even though it was buggy and unreliable. Then, combining it with NT in Windows XP, it became reliable, and people bought that. Then, security was the issue, and that got fixed. It may seem a little surprising that Windows 7 is popular, but one thing is that all those books and sites about "windows annoyances" mean that there's room for windows to improve... which means they can sell another version. If it no one complained because it was perfect, that would be bad news for microsoft. (of course, their run may be over now, if smartphones replace the desktop, and they can't win that market away from apple).
Now, just because development speed has been important for a while doesn't mean it always will be. Reliability and performance may become more important again, especially in niche markets. And it is there that ocaml may have an opportunity.
But meanwhile, although ocaml is amazing in that it has the expressiveness of functional programming, the correctness of strong typing, and the performance of C, it is a double straightjacket language: first it has to be functional (though you can mutate, it's not as nice); then it has to be strongly typed. You can't just code it they way you think about it. You have to adapt yourself to the machine. (note: this is based on my personal experience with ocaml).
tl;dr
OCaml has many benefits, which I don't question. What I am saying is that the mainstream market doesn't currently value those particular benefits of ocaml over other attributes.
I meant strongly typed. My previous post works just as well with for example Python 3 or Erlang code with type annotations enforced by static analysis.
I was trying to make point that simple nature of REST protocol makes it possible to write webapps ‘guaranteed’ to be correct, at least server-side.
Your view of how to solve problems seems very programmer-oriented and not business-oriented.
Stuff like how to process a REST request is simply details. I don't understand why you are focusing so much on this aspect, but I have seen this anti-pattern so often that it repulses me; most examples of RESTful APIs are bullshit, written by people who did not take the time to actually understand REST principles. A good example I documented on my blog is how awful and stupid the ThreeSharp Amazon S3 library is for C#. And writing it in the same style in F# would be just as ugly and stupid! I also discuss why it is a joke that S3 itself is called a REST API, and point out how the language examples in Amazon's documentation is COMPLETELY inconsistent from language to language -- there is no correctness-preservation across language implementations!!!
Incidentally, when people say "web development", they can mean many things, with True REST being just one of them. Most people are actually referring to corporate intranet applications, such as data entry forms and stock analysis tools that chart trends, provide real-time data feeds, etc.
Well REST and RESTful are at this point mostly buzzwords. I'd be happy to just use “Correct-HTTP” instead of REST and “Correct-HTTP+hyperlinks” instead of RESTful, especially since no one actually uses REST or RESTful when describing things, that do work by exchanging representations, outside of HTTP and webapps context.
I don't actually get what there is relevant about any possible business-oriented perspective you mention at the beginning. Actually, you have allocated most of your comment for advertising your blog…
As to your last paragraph, there's nothing like True REST etc. I'm not buzzword happy and I don't generalize things like that, as you can see in my other comments anyway. I wasn't referring to all those irrelevant things you've mentioned. My observation was that most web development—of various sort—was done by keeping state server-side. That approach is fine as long as you don't have multiple pieces of independent logic on one page. In that case the whole thing becomes complicated—you can either 1) use text-processing techniques, which is my hypothesis for why languages like PHP, Python and Perl are so popular for webdev or 2) abstract stateless HTTP protocol away, which results with very unfriendly and difficult to scale artifacts, like continuations.
The separations of concerns: server logic and presentation, that is possible by properly utilizing HTTP and by having powerful enough client-side environment (Javascript VMs) enable for a much saner approach, and that's why I think strongly typed languages are relevant for web once again.
> Actually, you have allocated most of your comment for advertising your blog…
Sorry if it came across that way. I really don't check who reads my blog, there is no comment mechanism, and I do not like linking it anywhere except to friends. Even then, I prefer they not read it directly. My blog is mainly a personal thought dump and collection of links.
I think they are strong anywhere you need dependable core of the system.
I see it as a trend, actually, statically typed languages grew stronger in various fields, from operating system kernels [1] to web development and shell scripting [2].
I still like that analogy of REST to Plan-9's everything-behaves-like-file. It put it for me in an entirely different perspective. Sure enough, everything seems to have HTTP/RESTful API nowadays—maybe the total uniformity and transparency envisioned by Plan-9 creators is not so far away?
I love it. We're done with the "ZOMG WEB!" thing. You don't have to lay out your GUI's with a markup language designed for typography - The modern VT100. You don't have to keep state with a stateless protocol. Now you get a nice (mostly) standardized interface and you get to build a lighting fast native GUI for your app.
I can't wait to see what people cook up over the next five years. Particularly with the trend towards tablet computers.
Right, all you have to do is choose between a number of incompatible GUI platforms which are not standardized and all of which have an uncertain future, including the possibility of eventually be swallowed up by HTML/CSS/JS whose progress and growth is inexorable due to its openness and ubiquity. Good luck!
I see you're actually eager to make a full leap from 'WEB' to native apps. I don't disagree, but I think REST+DOM/JS will still have its place there. A lightweight alternative to full-blown applications, interactive documents that load in the blink of an eye and transparently integrate with your ecosystem. I guess it's what web was supposed to be in the first place, but with some added zing.
If by 'REST+DOM/JS' you mean "Random Bad, Hodge-Podge Code Filled with Callbacks and pervasive use of global variables", then yes, bad programming will always have a place - for PHP programmers.
Most really awesome apps being written these days, that use HTML, are using the CANVAS tag and doing stuff like building terrain maps of buildings and showing people holding 4.5" smart phones where in the building druglords are. Crazy stuff like that.
Actually I never did web apps. I keep looking at it and just cringing. I'd be alcoholic if I had to suffer web programming, knowing that the pain is self inflicted.
Still I am jealous of the numerical advantage the web gives people. The iphone/ipad ended that though.
Do you know what ODBC is, and why most smart programmers dislike it and try to stomp out its stupidity?
The model for writing drivers, and plugging in drivers, in ODBC, is R. E. T. A. R. D. E. D.
Edit: I forgot to mention that using the drivers suck, too. The ODBC transaction interface is basically RPC, and is becoming out-moded with recent language research on remote batch execution.
Usually, you have a custom transport protocol for client/server, like the Microsoft SQL Server Tabular Data Stream protocol. It is ultimately not very extensible. Imagine something like LINQ today. Would be nice to just send that expression tree to SQL Server, and not have a client-side or middle-tier ORM tool have to transform the tree into SQL.
The advantage is a uniform interface, like a file-descriptor in Plan-9 (an analogy used in latest InfoQ interview with GO/Newsqueak creator), the HTTP protocol.
And for that, languages like OCaml or Haskell should flourish. Especially functional languages, since typical REST API request should be nothing but data+auth token (whether that's cookie or oauth token).
Applications developed in that model—besides being much simpler to write and test—are easily cacheable and more secure by default. The added bonus is that object oriented languages, that have been most successful in GUI programming, can be once again utilized purely for that.
If not embracing this model one is left with little appealing options: 1) continue to process text in perl-like manner with RoR/Django/etc., coping with nondeterministic behavior and security 2) to invest in frameworks that hide HTTP at all, coding to widgets instead of pages, and to let framework decide how to push that over the wire, which usually means that some sort of continuations are employed, which are inherently HTTP-unfriendly and uncacheable outside of the app's context 3) to replace HTTP with something else, probably some sort of RPC