3 ms·
I'm an old guy so you are free to ignore me. A trend I've seen is young & extremely smart people making posts saying "you are doing it wrong, you should use li
by luckydude 14y ago
I'm an old guy so you are free to ignore me.
A trend I've seen is young & extremely smart people making posts saying "you are doing it wrong, you should use lisp or $whatever_language_they_like".
What I haven't seen is a lot of posts from these same people (have seen them from others) where they are talking about maintaining code, bringing new people in who can fix bugs, add features.
I think the natural progression for smart people is
- wow, I'm dumb, I'm so dumb, I need to learn.
- a few weeks/months/years of learning
- holy crap, everyone is doing it wrong! They need to use $New_Whiz_Bang! It's so cool, it's objects or functional or has $feature_I_really_like, why aren't they using it?
- time passes. A lot of time. Maybe a decade.
- Oh, my, legacy code sucks. I don't understand what $programmer did 5 years ago. Holy crap, $programmer is me!
- Wow. Customers suck. They want this code to work and $cool_guy embedded a lisp interpreter in the middle of our database and wrote a bunch of cool lisp that I don't understand. And the customer wants it fixed yesterday. And my kids and wife hate me because I work too much.
- I really wish everyone would program their code like it was intended to be understood by an idiot.
My take? Writing code is easy. Fixing it is hard. It's easier if you weren't trying to be clever when you wrote it.
- tikhonj 14y agoI can't comment on Lisp (except to say that Scheme is awesome), but I think you are very far from the mark on functional programmers in general. In particular, Haskellers worry about maintainability far more than normal programmers. One of the main advantages of functional programming is that it makes reasoning about the code--including ensuring correctness--much easier. Haskell enforces referential transparency, limits IO interactions with the type system, allows you to encode some fairly complex invariants in types and, despite all this, has some of the best testing software around in QuickCheck (which goes beyond unit tests). In my experience, Haskell programs tend to have smaller, less coupled parts with better defined invariants. You don't have to worry about a large class of errors right off the bat: you can't get null pointer exceptions, functions you call can't have any unexpected side effects, you won't get type errors at runtime and so on. If anything, Haskellers worry about correctness too much. Happily, this is offset a bit by the language which happens to be very expressive and productive. You can also get very good performance from high-level code and even unoptimized code tends to be decently fast. Some people also find it hard to learn, but that's simply a cultural issue. Somebody already familiar with functional programming has much less difficulty picking it up, but even without much functional experience the basics shouldn't take too long.
- jackpirate 14y agoIn particular, Haskellers worry about maintainability fra more than normal programmers. One of the main advantages of functional programming is that it makes reasoning about the code--including ensuring correctness--much easier. This was what finally convinced me to become proficient in functional programming. I'm constantly amazed at how stuff just works.
- luckydude 14y agoSo you want the code that makes your hands free car to be written in Haskell? I can just hear the answers: "Why, yes! Because I can prove that it is correct!" Now consider that you are going to get bored at GM and move on. Someone a lot less talented than you is going to go in and modify your perfect haskell code. They don't know haskell, they aren't you, but the code needs to be enhanced. Now how comfortable are you in that car? (I know what you will say, but as an experienced manager, I would not be comfortable in that car.)
- wpietri 14y agoThere is something to be said for hard things looking hard. Personally, I'd rather that code be in Haskell than Java, because there are plenty of people with room-temperature IQs who think they can code in Java but would get beaten up and have their lunch money taken by something like Haskell. I've heard about some really interesting Smalltalk systems, super high-reliability stuff. I'm sure SmallTalk helped some, but what I suspect helped more is that the kind of people who were off-the-beaten-path enough to have years of SmallTalk experience were well above average.
- tikhonj 14y agoI'm not sure I would want to be in a car with code written in any language by somebody who couldn't learn Haskell (or any other language, for that matter) in a couple of weeks, at least well enough not to mess something up without noticing. That said, if I had to be in a car with code written by somebody who didn't know a language, I would much rather that language be Haskell than C (to pick an extreme example; replace C with most any other language and it would be true to a smaller degree). It's much harder to sneak a bug through Haskell than pretty much any other language and it's easier to have more thorough testing. Somebody new is very likely going to have trouble getting code to compile at all, but the would also have trouble adding subtle (or even unsubtle) bugs to it. To continue with the extreme example, there is a whole host of C bugs which are easy to add without realizing but are practically impossible with Haskell: memory issues (having the occasional segfault or bus error), concurrency issues (these can be very subtle and hard to catch), mutation in the wrong place (could also be very intermittent), potential type issues and so on. If the language was C, I wouldn't want anybody without a lot of experience working on the code at all--there's just too many very subtle ways it can fail without being easily detected. Even languages that make is harder to shoot yourself in the foot make it easier than Haskell.