Dropping the Cottage Industry Mindset for Programming

2025-04-28

Apr 29, 2025

There seems to be a pervasive belief that everything can be done in only 1 language. I disagree - we need multiple languages per project and we need to treat type-checkers as separate pieces of software that are meant to help developers, yet don’t end up in the product code.

We need to drop the cottage-industry mindset wherein 1 person (or 1 group) does everything, and calls it “programming”. Other Engineering disciplines have learned that we need to chop up responsibilities across several groups, e.g. Architecture, Design Engineering, Production Engineering, Testing, etc., etc. Our spate of one-language-to-rule-them-all languages discourages this kind of division of labour. It used to be hard to build languages, but, not today. We can do better. A lot better.

Syntactic composition and macros-for-non-lisp-languages are easy to build today. These were hard to build in 1960. We still design programming languages like it was 1960.

Yes, we need abstractions to help us think about designs more clearly, but, we don’t need mashups of every possible abstraction wedged into one language. Prolog is a good example. Prolog makes it easy to write relations between high-fallutin’ concepts. Yet, when pushed too far, Prolog makes simple things hard, like manipulating strings of characters - even Javascript is better than Prolog for this kind of thing. We need to be able to bolt Prolog and Javascript code together to solve problems. In fact, we need more of that. We could make use of DSLs for text-parsing (called “BNF”), we could make use of DSLs for character parsing on a line-by-line basis (called REGEX), we could use DSLs for concatenative programming (called Forth and Postscript) to do some (but not all) work, etc., etc. We could even use DSLs for function-based thinking - as opposed to CPU-based limited-memory subroutine thinking - (called FP, SICP, etc.).

We need new ways to think about asynchronous programming, but, the use of FP and of Operating Systems discourages the discovery of these new paradigms.

How can we bolt multiple languages together? In the 1970s, UNIX pipelines showed one way. Today, we have closures and we have queue classes and we have garbage collection and we have PEG technology for creating syntactic coupling and macros for non-lisp languages. Technically, it’s not hard - we already have all of the technology that we need. In fact, we had all the tech we needed back in 1960 (e.g. Lisp 1.5 gave us the forerunner of closures), but, we succumbed to the Greenspun approach.

It’s a mindset issue. We need to stop thinking that our problem spaces and that our hardware capabilities are the same today as they were in 1960. Standing on the shoulders of giants only works when the giants were facing the same kinds of problems and capabilities that we face today. The giants got us to here, but now we need new giants. FP and SICP and C are no longer appropriate ways to approach the problems we face.

Programming Simplicity

Discussion about this post

Ready for more?

Programming Simplicity

Dropping the Cottage Industry Mindset for Programming

2025-04-28

See Also

Discussion about this post

Ready for more?