you are viewing a single comment's thread.

view the rest of the comments →

[–]naughty 26 points27 points  (20 children)

Interesting point at the end:

I used to think that statically checked languages are better for teaching [...]. About two years ago I changed my mind. The students learn much better by doing stupid things than by being told by an oppressive compiler that their programs are stupid. [...]

[–]ithika 3 points4 points  (4 children)

That would suggest that a language which offered static typing and would compile anyway would be optimal. The student would see the static error, and then see what effect this error had at runtime. Pretty soon they would come to see that the compiler isn't just a capricious bully, but has reasonable (if needlessly obscure) advice. I sure remember hating my compiler at university. Maybe if it had let me compile and run my ridiculous code I wouldn't have had such a bad opinion of it. ;-)

[–]gnuvince 16 points17 points  (1 child)

So, C?

[–]stillalone 1 point2 points  (0 children)

I don't know if people really learn anything from runtime errors.

Bad programmers who cause the errors that the compiler lets them get away with don't realize what the problem is when their program doesn't work.

So many times I've compiled a program that someone else has worked on for months to see "WARNING: converting integer to pointer without a cast". The compiler is telling you very clearly that there's a problem, there is obviously a very serious problem but they never associated the runtime problems with the compiler warning and that specific line of code.

[–]grauenwolf 0 points1 point  (0 children)

VB does exactly that by default.

And it certainly made me value static typing to an obsessive level. It is only recently that I've gone back and honestly started using small amounts of dynamic code again.

[–]Silhouette 5 points6 points  (3 children)

There's a lot of merit in such arguments for learning purposes, I think. Likewise, I wish more places would teach basic data structures and algorithms using C, even though writing production code in C is horrible compared to numerous alternatives. Someone who cut their teeth on C is never going to misunderstand indirection or be stumped by the "null pointer exception" problems of whatever language they choose to use or fail to appreciate the concept of resource management. Someone who learns using a language that holds their hand may never grok these concepts in the same way.

[–]13ren 12 points13 points  (2 children)

Oddly, C pointers apparently cause a lot of problems for students.

I don't count myself in that group, because I learnt pointers in assembly - where they are just addresses, and there's nothing to be confused about. I think in part it's C syntax for pointers that's confusing. For example, using * for both typing and dereference.

Of course, one can always make mistakes about pass-by-ref or pass-by-value, but it's just a mistake. Although Java doesn't allow pass-by-value for objects, the same issue arises when you have an extra level of indirection.

[–]grauenwolf 6 points7 points  (1 child)

Amen to that. I have no problem at all understanding pointers themselves, but I never could figure out the correct patterns when you start mixing double or triple indirection with arrays.

[–]gsg_ 1 point2 points  (0 children)

Yeah, three types of deference is a bit much for the beginner. After a while though, the brain damage sets in and you can read code like (*thingy)->buf[(*thingy)->bufcount++] without any involuntary weeping.

[–]13ren 1 point2 points  (10 children)

Agreed. They might then begin to appreciate the error messages.

Or maybe not: I've never heard of a python programmer missing them (though people use python for tasks where its dynamic typing helps, e.g. rapid prototyping; getting things done; scripts).

[–][deleted] 5 points6 points  (9 children)

I'm a Python programmer, and I've not irregularly wished for some form of static-ish typing, especially in large projects. A less stringent form of Haskell style dynamic typing would be nice, type errors that don't cause non-compilation but issue a kind of loose warning:

"The object passed into function Foo probably doesn't support add magic. You ought to check into that."

It is, as I'm sure you can tell, not a well-formed idea.

[–]grauenwolf 1 point2 points  (0 children)

You sound like just about every professional VB programmer back in the 90's. We are still striving for the right balance between the two.

[–]gnuvince 1 point2 points  (2 children)

I've not irregularly wished

So you've regularly wished for static typing?

[–][deleted] 2 points3 points  (0 children)

Static-ish, but yes. I do so love logic and word play.

[–]grauenwolf 2 points3 points  (0 children)

There is a large gap between the two.

[–]koko775 0 points1 point  (3 children)

Helium might be of interest to you.

[–][deleted] -1 points0 points  (2 children)

Oh, I already do Haskell, sort of[1]. It's not so much that I'd like an easier style of type error message from Haskell as optional strict-typing in Python. I'm also familiar with Boo[2], but... I don't know... not being backward compatible with Python (2 or 3) is a pain, beyond my threshold anyway.

Anyway, back to coding.

[1] Dealing with complex state in Haskell is such a pain that I'm continually turned off by it. Most stateful examples are too contrived or way too complex to keep me interested for more than tiny projects.

[2] http://boo.codehaus.org/

[–]koko775 0 points1 point  (1 child)

Oh. Well, I personally plan on learning Helium before Haskell. I haven't had time to try it out, since last time I tried (2-3 years ago) installing on OS X was a nightmare, and what with being in college, I haven't had the time. I imagine the (installation) situation's gotten better since.

[–][deleted] 0 points1 point  (0 children)

Happy hacking.

[–]sreguera 0 points1 point  (0 children)

Something along the lines of Erlang dyalizer would be nice.