> And here here we are maintaining that how best to express the core
> application logic in a robust, maintainable, bug-free way depends on the
> type of problem the application is supposed to solve.

OK. But if you have an inflexible language, then you have only one way 
to express your solution. And if that isn't a good way for a certain 
problem, things get tricky. If you have a powerful and expressive 
language with the flexibility to support multiple ways to solve the 
problem, it's far more likely you can find one that works well. No?

> If you are tied to a particular language, then for some problems you
> WILL end up with writing libraries, metaprogramming tools and the like,
> and you're actually no longer programming in that language - you're only
> using it as glue code here and there. (Provided you do aim for that
> robust, maintainable, bug-free way of expressing stuff of course.)

And this is bad somehow?

> Anyway - at present it looks like function-oriented programming is
> supposed to make everything functional and wonderful now. But what
> problems will they discover (if they haven't done so already and you
> just haven't heard of it yet)? I betcha there will be quite a few and
> then some, just like with every other programming paradigm we've had so
> far under the sky.

 From what I've seen, "every other programming paradigm so far" has been 
ad hoc without much in the way of a strong, consistent theoretical basis.

I mean, take SQL. It solves only one problem, but it solves it so damned 
well that it is basically the /only/ language of its type. And oh look, 
it's based on a theoretical model. Funny coincidence, that...

Post a reply to this message