Another great resource to learn functional programming. Thanks.
Teenage Haskell
71–80 of 93 posts
Re: Teenage Haskell
#72Earlier quoted context omitted.
That is an incredibly condescending way of arguing. On the other side of the coin you could claim that imperative programming is more practical, concerned with the actual steps needed to solve a problem, instead of an ideal, indirect formulation. Imagine having to explain someone how to bake an apple pie without being able to state any specific steps how to do it but instead describing the pie as some set of interrel…
Actually, I would point out that Lisp is not limited to any single paradigm... But something else you wrote brought to mind this rather interesting statement from - of all places! - the introduction to Michael Barnsley's famous book, 'Fractals Everywhere': 'In deterministic geometry, structures are defined, communicated, and analysed, with the aid of elementary transformations such as affine transformations, scalings…
I have no idea how your reply relates to my comment. I wouldn't claim that Lisp is limited to a single paradigm, nor do I see how fractals are related to the discussion at hand.
Re: Teenage Haskell
#73Earlier quoted context omitted.
Actually, I would point out that Lisp is not limited to any single paradigm... But something else you wrote brought to mind this rather interesting statement from - of all places! - the introduction to Michael Barnsley's famous book, 'Fractals Everywhere': 'In deterministic geometry, structures are defined, communicated, and analysed, with the aid of elementary transformations such as affine transformations, scalings…
I have no idea how your reply relates to my comment. I wouldn't claim that Lisp is limited to a single paradigm, nor do I see how fractals are related to the discussion at hand.
The point is that Lisp can be imperative too. But, because the language was not constructed according to the underlying physical architecture, it's not bound by the limitations of ALGOL-like languages.
So, rather than condescending, I find this interesting: these are two dissimilar approaches to solving problems.
Your comment about baking an apple pie 'without being able to state any specific steps how to do it but instead describing the pie as some set of interrelationships of the ingredients' was also an excellent statement of the differences between these points of view.
Barnsley's perspective was that relationships may indeed be a better way to describe structures. His concern was fractals, but perhaps the analogy extends to the logical structures that comprise a program.
Re: Teenage Haskell
#74Earlier quoted context omitted.
Here's a relevant comment I made just yesterday: https://news.ycombinator.com/item?id=7956162 In short, Scheme (Racket) is regarded as a superior beginner's language because of its simplicity, together with the ability to explore various paradigms (including OO). Beginners in Scheme subsequently did better with Java than those who started solely with Java. I think there's a deep lesson in that...
But scheme/racket is really not that far off from java compared to Haskell. I've never had a hard time working with it, even though I've never learned it formally (ok, two weeks of LISP a long time ago). Racket never felt weird, and many of its API are OO in everything but name, it's like C# with the same amount of FP abstractions (list comprehensions), and maybe some macros and continuations if you want to do someth…
Monads are pretty simple if you aren't pre-emptively primed with "monads are really hard."
I remember the day I sat down, worked through some examples, and grokked monads. I said, "That's it?"
That's not to say that they can't be hard to learn. I just don't think that they're _inherently_ hard to learn, and I think that they're sufficiently different enough from 'more traditional' CS concepts that said other concepts can hamper your ability to learn them. I suggest http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba... if you're still trying to figure them out.
Fun story: one time I had to suddenly explain monads to an English professor, because she overheard me say the word and said, "wait, Leibnitz?"
Re: Teenage Haskell
#75My brother (a Haskell programmer) and I (a teacher of high school CS) have talked about this often. He's postulated that teaching Haskell to kids with no programming experience would be an interesting experiment. Their lack of preconceptions regarding programming might make Haskell much easier for them to pick up, than it would for a student with experience in another language. What would be more interesting however,…
Speaking as your brother, the thing that tipped me onto the preconceptions thing was the odd student who, with no prior programming experience, declared "oh, I get it. It's just maths!"
I was the TA on the Edinburgh Haskell course over a couple of years, and took the attitude that, whether the students are any good at maths, they've at least seen it before, and so it was something I could use to bootstrap their understanding of the code they wrote.
The Edinburgh course is very nicely paced. Students aren't thrown in at the deep-end. In the first tutorial we had them composing pictures along similar lines to that shown in the OP. By the third tutorial, they're using their repertoire of maps, filters and folds to do basic web scraping. The most advanced stuff we assess them on is writing recursive functions on recursive data-types, like a function that takes a simple mathematical expression and evaluates it. Come the final exam, they can pretend they'd never heard the word "monad."
Re: Teenage Haskell
#76My brother (a Haskell programmer) and I (a teacher of high school CS) have talked about this often. He's postulated that teaching Haskell to kids with no programming experience would be an interesting experiment. Their lack of preconceptions regarding programming might make Haskell much easier for them to pick up, than it would for a student with experience in another language. What would be more interesting however,…
They actually do this at Imperial College, London for computer science. Programming 1 is 100% haskell [1]. The idea is to have a level playing field for all students as many may have had prior experience in imperative languages.
[1] http://www3.imperial.ac.uk/computing/teaching/courses/120_1
Re: Teenage Haskell
#77I never tried Haskell, or 'functional programming". To be honest, I don't even know what functional programming is. Can someone explain how is it different from Python or C (the only two languages I did little coding with)?
Some other descriptions here do a good job. It's worth being clear that "functional programming" is more of a set of similar but different programming cultures than a hard-and-fast language property.
That said, one thing that's more common in FP than anywhere else is an adherence to the notion that a variable stands for an "unknown" and not a mutable slot. Thus, you cannot assign to a variable but instead can only define it within a context.
x = 3
x = x + x
Typically, functional languages operate by giving "first class" domain to functions (thus their namesake). What this means is that you can both create and define functions as though they were mere values like integer or characters. To do so, to say define a function of one argument which doubles that argument, you use what's called abstraction
x . x * x
(x . x * x)(3)
3 * 3
9
square = x . x * x
square(3)
(x . x * x)(3)
3 * 3
9
λ x . x * x
So why does all this matter? In short, variables which behave as unknowns instead of mutable slots are very easy to reason about and functions as first class values are very expressive. When affixed to many of the other trappings of normal languages you have a very powerful basis for programming.
Re: Teenage Haskell
#78At UChicago, there are two introductory sequences. The Honors course, intended for students who are already comfortable programming, is taught entirely in Haskell.
Here's what it looks like: http://brick.cs.uchicago.edu/Courses/CMSC-16100/2013/lecture...
The normal introductory CS course is taught in Scheme. Actually teaching - even acknowledging the existence of - functional programming was a major reason I chose that department.
Re: Teenage Haskell
#79Earlier quoted context omitted.
I have no idea how your reply relates to my comment. I wouldn't claim that Lisp is limited to a single paradigm, nor do I see how fractals are related to the discussion at hand.
The point is that Lisp can be imperative too. But, because the language was not constructed according to the underlying physical architecture, it's not bound by the limitations of ALGOL-like languages. So, rather than condescending, I find this interesting : these are two dissimilar approaches to solving problems. Your comment about baking an apple pie 'without being able to state any specific steps how to do it but…
What are the "limitations of ALGOL-like languages"? As Turing-complete languages, they probably do not have actual limitations, rather, they suggest a style of programming which may be more or less applicable to particular problems. Functional programming, depending on how pure it is, does have limitations, notably avoiding mutable state.
You can claim that it's interesting that there are these two approaches, but the quotation you gave was definitely condescending, because it flatly states that one approach is better than the other, despite the widespread success of the latter. The argument that it's good to abstract as much as possible from the machine is interesting, but to me it is by no means obvious.
I don't really see the relation with fractals. Although it is an interesting quotation, the relation of fractals to real world phenomena is often very dubious.
Re: Teenage Haskell
#80Earlier quoted context omitted.
As a student of the TU Berlin myself, I feel that this has to be taken with a large grain of salt. In the first semester you learn one functional programming language, after that it's Java, C and MIPS Assembler. The functional programming language is Opal, a language developed at the TU Berlin, it has barely any documentation, a compiler that only works on Linux and OS X, that is if it works because it has quite a fe…
We were lucky in that Opal wasn't ready yet. :-P But we were horrified by what we heard about it. So we were spared that particular disaster, which was and is sold using the same "unquestionable superiority" rhetoric. Instead we dealt with Hope. As in "I Hope it will finish in the next 15 minutes". "It" being a 10-30 line program. Usually it didn't, instead producing a largish coredump. Our Sun 3-50 diskless workstat…
Well you have to take into account the amount of effort, time and manpower spend on different languages and (in-)directly on different paradigms.
FP hasn't been given as much attention as imperative programming languages, especially not when it comes to the important last step of language development, which turns ideas that are nice in theory into tools that are actually convenient to use.
Java is a good example for how much that matters. The language is inelegant and makes it impossible to express yourself concisely nevertheless the tooling is incredibly good, so good that it makes up for quite a few surprises.
A FP IDE that for example shows you inferred types and type errors while you are writing the code, would already help a lot as it could much better visualize the problem, than a compiler that has to describe an error purely with text.
FP languages are not perfect, no language is but they have the potential to be much more powerful in lot of ways than imperative languages. Lisp is a good example for this although it's also a good example that such power can corrupt people to use macros in awful ways.
In any case when it comes to the rhetoric especially from professors, you have to take into account that they have spent their entire life specializing on what they are doing. Of course they are excited by what they are doing and even if they aren't they have a good reason to lie to themselves consciously or not because the alternative is acknowledging they wasted their life on bullshit. They are biased and that's ok, you just have to be aware of it.