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

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.

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

I think really good high-level documentation would be a good place to start here. If someone looks at your code and immediately says "wtf", it seems like it would be good form to point them to a great piece of documentation. Without that, it seems unreasonable to ask your colleagues to dive into something well outside what they're used to seeing in that code base.

As soon as I read that I looked for the date of the post. May, 2007. This is before C# 3.0 was released and chances are he was even using 1.0 based on impressions from his boss.

C# isn't half bad now, but back then, I agree it was fairly crummy.

Familiarity breeds contempt. Often it's the language that coders are currently using that seems like the worst, because they're dealing with that language's problems on a daily basis.

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.

Yeah, I initially wrote a comment insulting him for not being able to figure out how to fold a list in C#, but the fact is, that wasn't in the standard library until late 2007, so I can sympathize.

I think I can explain the author's point of view. C# 2.0 was still the cutting edge for most of 2007. Most shops were still using 1.1.

The author's qualm, coming from a Lisp POV, is most likely that if you are a consumer of C# 1.1 you can't just build C# 2.0 or 3.0 or 4.0 features. Using Lisp, he had access to everything that would eventually become C# features and then some, because if you want a fancy new language feature in Lisp you just add it. You don't have to touch the compiler (you write functions, macros, or a micro-compiler at the limit).

So there's some hyperbole there, but it's true that C# 2.0 or 1.1 was really not anything special and felt a lot like "Microsoft's Java" at the time.

He loses all credibility because he don't like you religio.. I mean language? Strange metrics of credibility. I disagree with you, therefore you have no credibility.

For this reason, I wrote a chrome extension that shows more of the subdomain on hacker news: https://chrome.google.com/extensions/detail/amenlkcfjlmchdpo...

Yes, I also expected an official Google stance on using Lisp.

I am new to HN, but I think you should try to read posts before you vote them up. At least that is what I do, after clicking on the comments page. Often, HN comments are even more valuable than the article itself.

You seem to have read an article about someone complaining about C#.

The article I read was about someone complaining about not being allowed to use all the features in the language selected for the project.

Meta: That would be this post:

http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006...

Which I think has been posted on HN before, Ron Garret's popped up a few times here, but it's still a great story.

This was written in May 2007. C# 3.0 was released in August. We are talking about c# 2.0 here. No Lambda syntax, no Linq, no Type Inference, no nothing. Anonymous methods were clearly intended to handle events, and even that was discouraged in favor of On_SomethingHappend(...) methods in the MSDN docs.

His code must have looked like this:

    public delegate TResult Func<T,TResult>(T input);
    public delegate TResult Func<T,U,TResult>(T inputA, U inputB);
    
    public static TResult Fold<TAcc,T>(IEnumerable<T> collection, TAcc state, Func<TAcc,T,TAcc> f) 
    {
        TAcc acc = state;
        foreach(T item in collection) 
        {
            acc = f(acc,item);
        }
        return acc;
    }
    //[...]
    public int FunctionalMasturbation() 
    {
        int totalWithdrawed = Fold<int,int>(0,_withdrawals,
                delegate(int acc, int value) 
                {
                    return value+acc;
                }
        );
        //...
    }

This is an abomination. Right, for developers with a background in FP, than it's pretty clear what's going on, even if it looks like puke. But in 2007 you could hold a conference for all .net devs with knowledge of Functional Concepts in a telephone booth.

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

I'm not sure where managers come into the discussion, but the second example is good, but even better like this:

     arr.sum()

I take the point about "Java's designers were consciously designing a product for people not as smart as them."

But, consider the reverse - The C++ spec always seemed to as if the language designers were showing off - competing to add fatures that showed off how clever they were, without as much regard for the readability and maintainablity of the resulting code in the language. I don't think that strategy is optimal either.

Also, if you think only simple code can be done in C#, have a look at the Rx framework. C# as a language is suffering from a bit of bloat too, but not as bad as C++.

I agree with PG and I also think that Java and C# maintainers are wrong to keep adding features to these languages.

I've done a lot of work with Java (and some with C#) and most developers have a hard time even with original Java's scope rules.

So, if these languages want to be the COBOL of the future, they should keep it simple and dumb. Closures and Generics aren't for most people.

Or they could add some compiler directive for switching on advanced features.

The more fundamental reason, I believe, is that it is often hard to just hack something together in Lisp. This mostly due to the library issues and a lack of users creating good documentation and guides.

For example, a few weeks ago I wanted to start writing a program that analyzed some spreadsheet files, spit back out some relevant information (including graphs), and then served this information up on some specified port. I initially wanted to write this program in Lisp so I began to look at available libraries. For the gui component, my first pick was Qt, for which Lisp actually has bindings. I spent about a week trying to get all the dependencies for it installed unsuccessfully. The documentation essentially says, "You need all these installed," and then gives you a bunch of links to their respective websites. All of the other details were missing.

Specifically, I could not install the smoke bindings for Qt. I searched for any guides or documentation and always found a git/svn repository. Once I had the files, I had no idea what to do with them; where they needed to go or how to compile them, etc. Raw .cpp and .h files that have dependencies do nothing in isolation. Furthermore, there was no support forum or any other place to ask for help.

Finally, I just gave up. It was too much work to just hack together what was supposed to be a fun weekend project. So I moved onto Python, which just worked. I'm sure I'm not the only one who has had such frustration.

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.

I suspect they were using .NET 1.x at the time, which would explain a lot.

I do not understand why giving feedback about the usability of the link deserves downvotes. I didn't even understand what had happened when I was suddenly at a google log-in, shrugged, and closed the tab.

Whether your "simple loop" is actually simple depends on the complexity of the underlying problem. At a certain point, it takes less time to understand the abstraction + the code using that abstraction than to understand the fully-expanded code without the abstraction.

If you're just adding up the elements of an array, no big deal use a simple loop. If you're iterating through three lists of potentially unequal length processing some triplets and skipping others and returning some data structure based on that iteration, a raw loop is going to be anything but simple and readable while using an abstraction like CL's LOOP is going to result in something very manageable.

To give an empirical example off the top of my head, look at any compiler code written in C. Iterating over flow graphs is a big PITA because they're nested heterogenous structures (a procedure has basic blocks which has instructions which has uses and defs). You iterate over them a lot and a lot of iterations end up being complex triply-nested affairs. Nearly all compilers written in C use some sort of abstraction to deal with this complexity. Eg: GCC has a bunch of macros of the form FOR_EACH_ that use the pre-processor.

> Smart developers write complex code, just because they can (and often it does make it shorter), but then mid- and junior-level developer struggle with it.

You know, I can't help but be reminded of Harrison Bergeron when I read this. I'm waiting for the day when someone comes up with a handicap for programmers so that we can all write code with the same ability as the least intelligent and least experienced members of our teams.

Did it ever occur to you that there might be a method to smarter developers' madness? I mean, maybe they write code the way they do because, you know, they're smart and know something you don't?

> Kudos to his manager for actually looking at the code and recognizing the problem.

In the majority of the cases however you deal with managers who lost understanding of anything but simple language constructs because all they did since becoming managers is management and no code development at all. At some point they start rejecting everything they don't understand. They justify their position by arguments of code clarity and maintainability. But they are misguided. To recognize readable and maintainable code you actually need to practice programming continually.

I dealt with such managers. They would tell me that a dozen of simple code lines are unreadable because they saw a new keyword they don't understand. But they would accept a hundred of code lines that do the same thing in which they can recognize all keywords. They wouldn't care about what the code actually does, nor they would care about what it takes to parse a hundred lines of spaghetti code.

It always fascinated me that some managers think they understand developing code better than developers they manage. I've had the best experience with managers that trust their developers to make decisions and the worst experience with managers that try to micromanage.

> Kudos to his manager for actually looking at the code and recognizing the problem.

Huh?

> My manager looked at the code and asked "Who's going to maintain this? How will they understand it?" That's not the first time I've encountered these questions. I heard it when I used function pointers in C. I heard it when I used templates in C++.

So essentially the manager bans the use of basic language features because they have hired incompetent programmers who shouldn't be working in the languages before understanding them. How exactly did the manager "recognize the problem"? The problem isn't that people use languages like they are supposed to be used, it's that they have made bad hires, which is not the competent programmers fault.

I agree. I suspect any manager who looks at code and says it is not maintainable would have a very different side of the story, that might sound something like, "We already had an accumulator that did exactly what was needed. It just used a named delegate. I told him to either use that, or refactor the existing code to use his new and get rid of the old one. Maintaining both is wasteful. He seemed to get in a tissy about it."

Try:

http://groups.google.com.nyud.net/group/comp.lang.lisp/brows...

or type the original link in to the form at:

http://dongana.com

For me type inference changes the picture, since it reduces the duplication you see throughout Java-style statically typed code, but doesn't give up all the benefits.