“You might find it easier to use languages like Perl, Python, or Ruby…” In a nutshell, which of these to start with? I’m totally clueless. And it all seems so daunting. Yes, I’m a big user of little nifty tools/utilities you programmers put out, free to the world. It’s simply amazing what you programmers accomplish. I’m always searching the web to find new ones. But it would be terrific to be able to do some of that myself – if I could find a good practical ‘tool’ to make my own little tools, to extemporaneously cobble together as needed. Nicholas From: Joseph Fredette [mailto:jfredett@gmail.com] Sent: Friday, April 27, 2012 3:06 PM To: nkormanik@gmail.com Cc: beginners@haskell.org Subject: Re: [Haskell-beginners] Haskell as a useful practical 'tool' for intelligent non-programmers It seems to me that what you're looking for is a way to build tools suited to particular tasks, subject to particular performance constraints. If you're goal is to be able to build these tools yourself, I would say that, by definition, you are intending to be a programmer; inasmuch as a programmer is a person who's job is to build tools using a tool-building tool. To that end, I recommend Haskell as a good language to use to build performant tools, especially for stuff like data-analysis, where speed is a factor. Branching out from there, you may want to look at and learn about Hadoop and similar technologies, MapReduce is a very powerful tool for large-scale data analytics. Along those lines, languages like R are optimized for datacrunching and data visualization, and are certainly worth learning about. So, in essence, I guess I'd say that if you're intention is to learn about practical, generic tools; then by definition your intention _is_ to be a programmer, and therefore you may want to consider approaching the problem from that point of view. If your goal is merely to consume tools -- perhaps writing a small amount of code, you (I think) still have intention (if unseen) to be a programmer, but you might find it easier to use languages like Perl, Python, or Ruby -- which have large standard libraries, good ability to function as "glue" and low syntactic and semantic overhead (that is to say, they're a bit easier to write) than some languages (eg, Erlang, Haskell, R, etc.) That's not to say it's hard to write good code in the latter set of languages, merely that it requires (I think) more understanding of a potentially more complicated model (especially true with haskell). I don't know if that answers your question, I hope it helps. /Joe On Fri, Apr 27, 2012 at 4:16 PM, Nicholas Kormanik wrote: I am not a programmer, and have no intention of becoming one. I'm a stock and options trader. MetaStock is one of the primary programs I use. Other statistical and mathematical programs as well. Very often when some small need arises, I Google-search for a solution. There seems to be any number of freeware utilities out there in cyberland -- and more all the time -- that do pretty much whatever is needed. Additionally, Mathematica (as one example) has a powerful programming language built in. So, my question is: Does it make practical sense to spend time learning Haskell for the purpose of adding it to my assortment of 'tools' -- to quickly do this or that, as the need arises? Is there any better general practical 'tool' (or, if you want, 'programming language') to add to my arsenal. Thanks for your comments and suggestions. Nicholas Kormanik _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On Sat, 28 Apr 2012 15:50:36 -0600 "Nicholas Kormanik" wrote:

A bit frustrating that you mention four as candidates: "Groovy, Clojure, Ruby, Python."

I'd not recommend starting with Groovy or Clojure. While Clojure is a great language, the most popular implementation is hooked into the JVM, and you wind up needing to deal with a lot Java infrastructure fairly quickly. Being able to use that infrastructure is a design goal, but adds to the learning curve. I haven't looked into Groovy, but suspect some of the same issues will arise (and hope a Groovy programmer will correct me if I'm wrong). Ruby makes a bad fit if Haskell is a goal (and that's a good goal). Ruby functions aren't first-class objects, and can't simply be passed to other functions as arguments. Last time I looked, there were a half-dozen workarounds for that, none of them really very elegant. That ability is a critical feature in Haskell. Python at least allows it, though it's not as nicely integrated as in Haskell, or even Clojure.

But it sounds like you are leaning toward recommending Python as the best way to start.

Given those for, and that this is a Haskell list, I'd certainly agree with that. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Your first example is not behaving how you think it is... ruby-1.9.2-p0 :012 > def foo ruby-1.9.2-p0 :013?> puts "foo" ruby-1.9.2-p0 :014?> end => nil ruby-1.9.2-p0 :015 > def call_arg(f) ruby-1.9.2-p0 :016?> puts "calling" ruby-1.9.2-p0 :017?> f ruby-1.9.2-p0 :018?> end => nil ruby-1.9.2-p0 :019 > call_arg(foo) foo calling => nil Note that "foo" is printed before "calling". On Sun, Apr 29, 2012 at 10:22 AM, Michael Orlitzky wrote:

On 04/28/2012 08:47 PM, Mike Meyer wrote:

...

Ruby makes a bad fit if Haskell is a goal (and that's a good goal). Ruby functions aren't first-class objects, and can't simply be passed to other functions as arguments.

That's like, the least true thing you can say about Ruby =)

A simple test program:

 $ cat fcf.rb  def foo    puts "foo"  end

 def call_arg(f)    f  end

 call_arg(foo)

Running it:

 $ ruby fcf.rb  foo

Moreover, every function and method implicitly accepts a function as an argument:

 $ cat yield.rb  def call_block    yield  end

 call_block { puts "foo" }

This allows you some nice do-block syntactic sugar instead of lambdas which can get ugly.

 $ ruby yield.rb  foo

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On Sat, 28 Apr 2012 22:22:34 -0400 Michael Orlitzky wrote:

On 04/28/2012 08:47 PM, Mike Meyer wrote:

...

Ruby makes a bad fit if Haskell is a goal (and that's a good goal). Ruby functions aren't first-class objects, and can't simply be passed to other functions as arguments.

That's like, the least true thing you can say about Ruby =)

I respectfully disagree. For instance, I could have said that it uses indentation to delimit blocks like ABC does. That's much less true. But I believe the statement about functions not being first class objects is true. Of course, I don't use ruby on a regular basis because that turns out to be the case every time I go look at it. If the language has changed so this can be done in a manner that's as straightforward as Python, I'd be interested in hearing about it. For the record, the Python version of your example is: def foo(): print("foo") call_arg = apply call_arg(foo)

A simple test program:

$ cat fcf.rb def foo puts "foo" end

def call_arg(f) f end

call_arg(foo)

And that would do it, except, as Lyndon explained, it's not doing the right thing. You provided one of the workarounds (using Proc) when you corrected it.

Moreover, every function and method implicitly accepts a function as an argument:

Doesn't quite seem that way to me.

$ cat yield.rb def call_block yield end

call_block { puts "foo" }

This allows you some nice do-block syntactic sugar instead of lambdas which can get ugly.

They are accepting a *block* as an argument. And you're right - blocks are cleaner than lambdas. It's also more powerful than Python's lambdas, which are restricted to being expressions. A lot of people (me among them) would like Python to have something like Ruby's block construct for anonymous code, and there are regular proposals on how to do it (including from me). If someone ever comes up with a way that both reads well in an indent-delimited language and doesn't invite incredible abuse, it'll probably make it into the language. But that doesn't make a function a first class object. It doesn't even make a block a first class object (can I give a block a name?). There are other ways to work around this limitation (I think I found 6 last time I looked). IIRC, the Proc version was about the cleanest. Note that I *didn't* say that this limitation makes Ruby a bad language. I don't like it, because I find that languages that don't make functions first-class objects grate on me. If it doesn't bother you, you're a better person than I am. That's why I added the proviso "if Haskell is a goal". Trying to go from a language where functions can't be treated as first class objects, requiring wrapper objects and similar things in order to write in a functional style to one where a functional style is de rigueur just seems like a bad idea. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Sun, 29 Apr 2012 01:20:22 -0400 Michael Orlitzky wrote:

On 04/29/2012 12:15 AM, Mike Meyer wrote:

...

On Sat, 28 Apr 2012 22:22:34 -0400 Michael Orlitzky wrote:

...

On 04/28/2012 08:47 PM, Mike Meyer wrote:

...

Ruby makes a bad fit if Haskell is a goal (and that's a good goal). Ruby functions aren't first-class objects, and can't simply be passed to other functions as arguments.

That's like, the least true thing you can say about Ruby =)

I respectfully disagree. For instance, I could have said that it uses indentation to delimit blocks like ABC does. That's much less true.

But I believe the statement about functions not being first class objects is true. Of course, I don't use ruby on a regular basis because that turns out to be the case every time I go look at it. If the language has changed so this can be done in a manner that's as straightforward as Python, I'd be interested in hearing about it.

They're wrapped in Proc objects, but those objects can be treated like any other in the language. Everything else is just syntactic sugar on top of Procs.

That makes *Procs* first class object, not functions.

This is not conceptually any different to me than in Haskell or C; you have a name for the thing, distinct from the thing itself, and you have to ask for function application via (f x), f(x), f.call(x), or whatever.

And if having the same set of concepts were all that mattered, we'd still PERFORMing blocks of code. The syntax of a language makes some things easier to do, and some things harder - that's why there's more than one of them. Writing HOFs is harder in ruby than in a language with first-class functions, because you can't pass a function to a function. You have to decide which of the workarounds you want to use (blocks or lambdas or Methods or Procs or ...). If you want to use a function from the standard library - you have to wrap it in order to pass it to your HOF. Since "all of the above" isn't a valid choice, if you're trying to use a library of HOFs (assuming such exist in Ruby - and if they don't, that's yet another reason Ruby isn't a good way to get to Haskell), you may wind up wrapping some things multiple times, or wrap the results of your HOFs, or ... well, you get the idea. None of this makes Ruby any better or worse for anything other than writing code in a functional style. There are perfectly usable languages that can't do HOFs at all. That you can do it at all makes Ruby a better choice than them for writing functional code. But it requires a lot of code that's nothing more than boilerplate, which makes it worse than languages that don't require such. Of course, if you don't think boilerplate makes things harder, and all that matters is having the same concepts, then I expect you won't argue if I claim that there's no reason to pick Ruby over Java for writing OO code. After all, they have the same concepts, just with different syntactic sugar and more or less boilerplate. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Sun, Apr 29, 2012 at 03:32:48AM -0400, Michael Orlitzky wrote:

On 04/29/2012 02:35 AM, Mike Meyer wrote:

...

On Sun, 29 Apr 2012 01:20:22 -0400 Michael Orlitzky wrote:

...

They're wrapped in Proc objects, but those objects can be treated like any other in the language. Everything else is just syntactic sugar on top of Procs.

That makes *Procs* first class object, not functions.

What's the difference? You're not passing around the actual function, in any language.

$ python Python 2.7.3 (default, Apr 14 2012, 23:17:33) [GCC 4.7.0 20120407 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

def f(): ... print 'foo' ... def g(f): ... print 'bar' ... f() ... g(f) bar foo

Also: http://en.wikipedia.org/wiki/First-class_function#Language_support L. -- Lorenzo Bolla http://lbolla.info

If you're interested in OS integration, it may be worth learning C# if you're on windows. It's certainly quite amenable to 'glue', and it's gaining more functional features all the time. Also, you have the option of branching out to F# if you enjoy the .Net environment, but crave a purer language. I'd probably consider some combination of .Net and Mathematica if I were doing trading on Windows and didn't mind paying for the software, but it might not be a popular opinion :-) Disclaimer - I don't really know how trading works in practice. On Sun, Apr 29, 2012 at 10:56 PM, Michael Orlitzky wrote:

On 04/29/2012 10:28 AM, Lorenzo Bolla wrote:

...

...

What's the difference? You're not passing around the actual function, in any language.

$ python Python 2.7.3 (default, Apr 14 2012, 23:17:33) [GCC 4.7.0 20120407 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

...

def f(): ...     print 'foo' ... def g(f): ...     print 'bar' ...     f() ... g(f) bar foo

Also: http://en.wikipedia.org/wiki/First-class_function#Language_support

You're not passing around the function, you're passing around the name of the function or a pointer. Python happens to know that when you write f(), you want to evaluate the function named f, much like when you say f.call() in Ruby.

Ruby doesn't even have functions, only methods, so you have to entertain the idea that the same thing can have two different names to even have this discussion. Passing functions to other functions is so fundamental to Ruby that it's baked into the language:

 irb(main):001:0> [1, 2, 3].map { |x| 2*x }  => [2, 4, 6]

They're not called functions, but the distinction is imaginary. For an imperative language, the culture pretty strongly encourages you to use map, filter, fold etc. which are all passed functions (Procs) using the block syntax.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On Sun, 29 Apr 2012 03:32:48 -0400 Michael Orlitzky wrote:

On 04/29/2012 02:35 AM, Mike Meyer wrote: We were never talking about easy, only possible.

You may not have ever been talking about easy, but that's pretty much all I've been talking about. In fact, that's my point: functions not being first-class objects in ruby makes functional programming in it harder. This makes it a poor choice if haskell (or any other language where functional programming is de rigueur) is the goal. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On 28 April 2012 22:50, Nicholas Kormanik wrote:

** **

Greatly appreciate your sharing these thoughts.****

** **

A bit frustrating that you mention four as candidates: “Groovy, Clojure, Ruby, Python.”****

** **

But it sounds like you are leaning toward recommending Python as the best way to start. ****

** **

Nicholas****

**

No. I'm the person who mentioned all four of those as examples of languages that are good for web scraping. I then went on to say that given what I **guess** you might need to do that Python is the "no-brainer" best. You really don't say enough for anyone to be sure though - if you want to implement some very time consuming numerical algorithms and have them run fast then CUDA might be the only option. (In which case you're probably out of luck, because CUDA programming isn't for amateurs.) Or for less demanding numerics centred around stats and matrix ops, the R could be a better choice than Python and Sagemaths: http://en.wikipedia.org/wiki/R_%28programming_language%29 ..and R will webscrape too: http://www.programmingr.com/content/webscraping-using-readlines-and-rcurl If you want to do stuff like time series analysis then you'll probably find more books and papers using R: http://www.stat.pitt.edu/stoffer/tsa2/R_time_series_quick_fix.htm

...

Mike Meyer: Ruby makes a bad fit if Haskell is a goal (and that's a good goal)

...

While Clojure is a great language, the most popular implementation is hooked into the JVM, and you wind up needing to deal with a lot Java infrastructure fairly quickly. Being able to use that infrastructure is a design goal, but adds to the learning curve. I haven't looked into Groovy, but suspect some of the same issues will arise (and hope a Groovy

I don't see it as being a goal for this guy! He just wants to be able to write utilities he needs without bogging down in "becoming a programmer." programmer will correct me if I'm wrong).<< I played around with Groovy for a weekend to write some utilities and a music generation program. I can't remember having to put any effort into "needing to deal with a lot Java infrastructure," even though I was using a midi library written for pure Java. But I'm not really sure what you mean (installing a Java compiler?? doesn't seem like a lot) and it doesn't matter - Python/Sagemaths and R seem like the most reasonable tools without spending big money. Re. the OP's needs: learning a programming language isn't enough to write programs that work correctly. You will need to learn how to design and debug code if you're writing more than very trivial apps. Take a look at something like Kernighan and Pike's "The Practice Of Programming." There is no magic language that let's you write code "without becoming a programmer." Some are easier to learn than others or offer more functionality in particular areas, but writing even moderately complex programs that really work - rather than just seeming to - requires reasonable practice, some book knowledge, and lots of discipline. Programs are treacherous and deceptive and it requires skill just to verify that they are working reliably.

**

** **

*From:* umptious [mailto:umptious@gmail.com] *Sent:* Saturday, April 28, 2012 9:39 AM

*To:* nkormanik@gmail.com *Cc:* beginners@haskell.org *Subject:* Re: [Haskell-beginners] Haskell as a useful practical 'tool' for intelligent non-programmers****

** **

** **

On 27 April 2012 21:16, Nicholas Kormanik wrote:****

So, my question is: Does it make practical sense to spend time learning Haskell for the purpose of adding it to my assortment of 'tools' -- to quickly do this or that, as the need arises?

Is there any better general practical 'tool' (or, if you want, 'programming language') to add to my arsenal.****

No one can give you advice on what tool to use without knowing what the task or who you are in more detail than you provided. And you're often better with several tools than "general" one - trying to saw with a hammer isn't easy.

Unless you're unusually smart in the IQ sense and/or have a maths or formal logic background, then I'd say that Haskell would be a miserable choice for a first programming language.

As for tools you might look at for tasks that I ***guess*** that a trader is likely to want to do:

- For web scraping and text mining, Groovy, Clojure, Ruby, Python and (maybe) Perl are reasonable choices

- For both number crunching and symbolic maths, look at sagemaths (which is scripted in Python) - it's a reasonable free alternative to both Matlab (number crunching) and Mathematic (symbolics)

..Which I suppose makes Python the no-brainer choice. Python is easy to learn, the community is supportive, there are lots of reasonable books and tutorials. I think it also has stuff around for working with Excel spreadsheets, which I'd imagine you might want to do.

Haskell is actually a better language than any of the above (leaving aside learnability and without defining "better") but for real world use libraries count more than language features. It would take you years to write the equivalent of sagemaths in Haskell, which rather negates Haskell's advantages if you need that functionality.****

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

umptious wrote:

...

To someone marginally skilled at logical thinking Haskell appears to be the first choice as the first programming language. I'm offering two experiences as a reference:

* A friend of mine with no technical and no math background wanted to learn programming. I decided to go with Haskell, because it would be an interesting experiment.

The experiment turned out to be very successful.

I suspect that most experiments in teaching programming languages with one-to-one tuition are! If the guy had posted saying "Hey, I have a friend who knows Haskell really well and wants to teach me" then I'd have said that he should very seriously consider it.

Your message is not related to my post, and a good indication is that the given quote is incomplete even for the purpose of making the point of that particular experiment. Then that point alone is also not enough either, because there is a strong connection between the two examples I mentioned. All in all you apparently didn't understand a word of my post. My statement is not about teaching, it's about learning and I'm pretty sure it is very solid. On the other hand, your suggestion to avoid Haskell unless you have a high IQ or math/formal logic background is entirely unfounded. If you make a claim like this, you should provide some reasoning. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

A 29/04/2012, às 19:43, Ertugrul Söylemez escreveu:

Hello there,

actually I did not want to participate in this discussion, but as I have experience teaching many programming languages to many different sorts of people, I feel obligated to share my observations.

To someone marginally skilled at logical thinking Haskell appears to be the first choice as the first programming language. I'm offering two experiences as a reference:

* I had to teach C++ to a math student. The language was very hard to grasp, because as someone with math skills you practically have to go back to stone age. Instead of writing equations and relationships you have to imagine yourself sitting before a large array of little slips of paper and manipulate them arithmetically to reach the goal you want. Remember that the array is your memory. You don't have a brain in C++. This was about the most difficult part and the whole thing turned out to be a very frustrating endeavor, because you basically have to temporarily forget what you learned in university.

Yes ! As someone who studied pure maths for 6 years, Haskell seems so natural and elegant to me, yet so alien to about everyone else I know that are very good coders already in other languages. When I’m reading about Haskell, I’m constantly like “yeah, that’s like it’s done in mathematics !”, the type of discourse is the same, the same relentless obsession with finding more general models of things, getting what are the fundamental properties of something and then generalizing (what is an open set ? -> topology, what is summing ? group theory, algebras, etc ) until you hit the stratosphere (category theory...). Specially since discovering functional programming I have a hard time coding in imperative languages because my times studying math refined my taste for elegance and I find it quite rare to find elegance or beauty in imperative code, where I find it a lot in functional code. In the end for me it has really become an aesthetic choice. This is such an insightful post ! Thanks ! best, Miguel Negrão