5 ms·

> the idea that every Rails programmer will be switching to Clojure or Elixir! [...] I don't see any 10x advantages [...] I do. While I cannot speak for Clojur

by cies 12y ago

> the idea that every Rails programmer will be switching to Clojure or Elixir! [...] I don't see any 10x advantages [...] I do. While I cannot speak for Clojure and Elixir, I can speak for Haskell, which I have moved to from Rails. 10x for me is: 1. A 70MB all-in binary to deploy, using 1-3MB of memory when running (has a build in HTTP(S) server), responding in 2-10ms to my requests. Compare that to 700-1500MB of gems, using hundreds of MB while running, serving requests in 50-200ms... More then 10x! And my framework of choice (Yesod) consists of 23kLOC, where Rails has 210kLOC (source: openhub.net)... Another 10x! 2. Less bugs when growing the codebase; "strong compile time guarantees" is now my main weapon when fighting maintenance curve. Back in my Rails days I'd say "typing is a very narrow form of automated testing", which given my exposure to C++/Java was defendable opinion. Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time. TL;DR: I believe 10x frameworks are out there.

ionforce 12y ago
But isn't that like saying a healthy person can run 10x faster than someone with a limp? For context, my background has been predominantly in a dynamic language, but now I've drank all the typed kool-aid, so I'm sold, as it seems you are as well. So we're essentially saying typed is 10x better than dynamic, but was dynamic ever really a good place to start with?
- cies 12y ago
  I'd say dynamic has its place. Especially Ruby since it can serve as a stepping stone for the imperative-minded into functional. > typed is 10x better than dynamic 10x what? Rails' community is many-x larger then Yesod's, in that case dynamic wins. :)
- chipsy 12y ago
  Dynamic has a nice exploratory quality. It pushes off the moment of reckoning, but sometimes you need that if you're sketching an idea in code. It was good for me when I first learned, and I think that's still true now. For "in the large" systems it's basically required that stuff gets a bit more gooshy and dynamic-y and interact in an indirect, protocol-driven fashion. But when you actually have a specific piece of engineering in mind, it's nowhere near as helpful - it tends to solve things that could probably be solved more soundly with compile-time constructs. But there's a process of building up your understanding to where you can actually have confidence in what you're building, which isn't reached so easily. Having the compiler fail your code before it can run is very "magical" in that sense.
jarrettc 12y ago
Strong typing on the web has been an intractable problem for me so far. Sure, I can have strong typing in my server-side code. But so many errors result from the interaction between the server, CSS, HTML, and JS. For example, you define a route at the path `/apples` but send an AJAX request to `/oranges` instead. Or you write `<div class="apples">` but query it with `div.oranges` instead. These are very much like type errors or name errors, except they occur at the boundaries of languages and processes. Have you worked out a way to catch these sorts of things at compile time? If not, do you think it's possible in the framework of the future?
- tel 12y ago
  Haskell has some typesafe template languages. I'm not a huge fan of them, tbh, as they're kind of rough at the moment. More promising in my opinion is the fact that Javascript is becoming an increasingly popular backend for Haskell via GHCjs which will give a great space for building type-checked front ends which have all the guarantees you like. For instance, type checked routes already exist which prevent you from writing the wrong endpoints or sending invalid typed data to them... these can be transparently extended to the frontend without much more difficulty.
- dragonwriter 12y ago
  The examples you give don't seem to be typing problems, they seem to be wrong-value problems. They might incidentally also involve typing issues (e.g., "/oranges" might not exist or might be an endpoint with a different signature than "/apples"), but that doesn't seem to be the central problem in any of the examples. > Have you worked out a way to catch these sorts of things at compile time? If not, do you think it's possible in the framework of the future? To the extent that they are typing problems, it would seem conceptually possible to catch them through a strongly typed language and framework that abstracts all the underlying technologies and compiles to a combination of backend executable(s), and front-end HTML, JS, and CSS, and includes all the routing for both ends. Actually building such a beast would seem to be a non-trivial engineering challenge.
  - dllthomas 12y ago
matthewmacleod 12y ago
I'm not sure that reduction in code size or better performance is necessarily the 10x metric you want to go for. Maybe in some cases, of course, but 'my framework has fewer lines of code' is absolutely irrelevant to the delivered value of a service, for example. Does using Yesod mean that you can deliver code that better meets your goals? In a business environment, that might mean easier maintenance, or better performance. Equally, it might mean faster development times, where maintenance is less of a priority. If it meets your goals then awesome! If it doesn't, then there are lots of other things you can use – including Rails.
- cies 12y ago
  Often goals are: crank out X with programmers Y on deadline Z. I assume the client has no language/framework preference. If X is a greenfield webapp and Y are not Haskellists yet (language has a steeper learning curve then, for instance, Ruby), and Z is very soon then I will probably choose Rails (given that programmers have some experience with dynamic languages and/MVC framework, and I'm fluent with Rails). Notice that maintenance costs are not a factor. This is often not accounted for, but a large part of a webapp's costs are maintenance: and this is where Haskell shines: maintenance and refactoring. Let's say I'm starting up, then low maintenance costs are of PRIME importance. You want to be able to keep adding/improving with a small team, not being bogged down by an endless stream of bugs only found on production -- nothing ruins flow like that.
YorickPeterse 12y ago
> Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time. Ruby is strongly typed.
- ssmoot 12y ago
  That's true. But in practice I've come to the idea it's a meaningless distinction if you're not going to bother to declare the types on your methods/functions. Instances may be Strongly typed in Ruby. Methods are not. So you get almost none of the benefit. It's like Types only exist in Ruby to support Mixins and inheritance chains. Prefer Composition over Inheritance right? But what if through Composition you effectively lost all your Type information? That's the issue Ruby presents.
  - YorickPeterse 12y ago
    > Instances may be Strongly typed in Ruby. Methods are not. Sure they are, just not all of them: [].first('wat') # => TypeError: no implicit conversion of String into Integer What Ruby lacks is _static typing_ and compile time checks of these types. Instead we have runtime checks in a few places. > Prefer Composition over Inheritance right? But what if through Composition you > effectively lost all your Type information? That's the issue Ruby presents. This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour. For example: class MyArray < Array end m = MyArray.new([10, 20, 30]) p m.map { |number| number * 2 }.class # => Array Here one would probably expect an instance of MyArray to be returned, but instead we get a vanilla Array.
    - oh_sigh 12y ago
      Why would you expect that if you didn't implement map in MyArray?
    - yxhuvud 12y ago
      > This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour No. It is advocated because it produces simpler code in the long term in most cases. It is a quite different question to inheritance from core classes.
thothamon 12y ago
As a Haskell programmer who has also come from Rails -- I'm a Rails developer now -- and who is also interested in writing a web app in Haskell, I'm very interested in your experiences. Are you on any forums or online communities that have helped you in developing a Haskell web app?
- cies 12y ago
  No, just started to use Yesod to do simple things. Then moved on to hard things. Sure I'm on relevant mailinglists and /r/haskell; but apart form that no special community forum helped me.
- cies 12y ago
  What would you like to know about my experiences? Please ask your questions, I'll answer :)
  - thothamon 12y ago
    Well, I haven't started my web app yet. Right now I'm finishing up a Haskell app that plays Connect Four: maybe that could be the backend for a web app. It looks like you're using Yesod. What resources did you use to learn it -- I think there's a Yesod book, was that helpful? Did you consider any other Haskell frameworks? What did you find hard about writing an app using Yesod? Do you think it took less time to write the app than it would have given a similar level of knowledge about Ruby/Rails? Although I'm way faster writing Haskell than I was, say, six months ago, I feel I'm still really slow compared to how fast I can code in Ruby. Having said that, when I write a Haskell program, the only errors are usually logic errors, not process errors. NoMethodError (an unexpected nil) must be one of the most common Ruby/Rails errors. It's really great to just not get that anymore. :-)

by cies 12y ago

ionforce 12y ago

But isn't that like saying a healthy person can run 10x faster than someone with a limp? For context, my background has been predominantly in a dynamic language, but now I've drank all the typed kool-aid, so I'm sold, as it seems you are as well. So we're essentially saying typed is 10x better than dynamic, but was dynamic ever really a good place to start with?

cies 12y ago
I'd say dynamic has its place. Especially Ruby since it can serve as a stepping stone for the imperative-minded into functional. > typed is 10x better than dynamic 10x what? Rails' community is many-x larger then Yesod's, in that case dynamic wins. :)
chipsy 12y ago
Dynamic has a nice exploratory quality. It pushes off the moment of reckoning, but sometimes you need that if you're sketching an idea in code. It was good for me when I first learned, and I think that's still true now. For "in the large" systems it's basically required that stuff gets a bit more gooshy and dynamic-y and interact in an indirect, protocol-driven fashion. But when you actually have a specific piece of engineering in mind, it's nowhere near as helpful - it tends to solve things that could probably be solved more soundly with compile-time constructs. But there's a process of building up your understanding to where you can actually have confidence in what you're building, which isn't reached so easily. Having the compiler fail your code before it can run is very "magical" in that sense.

jarrettc 12y ago

Strong typing on the web has been an intractable problem for me so far. Sure, I can have strong typing in my server-side code. But so many errors result from the interaction between the server, CSS, HTML, and JS. For example, you define a route at the path `/apples` but send an AJAX request to `/oranges` instead. Or you write `<div class="apples">` but query it with `div.oranges` instead. These are very much like type errors or name errors, except they occur at the boundaries of languages and processes. Have you worked out a way to catch these sorts of things at compile time? If not, do you think it's possible in the framework of the future?

tel 12y ago
Haskell has some typesafe template languages. I'm not a huge fan of them, tbh, as they're kind of rough at the moment. More promising in my opinion is the fact that Javascript is becoming an increasingly popular backend for Haskell via GHCjs which will give a great space for building type-checked front ends which have all the guarantees you like. For instance, type checked routes already exist which prevent you from writing the wrong endpoints or sending invalid typed data to them... these can be transparently extended to the frontend without much more difficulty.
dragonwriter 12y ago
The examples you give don't seem to be typing problems, they seem to be wrong-value problems. They might incidentally also involve typing issues (e.g., "/oranges" might not exist or might be an endpoint with a different signature than "/apples"), but that doesn't seem to be the central problem in any of the examples. > Have you worked out a way to catch these sorts of things at compile time? If not, do you think it's possible in the framework of the future? To the extent that they are typing problems, it would seem conceptually possible to catch them through a strongly typed language and framework that abstracts all the underlying technologies and compiles to a combination of backend executable(s), and front-end HTML, JS, and CSS, and includes all the routing for both ends. Actually building such a beast would seem to be a non-trivial engineering challenge.
- dllthomas 12y ago

matthewmacleod 12y ago

I'm not sure that reduction in code size or better performance is necessarily the 10x metric you want to go for. Maybe in some cases, of course, but 'my framework has fewer lines of code' is absolutely irrelevant to the delivered value of a service, for example. Does using Yesod mean that you can deliver code that better meets your goals? In a business environment, that might mean easier maintenance, or better performance. Equally, it might mean faster development times, where maintenance is less of a priority. If it meets your goals then awesome! If it doesn't, then there are lots of other things you can use – including Rails.

cies 12y ago
Often goals are: crank out X with programmers Y on deadline Z. I assume the client has no language/framework preference. If X is a greenfield webapp and Y are not Haskellists yet (language has a steeper learning curve then, for instance, Ruby), and Z is very soon then I will probably choose Rails (given that programmers have some experience with dynamic languages and/MVC framework, and I'm fluent with Rails). Notice that maintenance costs are not a factor. This is often not accounted for, but a large part of a webapp's costs are maintenance: and this is where Haskell shines: maintenance and refactoring. Let's say I'm starting up, then low maintenance costs are of PRIME importance. You want to be able to keep adding/improving with a small team, not being bogged down by an endless stream of bugs only found on production -- nothing ruins flow like that.

YorickPeterse 12y ago

> Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time. Ruby is strongly typed.

ssmoot 12y ago
That's true. But in practice I've come to the idea it's a meaningless distinction if you're not going to bother to declare the types on your methods/functions. Instances may be Strongly typed in Ruby. Methods are not. So you get almost none of the benefit. It's like Types only exist in Ruby to support Mixins and inheritance chains. Prefer Composition over Inheritance right? But what if through Composition you effectively lost all your Type information? That's the issue Ruby presents.
- YorickPeterse 12y ago
  > Instances may be Strongly typed in Ruby. Methods are not. Sure they are, just not all of them: [].first('wat') # => TypeError: no implicit conversion of String into Integer What Ruby lacks is _static typing_ and compile time checks of these types. Instead we have runtime checks in a few places. > Prefer Composition over Inheritance right? But what if through Composition you > effectively lost all your Type information? That's the issue Ruby presents. This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour. For example: class MyArray < Array end m = MyArray.new([10, 20, 30]) p m.map { |number| number * 2 }.class # => Array Here one would probably expect an instance of MyArray to be returned, but instead we get a vanilla Array.
  - oh_sigh 12y ago
    Why would you expect that if you didn't implement map in MyArray?
  - yxhuvud 12y ago
    > This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour No. It is advocated because it produces simpler code in the long term in most cases. It is a quite different question to inheritance from core classes.

thothamon 12y ago

As a Haskell programmer who has also come from Rails -- I'm a Rails developer now -- and who is also interested in writing a web app in Haskell, I'm very interested in your experiences. Are you on any forums or online communities that have helped you in developing a Haskell web app?

cies 12y ago
No, just started to use Yesod to do simple things. Then moved on to hard things. Sure I'm on relevant mailinglists and /r/haskell; but apart form that no special community forum helped me.
cies 12y ago
What would you like to know about my experiences? Please ask your questions, I'll answer :)
- thothamon 12y ago
  Well, I haven't started my web app yet. Right now I'm finishing up a Haskell app that plays Connect Four: maybe that could be the backend for a web app. It looks like you're using Yesod. What resources did you use to learn it -- I think there's a Yesod book, was that helpful? Did you consider any other Haskell frameworks? What did you find hard about writing an app using Yesod? Do you think it took less time to write the app than it would have given a similar level of knowledge about Ruby/Rails? Although I'm way faster writing Haskell than I was, say, six months ago, I feel I'm still really slow compared to how fast I can code in Ruby. Having said that, when I write a Haskell program, the only errors are usually logic errors, not process errors. NoMethodError (an unexpected nil) must be one of the most common Ruby/Rails errors. It's really great to just not get that anymore. :-)