[zardo]

People don't want powerful features because they can be misapplied, making a mess. These people aren't worried that they will make a mess of their own code, they are worried that they will have to deal with someone else's mess.

What happens as you add more developers to a code base, with larger variance in ability and favored abstractions is going to be important in some cases, and irrelevant in others.

[AnimalMuppet]

To expand a bit on this:

Imagine that you're joining a project. It's been worked on by a team of 100 people for a decade. Half of those people were below-average programmers. Many were newbies in the language, and some were newbies to programming. And you're going to get to try to maintain this code.

Now, do you want it to be written in a restrictive language, or in one that gives developers the ultimate amount of freedom?

[TeMPOraL]

Having worked both with big Java projects written by newbies, and on a large Common Lisp codebase that's older than I am (29), I don't really see much difference. Large projects are large, they always require time and effort to get into. That said, my current experience is that:

- A dumb language and simple code in a big project means lots and lots of code. On such codebase, my biggest issue is keeping track of how things fit together, because there's just so much of it (hint: they don't; people writing it can't keep track of all that stuff either).

- A powerful language and complex code in a big project means dense code. Like in that Lisp codebase, where I dealt with big macro-writing-macros, I would spend an hour with a macrostepper, trying to grok what a single line of code does. But once I did, that line of code (and similar lines in other places) were not a problem anymore, and they compressed what would otherwise be thousands of lines of boilerplate.

Which one I like more? I don't know. Big, old codebases suck, that's a fact of life. But I lean a bit towards "more Lispy" than "more Java-y", because it makes me feel I'm using my brain to actually think, instead of just tedious bookkeeping.

[pjmlp]

Surely in one that gives developers the ultimate amount of freedom.

I have seen enough C and Java code to see how creative developers and architects get to workaround the limitations of a restrictive language.

A convoluted code base full of design patterns, indirection layers, DSL and UI tooling for code generation, libraries to simulate language features.

[flavio81]

>Many were newbies in the language, and some were newbies to programming.

I wouldn't join this project, no matter what the language is.

Imagine it's a popular languae. Javascript or C code, for example. There are no true namespacing / packages and modules facilities in JS or C. It would be even worse than the theoretical nightmare you think Lisp would be. (Lisp has extensive namespacing facilities; code can be contained within modules that don't clash.)

If it was Java, you will see wrongly applied Design Patterns, leading to over-complicated, hard to mantain code.

No, thanks. I wouldn't accept no matter the languages.

Newbies to programming should be educated and trained, not incorporated directly into an important project.

[JetSpiegel]

>>Many were newbies in the language, and some were newbies to programming. >I wouldn't join this project, no matter what the language is.

Then you will never be employed, because that describes virtually every software project at a for-profit company.

[flavio81]

>Then you will never be employed, because that describes virtually every software project at a for-profit company.

I have had 8 years doing software dev (at a for-profit company) most of them as software development director in command of a 15+ people team, thus, I reaffirm what I said: Newbies should be trained first, and only afterwards included in the projects, and that's what I made sure happened on the team, under my command.

They deserve to be trained first, in an environment where they can make mistakes freely until they feel confident.