Hi all, I was afraid of that. The tenor here is "there is no way to get off haskell" so either do woodwork or try to get a haskell job. :( Günther

Another way to be happy is to get a family to support, then any idea of making a quick pfennig with C# and then luxuriating in Rio with a laptop full of Haskell will only work if your company goes public! :) -- Alexy

Excerpts from Paul Lotti's message of Thu Jun 17 15:33:30 -0400 2010:

Same feelings here. I work in a company that uses C++/Java and the best I could manage was to use Haskell for prototyping and then deliver in Java. This worked out twice so far. The downside is having to translate it later.

*Shudders at the though.* Must be a what, x10 size blow-up?

The fast write-only way: - generate C code with JHC (no haskell runtime) - use a C-to-java converter , for example, c2j (http://www.novosoft-us.com) At least you can laugh at the generated code. anyone tried that? Alberto 2010/6/18 wren ng thornton :

Edward Z. Yang wrote:

...

Excerpts from Paul Lotti's message of Thu Jun 17 15:33:30 -0400 2010:

...

Same feelings here.  I work in a company that uses C++/Java and the best I could manage was to use Haskell for prototyping and then deliver in Java.  This worked out twice so far.  The downside is having to translate it later.

*Shudders at the though.* Must be a what, x10 size blow-up?

I've done that too. It works fairly well for certain kinds of programs/problems, but you have to be careful about your abstractions.

For instance, Java Generics are no substitute for real parametric polymorphism. They only work for the simplest kind of container/element polymorphism, interact poorly (i.e., not at all) with subclassing, and explode with many of the higher-order tricks common in idiomatic Haskell. Any sort of higher-order programming (HOFs, point-free style, CPS, parametricity,...) rarely translates well--- especially if you want to avoid code bloat and have anything resembling idiomatic Java. Though sometimes defunctionalization[1] can help.

The code blow up varies. 10x is on the good side of things and indicates a good match of abstractions. 20x or 30x is more common I think. But if you're relying on any libraries or fancy datastructures, you'll be lucky not to have to reimplement everything...

[1] http://blog.plover.com/prog/defunctionalization.html http://www.brics.dk/RS/01/23/ http://cristal.inria.fr/~fpottier/publis/fpottier-gauthier-popl04.pdf

-- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

...

So how does one get off haskell? Are there people in similar situations that have managed? How did you do it?

I used to get annoyed about all the java boilerplate and awkwardness. But then I learned that if I relax and stop thinking so much about the aesthetics of what I'm writing, I can just let my fingers go on typing without having to think too much. Yes, it would have been shorter and more graceful in more capable languages, but I would have had to think more about how to factor things or apply the right abstractions. Ultimately the problems to be solved are the same, it's just that java and c++ give you a lot of padding where you're writing boilerplate and workarounds for not having closures, monadic values, a nice type system, etc. It could be relaxing in the same way that playing 3rd trombone could be: you still get to play technical music every once and a while, but you also get a lot of downtime to count rests and listen to the music, or play whole notes. There is a pleasure in that, even if it's not the same as when you're in the 1st violin section. Music is still being made, problems are still getting solved.

Evan Laforge wrote:

I used to get annoyed about all the java boilerplate and awkwardness. But then I learned that if I relax and stop thinking so much about the aesthetics of what I'm writing, I can just let my fingers go on typing without having to think too much.

:-) A good Java IDE will write most of the boilerplate, too. I find the most annoying thing is not *writing* the boilerplate, it's the fact that it clutters things up and makes it hard to see what is going on.

Ultimately the problems to be solved are the same, it's just that java and c++ give you a lot of padding where you're writing boilerplate and workarounds for not having closures, monadic values, a nice type system, etc.

One thing I'm curious about is Haskell versus Python or Ruby. Code in those languages is, IMO, prone to type related bugs because there is no compile-time checking. On the other hand, I would expect the 'density' of the code to be similar to Haskell. You can do a lot of the same things, although they support an OO programming style too. Interestingly, the Shootout benchmarks show Haskell doing quite poorly on code size. I suspect that is because a lot of effort has gone into making those programs fast at the expense of everything else, though. Pete

On Friday 18 June 2010 12:31:26, Ivan Lazar Miljenovic wrote:

Pete Chown <1@234.cx> writes:

...

One thing I'm curious about is Haskell versus Python or Ruby. Code in those languages is, IMO, prone to type related bugs because there is no compile-time checking. On the other hand, I would expect the density' of the code to be similar to Haskell. You can do a lot of the same things, although they support an OO programming style too.

Haven't you heard? Enough unit tests give you almost the same security as a good static type system at the expense of more code!

Uh, wait, why is that an advantage again? :p

Duh, because it's much faster to develop in a dynamically typed language. Writing out all those type signatures costs time. Much more time than writing a few dozen unit tests per function, right?

On Fri, Jun 18, 2010 at 8:37 AM, Daniel Fischer wrote:

...

Haven't you heard?  Enough unit tests give you almost the same security as a good static type system at the expense of more code!

Uh, wait, why is that an advantage again? :p

Duh, because it's much faster to develop in a dynamically typed language. Writing out all those type signatures costs time. Much more time than writing a few dozen unit tests per function, right?

That's... not really fair. A static type system DOES impose limitations, and arguing with the compiler about whether some code is acceptable does take time. Even a handful of simple unit tests will catch the majority of possible errors, and things that require deep metaprogramming wizardry in Haskell can be stupidly trivial in something like Ruby. If writing something in Haskell would mean ten lines of metaprogramming and type signatures for every single line of code, but a few unit tests and some quick-and-dirty Python would provide acceptable results, I'd go with the latter. The better question is "when do the benefits of static typing outweigh the costs imposed?". If you're using Java, the answer is probably "never", but even in Haskell I don't think the answer is quite "always". - C.

On Jun 18, 10:37 am, Ivan Lazar Miljenovic wrote:

"C. McCann" writes: I've seen a lot of people claim that there are cases where it's easier/better to use dynamic typing than even Haskell-style static typing, but have never been given an example or reason why.  Care to actually provide one?

Since this is heading for yet another static vs. dynamic typing and the universe kind of threads, I'd add some dynamic spice. In the last two years I've explored, and learned, the following languages for large-scale data mining: OCaml => Scala => Clojure => Haskell now => back to OCaml tomorrow with my graph for now :). I was seriously impressed with Clojure for data mining as its dynamism allows to easily handle any shape of data. When you slice and dice a huge data frame (in R parlance), your subsets are vectors or maps of varying types and lengths; you can also get nulls. Clojure is made for this. Its vectors and maps are first-class citizens, so my graph data looks like: {:mandy {1 {:alice 1 :bob 2} 2 {:john 1 :alice 3} ... :bob {...}} So when your problem is open-ended and the shape of data is in flux, a dynamic language is faster to prototype. If, on the other hand, you're at PHB's whim and some specs and types are handed around, then static approach is natural from the beginning. The NPEs are still very annoying, but it all kind of works in the end. The choices are often dictated by external library availability, accepted usage, etc. I can see Haskell an excellent replacement for a majority of Python/ Ruby/Java/C# situations if you have the manpower, including the bosses'; Scala or Clojure when on JVM, F# when on .NET. In fact mixing Clojure and Scala projects allows a good dynamic vs static balance in a similar functional style, with some excessive OO in Scala for those who miss it. -- Alexy

On Jun 18, 12:59 pm, "Edward Z. Yang" wrote:

... I would still prefer Haskel for a system intended for production; with the pain of making sure you've handled all of the possible constructors for the data you're operating on, you also have a pretty good assurance that you haven't forgotten anything stupid.

Absolutely. You suddenly feel naked when a working dynamic system must pass assurances, and all those unit tests are just busywork of the script kiddies trying to make it look reliable. :) Nothing like a good static type system to be able to trust the thing more. However, some things are hard to catch even with strict typing. Here's an example from my current program: dstarts = M.fromList $ map dayUsers (groupBy ((==) `on` snd) dranges) This was a bug. dranges is a [(User, (Int,Int))], and I needed the first int of the pair, not the whole pair. But groupBy would take either. I had to identify it and replace by dstarts = M.fromList $ map dayUsers (groupBy ((==) `on` fst . snd) dranges) -- which feel almost like Clojure's easy tweaking. Both things type check unless I add the type signature for dstarts. But where to add them is not clear from the get-go, and you want to use inference where you think what you mean is clear... which sometimes is not. -- Alexy

Excerpts from Bryan O'Sullivan's message of Fri Jun 18 13:16:58 -0400 2010:

I'm inclined to disagree. It's precisely when the code is in a state of constant upheaval that I want the type system to be pointing out my dumb errors.

In my experience, the type system has forced me to care about thing that I don't want to care about (yet). It's a different mindset: in the words of the prototyper: being first is valued over being correct. This does mean that Haskell forces you to write long-term maintainable code from the get-go, yes. :-) Cheers, Edward

I've written code with less bugs in Haskell than any other language I've used. And that's a credit to GHC and not because I'm a great programmer. But I still don't know how to deal with the situation where you don't have a clear picture of your data or heterogenous data that you are wrapping up in a type just to make the compiler happy? Here's an example of the latter: I was writing some Haskell web app code where continuations are used to compose multi-step web transactions. The continuations were stored in a map keyed with a unique session id and invoked when the user POST'ed back that session id. The problem was that the map would only accept functions of one intermediate type and one result type. So I had to marshall/unmarshall all my functions to some common type (ContT () IO String in my case) just so I could store it in the map - which felt kind of dirty. While pointers on this particular problem would be appreciated, I think this is the kind of issue (needing to be flexible about data types) is a stumbling block for many beginning Haskell programmers. -deech On Fri, Jun 18, 2010 at 12:44 PM, Andy Stewart wrote:

"Edward Z. Yang" writes:

...

Excerpts from Bryan O'Sullivan's message of Fri Jun 18 13:16:58 -0400 2010:

...

I'm inclined to disagree. It's precisely when the code is in a state of constant upheaval that I want the type system to be pointing out my dumb errors.

In my experience, the type system has forced me to care about thing that I don't want to care about (yet).  It's a different mindset: in the words of the prototyper: being first is valued over being correct.

This does mean that Haskell forces you to write long-term maintainable code from the get-go, yes. :-) Haha, that's true. :)

When i write Haskell code, it force me write *framework* code.

Sometimes, i wrote dirty code quickly, Haskell will told me :

  "Hey, bad code! Rewrite it! I don't accept dirty code ... bla bla ...".

Then i rewrite my code to make it flexible and maintainable.

Once you build beautiful framework code, you will find your life is so simple. :)

Cheers,

 -- Andy

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Jun 18, 2010 at 10:30 AM, C. McCann wrote:

The better question is "when do the benefits of static typing outweigh the costs imposed?". If you're using Java, the answer is probably "never", but even in Haskell I don't think the answer is quite "always".

I have half a concrete example! I do research in automated planning, and the standard problem definition language is PDDL[1]. PDDL uses FOL logic expressions for expressing goal conditions, action preconditions, effects and various other things. The problem comes in that it uses a /different/ subset of first-order logic for each expression, leading to something like 8 or so expression types contained just in PDDL 3.1 (the latest 'standard'). Then there are the many previous versions of PDDL, and all the many extensions and subset/extensions to various versions of PDDL used in other people's research projects. So, when I wrote a PDDL library to help with my research, I needed extensibility. If not, I'd need to either fork the library for every PDDL extension, or create some sort of uber-PDDL which contained all the extensions. The best I came up with is Wouter's Datatypes a la Carte [2] which I used along with an extensible record technique my implementation[3]*. There are downsides to this approach. The most obvious is that to define a function over one of these datatypes, you need to define a class associated with that function and then define an instance of that class for every component. Also, type signatures are huge and I feeling like I'm using half the language extensions out there. I end up with a full complement of boilerplate code, and it doesn't even buy me full expression type safety (there are restrictions in PDDL on how expressions combine). Now, one thing I'm missing out of this example is the other side of the coin - doing it better in a dynamically typed language. However, there are plenty of C, lisp, and python PDDL planners out there, and I'm pretty sure they don't bother with type safe expressions. Also, this isn't an indictment of static typing in general. This only shows that my task isn't well suited to Haskell's current static typing. -Ron Alford * Note that this was my first and only real haskell project, and all that this entails. [1] http://en.wikipedia.org/wiki/Planning_Domain_Definition_Language [2] http://lambda-the-ultimate.org/node/2700 [3] http://www.cs.umd.edu/projects/planning/data/alford09translating/

2010/6/24 Serguey Zefirov :

I should suggest code generation from Haskell to C#/Java and PHP.

Like Barrelfish, Atom, HJScript and many others EDSLs out there.

You will save yourself time, you will enjoy Haskell. Probably, you will have problems with management because your programs will appear there in their completeness very suddently. ;)

You need a domain that favours multiples for code generation to be successful, though. Atom seems ideal, as it is generating controller code of product lines of embedded systems; but enterprise domains typically favour code delivered in libraries / frameworks where the components are singular, evolving entities, possibly used across in multiple applications.

Quoting Andrew Coppin :

Serguey Zefirov wrote:

...

I should suggest code generation from Haskell to C#/Java and PHP.

Like Barrelfish, Atom, HJScript and many others EDSLs out there.

You will save yourself time, you will enjoy Haskell. Probably, you will have problems with management because your programs will appear there in their completeness very suddently. ;

I would imagine a bigger problem is that machine-generated C# is probably incomprehensible to humans. ;-)

Most machine-generated code is probably incomprehensible to humans. :) What one wants is a translator back and forth, if one could understand the machine-generated code.