4 ms·

No, it can't. Haskell is not a prototyping language. Ruby (and more generally dynamic languages like PHP/Python) are and Rails like frameworks are amazing tool

No, it can't. Haskell is not a prototyping language. Ruby (and more generally dynamic languages like PHP/Python) are and Rails like frameworks are amazing tools for prototyping when you don't know what you are building, need to iterate quickly, and need to prove out an idea. Dynamic languages are great for building things that are very dynamic, things that are in fact a kind of prototype. Haskell and other languages with things like type checking and compilers and so on are designed to be safer, smarter, and are better long term for projects where the cost of complexity and maintenance are more significant and the development investment will get a payback. If you don't know if a project is going to work, you shouldn't spend a huge investment to find out if it will work. So, use a tool like Wordpress, Drupal, Rails, Django, etc. to build out the minimum viable thing that you can build to prove out the idea and see if there is a real business there. Once you prove out the prototype and you know it is going to be a long term project that can pay for itself in terms of ongoing development investment, you need to throw the prototype away and build it with a tool like C#, Go, Java, Haskell, etc. Most projects never realize they are no longer a prototype and should no longer be written in a prototyping language. Thus, you get all of the problems that come with a prototype without a lot of the solutions that we already have for solving them like compilers and such. Interestingly, if you use a tool like Rails, there is enough there that you can get far past the point of a prototype before realizing it is no longer the right tool for the job. This is evidenced by the fact that there are now a ton of people talking about large project OOP and structure in Ruby and Rails, without them realizing that it's always going to be an uphill battle in Ruby because of the language itself. So, if the question is if Haskell can be the next great prototyping language, then I don't think it is. If the question is if Haskell can be the language that you could migrate a project to after you realize it's no longer a prototype, then yeah it might be. Building a large production product with long term maintenance and scaling needs in a prototyping language is very likely a bad idea and is probably why there are so many projects that start to be really difficult in dynamic languages after they reach a certain size.

cordite 13y ago
Sure, the type checker forces you to think more when you are actually typing. It makes up for being easy and rapid to refactor, repurpose, and reuse--arguably making it competitive to prototype with.
- programminggeek 13y ago
  I actually agree, but I don't think most people do and there are times when static typing isn't as much fun - like say pulling data from an API and shoveling it on to a page or through some filtering or something like that or just doing some random UI manipulation with jQuery or the like. Most developers see the pain and are given a deadline and so they do it dirty and hope to have a chance to pay downy that technical debt later. Later almost never happens until the system crashes beyond repair and the instability starts costing money in the form of downtime. In the grand scheme of things, maintenance is always the most expensive part of a system, but "prototyping" languages that aren't particularly safe or maintainable are inherently going to be more expensive to maintain and deal with over the long term. Ironically, dynamic languages like Ruby have taken the route of getting really good at unit testing and TDD instead of investing in moving their codebases from "prototypes" to "production" or "LTS" or whatever you would want to call a mature, complex codebase that will need to be maintained and evolved over time. I'm a huge proponent of TDD, and I love Ruby, but the more I use Ruby, the more I see the problems of not having a compiler.

cordite 13y ago

Sure, the type checker forces you to think more when you are actually typing. It makes up for being easy and rapid to refactor, repurpose, and reuse--arguably making it competitive to prototype with.

programminggeek 13y ago
I actually agree, but I don't think most people do and there are times when static typing isn't as much fun - like say pulling data from an API and shoveling it on to a page or through some filtering or something like that or just doing some random UI manipulation with jQuery or the like. Most developers see the pain and are given a deadline and so they do it dirty and hope to have a chance to pay downy that technical debt later. Later almost never happens until the system crashes beyond repair and the instability starts costing money in the form of downtime. In the grand scheme of things, maintenance is always the most expensive part of a system, but "prototyping" languages that aren't particularly safe or maintainable are inherently going to be more expensive to maintain and deal with over the long term. Ironically, dynamic languages like Ruby have taken the route of getting really good at unit testing and TDD instead of investing in moving their codebases from "prototypes" to "production" or "LTS" or whatever you would want to call a mature, complex codebase that will need to be maintained and evolved over time. I'm a huge proponent of TDD, and I love Ruby, but the more I use Ruby, the more I see the problems of not having a compiler.