A) It's kind of presumptuous to show up in an esoteric lisp community and ask them to adopt C-style comments for your sake.
B) "We think for a while before typing" is the worst excuse ever for a hard-to-type construct. Why not just make it easy? Especially for comments. Make bad code hard to type.
I was wondering how the waterfall model would be justified when the pendulum started to swing back from manic styles like XP and TDD. The idea that you can't play around with your code and experiment with it right away before thinking too hard is just silly. Many of the nice points about functional languages are precisely that iteration time can be really low. A dev should smack this person for messing with the bugtracker of a project that should be better than this.
Encoding system information into a string should be a last resort. That's why a good type system, where you can encode EscapedString [Char] versus UnescapedString [Char] as strings of different types, where you have to work hard to do a safe-to-unsafe cast, that good type system is vastly better than prepending esc and unesc to variable names, and hoping that you don't mess up.
Making commenting easy is like spending a lot on orphanages; good in the short term, but causes problems in the long term. You want to document as much of your intent in code as you can, and Haskell makes that easier than, say, assembler.
That's no doubt true, but that can only get you so far. If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead. The more bugs in the system, the shorter you can think ahead.
This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance.
It looks like you started with some important points, and then let them lead you to the most unproductive possible conclusion.
> The more bugs in the system, the shorter you can think ahead.
Very true. Too many bugs prevent me from thinking ahead, forcing me to program very slowly by trial-and-error.
> If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead.
There are many buggy systems over which I have little or no control. I often, however, can decide not to work with such systems in the first place. Since such buggy systems have so much effect on my productivity, it is worth putting a lot of effort into avoiding them.
> This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance.
It may also explain why Haskell has so much built-in error checking, why Haskell programmers have been pioneers with respect to new testing strategies (Quickcheck), and why Haskell programmers try to separate `pure` and `impure` code so that as much of their program as possible can be math-centric. They are trying to spend as little time as possible with buggy code that slows them down.
> That's no doubt true, but that can only get you so far
Thinking ahead is great only under ideal conditions, as you pointed out. If you accept whatever conditions are there, thinking ahead can only get you so far. Taking responsibility for such conditions, and trying to change them, can get you much farther.
--------------
I actually don't use Haskell very much, but Clojure has a lot of similarities. Like Haskell, Clojure has a lot of support for abstraction and allows you to do a lot with very little code. Perhaps even more importantly, Clojure libraries tend to be simpler, easier to understand, and less buggy than their Java counterparts.
I always thought that Haskell programmers provided so many math-centric examples because the language provides one of the cleanest mappings of math to code available in any language. You might as well code to the language's greatest strength.
I'm curious as to what you have in mind as a credible example in Haskell of a "buggy system over which you have little or no control." Haskell is such a marginal little language right now that it hasn't attracted the same level of programmer mediocrity as, say, Java has.
Also, the typing system tends to all but eliminate common errors in other languages -- your segfaults and NPEs and buffer overflows. Haskell tends to front-load the pain of development. If your code compiles, you can reasonably expect that any bugs in the code are due faults in your own reasoning rather than failing to accommodate some unplanned-for side-effect (like the uninitialized pointer in C). And unless you've made the mistake of locking up all your logic within the IO monad, finding and correcting these faults tends to be more straightforward, thanks to the math-like syntax.
My experience with Haskell is that, as hard a language as it is to learn, it is remarkably easy, once learned, to think in.
common errors in other languages -- your segfaults and NPEs and buffer overflows
I never see those in Smalltalk. I'd be surprised if that's an issue in Python, Ruby, or Lisp.
(But the number of DoesNotUnderstand errors in Smalltalk is quite impressive. This is why XUnit unit testing was first developed in Smalltalk. Unit testing with good code coverage is the only way to reliably prevent those.)
But the thing is, null/nil/incorrect type references (the cause of NPEs and doesNotUnderstand:s) aren't a problem in Haskell. If you try to pass the wrong type, you'll know right away, before you even get to your hand-written tests — and values that might be Nothing (the Haskell nil) are a different type than normal values. A plain-jane String that is always a list of characters is a different type than a Maybe String and the compiler will catch the mistake for you if you forget that.
> I'd be surprised if that's an issue in Python, Ruby, or Lisp.
I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." I don't have extensive experience in any of the above, so I couldn't include any examples of errors they are prone to.
Ruby's method_missing, the equivalent of Smalltalk's doesNotUnderstand:, is a plague on Ruby programmers. It might mean something returned nil, it might mean the wrong type got passed or returned, it might just mean that you forgot to include a module — but you will run into them more times than you can count while you're developing a Ruby app. (Or at least I will. I don't know. Maybe everybody else has better luck with their libraries or is just more studious than I am.)
> I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking."
Duck typing means that I can run an incomplete program, that is, one that will misbehave for certain inputs.
It turns out that running incomplete programs is incredibly useful.
Yes, I can spend time up front to fake a complete program and remove the fakeness as I provide additional completeness, but ....
I haven't had enough experience with Haskell to do so, but it is my understanding that one can interface with C (and would need to do so, to get a native GUI on Windows, access the registry, etc).
Actually, having used the interfaces to OpenGL, SDL, GLFW, and several other native C libraries, I have to say this isn't the case at all. Haskell's FFI is pretty clean, which shouldn't be too surprising, since Haskell compiles natively, and so isn't relying on some VM translation layer. The headaches you have with, say, Java's JNI simply don't happen.
The headaches you run into have more to do with getting Haskell to recognize where the relevant dev and runtime libraries are, especially on non-Unix systems where library locations are not standardized. It's possible, but you end up having to hack the Cabal package, a process that is not particularly well documented at the moment.
Another issue is simple bitrot. Many libraries in Hackage were developed by students who have no interest in maintaining their thesis work post-graduation.
Yes, you can dive in and explore-through-doing as a precursor to actually your actual coding. In good Smalltalk environments, the best way to read (and write) code is often in your debugger. This way, you add some empiricism to double check your reading comprehension.
Doing iPhone development in XCode, I find it's best to try out code with lots of NSLog statements and a breakpoint in the new routine, so I can explore what's happening at runtime. (The NSLog statements are mainly to get around annoying quirks in the inspectors when you have really long Strings.) This is probably just my taking my Smalltalk habits and trying to do analogous things in XCode/Objective-C.
I used to have to think a great deal before typing, with Haskell and ML. Nowadays, I should think a great deal, but the thinking goes on at a higher level in the design than I'm used to. Of course, I could be prototyping.
But the point is, there is light at the end of the tunnel. No one told me about that. These were languages that were supposed to discourage wild hacking. And they do. But that doesn't keep you from prototyping, or alternately, writing bad APIs.
B) "We think for a while before typing" is the worst excuse ever for a hard-to-type construct. Why not just make it easy? Especially for comments. Make bad code hard to type.