Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Both programs are fundamentally ugly, so having it be superficially ugly as well is no big loss.

Perhaps we’ll just have to amicably disagree on that point. I think making code superficially ugly is a huge barrier to adoption that has held back otherwise good ideas throughout the history of programming.

Many an innovative programming style or technique has languished in obscurity until some new language came along and made the idea special and provided dedicated tools to support it. Then it becomes accessible enough for new programmers to experiment with the idea, and the code becomes readable enough to use the idea in production, and over time it starts to change how we think about programming. We push the envelope, probably developing some ingenious and useful but horrible abuses of the idea along the way, until we figure out how to make those new ideas available in a cleaner and more widely accessible way and the cycle begins again.

I suspect that people simply don't care enough.

Most people are programming in languages that don’t have the problem in the first place, so they don’t need to care.



> I think making code superficially ugly is a huge barrier to adoption that has held back otherwise good ideas throughout the history of programming.

Haskell tries to make elegant code look nice and inelegant code look ugly. When you see something ugly like the example above this is a sign that there would be some more elegant way of writing it. That certainly holds in this case as you don't need an mutation to do the fib sequence.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: