High school programming taught in Haskell in Argentina
sawafaso.blogspot.com.ar
sawafaso.blogspot.com.ar
Then I stopped to remember the process. It has been ridiculously hard. It has required a ton of engagement on my part. Without me being a constant cheerleader it would go absolutely nowhere. My kid likes programming but, let's face it, today there are tons of distractions and you are in competition with all of it.
I would imagine it is really hard to teach a random group of 14~16 year olds. I would really like to learn more about this from others with experience in this area.
It may not be the best language around, but it's simple and you can make something that works in Windows ridiculously easy. If they show continuous interest, then they will hear about some other languages but most people just want to see something working with buttons and text boxes and then after a few weeks they lose interest.
It's like going to the gym, some of us love it but it's not for everybody. And if it's your first time, don't spend time with a complex routine... just run on the treadmill until you feel tired. If you like how it feels, then you will keep coming back, and if you don't, you didn't waste time doing the advanced exercises that are useless without continuous workouts.
Disclaimer: I told them that programming serious applications takes a lot of time, hard work and lots of reading and practicing. They just wanted to make toy applications. They were instructed to never deal with secure applications or production critical applications until reaching programming enlightement.
In the 1990's C# didn't exist and to it was much difficult to create a GUI in C++ than in (Classic)VB.
I started with Applesoft BASIC on the Apple II series and I'm not so sure about the bullshitness of the argument. Dijkstra was not talking about VB at the time. It's nearly impossible to explain recursion in terms of "classic" BASIC.
I'm lucky I also learned C and FORTH (through the wonderful GraFORTH environment). Because of that, the quality of my Basic code (my first job was programming educational software for Apple IIs) was much increased.
In order to properly assess the damage, you must ask yourself how comfortable you feel with concepts that cannot be expressed in your first (or "native") language.
After a certain point in your progression, you realize that you can make certain type errors deliberately so that the type checker will tell you what types it's expecting. This is when it all clicks! The type checker is a tool that lets you query for information about your program. It's an immense aid to reasoning and a powerful sanity check against your assumptions. This is a capability that less strictly/statically typed languages lack and it can lead to a lot of surprises and guesswork.
Some new features like deferred type errors and type holes are going to really help with this. Especially once editors start taking full advantage of this. I think that this is the future of programming: not writing a program and then debugging it, and not even just working in a repl, but being actively guided by your tools seamlessly as you write your code. Having a dialog with the compiler.
Not to mention the traditional argument for lisp as a teaching language: the extremely simple syntax. For somebody who hasn't seen code before, lisp would look just as weird as any other language, so the unfamiliarity argument doesn't hold much water. Prefix notation isn't at all difficult to learn, (+ 1 2) would be just as weird as dividing using / or multiplying with *, and using % for modulo division. You just tell the students that this is how you write math with a keyboard(a white lie at worst:).
I'm currently working on a "try ruby" like tutorial to interactively teach FP using racket to college students, as my last year project.
Sure. But it is a slower feedback cycle then a good IDE (which tells you what it is expecting as you type it). Also, the same can be said about an interpreter: you can try things, and when they fail, it lets you know what it was expecting.
There is a good reason why one of the most important Forth books was titled "Thinking Forth". Lisp is also very different from C and Java, and you have to change your thinking radically to understand and to apply the power of Lisp. Now I am determined to learn Haskell, and I believe that I have to change my thinking much more into a mathematical approach.
Pointers? Really? Nothing could be simpler so long as you understand how a basic microprocessor works. Perhaps I see it this way because I started my programming experience typing machine code into a hex keypad. I can see that someone who comes from a frame of reference devoid of low level exposure can get confused by something as simple as pointers.
Even so, easy teaching analogies abound, for example: A pointer is the number of the post office box. The data is what it contains.
You should start with basic prcedural languages first leave OO for later
The main issue was their intrinsic interest/motivation/discipline. It is important to note that I am talking about average kids with curiosity.
Now I feel that is extremely easy to teach kids with the tools in hand but parents must start slowly. Programming languages like C have many concepts (i.e.: pointers) that must be added at a later stage. I think even Alice 3D or Scratch are complex. I feel the Logo approach is the right one (a graphic feedback and an immediate command line at the same time). Also, combining the manipulation of real objects like cars and robots with programming is an excellent approach.
Colour me surprised.
My kid has not has difficulty learning. I never said that. The challenges are in maintaining interest because there are other attractors that lure kids away. There are a lot of things that are vastly more fun than programming. For example, I'd rather go sailing, kayaking, fishing, scuba diving or mess around in the garage than sit in front of the computer programming for ten hours.
Perspective is important.
You basically gave your child a job training, concentrating on technology which is popular today (and probably at the time when he is looking for a junior maintenance developer position, too). Nothing wrong with that.
If I decided to teach my child programming, I would certainly try and pick the best, most consistent, fun & exciting, state of the art technologies out there which would expand the mind of my child about what's possible today and inspire my kid to push the boundaries when he grows up (if he/she ever decides to pursue that career option).
Different decisions, and one could make the case for both.
Really, saying that these are "the most horrible to learn languages" is beyond my comprehension. There's nothing "horrible" or, for that matter, difficult about any of them.
C is easy as pie. It's the most fundamental language.
Forth is a super-cool game. My kid already rocks on an HP-41 calculator (RPN). When I introduced him to Forth he literally said: "Wow! I can program in RPN!".
Java, was a short stepping stone as I wanted to give him a quick taste of OO but not drown him in the details. He actually wrote a dozen little games with graphical interfaces and all. Great fun.
Now with Python we are going through the Project Euler site problem by problem implementing solutions mostly in Python but then looking at C and Forth where it makes sense.
It's hard work. At the same time I like it because it keeps me on my toes. At one point I'll have to choose whether to move him towards developing, say, iOS apps or web apps. In other words, there's at least one fork in the road ahead.
However, the principles are all the same. The constructs are fundamentally equal. A state-machine driven website is no different than a state-machine driven iPhone app. Same concepts, you just "say" them differently in code.
And so I fail to see or agree with people who make categorical statements such as "C is horrible" or "C is hard to learn". I don't get it. Yeah, from the vantage point of someone with no frame of reference whatsoever even basket-weaving is horrible and hard to learn. At one point you start taking steps towards learning and, if a good foundation is built, nothing is really horrible, difficult or impossible to learn.
To me, C is the foundation of nearly all you'd want to understand in programming. Only assembler would give you more perspective. I have written plenty of software with complex data structures in assembler. Not for the weak of heart, but you do learn a lot. With a solid foundation in C you can undertake just about anything in any domain, from embedded to web and mobile programming.
So, yes, I felt that taking what I said so far out of context and then expressing surprise for your own made-up statement had to come from ignorance. Perhaps I shouldn't have said it the way I did. So, again, I apologize.
C is easy as pie. It's the most fundamental language.
Forth is a super-cool game. My kid already rocks on
an HP-41 calculator (RPN). When I introduced him to
Forth he literally said: "Wow! I can program in RPN!".
Java, was a short stepping stone as I wanted to give
him a quick taste of OO but not drown him in the
details. He actually wrote a dozen little games with
graphical interfaces and all. Great fun.
Now with Python we are going through the Project Euler
site problem by problem implementing solutions mostly
in Python but then looking at C and Forth where it
makes sense.
That would have been a sound choice ... in 1990. Since then, there has been a lot of progress in language design.C is fundamental, but calling it “easy as pie”? 90% of C consists of undefined behaviour, just waiting to screw you over.
Forth ... why not some Lisp instead? I don't like Lisps in general, but they are at least not as completely obscure as Forth.
The designers of Java had some good ideas, but the execution of the language itself is terrible. Java is what gives OO a bad name, why not pick a language which is good at OO?
Python, well sounds sort of OK, at least no PHP or JavaScript.
====
I guess my choice would have been something like that:
- Assembler - ML/OCaml/ATS/Rust - Scala - Haskell
I've been coding in C for thirty years. Anything from mission critical embedded to system code. I've never been screwed over by the language. So it is reasonable to assume that I just don't get it because I haven't had the experience. Is it because I started at a very low level and have a solid foundation? Don't know. I've seen people comment on C being horrible and hard to learn and I can't find any scenario in my life where I, even remotely, had that opinion of the language. It is easy. Very easy.
> Forth ... why not some Lisp instead?
I wanted to expose him to the ideas of TIL's. They are very powerful, particularly if you think embedded.
Yes, I'll teach him Lisp too. I can't throw everything at him right now. Remember, he's only 14.
So, C laid the foundation. Java doesn't look too weird. It's easy to make the transition from C to Java at a basic level. I am not having him do anything massive in Java so he isn't running into the ugliness. This is more about teaching conceptually than anything else. I used Java to teach him about basic OO. For that purpose it worked just fine.
Forth was a trip in a different direction. The concepts from C can be applied in that conditionals, looping, arrays and other constructs can still be executed in Forth. It's an interpreted language, which makes it different and fun. I made sure I got him rocking on an HP41 calculator first. He used the HP41 in school for a year before I revealed Forth to him. After being comfortable with C and the HP41 the transition to RPN programming was easy. The interpreter made it fun for him to experiment and learn. I saw huge value in this.
As for Python, well, I like it.
PHP, JavaScript. He will learn those if we push in the direction of web design. They are easy. Perhaps my point is that with a solid foundation in programming all languages are easy. I have yet to run into a language where I stop cold and say "Wow, this is hard. I don't understand it. It will take ages to learn.". Quite the opposite, there's a huge ecosystem of languages that are C/C++ like. Easy to learn. In most cases you spend more time learning libraries and "the way of..." but that's it.
Take something like Objetive-C. Once you get past the notation/syntax quirks it's all about knowing what's available to you in the libraries and off you go. There's nothing hard about O-C. If you have a solid foundation in memory allocation through C it is easy to understand memory allocation in O-C.
The last age survey on HN showed that the site is dominated by folks in their twenties. Perhaps this is the reason things are seen as "hard" or "horrible". Not enough experience. Or, what could be worst, not enough experience solving difficult problems. Not to get political, but our youth lives within a level of entitlement and "I want it easy and now" mentality that I can see someone looking at C and saying "It's hard, I want it easy" in a five year old voice.
As an older engineer I stopped seeing things as hard a long time ago. There's nothing I cannot do given the time, dedication and the right mental attitude. I've walked into territory I knew nothing about many times over the years. After you do that a few times your approach and your view of things changes.
It's like the first time my oldest kid had to swim in murky lake water to enter our local Junior Lifeguard program. He was freaked out. A life of swimming in a clean pool. Now you jump into water where you can't see the fingers on your hand. He was kicking and screaming for half an hour. I didn't let him quit. He eventually passed the test and got into the program. Now, a couple of years later, we went for a swim in the ocean. His demeanor was completely different. Instead of being afraid of the waves he asked the right questions: How do we approach this? What's the best entry/exit technique? What can go wrong?, etc. We had a great time.
Everything in Argentina can be awful, but for sure it's not education: even if we are not learning Haskell I'm really pleased with the education I'm recieving; we use free software when possible (LibreOffice, LibreCAD, MySQL, etc.) and we learn languages like C or Java (OK, not the best in the block, but at least it's not VisualBasic).
Sadly we can't get good programming books here (Such as O'Reilly, Apress or books like CLRS, APUE or SCIP). So we either rely on our teachers or in crappy, old books.
Teaching 15-16 years old to program is not easy, mainly because many of those really don't care about school... we start by learning Algoritms as in little pseudocode programs, then we move to a software called PSeInt which is basically an IDE for writing pseudocode (Pseudocode in Spanish... ugh) and finally we learn our first language, which is chosen by the teacher (We are learning C).
I've been programing since I was 9. And it's interesting to see this from other perspective, the teachers are young (26-36 aprox.) which is good, because they know about the latest technologies are have similar hobbies to us. But it's also bad because they don't have a lot of experience).
But so far, so good, the education in the Systems branch is really good: but beware, not everything is like this, for example we are lacking a Chemistry teacher and we only had like 4 classes of Physics in a year, not to mention our Mathematics teacher is a disaster.
The school isn't in a good condition either, we have leaks when it rains and we are lacking a few walls and windows... but hey, it does it's job.
That's very much relative to where you look. There are very good high schools and universities. Notably, there are very good <i>free</i> universities. But that's mostly in Buenos Aires city. The education system as a whole is in an awful state. Most schools in the rest of the country are in a very poor state. And as you mention the state of the buildings in even dangerous in some cases.
I think it also suggests that math concepts are not taught properly either. We tend to focus on the mathematical operations rather than the abstractions. (Khan Academy is a good counter example). It would be interesting to see a combined CS (with Haskell) course taught in tandem with math. At the high school I went to, there were several courses like that (calculus + physics, or American History + American Lit).
After 4 or 5 weeks we wrote a calculus solver (able to do a lot of pretty interesting integrals and differentials, just from first principles).
However the best choice for learning to program (in my opinion) is a language like Logo where you can immediately see your results and the concepts are incredibly simple.
Also in that vein https://www.coursera.org/course/programdesign says it needs only a grade-school background.
I think there are always only going to be a small set of kids in the class that will get or understand programming anyway, without resorting to just "simpler" forms (such as Scratch, for example).. whether this is a good thing, is of course up for debate, but regardless..
These days, I think (as a parent) I'd be pleased if the school was teaching Haskell, so from a personal perspective: +1 Argentina schools, keep at it!
A long time ago, I had wondered if Lisp would be a better introduction to programming for beginners. Now we can see some practical experiences from this attempt to use Haskell.
I looked at the code samples provided; from a cursory review, the fourth class code looks to be purely functional, although fairly simple.
The fifth second class code is more advanced code, but a lot of it is procedural. I wonder if Haskell experts might weigh in here -- is it worth doing Haskell with so much procedural code?
I am a novice in Haskell, but I have tried to embrace its functional nature entirely. I think I would advocate learning Go or Python rather than Haskell if the code is going to be procedural anyway.
It is a horrible language, but you can quickly do stuff that you can see everywhere on every browser, you can quickly show them to the world, you can host them everywhere, there is no compilation/porting/deployment/etc. that you have to go through to actually run your stuff and be excited.
That is, I think, more important than teaching a language with perfect object model or perfect lambda calculus.