Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

With all the programming languages that are out there, what exactly does it mean to program in the small and is it still possible, without the possibility of re-purposing to the large.

The original article which mentions in the small was dated to 1975 and referred to scripting languages (as glue languages). Maybe I am missing the point, but any language that you can built components of code out of, I would regard to being able to handle "in the large".

Is there a confusion on what Objects are and do they really figure as being mandatory to being able to handle "the large". Many have argued that this is the true meaning of "In the large" and that the concepts of objects are best fit for the job.

share|improve this question

migrated from stackoverflow.com Feb 13 '11 at 19:01

This question came from our site for professional and enthusiast programmers.

link the article? domain specific languages come to mind for handling the small... sql, xml, json work very well for their domains but can't scale to handle all things. –  mlaw Feb 13 '11 at 17:18
Your link to the article is a place to buy a PDF copy. Take what's relevant in the article, and summarize it. Do not expect us to pay money to answer your question. –  David Thornley Feb 16 '11 at 20:44

2 Answers 2

The Linux kernel is a very large project that, as far as I know, doesn't use objects. At the last place I worked, the entire code base there was in COBOL when I started. Again, no objects. So it's certainly possible to write large projects without using objects.

One of the things objects do for you is make it more natural to organize your code. Each object has responsibilities and the code needed to fulfill those responsibilities naturally goes with the object. However, organizing code can be done without objects, and in some OO languages (e.g. Common Lisp), the object belongs to the method instead of the other way around. Packages in Common Lisp and modules in other languages are other alternatives for organizing code.

I don't know of any languages used exclusively for small projects, but I can think of a few languages I wouldn't use for anything over 100 lines or so. Perl and shell would be at the top of that list. But that's a matter of personal preference. I'm sure that people using them for larger projects have their own ways of managing complexity.

share|improve this answer
It's not entirely correct to say that the Linux kernel doesn't use objects. C doesn't provide language support for OOP, but Linux rolls its own OOP. Many of the structs that they use contain a pointer to a struct that contains a bunch of function pointers for operating on its data. This is very similar to how virtual functions are typically implemented in C++. –  Dirk Holsopple Sep 17 '12 at 17:20

Functional programming, which is becoming more and more mainstream every day, especially Erlang and the JVM based languages, is firmly based in "programming in the small". To be manageable functions need to be small, like dozen lines or so. The programs in total tend to be small because of the terse syntax and built in standard libraries.

Languages is a harder thing to put a metric on. Python has so much built in and can do so many things in a line or two because of the "batteries included" standard library most programs can be small. A lot of functionality can be had in 100 lines of Python if you know the standard library modules and the advanced features of the language. Same goes for Groovy, Lua and Ruby, and any other dynamically typed language.

Terseness != readable or maintainable. A lot of things that can be considered "concise" like lambdas, list comprehensions and other "magic" features, are just that to junior level developers. Who might be the ones having to maintain your "small" program after you.

That said, using lines of code as a metric for anything is usually at best a waste of time and at worst just wrong.

Objects are not required for large scale projects, Erlang powers telephony switches that have Nine Nines up time, ( 99.9999999% ) that is 31 ms, yes milliseconds, of downtime a year, that consist of Millions of lines of code.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.