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 p
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
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 n
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
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:
>
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
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
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/concis
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 hask
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
> origina
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,
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 bet
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 be
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 lan
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
chael 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 automatio
). 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 evangeli
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
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 in
19 matches
Mail list logo
