The take-away for Haskell tends to be if there is some kind of a commitment at some "core" level to it (i.e the the long-term members of the tech team, CTO, etc.). If there is none and people move in-and-out of the company, then it's more practical to use a more mainstream language, which is easier and less far-out to learn.
Mastering Time-to-Market with Haskell
111–120 of 120 posts
Re: Mastering Time-to-Market with Haskell
#112Earlier quoted context omitted.
OK, so you define effect-freedom using the language's equality operator. I agree it's a better definition than mine, but I think assembly language and BASIC would still qualify as effect-free (provided there's no concurrency) even though some people would not consider them pure.
> OK, so you define effect-freedom using the language's equality operator. Not the runtime equality testing operator. Rather, the language's static notion of contextual equivalence. It just happens to be the case that most high-level languages provide a built-in equality testing operator that works on primitive types, returning `true` iff its operands are contextually equivalent values. > I think assembly language an…
> Not the runtime equality testing operator. Rather, the language's static notion of contextual equivalence.
How is that different from denotational semantics?
> The ones that can be effectful or effect-free are specific computations, not whole languages.
Well, we could define an effect-free language as one where all programs are effect-free. But anyway, what is the "static notion of contextual equivalence" in assembly (or BASIC), and how can you write an effectful program in such a language?
Re: Mastering Time-to-Market with Haskell
#113Earlier quoted context omitted.
> IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way: you have to declare up-front which functions do I/O, etc There's some evidence Haskell is pretty good at rapid prototyping. Are you familiar with this '94 paper on rapid prototyping [ http://www.cs.yale.edu/publicati…
1994 was well before the IO monad became the standard IO paradigm for Haskell, and a year before there was even a proposal on the table for monadic IO for Haskell. It makes me wonder what the language was like back then and whether the results would be repeatable with today's language.
Sure! I think Haskell would fare pretty well today, because the essential aspects haven't changed. It's still very suitable for prototyping and exploratory programming.
Of course, today it would have to go toe to toe against modern dynamic languages. In this case it'd be essential to demonstrate running code, which is arguably a huge advantage of static typing over dynamic typing; if you're only comparing source code, dynamic languages can get away with being terse and claiming "trust me, it works".
I imagine Haskell would still leave modern C++ coughing dust at the start line :)
Re: Mastering Time-to-Market with Haskell
#114Although very fresh into the Haskell world myself, I tend to agree with the author that, when I know what I am doing, my Haskell code is usually written in less time and has less bugs. Having said that, Time-to-Market is only partially influenced by my-code, the biggest part is the code that I don't have to write, i.e. third-party libraries. In my Haskell adventures I am having trouble finding third-party libraries f…
Mine has a single star but you may find it useful. https://github.com/eklavya/hascas
Thanks. I love that you have a fair-sized concrete example for usage. I am giving it a try now.
Re: Mastering Time-to-Market with Haskell
#115> Haskell developers are self-selecting This is not going to change. I love Haskell, and I appreciate the effort many are making to evangelize the language, but I am experienced (ie. cynical) enough to believe that it's never going to become truly mainstream.
That's my experience as well. As a Haskell user I once felt that I had a secret, that it's so much better than the rest. Now, years later, it seems many pretty much can't tell a difference between a good and a bad language. Or rather, that many pick a language by the language's spread rather than its properties.
Re: Mastering Time-to-Market with Haskell
#116> Haskell developers are self-selecting This is not going to change. I love Haskell, and I appreciate the effort many are making to evangelize the language, but I am experienced (ie. cynical) enough to believe that it's never going to become truly mainstream.
Haskell would be a lot easier to manage in production environments if resource-usage was more predicable - meaning strict by default.
Re: Mastering Time-to-Market with Haskell
#117Earlier quoted context omitted.
Yes, but that's a dynamically typed language and everything changes when comparing it. There are so many tradeoffs. Clojure is quite quick to write and time to market can be very fast, as with most lisps, but you pay the price at debug time. We recently shipped a production app that had a small typo that the compiler would have easily caught, but instead it crashed the site when this one particular task was run.
Your experience with Clojure might not in fact generalize to "most lisps", which have very good compilers that catch all kinds of errors. Certainly the "low hanging fruit" ones like references to unbound variables or functions and such. What was the typo? > it crashed the site when this one particular task was run. Might that also be because that was the first time the task was run at all, since the code was written…
The typo had to do with accidentally naming a variable in a let binding to the same name as a built-in function. It happily compiled but when that code actually ran in one particular use-case, it crashed due to the way the binding and the scoping worked in that case.
Re: Mastering Time-to-Market with Haskell
#118Earlier quoted context omitted.
Your experience with Clojure might not in fact generalize to "most lisps", which have very good compilers that catch all kinds of errors. Certainly the "low hanging fruit" ones like references to unbound variables or functions and such. What was the typo? > it crashed the site when this one particular task was run. Might that also be because that was the first time the task was run at all, since the code was written…
The typo had to do with accidentally naming a variable in a let binding to the same name as a built-in function. It happily compiled but when that code actually ran in one particular use-case, it crashed due to the way the binding and the scoping worked in that case.
> accidentally naming a variable in a let binding to the same name as a built-in function.
Not even a problem in a Lisp-2 like ANSI CL!
(let ((list '(1 2)))
(list list list)) -> ((1 2) (1 2))
Even without a compiler, we can implement a warning for this. The code walker which expands macros is aware of lexical environments and can issue diagnostics when suspicious-looking shadowing is going on, or unbound variables are referenced and such.
Not only is this not the fault of the language being dynamic, but the problem could exist in a static language, like, oh, C:
#define DECLARE_MY_PRINTF int (*printf)(const char *, ...) = my_printf;
{
DECLARE_MY_PRINTF:
printf("hello, %s\n", "world"); // goes to my_printf via shadowing local var
}
Of course, the above depends on the local printf pointer actually having the right type so that the call is well-formed. If we just have "int printf" or whatever, the type system will catch it.
Re: Mastering Time-to-Market with Haskell
#119If you were a developer with 10 yoe looking for something new to get into, what would you choose at this moment and thinking about the near future: Haskell, Scala or F#?
Near future: Scala.
There is more professional work being done in Scala, and it makes it more palatable to managers that it runs on the JVM and allows them to leverage some of the existing knowledge of their Java programmers.
In the financial world, however, F# use is on the rise.
I currently work in F# but not in finance, and the lack of mature libraries for common things (like JSON serialization!) makes it a major pain in the behind.
Were I told to select a functional language, "quick!", I would select Clojure when caffeinated, and Javascript (ES7) when not.
FWIW: I subscribe to the notion that dynamic typing with unit testing will get you a correct and working program faster than static typing. In the case of Clojure, you now have clojure.spec, which means you can write conformance criteria as functions and generate tests and test data.
http://games.greggman.com/game/dynamic-typing-static-typing/
Re: Mastering Time-to-Market with Haskell
#120If you were a developer with 10 yoe looking for something new to get into, what would you choose at this moment and thinking about the near future: Haskell, Scala or F#?
I would recommend none-of-the-above. Having gone down the Haskell rathole, it's clear to me that the advertising is better than the product. It's complex and difficult to learn and the "less errors because of typing" mantra turns into 'how in the world am I supposed to find my error'. In practice, I very rarely run into errors caused by type problems. I know nothing about F#, but that's actually my criticism of it. T…
Thanks Steeeve, really informative answer.