5 ms·

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

by deno 16y ago

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

thesz 16y ago
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]. [1] http://www.ok-labs.com/ http://www.ok-labs.com/ [2] http://lambda-the-ultimate.org/node/4197 http://lambda-the-ultimate.org/node/4197
rickmode 16y ago
Correct me if I'm wrong but it seems you mean "statically typed" instead of "strongly typed". PHP is weakly typed. Common Lisp, Clojure, Haskell and OCaml are strongly typed. PHP is dynamically typed, Haskell and OCaml are statically typed. That said I would like to learn more about these statically typed functional languages.
- deno 16y ago
  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.
  - philwelch 16y ago
    "type annotations enforced by static analysis" Isn't that the definition of static typing?
    - deno 16y ago
      I suppose. However, I didn't specify that in terms of static/dynamic typing because I don't find that definition very useful. On the hindsight the better term to use was probably just “type safety.”
spitfire 16y ago
Welcome back to client server computing!
- deno 16y ago
  Ah, yes. We made it, indeed, a full circle. Quite sad, if you think about it…
  - spitfire 16y ago
    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.
    - johnzabroski 16y ago
      RE: You don't have to lay out your GUI's with a markup language designed for typography - The modern VT100. Are you referring to HTML and CSS? RE: You don't have to keep state with a stateless protocol. You are referring to HTTP. RE: Now you get a nice (mostly) standardized interface and you get to build a lighting fast native GUI for your app. What are you referring to?
    - deno 16y ago
      It's good online programming becomes sane again. 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.
      - johnzabroski 16y ago
johnzabroski 16y ago
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.
- deno 16y ago
  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. Hope this clarifies my position :)
dasil003 16y ago
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.
- 6ren 16y ago
  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.

by deno 16y ago

thesz 16y ago

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]. [1] http://www.ok-labs.com/ http://www.ok-labs.com/ [2] http://lambda-the-ultimate.org/node/4197 http://lambda-the-ultimate.org/node/4197

rickmode 16y ago

Correct me if I'm wrong but it seems you mean "statically typed" instead of "strongly typed". PHP is weakly typed. Common Lisp, Clojure, Haskell and OCaml are strongly typed. PHP is dynamically typed, Haskell and OCaml are statically typed. That said I would like to learn more about these statically typed functional languages.

deno 16y ago
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.
- philwelch 16y ago
  "type annotations enforced by static analysis" Isn't that the definition of static typing?
  - deno 16y ago
    I suppose. However, I didn't specify that in terms of static/dynamic typing because I don't find that definition very useful. On the hindsight the better term to use was probably just “type safety.”

spitfire 16y ago

Welcome back to client server computing!

deno 16y ago
Ah, yes. We made it, indeed, a full circle. Quite sad, if you think about it…
- spitfire 16y ago
  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.
  - johnzabroski 16y ago
    RE: You don't have to lay out your GUI's with a markup language designed for typography - The modern VT100. Are you referring to HTML and CSS? RE: You don't have to keep state with a stateless protocol. You are referring to HTTP. RE: Now you get a nice (mostly) standardized interface and you get to build a lighting fast native GUI for your app. What are you referring to?
  - deno 16y ago
    It's good online programming becomes sane again. 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.
    - johnzabroski 16y ago

johnzabroski 16y ago

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.

deno 16y ago
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. Hope this clarifies my position :)

dasil003 16y ago

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.

6ren 16y ago
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.