And if it requires merging together several different mutually exclusive paradigms, such as OO and FP, isn’t this just getting messy for the sake of having too many little moving bits?

In the end, are we looking for intricate little bits to fiddle with or are we actually trying to take something with a massive amount of complexity and reduce it into something that is simple, maintainable and solves (some of) our user’s problems?

So, if after fifty years of progress, the technologies aren’t actually getting more simple or obvious, and are in fact getting way way harder to grok, isn’t that a strong indicator that there is some type of serious problem with them? Do we get more from our modern technologies, or is it that there is just more code and data available to play with?

Paul.

And if it requires merging together several different mutually exclusive paradigms, such as OO and FP, isn’t this just getting messy for the sake of having too many little moving bits?

In the end, are we looking for intricate little bits to fiddle with or are we actually trying to take something with a massive amount of complexity and reduce it into something that is simple, maintainable and solves (some of) our user’s problems?

So, if after fifty years of progress, the technologies aren’t actually getting more simple or obvious, and are in fact getting way way harder to grok, isn’t that a strong indicator that there is some type of serious problem with them? Do we get more from our modern technologies, or is it that there is just more code and data available to play with?

Paul.

C’mon, you know I’m not smarter than you :-) It’s just a matter of getting used to some paradigm/methodology/etc. For example, Python and Ruby make functional programming easy to integrate in a object-oriented language. Once you have gotten used to use functions as first class citizens, you feel that Java imposes you too many limits.

That’s why I like C++ and Python so much:

- traditional procedural language (check)
- object oriented features (check)
- functional programming (check). In C++, if you want to pass around functions, you’ll need to write a class that overloads the () operator (usually called a functor). It’s not as straightforward as in Python, but it’s something you cannot do in Java.

C’mon, you know I’m not smarter than you :-) It’s just a matter of getting used to some paradigm/methodology/etc. For example, Python and Ruby make functional programming easy to integrate in a object-oriented language. Once you have gotten used to use functions as first class citizens, you feel that Java imposes you too many limits.

That’s why I like C++ and Python so much:

- traditional procedural language (check)
- object oriented features (check)
- functional programming (check). In C++, if you want to pass around functions, you’ll need to write a class that overloads the () operator (usually called a functor). It’s not as straightforward as in Python, but it’s something you cannot do in Java.

Since kids have grown up using high level tools, it should be easier for them to think in abstract terms, that’s the key IMHO.

Agreed – though I’d say to think in the new paradigms, as I don’t know that they’re necessarily more abstract. In the case of OO, I’d say that it’s more natural and more concrete, not more abstract. But that’s just a matter of words – I agree that that’s key.

You don’t look at problems the way I do. You quickly see approaches and solutions that I find very natural once you’ve pointed them out to me. I’m hoping to change that, but maybe you just are smarter :-)

Since kids have grown up using high level tools, it should be easier for them to think in abstract terms, that’s the key IMHO.

Agreed – though I’d say to think in the new paradigms, as I don’t know that they’re necessarily more abstract. In the case of OO, I’d say that it’s more natural and more concrete, not more abstract. But that’s just a matter of words – I agree that that’s key.

You don’t look at problems the way I do. You quickly see approaches and solutions that I find very natural once you’ve pointed them out to me. I’m hoping to change that, but maybe you just are smarter :-)

I didn’t think all this out in great depth, and some of you have raised good exceptions that I agree with. As I said to Tim Bray in Twitter, I could have easily argued the other side. But I do believe history shows that that is ultimately the dinosaur’s side of the debate.

BTW, I probably wouldn’t have written the article at all if I hadn’t found such a cool image on Flickr to go with it.

The VFS example is a good one. Maybe Twitter is a good example for discussion. They used very high-level encapsulation (RoR) and it took them a long way, a really long way – much further than 99% of startups get. And yes, they now have to re-engineer a lot of stuff (throw out some encapsulations, and adopt some others that are more reliable). But you might argue that if they hadn’t built their first site in days they might not exist at all.

Amazon web services and Google’s App Engine are another good example. Scaling is really hard. But certain aspects, including some pretty significant ones, are now encapsulated to the point where any programmer who can put together a few HTTP requests can build massive systems that scale (at least in some important ways). I see things like AWS as being huge steps forward. They may not get it all right immediately, but it’s very early days yet for cloud computing.

I didn’t think all this out in great depth, and some of you have raised good exceptions that I agree with. As I said to Tim Bray in Twitter, I could have easily argued the other side. But I do believe history shows that that is ultimately the dinosaur’s side of the debate.

BTW, I probably wouldn’t have written the article at all if I hadn’t found such a cool image on Flickr to go with it.

The VFS example is a good one. Maybe Twitter is a good example for discussion. They used very high-level encapsulation (RoR) and it took them a long way, a really long way – much further than 99% of startups get. And yes, they now have to re-engineer a lot of stuff (throw out some encapsulations, and adopt some others that are more reliable). But you might argue that if they hadn’t built their first site in days they might not exist at all.

Amazon web services and Google’s App Engine are another good example. Scaling is really hard. But certain aspects, including some pretty significant ones, are now encapsulated to the point where any programmer who can put together a few HTTP requests can build massive systems that scale (at least in some important ways). I see things like AWS as being huge steps forward. They may not get it all right immediately, but it’s very early days yet for cloud computing.

I think the point of the article is not that Esteve doesn’t know about what’s underneath, but that growing up with more powerful tools (OO, patterns, etc.) changes the way you see the world. Take for example the Linux VFS layer, it’s a fine example of OO applied to a project that has to deal with lots of low level things, there’s inheritance, polymorphism, etc. Someone who hasn’t been exposed to OO might have implemented it differently, but since it’s the product of a generation that grew up with objects, Al Viro (the guy who designed the current VFS layer) thought it was natural to design it that way.

Although our primary language at Fluidinfo is Python, we have had to deal with things in C and C++, so I don’t think that a programmer who only knows high-level languages can be a good one.

Since kids have grown up using high level tools, it should be easier for them to think in abstract terms, that’s the key IMHO.

It’s funny to write about oneself in third person.

I think the point of the article is not that Esteve doesn’t know about what’s underneath, but that growing up with more powerful tools (OO, patterns, etc.) changes the way you see the world. Take for example the Linux VFS layer, it’s a fine example of OO applied to a project that has to deal with lots of low level things, there’s inheritance, polymorphism, etc. Someone who hasn’t been exposed to OO might have implemented it differently, but since it’s the product of a generation that grew up with objects, Al Viro (the guy who designed the current VFS layer) thought it was natural to design it that way.

Although our primary language at Fluidinfo is Python, we have had to deal with things in C and C++, so I don’t think that a programmer who only knows high-level languages can be a good one.

Since kids have grown up using high level tools, it should be easier for them to think in abstract terms, that’s the key IMHO.

It’s funny to write about oneself in third person.

I’m not claiming that progress in encapsulation is always (or even often) linear. Neal gave an example above (in beer brewing) in which we’ve gone back to re-examine how things were encapsulated. Also, I guess from your comments that I was thinking (or at least speaking) at a more general level than IDEs and programming languages etc. We do make mistakes, I agree. But the overall trend is towards more being encapsulated, towards good encapsulations gaining mindshare, etc. Very few people will ever need to write their own random number generator, or hashing code, or bitblt code – or you name it – there are hundreds of examples of that kind.

I also don’t like IDEs :-) Emacs is enough for me in that regard…

I’m not claiming that progress in encapsulation is always (or even often) linear. Neal gave an example above (in beer brewing) in which we’ve gone back to re-examine how things were encapsulated. Also, I guess from your comments that I was thinking (or at least speaking) at a more general level than IDEs and programming languages etc. We do make mistakes, I agree. But the overall trend is towards more being encapsulated, towards good encapsulations gaining mindshare, etc. Very few people will ever need to write their own random number generator, or hashing code, or bitblt code – or you name it – there are hundreds of examples of that kind.

I also don’t like IDEs :-) Emacs is enough for me in that regard…

We have, in a very real sense gone a long way down a specific technology path, heavily investing in a style of building tools. But are they just more complex because they are, or are they a huge mess? Horribly colored code in a flaky IDE, running on a platform that acts irrationally may look prettier than the old text-based screens, but honestly what is it doing now, that it wasn’t twenty years ago? Sure, the data is massive, but the functionality?

As we stretch the limits of this current technology we are quickly getting to a level beyond which it is too unstable to manage. To get past that threshold we’ll have to go back and refactor our foundations. At that point, either Esteve goes back and re-learns all that was known or he goes forward and just re-invents the whole same mess again (for the 4th time?)

Just a guess.

Paul.
http://theprogrammersparadox.blogspot.com

We have, in a very real sense gone a long way down a specific technology path, heavily investing in a style of building tools. But are they just more complex because they are, or are they a huge mess? Horribly colored code in a flaky IDE, running on a platform that acts irrationally may look prettier than the old text-based screens, but honestly what is it doing now, that it wasn’t twenty years ago? Sure, the data is massive, but the functionality?

As we stretch the limits of this current technology we are quickly getting to a level beyond which it is too unstable to manage. To get past that threshold we’ll have to go back and refactor our foundations. At that point, either Esteve goes back and re-learns all that was known or he goes forward and just re-invents the whole same mess again (for the 4th time?)

Just a guess.

Paul.
http://theprogrammersparadox.blogspot.com

I don’t know where your blog is, I don’t think. I’m surprised you know where mine is!

I’d like to read that article. We’ve run into some really interesting things just thinking about how to convert one function (an iterator that periodically goes to the network). It’s fun but also hard, as you say. I’m goin gto post about it to the Twisted list soon. Or maybe I should just blog about it…

Are you going to EuroPytho?

Terry

I don’t know where your blog is, I don’t think. I’m surprised you know where mine is!

I’d like to read that article. We’ve run into some really interesting things just thinking about how to convert one function (an iterator that periodically goes to the network). It’s fun but also hard, as you say. I’m goin gto post about it to the Twisted list soon. Or maybe I should just blog about it…

Are you going to EuroPytho?

Terry

There’s value in encapsulating knowledge and making it available to others. You wrote a book and you have a blog where you bundled up decades of extremely hard won experience. It benefits you to do so, and it benefits the rest of us to learn from you the easy way. And so it goes…