>Choosing between a functional language and an OO language is not like choosing between a hammer and a screwdriver to pound in a nail, it's more like choosing between different types of hammer
Take it one step further and ditch the terrible "tool" analogy altogether. It isn't like choosing between two hammers. Nothing we do is like driving a nail. We can't mix and match the way a carpenter can, taking hammer A for pounding these big nails, hammer B for the small ones, 4 different saws, a lathe, planer, etc. You can't use java's classes and perl's regexes and haskell's laziness. You have to pick the whole toolbox together, and take it as it is.
perl does give you a lot of that, since if has a vaguely lisp-ish facility for modifying language syntax, and is in general very flexible, so it supports things like inheritance, deferred evaluation, etc..
While on analogies, I like to think of a general purpose programming language as paper and myself - the programmer - as an origami artist. Papers come in different sizes, materials, thickness, elasticity, etc. with each better suited for a certain class of origami. When considering very similar papers, the outcome is more dependent on the artist than on the paper.
This also allows the possibility that it is possible to do great art with scrap paper or to crumple up a beautiful sheet of handmade paper. OOP/FP/etc are like various folding techniques.
This is true to a degree, but there are ways you can use multiple tools mixed and matched.
For a simple example, I might write my prototype in Python. After profiling I might decide to rewrite a couple of inner loops in C (or Cython). I might tie it to SQL Server as a datastore and use T-SQL in the interface.
Not really. I am just saying the tool analogy is really poor, and thinking of languages as hammers doesn't help us reason about them in any way. The analogy to toolboxes is less bad, but I don't think it is really very helpful either. Programming languages are like any other languages, they are used to communicate ideas.
Well, programming languages are rather specialized languages, compared to languages in general. This specialization is what this thread is about. What I meant was something like: maybe programmers should have a toolbox, call it programming environment, where several specialized languages could be used together in the same application with considerable ease. I have no specific ideas, just a vision.
The Microsoft .NET framework makes some claims of being like that. There is a grain of truth in the claims, but also some big gaps in practice. You can mix different .NET languages that all compile to the CLR virtual machine. For example, F# code can call C# code and vice versa.
But if you're looking to do cross-language like that, you have to know a lot about both languages and place some constraints on yourself.
I don't really see .NET as a viable implementation of your vision, but I wanted to at least point out that it does make those claims in case you were unaware.
The "extremist programming" approach to enable language compositionality would begin by asking what do the languages have in common: are there any fundamental principles from which the specific principles in each language derive? If we were considering just F# and C# for now, and we asked what they have in common - I think the obvious approach is that we should model everything as functions: after all - everything in F# is a function, objects can be seen as tuples of sets of functions and sets of variables, and variables can be seen as functions returning a value.
Another approach might be to look at things as objects, and to try and model functional programming in terms of objects. I'm sure you're familiar with how F# is implemented, and you'll probably agree that it's a disaster (although the language itself isn't terrible). The idea of building functions on top of an OOP which is defined in terms of functions clearly misses the point somewhere. The end result is a very specific compatibility layer between two different languages, but very far from solving the more general problem of language compatibility.
.NET isn't the only platform, or even the first to attempt this approach though, and it's hard to really blame them for not solving this problem, which they didn't set out to solve, but merely added as an afterthought. The author's article is about solving problems on principle, rather than making practical solutions and then trying to adjust them to solve other problems.
Nemerle is an interesting language on the .NET platform. The idea behind it is to have a syntax which can be extended from the language's own macro system - using a type-safe AST which is targeted with a PEG grammar. The eventual idea is that you should be able to use any syntax to target the same semantics in the AST, essentially merging the language and compiler into the same tool. 2.0 version is an attempt to define all of Nemerle's own syntax as it's macros - making it a good example of the "extremist programming" the article is talking about (and certainly a bit closer to jonsen's vision than .NET in general).
> You can't use java's classes and perl's regexes and haskell's laziness. You have to pick the whole toolbox together, and take it as it is.
Which is (i) a pity, and (ii), not entirely true. Sure, current modern compilers represent huge piles of code, but others are small enough that you can realistically craft your tool like a jedi would her lightsaber.
Of the top of my head, I have 3 example of language implementation small enough to be customized, ported, or otherwise scavenged for ideas. Lua, OMeta, and Maru.
It helps with things like library, tool or framework selection because you end up evaluating the language itself more so than the ecosystem. I don't think many people are actually writing their applications in more than two different general purpose languages at the same time and place. Maybe you inherit some crusty code you just wrap up and re-use but you probably aren't doing new development in that old code-base at the same time.
Shell is general purpose (perhaps even more so than Java or Python), when you look at it from the perspective that programs are simply functions you call and get a result from, or which perform additional computation.
It would if you wrote a language with those choices in it for the VM in question, but that is also an option without a VM. Sticking to the toolbox analogy, the only way to pick and choose the tools to go into the toolbox is to make your own toolbox.
Take it one step further and ditch the terrible "tool" analogy altogether. It isn't like choosing between two hammers. Nothing we do is like driving a nail. We can't mix and match the way a carpenter can, taking hammer A for pounding these big nails, hammer B for the small ones, 4 different saws, a lathe, planer, etc. You can't use java's classes and perl's regexes and haskell's laziness. You have to pick the whole toolbox together, and take it as it is.