help me evangelize haskell.
I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages.
2010/9/4 Michael Litchard
I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages.
Hi, At a talk presented during a Ghent FPG meeting, someone explained how they brought Ocaml to the work place. Basically, they made a drop-in replacement for a C++ (or maybe was it C) library. Less code, same or above performance. Maybe they had also a good reason to rewrite the library (because it was too big, or too difficult to maintain), not just as a proof that Ocaml was better suited. I guess that in your case, "Perl for internal automation task", you should find some little tool for which it would be acceptable to dedicate some time rewriting it in Haskell. Tell us how all this unfolds. Cheers, Thu
On 05/09/2010, at 2:38 AM, Michael Litchard wrote:
I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages.
Try to avoid religious arguments like "by using Perl you're living in a state of sin", and focus on "look how much easier it is to do X in Haskell". Grandiose, hand-wavy assertions like "strong typing leads to shorter development times and more reliable software" don't work on people that haven't already been there and done that. When you try to ram something down someone's throat they tend to resist. However, if you can provide something tasty and appealing they'll eat it themselves. Write a nice program, show it to your Perl programmer, and if they also think it's nice -- then you've already won. Ben.
On 5 sep 2010, at 09:28, Ben Lippmeier wrote:
On 05/09/2010, at 2:38 AM, Michael Litchard wrote:
I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages.
Try to avoid religious arguments like "by using Perl you're living in a state of sin", and focus on "look how much easier it is to do X in Haskell".
Grandiose, hand-wavy assertions like "strong typing leads to shorter development times and more reliable software" don't work on people that haven't already been there and done that. When you try to ram something down someone's throat they tend to resist. However, if you can provide something tasty and appealing they'll eat it themselves. Write a nice program, show it to your Perl programmer, and if they also think it's nice -- then you've already won.
I've had success in situations with tight deadlines: the only way I got it done quickly and without bugs is by using Haskell (as opposed to PHP). Another place where you might have success is by writing a small compiler or interpreter for an internal language. Start small (in a niche, if you will) and expand upon that. -chris
Quoth Ben Lippmeier
Grandiose, hand-wavy assertions like "strong typing leads to shorter development times and more reliable software" don't work on people that haven't already been there and done that. When you try to ram something down someone's throat they tend to resist.
Though, I think those sentiments can be appreciated when expressed properly. I mean, I can talk about how nice it is when my programs work the first time I run them, without necessarily being grandiose or trying to ram something down anyone's throat. I guess everyone's different - some Perl programmers might really respond to a nice Haskell program, if it isn't gratuitously incomprehensible. Others may be more interested in the rationale behind the language's features, and only from there find any motivation to try to understand the syntax. Of course it's a good idea to feign interest in their views on software engineering, etc., but mostly it comes down to your charisma. Never worked for me, but good luck! Donn Cave, donn@avvanta.com
Michael Litchard wrote:
I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages
Rather than "how can I convince them to use Haskell for everything?", how about just convincing them to use it on a case-by-case basis. It's plausible there are scenarios where Haskell is *not* the best thing to use. And if you just tirelessly "evangelize" Haskell, them one has to wonder who's the bigot. ;-) (That said, I really hate Perl...)
If they are perl programmers, they (should) understand perl very well. I
would suggest to try explaining to them the obvious disadvantages of perl
and the way that Haskell can cover those disadvantages without (much) of a
compromise.
Perl programs are either ones that are ridiculously short/concise, these are
one off scripts that become impossible to maintain (and even to read apart
from whoever coded the script). These perl scripts are typically shorter
then the equivalent Haskell ones. The other type of Perl scripts are the
ones that are fairly concise, and at least more maintainable/scalable. These
perl scripts tend to be the same size as the Haskell ones, except the
Haskell ones are type safe, have error checking and are much more
maintainable/scalable (the slideshow earlier with DonS shows this). Odds are
that the company probably has the latter of Perl scripts, so if you can show
them how Haskell can be just as excise (but not as extremely concise)
however have a lot more other benefits that will help a lot.
Another thing you can say is that Perl is a very extreme language in design
where as Haskell is more "general". This means the one thing Perl does, it
does very well (expressing programming problems in the most concise/short
possible way) but it has to sacrifice for it massively in other areas which
end up costing much more in the long run. Most 'real' world problems do not
require that amount of brevity, considering the massive cost that Perl
brings for such a thing.
Also show them quickcheck as well
On Sun, Sep 5, 2010 at 2:38 AM, Michael Litchard
I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sep 5, 2010, at 7:46 PM, Mathew de Detrich wrote:
Another thing you can say is that Perl is a very extreme language in design where as Haskell is more "general". This means the one thing Perl does, it does very well (expressing programming problems in the most concise/short possible way) but it has to sacrifice for it massively in other areas which end up costing much more in the long run. Most 'real' world problems do not require that amount of brevity, considering the massive cost that Perl brings for such a thing.
That doesn't sound right to me. Perl's biggest weaknesses are traditionally: (i) the syntax: but those $'s and @'s are actually type annotations; and (ii) "There's More Then One Way to Do It": the existence of multiple approaches to solving a problem, instead of an "official" obvious choice. This means that every programmer on the team either has to KNOW all the possible ways to solve a problem with Perl, or the programming team has to CHOOSE one and make it "policy" -- effectively picking out the nicest bits and sticking to that sub- language. Depending on your point of view, Haskell does not compare particularly favorably with respect to "TMTOWTDI". The whole Control.* hierarchy is the construction of custom control structures. That's the whole point of "glue" languages. You write custom control structures to support the chosen normal forms for expressing data and computations.
On 6 September 2010 03:46, Mathew de Detrich
If they are perl programmers, they (should) understand perl very well. I would suggest to try explaining to them the obvious disadvantages of perl and the way that Haskell can cover those disadvantages without (much) of a compromise.
Now that's going to go down well... Maybe the original poster might want to soak up the company culture for a while before than telling co-workers how to do things.
participants (9)
-
Alexander Solla -
Andrew Coppin -
Ben Lippmeier -
Chris Eidhof -
Donn Cave -
Mathew de Detrich -
Michael Litchard -
Stephen Tetley -
Vo Minh Thu