Re: [Haskell-cafe] help me evangelize haskell.
Thanks Don! On Tue, Sep 7, 2010 at 10:51 PM, Don Stewart wrote: > That's a separate module, based on System.Process -- > > http://code.haskell.org/~dons/code/cpuperf/Process.hs > > ckkashyap: >> Hi Dan, >> This presentation is really nice. >> I went over it a couple of times and I think this ppt will help me try >> to use Haskell for things that I usually use Perl for :) >> >> A quick question - import Process bombs on my GHCI(The Glorious >> Glasgow Haskell Compilation System, version 6.12.3) -what do I need to >> do for that? >> >> >> On Sun, Sep 5, 2010 at 11:12 PM, Don Stewart wrote: >> > Gaius: >> >> My usual rhetoric is that one-off, throwaway scripts never are, and >> >> not only do they tend to stay around but they take on a life of their >> >> own. Today's 10-line file munger is tomorrow's thousand-line ETL batch >> >> job on which the business depends for some crucial data - yet the >> >> original author is long gone and no-one dares modify in case it >> >> breaks. So it is just good sense to use sound practices from the very >> >> beginning. >> > >> > I gave a tech talk recently on using Haskell for scripting -- and it is >> > built on the idea that today's throw away script is tomorrow's key piece >> > of infrastructure -- so you better get the maintainance and safety story >> > right: >> > >> > http://donsbot.wordpress.com/2010/08/17/practical-haskell/ >> > ___ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> >> >> >> -- >> Regards, >> Kashyap >> > -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
That's a separate module, based on System.Process -- http://code.haskell.org/~dons/code/cpuperf/Process.hs ckkashyap: > Hi Dan, > This presentation is really nice. > I went over it a couple of times and I think this ppt will help me try > to use Haskell for things that I usually use Perl for :) > > A quick question - import Process bombs on my GHCI(The Glorious > Glasgow Haskell Compilation System, version 6.12.3) -what do I need to > do for that? > > > On Sun, Sep 5, 2010 at 11:12 PM, Don Stewart wrote: > > Gaius: > >> My usual rhetoric is that one-off, throwaway scripts never are, and > >> not only do they tend to stay around but they take on a life of their > >> own. Today's 10-line file munger is tomorrow's thousand-line ETL batch > >> job on which the business depends for some crucial data - yet the > >> original author is long gone and no-one dares modify in case it > >> breaks. So it is just good sense to use sound practices from the very > >> beginning. > > > > I gave a tech talk recently on using Haskell for scripting -- and it is > > built on the idea that today's throw away script is tomorrow's key piece > > of infrastructure -- so you better get the maintainance and safety story > > right: > > > > http://donsbot.wordpress.com/2010/08/17/practical-haskell/ > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > -- > Regards, > Kashyap > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
Hi Dan, This presentation is really nice. I went over it a couple of times and I think this ppt will help me try to use Haskell for things that I usually use Perl for :) A quick question - import Process bombs on my GHCI(The Glorious Glasgow Haskell Compilation System, version 6.12.3) -what do I need to do for that? On Sun, Sep 5, 2010 at 11:12 PM, Don Stewart wrote: > Gaius: >> My usual rhetoric is that one-off, throwaway scripts never are, and >> not only do they tend to stay around but they take on a life of their >> own. Today's 10-line file munger is tomorrow's thousand-line ETL batch >> job on which the business depends for some crucial data - yet the >> original author is long gone and no-one dares modify in case it >> breaks. So it is just good sense to use sound practices from the very >> beginning. > > I gave a tech talk recently on using Haskell for scripting -- and it is > built on the idea that today's throw away script is tomorrow's key piece > of infrastructure -- so you better get the maintainance and safety story > right: > > http://donsbot.wordpress.com/2010/08/17/practical-haskell/ > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
Hi All, Not a complete guide, but just something, which can help: Perl6 is inspired by haskell. That was, how I end up by haskell. And I believe a lot of people of the perl community got interested in haskell that way. Maybe this works for some of collegues too. I still like perl, but haskell is in many cases more productive. On the other hand perl has more libs. Greets, Edgar On Mon, Sep 6, 2010 at 12:50 PM, Mathew de Detrich wrote: > I Think you misinterpreted what I said. I didn't say you should tell the > programmers how to code, I said you should show the perl coders how Haskell > has advantages over pearls without much cost > > On 06/09/2010 5:21 PM, "Stephen Tetley" wrote: > > On 6 September 2010 03:46, Mathew de Detrich wrote: > > If they are perl programme... > 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. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > h... > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
I Think you misinterpreted what I said. I didn't say you should tell the programmers how to code, I said you should show the perl coders how Haskell has advantages over pearls without much cost On 06/09/2010 5:21 PM, "Stephen Tetley" wrote: On 6 September 2010 03:46, Mathew de Detrich wrote: > If they are perl programme... 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org h... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
On 6 September 2010 03:46, Mathew de Detrich wrote: > 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
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 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. > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
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...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
Gaius: > My usual rhetoric is that one-off, throwaway scripts never are, and > not only do they tend to stay around but they take on a life of their > own. Today's 10-line file munger is tomorrow's thousand-line ETL batch > job on which the business depends for some crucial data - yet the > original author is long gone and no-one dares modify in case it > breaks. So it is just good sense to use sound practices from the very > beginning. I gave a tech talk recently on using Haskell for scripting -- and it is built on the idea that today's throw away script is tomorrow's key piece of infrastructure -- so you better get the maintainance and safety story right: http://donsbot.wordpress.com/2010/08/17/practical-haskell/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
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, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
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___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] help me evangelize haskell
Michael: Hi. I take the risk to mention some facts you might already be working on. I speculate on three perceptions in the mind of decision makers related to the adoption of a new language in a shop. This perceptions can be modified in stages. First Stage: Awareness. Why programming in that language matters? Once you can justified this, advance to the following stage. Haskell is nice, quick to develop, brings tools to make abstractions at any level and has tools and libraries. And community support is really awesome! If you invest more in learning, you can strive to use it as formal programming method and earn safety guarantees. Please, see elsewere for success stories that help you to motivate and encourage management to test the new alternative. Second Stage: Small term engagment. Why your shop should do little investment in trying a new language in a small but representative project? Here you can make two arguments to gain support in this stage: 2.A) The shortcommings of the current tools/languages. 2.B) Small concept programs of how your current language/tool would fail where the new one would success. You can gain credibility by showing how your new tool could be short on some aspect that it's well mastered in the old one. (i.e. be impartial). Someone has already pointed how fragile interpreted programs are. In this stage you must gain both decision makers and peers recognition of the problem the shop is facing with the current language versus the improvements of using the new language. A project must be acomplished and reviewed, so a decision can be made over the facts of costs and benefits. Third Stage: Adoption. Is it really better to adopt a new language? At this point you have evidence of possible benefits and costs. And a decision is made. Among other costs, please take in account that embracing any new language in a shop will require formalised (funded, time alloted to, machines, any other resource) learning and coaching activities. Haskell has long learning curve. And you must consider this cost of being less productive than in your current language. There's too the risk of hitting walls in a tight-schedule situation. You can lower this risk of failure if you arrange to have a mentor (master) who can lead, provide hints to co-workers, discuss approaches and solve hard issues whenever they appear. Counter-arguments that you must deal with: c1) Why not... Erlang? F#? See Jon Harrop's claims. Scala or Clojure? c2) Performance predictability. c3) On the fly script generation and execution. c4) Will your co-workers be happy of embracing a new paradigm of solving problems? Will type signatures appear as pain or a valuable thing to them? -- Leonel Fonseca. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
On Sat, Sep 4, 2010 at 5:53 PM, Michael Litchard wrote: > I will be going into a situation where there are tasks that have yet > to be automated, so I will be going after that before re-writing > anything. But if I can come up with "here's why", there will be less > eyebrows raised. Thanks for all feedback so far. Perhaps give this talk: http://donsbot.wordpress.com/2010/08/17/practical-haskell/ Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
I will be going into a situation where there are tasks that have yet to be automated, so I will be going after that before re-writing anything. But if I can come up with "here's why", there will be less eyebrows raised. Thanks for all feedback so far. On Sat, Sep 4, 2010 at 10:21 AM, Gaius Hammond wrote: > My usual rhetoric is that one-off, throwaway scripts never are, and not only > do they tend to stay around but they take on a life of their own. Today's > 10-line file munger is tomorrow's thousand-line ETL batch job on which the > business depends for some crucial data - yet the original author is long gone > and no-one dares modify in case it breaks. So it is just good sense to use > sound practices from the very beginning. > > > One of the features of Perl is that it will try to work even if you make type > errors (e.g. give it a scalar in place of a list, or a string instead of an > int). One day, however, it WILL fail. Haskell finds these types of bugs > upfront, and not when your pager goes off at 3am... > > > Cheers, > > > G > > --Original Message-- > From: Michael Litchard > Sender: haskell-cafe-boun...@haskell.org > To: haskell-cafe@haskell.org > Subject: [Haskell-cafe] help me evangelize haskell. > Sent: Sep 4, 2010 17:38 > > 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 > > > -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
My usual rhetoric is that one-off, throwaway scripts never are, and not only do they tend to stay around but they take on a life of their own. Today's 10-line file munger is tomorrow's thousand-line ETL batch job on which the business depends for some crucial data - yet the original author is long gone and no-one dares modify in case it breaks. So it is just good sense to use sound practices from the very beginning. One of the features of Perl is that it will try to work even if you make type errors (e.g. give it a scalar in place of a list, or a string instead of an int). One day, however, it WILL fail. Haskell finds these types of bugs upfront, and not when your pager goes off at 3am... Cheers, G --Original Message-- From: Michael Litchard Sender: haskell-cafe-boun...@haskell.org To: haskell-cafe@haskell.org Subject: [Haskell-cafe] help me evangelize haskell. Sent: Sep 4, 2010 17:38 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 --___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
