4 ms·
One can absolutely work in groups using Lisp. There are a lot of examples for that. Often the groups don't need to be that large when working in Lisp. Code in l
by lispm 3y ago
One can absolutely work in groups using Lisp. There are a lot of examples for that. Often the groups don't need to be that large when working in Lisp. Code in larger projects tends to be more compact. I heard for example of 1/10th of a large (1000 persons) comparable C++ project at Lucent many years ago.
- shadowgovt 3y agoI'm sure it can be made to work; I'm saying the extra flexibility means you need someone making sure everyone's either on the same page or knows how to get there. I'd be interested to know what approach Lucent took to wrangling the complexity.
- lispm 3y agoLet's assume they had 10 times the people and something between 5 to 20 times the code size. Going from 100 to 1000 people adds a lot complexity. I would think that adding good and experienced managers is important. Keeping all these people aligned, avoiding code duplication, reducing dependencies also needs to be addressed on the organization level. One can make it work, but some of the consequences one can't avoid. Though, it has some positive sides, too. But then you'll need a lot of tools and architecture to deal with that. To reduce the code size to write, they probably would need to add frameworks, code generators, model-driven architecture, domain specific language, ... lot's of tools. Let's say you'll need to persist C++ objects into a database, they probably used an OO-database (at that time) for C++ with a special query language. Otherwise they would have used a more traditional relational database, either map things to an object-oriented persistence framework or write SQL. Tool building/usage is key, I would think. Greenspun's tenth rule also applies.