Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I finally understand why I'm not allowed to use Lisp

groups.google.com

Post reply on HN
Print view View original

81–90 of 121 posts

Re: I finally understand why I'm not allowed to use Lisp

#81

Post by fleitz »

fauigerzigerk wrote: post #80
fleitz wrote: post #79

A better question is whose going to maintain all those for-loops that are buggy because human error means even a basic thing like a loop will get screwed up. Managers are always talking about code reuse but as soon as you pass a function, they are like "Woah thats crazy how can we maintain that" Only managers would think that int accum; for(int i = 0; i is more readable and maintainable than... arr.sum(x => x) Oh loo…

Are you explaining the difference between code you have to write and debug and code that someone else has already written and debugged?

What I'm saying is that passing functions (or functional programming) allows you to reuse a lot more code than typical imperative programs with a lot less effort. I personally find the functional style to be much more readable and don't understand why everyone has such a problem with the maintainability of code written in a functional style even if it's a mostly imperative language.

Re: I finally understand why I'm not allowed to use Lisp

#82

Post by fleitz »

nyellin wrote: post #4
acangiano wrote: post #2

> I work in C# (worst language EVER!) You lose all credibility right there. C# is far from the worst language ever, and a pretty decent one among mainstream object oriented languages.

Agreed. I would choose Python over C# for my own projects any day. However, I can't comprehend the senseless hatred that people have for C#. It is a nicer language than Java (imo) and it has very good performance. Furthermore, due to Mono, C# is no longer a closed platform.

It never was a closed platform. C# was always an ECMA standard. MS even created rotor which was a FOSS implementation of C#.

Re: I finally understand why I'm not allowed to use Lisp

#83

Post by Joeri »

j_baker wrote: post #46

I learned something a long time ago. It's far, far easier to dismiss others' code as "complex", "unmaintainable", or "clever" than it is to try and understand the code well enough to figure out whether that code was written that way for a valid reason. It's true whether you're new and approaching a codebase for the first time or whether you're reviewing someone else's code. And no, I'm not saying that it's ok for cod…

It's always twice as hard to read code as it is to write code. For that reason alone, clever code is usually unmaintainable.

Re: I finally understand why I'm not allowed to use Lisp

#85

Post by raganwald »

Joeri wrote: post #83
j_baker wrote: post #46

I learned something a long time ago. It's far, far easier to dismiss others' code as "complex", "unmaintainable", or "clever" than it is to try and understand the code well enough to figure out whether that code was written that way for a valid reason. It's true whether you're new and approaching a codebase for the first time or whether you're reviewing someone else's code. And no, I'm not saying that it's ok for cod…

It's always twice as hard to read code as it is to write code. For that reason alone, clever code is usually unmaintainable.

It's always twice as hard to read code as it is to write code.

True.

For that reason alone, clever code is usually unmaintainable.

How does this follow logically from the first statement? And more importantly, what alternative do you suggest? Are you positing that for a given problem, there is always some alternative solution that is "less clever" and "more maintainable?"

If you've never seen folding and unfolding before, code that makes heavy use of "map," "each," "select," and so on looks clever. But in reality, it is simpler and less bug-prone than fooling around with for loops and off-by-one errors. To my eye, for loops are clever and unmaintainable.

Moving up the scale, what about recursive combinators?

https://github.com/raganwald/homoiconic/blob/master/2008-11-...

They look very clever. But then again, rolling your own recursion from scratch every time you need it makes the person reading your code do a lot of work to figure out what you're doing. Is it "clever" to separate the concerns of how to implement recursive algorithm from the code that does something recursively? Or is it clever to roll your own code every time?

WHat about parser combinators? Clever or not? How about rolling your own interpreter for a DSL? That's an official pattern from the GoF book. Can I do that and write maintainable code?

Anyhow, I'm saying the same thing over and over. What is "clever?" Making use of a language feature or algorithm or well-known practice that someone else hasn't seen before and is too lazy to learn? And what is the alternative? Greenspunning the same functionality in an under-specified, bug-prone one-off way?

Re: I finally understand why I'm not allowed to use Lisp

#86

Post by stcredzero »

Joeri wrote: post #83
j_baker wrote: post #46

I learned something a long time ago. It's far, far easier to dismiss others' code as "complex", "unmaintainable", or "clever" than it is to try and understand the code well enough to figure out whether that code was written that way for a valid reason. It's true whether you're new and approaching a codebase for the first time or whether you're reviewing someone else's code. And no, I'm not saying that it's ok for cod…

It's always twice as hard to read code as it is to write code. For that reason alone, clever code is usually unmaintainable.

For that reason alone, clever code is usually unmaintainable.

An entire application of "clever" for clever's sake is unmaintainable. This tricky sort of clever is sometimes exactly what's needed, but should be used sparingly, where it is most beneficial, and it should be well commented.

On the other hand, clever directed at the goal of readability and maintainability can be wonderfully maintainable. Clever for readability's sake should be throughout the whole application. Accomplishing this is an iterative task, ideally throughout the whole life of the application. This is one of the most important purposes of refactoring.

While it's much easier to brag about the 1st kind of clever and show it off to your coworkers, you'll benefit much more from the 2nd kind of clever.

A tip from my experience: Managerial emphasis on the 1st "clever" is sometimes accompanied by a culture of coder showmanship. Managerial emphasis on the 2nd kind of clever tends to be more focused on sustainable results.

Re: I finally understand why I'm not allowed to use Lisp

#87

Post by rapind »

raganwald wrote: post #85
Joeri wrote: post #83

Earlier quoted context omitted.

It's always twice as hard to read code as it is to write code. For that reason alone, clever code is usually unmaintainable.

It's always twice as hard to read code as it is to write code. True. For that reason alone, clever code is usually unmaintainable. How does this follow logically from the first statement? And more importantly, what alternative do you suggest? Are you positing that for a given problem, there is always some alternative solution that is "less clever" and "more maintainable?" If you've never seen folding and unfolding be…

I'd say clever is defined by your audience. If you're writing something that others on your team would consider clever, then you're responsible for making sure they understand it. Even if that means losing whatever time you saved by writing something clever (the advantage is still creating a smarter team though).

Responsible developers write a lot less clever code because it means they feel obliged to comment the crap out of it and find the time to go through it with other team members.

Unfortunately there's a lot more clever code that only one person really gets. If you're too clever for your team, then quit slumming it and find a smarter team. You're going to be toxic to a team that isn't as clever as you are unless you assume the role of mentor and all of the responsibility that comes with it... and the required patience.

Re: I finally understand why I'm not allowed to use Lisp

#88

Post by raganwald »

j_baker wrote: post #46

I learned something a long time ago. It's far, far easier to dismiss others' code as "complex", "unmaintainable", or "clever" than it is to try and understand the code well enough to figure out whether that code was written that way for a valid reason. It's true whether you're new and approaching a codebase for the first time or whether you're reviewing someone else's code. And no, I'm not saying that it's ok for cod…

Here's one rule-of-thumb that just occurred to me. If there is "prior art" for code, the onus is on the person reading the code to show that it is "complex", "unmaintainable", or "clever." If there is no prior art for code, the onus is on the person writing the code to show that it is "simple," "maintainable," and "straightforward."

Taking parser combinators as an example, if you write some code with parser combinators, simply document your choice as usual and include a hyperlink to http://en.wikipedia.org/wiki/Parser_combinator.

If I read your code and think this is overëngineered, it's up to me to show a better way, I can't simply wave it off as being too hard. That doesn't mean it gets a free pass, it could be that parser combinators for a custom DSL are too complex, perhaps the same problem could have been solved with JSON or something, but the default should be to accept it since it's a technique that is explained "in the literature."

On the other hand, if I roll my own complex code and I can't point to a reference for the technique, then it's up to me to make the case that it's simpler than the alternative. For an example, Benjamin Stein and I wrote #andand for Ruby. It's related to the maybe or option monads, but it doesn't take the standard form so I can't really document it with a hyperlink. The onus is on me to show that in Ruby, #andand is simpler than testing for null, using the null object pattern, or organizing code such that there are no unexpected nulls.

Re: I finally understand why I'm not allowed to use Lisp

#89

Post by fhars »

S_A_P wrote: post #33

OOOH I was so wanting to tell the OP What is so hard about this??? //assume some sorta IEnumerable derivitive IEnumerable bar = new IEnumerable () { obj1, obj2, obj3, obj4, ...}; var accumulator = bar.TakeWhile(x => x.property == someValue); but then I saw the .NET 2.0 timeframe. But even with .NET 2 you had generics which makes things pretty easy. But then again, he/she is ranting so I should just ignore him/her. It…

If you had read the article you would have noticed that using generics the way they were intended to solve this problem was what he was called out for by his manager.

Re: I finally understand why I'm not allowed to use Lisp

#90

Post by foljs »

gnufreex wrote: post #72
nyellin wrote: post #27

Earlier quoted context omitted.

In the professional Linux community, almost everyone views Mono-haters as nutters/trolls. If you have real concerns about Mono, I suggest that you contact Miguel de Icaza directly. Email: miguel@gnome.org Twitter: @migueldeicaza ( http://twitter.com/#!/migueldeicaza ) Blog: http://tirania.org/blog/index.html

Well, I am professional and I see Miguel De Icaza as Microsoft zealot and nutter/troll. Person that is "psyched" (see http://www.networkworld.com/community/blog/open-source-guru-... )about Nokia going Wp7 can't give unbiased opinion about anything connected to Micorosft, especially anything that he is actively pushing... and he pushes .NET more than Mono these days.

> Well, I am professional and I see Miguel De Icaza as Microsoft zealot

"Microsoft zealot". Yes, you are very professional. As in, (possibly) paid for your programming work. Your statement above however, and especially the choice of words, is not a professional statement. It's an amateurish rambling fit for a spotty teenager that would get you fired from most professional environments.

Oh, and your handle: "gnufreex". Yes. Very professional. Then again, even contract killers are professionals...

Post reply on HN