So no-one has built a QuickCheck for Ruby or Python?
I'd like to use this "property-based testing" he stressed.
Running a Startup on Haskell
31–38 of 38 posts
Re: Running a Startup on Haskell
#32Earlier quoted context omitted.
How does the strong typing compare with Java/C#? Thanks.
Several things jump out immediately: - Haskell has exceptionally thorough type inference (almost all type declarations are optional). - anything impure (e.g. involving an I/O) is typed as such - the types are easier to read and tend to give a good idea of what the function in question is doing - much more complicated types are readable - idioms like Monads lead to a lot of code that is much more abstract and generic…
The higher order monadic join concept cannot be implemented in java but a simpler function in terms of flattening a list of list is easy enough. In a functional language a simple way would be to fold over (++) append.
so in java a simple way would be to initialize an l = arrayList and then do a foreach on each list in the list of the lists and foreach element in each list add it to the arrayList l. Not as elegant, much more how instead of what but 4 noisy lines max.
C# has list.selectMany( _ => _ ) for that.
Re: Running a Startup on Haskell
#33Earlier quoted context omitted.
I think Haskell (and functional languages in general) will become increasingly popular as it is (they are) a powerful way to deal with concurrency and can easily take advantage of multiple processors. Languages are tools in a developers toolbox, and Haskell turns out to be a powerful one for several growing problems.
It's not just that. Haskell has exceptionally strong typing and containment of mutable computations, making it much easier to write correct programs. When a module compiles, it's usually pretty bug-free.
Space leaks, stack overflows (foldl vs. foldl'), failed pattern matches (head []), etc. There are tons of bugs lurking in well-formed Haskell programs.
Re: Running a Startup on Haskell
#34Earlier quoted context omitted.
Several things jump out immediately: - Haskell has exceptionally thorough type inference (almost all type declarations are optional). - anything impure (e.g. involving an I/O) is typed as such - the types are easier to read and tend to give a good idea of what the function in question is doing - much more complicated types are readable - idioms like Monads lead to a lot of code that is much more abstract and generic…
The higher order monadic join concept cannot be implemented in java but a simpler function in terms of flattening a list of list is easy enough. In a functional language a simple way would be to fold over (++) append. so in java a simple way would be to initialize an l = arrayList and then do a foreach on each list in the list of the lists and foreach element in each list add it to the arrayList l. Not as elegant, mu…
> In a functional language a simple way would be to fold over (++) append.
Though you probably wouldn't want to do use that approach for performance reasons.
Re: Running a Startup on Haskell
#35Earlier quoted context omitted.
It's not just that. Haskell has exceptionally strong typing and containment of mutable computations, making it much easier to write correct programs. When a module compiles, it's usually pretty bug-free.
Space leaks, stack overflows (foldl vs. foldl'), failed pattern matches (head []), etc. There are tons of bugs lurking in well-formed Haskell programs.
Tons being a vast overstatement. I mean, you could exploit these things to cause bugs, but really do you encounter them on a day to day basis? I know I rarely if ever have.
Re: Running a Startup on Haskell
#36Earlier quoted context omitted.
Several things jump out immediately: - Haskell has exceptionally thorough type inference (almost all type declarations are optional). - anything impure (e.g. involving an I/O) is typed as such - the types are easier to read and tend to give a good idea of what the function in question is doing - much more complicated types are readable - idioms like Monads lead to a lot of code that is much more abstract and generic…
Maybe it's better with more experience or when you're reading your own code, but I find that reading a Haskell program is often like reading a math paper - you can't skim it; you have to slow way down and study it, one line at a time, and look up the definition of each term as you go and think about what it means, and try out simple examples. And sometimes you don't have the background to understand the underlying co…
It has nothing to do with being a mathematician. There are common patterns as any language. Those patterns often end up as higher order functions. But at some point, it becomes very natural to read.
Re: Running a Startup on Haskell
#37So no-one has built a QuickCheck for Ruby or Python? I'd like to use this "property-based testing" he stressed.
There are plenty of implementations linked from http://en.wikipedia.org/wiki/QuickCheck. (I'm not sure in what state they are though.)
Re: Running a Startup on Haskell
#38Earlier quoted context omitted.
Maybe it's better with more experience or when you're reading your own code, but I find that reading a Haskell program is often like reading a math paper - you can't skim it; you have to slow way down and study it, one line at a time, and look up the definition of each term as you go and think about what it means, and try out simple examples. And sometimes you don't have the background to understand the underlying co…
"When I'm done, I want it to be as smooth and easy to read and as obvious as an article in the New Yorker." Your metaphor is apt; if your code is going to be that smooth, you need to learn Haskell to the same extent you know English for the New Yorker. The Internet suggests that the New Yorker is written for a "10th grade reading level", but of course the average American has between an 8th or 9th grade level. It doe…
If I learn Haskell well and start writing code that's idiomatic for that audience, I'm limiting my audience to the few people who also know Haskell (and the particular Haskell idioms I'm using). It's like writing in Esperanto instead of English. My ideal is more along the lines of the Python examples that Peter Norvig writes, which can be understood by pretty much any programmer, even if they're not all that fluent in Python.