Linked by snydeq on Mon 25th Oct 2010 21:23 UTC
General Development InfoWorld's Peter Wayner reports on once niche programming languages gaining mind share among enterprise developers for their unique abilities to provide solutions to increasingly common problems. From Python to R to Erlang, each is being increasingly viewed as an essential tool for prototyping on the Web, hacking big data sets, providing quick predictive modeling, powering NoSQL experiments, and unlocking the massive parallelism of today's GPUs.
Thread beginning with comment 447072
To read all comments associated with this story, please click here.
Dawnfall of OO?
by peskanov on Mon 25th Oct 2010 23:48 UTC
peskanov
Member since:
2006-01-15

On the whole list, the only OO language is Python. And to tell the truth, Python is loved mostly by people who tends to program in imperative style. Most pieces of python code could be easily confused with (late eighties - early nineties) basic.

I have always disliked OO strongly, specially fundamentalist OO (everything must be part of an object - java). I was loosing all hope to see other areas of programming moving forward, the OO blackhole seemed to eat everything...but these last years functional languages (Erlang, F# (Ocaml), Haskell) started to make some noise. Also, others trendy languages are more permissive and interesting in the non-OO front, like Python or Lua.

Let's hope this trend continues, and we see real improvements in areas like parallelization, expressiveness, optimization and debugging.

Edited 2010-10-25 23:50 UTC

Reply Score: 4

RE: Dawnfall of OO?
by Hypnos on Mon 25th Oct 2010 23:56 in reply to "Dawnfall of OO?"
Hypnos Member since:
2008-11-19

Agreed -- imperative programming is much more natural than OOP for data reduction. Data doesn't "do" anything, stuff gets done to it.

Not sure about functional programming, as I'm not sure if every data reduction can simply be expressed as a transformation. And then, you have tasks like plotting/visualization which would be cumbersome to handle as "side effects."

Edited 2010-10-25 23:58 UTC

Reply Parent Score: 1

RE[2]: Dawnfall of OO?
by torbenm on Tue 26th Oct 2010 07:36 in reply to "RE: Dawnfall of OO?"
torbenm Member since:
2007-04-23

Not sure about functional programming, as I'm not sure if every data reduction can simply be expressed as a transformation.


A reduction is a transformation. There are standard functions in most functional languages for data reduction. I find functional languages much better suited to complex data handling than imperative languages.

And then, you have tasks like plotting/visualization which would be cumbersome to handle as "side effects."


Some functional languages (e.g., SML, F# and Scala) treat i/o such as graphics and file access as side effects, so they work pretty much as they do in imperative languages. Other languages (like Haskell and Clean) are purely functional and handle i/o by forcing sequence on i/o operations through monads or linear types. These take some getting used to if you come from an imperative world. IIRC, Erlang uses CSP-style message passing for i/o. This, IMO, is a very natural way of doing it.

Reply Parent Score: 1

RE[2]: Dawnfall of OO?
by vivainio on Tue 26th Oct 2010 19:53 in reply to "RE: Dawnfall of OO?"
vivainio Member since:
2008-12-26

Agreed -- imperative programming is much more natural than OOP for data reduction.


OOP is imperative programming.

Reply Parent Score: 2

RE: Dawnfall of OO?
by earksiinni on Tue 26th Oct 2010 01:12 in reply to "Dawnfall of OO?"
earksiinni Member since:
2009-03-27

The downfall of OO is really about the need for an indicative mood in computer languages. OO tried but failed. Declarative languages also had the idea in their head but also failed.

Reply Parent Score: 1

RE[2]: Dawnfall of OO?
by rycamor on Tue 26th Oct 2010 13:56 in reply to "RE: Dawnfall of OO?"
rycamor Member since:
2005-07-18

The downfall of OO is really about the need for an indicative mood in computer languages. OO tried but failed. Declarative languages also had the idea in their head but also failed.


Maybe I'm opening a can of worms here, but what exactly do you mean by 'indicative mood'?

Reply Parent Score: 1

RE: Dawnfall of OO?
by Richard Dale on Tue 26th Oct 2010 02:33 in reply to "Dawnfall of OO?"
Richard Dale Member since:
2005-07-22

On the whole list, the only OO language is Python. And to tell the truth, Python is loved mostly by people who tends to program in imperative style. Most pieces of python code could be easily confused with (late eighties - early nineties) basic.


Ruby and JavaScript are both certainly both OO. And there is even an OO version of COBOL I believe, although I've no idea if anyone actually uses it.

I don't think OO is dead at all. Good luck writing GUI applications with a non-OO toolkit.

Reply Parent Score: 2

RE[2]: Dawnfall of OO?
by peskanov on Tue 26th Oct 2010 07:56 in reply to "RE: Dawnfall of OO?"
peskanov Member since:
2006-01-15

Of course, Javascript, Python, Ruby and nearly all languages are still OO. I was talking about not being "strict OO" like Java.
Python is used in imperative style programs very often. The same is true for Javascript, in fact is even more common.
Most of the Javascript code I have seen looks like an amateur basic program made in the 80's. I really think the popularity of Javascripts comes from that aspect of the language: it's so easy to produce a snippet of code which does something useful...without having to model a set of object abstractions unrelated to the task at hand.

BTW, I never said OO is dead. I am not so optimistic!

Reply Parent Score: 2

RE[2]: Dawnfall of OO?
by peskanov on Tue 26th Oct 2010 08:10 in reply to "RE: Dawnfall of OO?"
peskanov Member since:
2006-01-15

I forgot about the GUI comment.
When I started programming, few people had access to OO languages or even books about that thing.
All the GUIs available for the home user were programmed in procedural/imperative style, most of them in assembler.
And you did not need any "luck" for doing a GUI system. You had to be smart enough to abstract so much, but the same is true trying to do so in OO style.

These days I am remembering a little generic GUI thas was released for C64, (not GEOS) and probably took a few KB of ROM only. It was included in the Final Cartridge 3, a pirating tool for software "backup" ;)

http://www.youtube.com/watch?v=ZrAh-hBSBA8

There is a window example in 2:00. And a text editor with proportional fonts in 1:15 (it was more powerful than it look in the video).

Reply Parent Score: 2

RE: Dawnfall of OO?
by SuperDaveOsbourne on Tue 26th Oct 2010 03:37 in reply to "Dawnfall of OO?"
SuperDaveOsbourne Member since:
2007-06-24

Grab the old 'software tools' book and find a recent implementation of RatFor, and go to town. Man, if you want to live in the code, and not the data then do something functional and reusable like RatFor.

Reply Parent Score: 1

OO is on it's peak
by pica on Tue 26th Oct 2010 09:11 in reply to "Dawnfall of OO?"
pica Member since:
2005-07-10

"not rising" does not only imply "falling". "Not rising" may also be "stagnating".

pica

Reply Parent Score: 1

RE: Dawnfall of OO?
by MacMan on Tue 26th Oct 2010 16:49 in reply to "Dawnfall of OO?"
MacMan Member since:
2006-11-19

Lets hope this trend away from OO languages continues indeed.

I'm not saying OO is evil, there are some domains where it makes a lot of sense, perhaps business applications, possibly operating systems.

But there are a lot of domains where OO makes no sense. I'm a physicist, and most physical simulations at least to me make a lot more sense expressed in a functional manor, with languages like Haskel or Mathematica, and to a certain degree, Python (Python does have some functional features, enough to make it useful IMO).

Basically, some things I like in a high level language are easy binding to C/C++ for the numerically intensive bits, and an expressive language with functional features. Matlab is a nightmare to interface with C, Mathematica is not much better. Python and Haskel on the other hand are very easy to interface with C.

I

Reply Parent Score: 1

RE: Dawnfall of OO?
by hibridmatthias on Tue 26th Oct 2010 16:56 in reply to "Dawnfall of OO?"
hibridmatthias Member since:
2007-04-11

Um, no Ruby is OO

Reply Parent Score: 1

RE: Dawnfall of OO?
by frytvm on Tue 26th Oct 2010 22:35 in reply to "Dawnfall of OO?"
frytvm Member since:
2009-11-11

Perhaps the problem isn't so much OOP as its evangelists. There's no problem with everything being an object, so much as being forced to write code in what people consider "proper" OOP style (often in a high-mutation style, where accessors are mandatory even for simple data structures, like linked list items).
There's no reason why OOP can't be used in a functional style (immutable objects) or work nicely with other styles of coding (smalltalk, for example, is a lot more "functional" than python). Languages like F# and Scala show that these approaches don't have to be at odds with fp.
That's not to say that OOP is worthless. http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
is a good essay on the comparison of OOP with more traditional abstraction techniques, although it perhaps requires a bit of functional programming knowledge.

Reply Parent Score: 1

RE[2]: Dawnfall of OO?
by peskanov on Tue 26th Oct 2010 23:44 in reply to "RE: Dawnfall of OO?"
peskanov Member since:
2006-01-15

I never really understood what "everything is an object" means. In fact, I share with Stepanov the opinion that it means nothing at all.
I can understand, however, "everything must be declared inside the scope of a class, and used through instanced objects". And I don't like it. It's unproductive, and push people to produce inefficient, long and brittle code.

If I want (for example) to implement an algorithm which takes a raw data set and produces a quantized result, why should I abstract a class of it? And why should it work only on a few datatypes/classes, which must make explicit reference to it though inheritance?

I would like to see programming languages advancing in that kind of tasks, in order to produce generic code that molds itself to different data instead of the class/inheritance mess.
But please not in the path of the C++ templates; I mean solutions that can be read/used/compiled by humans.

Reply Parent Score: 1