Slashdot Mirror
Ingy döt Net Tells How Acmeism Bridges Gaps in the Software World (Video)
Ingy döt Net (yes, that's his name) likes to bridge gaps in the software world. People get religious about their favorite programming languages, he says, but in the end, no matter the language, the methodology or the underlying OS, all programming is about telling computers what to do -- from "add these numbers" to complex text manipulation. Ingy compares a new app or module in the world of Free and Open Source as a gift that the creator has given to others; if that gift can be simultaneously bestowed on users of Perl, Python, and Ruby at the same time, its worth is amplified. So he proposes (and provides a growing set of tools) to make programming language irrelevant, by the sly means of encouraging people to write software using whatever their favorite tools are, but with a leaning toward using only language features which are broadly available to *other* programming languages as well. He's adopted the term Acmeism to describe this approach; Acmeists who follow his lead strive to create software that is broadly re-useable and adaptable, rather than tied only to a single platform.
From his web site:"Most computer programmers learn one programming language."
Umm...I'm sure I've ever met a programmer who only knew one language. Even in college, I had to navigate six (mainframe and PC assembler, COBOL, C, C++, FORTRAN) in coursework and 3 more (Perl, Java and Javascript) in my campus job, not to mention all the scripting and compiling environments I had to navigate to get things to work.
For those who don't know, Ingy is a fairly prolific Perl developer [1]. The position he espouses here is quite typical of folks developing modern Perl. The crux of it is that it is better to provide an interface or API for a smaller bit of code that is easily spoken with than one tucked away in the bowels of a massive framework that's tied to a specific language. This position is really a reiteration of Ken Thompson's Rule of Modularity within the Unix Philsophy [2].
To me, this is a noble design goal because it allows developers to use the programming languages they're comfortable with and/or those that best fit the task at hand. I feel that this general principle has been the guiding force behind Google developing Protocol Buffers [3] and Facebook developing Thrift [4]. Software seems easier to build in small pieces that interoperate than if the developers try to build a monolithic and homogenous system all in one go.
It saddens me to see so many folks dismiss this position as a "fad" when it's one of the points to the open source movement.
Where to start. First of all, let me make a nod to (http://www.swig.org/) a tool that makes binding C and C++ to other languages easier. The technology to provide code to many languages is a largely solved problem. Write what you can in C and bind it to the world.
The notion that you can have an abstract programming language that just maps into a bunch of platforms is quite a ways off. The demand for it just doesn't exist. UML tried this in the late 90s, and it mostly failed (there was some traction in real time systems engineering).
The lack of code reuse is not due to a single language mindset, a unwillingness to share. Writing reusable code is just hard. It requires careful design and a lot of effort.
There no easy way around the lowest common denominator problem. Sure, it's easy to map printing a line to a console to a bunch of platforms. But, when you get past what the basic of the standard C library calls, you pretty much just end up creating yet another platform and language, compounding the problem. We just don't have the design experience or languages yet to express many programming tasks abstractly and effectively.