37 ms·

The problem with OO Languages is not the OO

41 points by dragonquest 17y ago

gruseom 17y ago
Can anyone give an example of what he means by expressions carrying an implicit environment around with them in REBOL?
- 83457 17y ago
  My impression from this statement is that to resolve dependencies objects can/should be designed to reference the primary environment where they are to be run instead of the having these details passed per object creation and/or functions calls. I could be totally wrong but that was my first thought while reading it.
- JulianMorrison 17y ago
  Sounds like lisp "special variables".
middayc 17y ago
"At Apple ATG, I worked with many from the Xerox Smalltalk team, and we pushed for stronger models of OO within software designs. And, we resisted as much as possible the introduction of C++ , which in fact Larry Tesler jokingly called it C+- (approriate, actually.)" I already read this (I use REBOL), this paragraph was very funny to me :)
- hassy 17y ago
  What sort of software do you write in Rebol? I've only read about it and I find it fascinating. It'd be great to hear something from an experienced user.
  - middayc 17y ago
    my last 4 webapps are made in 100% REBOL and it's cheyenne webserver. They are http://www.site-assistant.com http://www.site-assistant.com , http://www.cebelca.biz http://www.cebelca.biz http://www.qwikitodo.com http://www.qwikitodo.com http://www.qwikitxt.com http://www.qwikitxt.com (last two, first two I've made are more of miniapps)
- btilly 17y ago
  I've long commented that one of the ironies of C++ is that it demonstrates that the idiom is better written ++C.
damienkatz 17y ago
I think a problem Rebol might have is it's name sounds very outdated, like a strange cousin of COBOL.
- davidw 17y ago
  The real problem, IMO, is that it's got some kind of closed-source licensing model. That may work for Microsoft, but not too many other people can get away with it IMO.
  - middayc 17y ago
    I used rebol 10 years ago and left it after few years because of it's closeness and artificial limitations set. The general closeness was a huge factor IMHO. I'm back now. With direct communication between community members and REBOL author the feel of closeness is gone now even in R2 (also free versions of R2 can talk to dll/so -s now also which was the main hurdle back then). R3 is about to fix the things discovered wrong in R2. It's development is highly interviewed with community. With very active development chat, open buglists, wiki based documentation, weekly releases, autor's blogposts that ask for opinions I can say the closeness factor isn't there any more. I am not sure but I think in R3 everything except very narrow core of language will be open sourced.
    - plinkplonk 17y ago
      "I am not sure but I think in R3 everything except very narrow core of language will be open sourced." I am not sure if that would be very attractive to hackers. Why would anyone want to use a non open source language these days? Making a language closed source (even in parts) these days is to guarantee that it remains a niche language (unless it has been lucky enough to have a lot of pervasive legacy code, which Rebol certainly doesn't). I, for one, would never choose a closed source language for one of my projects.
timwiseman 17y ago
This is one of the reasons I have become a big fan of Python. It lets you easily use objects and OO concepts when they are the best approach, but it does not force you to use them when the particular problem is more functional (or even more procedural for many short, simple scripts.).
- logicalmind 17y ago
  Isn't this true of any OO language? I've seen former COBOL programmers write COBOL-like code in Java. As well as C-Like code in Java. Nothing stops you from having a single java class with numerous functions at the same level and static/global variables.
  - scott_s 17y ago
    But you are forced to use classes and instantiate objects, even if the resulting program you write is procedural. Languages like, say, Python, don't force you to ever declare a class.
    - logicalmind 17y ago
      I wouldn't recommend it, but you are only required to declare one class in a java program that contains the static "main" method. If you strictly use primitives and static methods there would be no instantiation needed. I think the only real difference is that in python your methods would be scoped at the global level. While in a single class java program your methods would be scoped within the class.
      - scott_s 17y ago
        Right, but you are required to declare a class. You are required to acknowledge that the object system exists. Python has no such requirement. Mechanically, what can be accomplished in one language can be accomplished in the other. But that's not what this distinction is about.
        17y ago
praptak 17y ago
"I realize that in today's programming world, I am a heretic." Yeah, right. Nobody ever questioned this "everything should be OO" paradigm. Except that Java was actually the last language influenced by it. Someone should tell this guy about Python, Clojure, Ocaml, Haskell or even Javascript.
- jshen 17y ago
  No, scala was clearly sticking to the everything is an object model. clojure, ocaml, and haskell combined have maybe 1% of the market share. This supports his point. Javascript is widely used only because it's the only game in town for non proprietary programming on the client side. Also, most people that do heavy js try to bolt typical OO features on to javascript and are even pushing to add it to the standard. I think is point holds. Some people have certainly questioned OO, pg is one of them, but they are clearly in the minority.
  - joe_the_user 17y ago
    Ah, so that's scala seems so obtuse...
  - kls 17y ago
    "JavaScript is widely used only because it's the only game in town for non proprietary programming on the client side. Also, most people that do heavy js try to bolt typical OO features on to JavaScript and are even pushing to add it to the standard." Be that as it may, OO lends itself very well to UI programming. widget, containers et al. lend thenselves very well to becoming encapsulated black boxes that notify the larger system through defined event contracts to publish out changes. I believe that the problem has historically been between the UI and business logic. UI is a natural fit for OO where as business logic is a good candidate for procedural services based workflow that expose their functionality to the UI. The problem is alot of developers try to solution the entire problem domain with one tool a.k.a the gold hammer. This is why I think Ajax and JavaScript coupled with toolkits like Dojo are a huge step forward they allow the UI developers to work with in the best toolthat fits their problem domain while the service developers can do the same with the best tools for that problem domain. The nice part is that their is a hard contract between the two and you cannot cross the barrier with the other tool. As their are built on messaging JSON or XML contracts to and fro.
vlucas 17y ago
Lately I have been finding myself thinking along the same lines. Everything in moderation. There is no universal tool for anything. OO is just a tool that should be used when appropriate. Lately I have found myself preferring to model data with OO and use procedural/functional code for the rest. This is especially handy for simple sites like feed readers, etc. Python and PHP handle switching back and forth between the two styles very easy (and acceptable).
billswift 17y ago
I am not much of a programmer, and have never understood OO development, despite a fair bit of reading. I was thinking about it earlier today, and I think part of the reason OO seems so difficult is that it does not fit human languages. Languages have separate nouns and verbs and various modifiers (adjectives/adverbs) and connectives. OO with its "unifying" attributes and methods is like a language with preformed phrases rather than words, and which can be modified in only limited, preset ways. This works much better for visual images (since it seems to be closer to how we manipulate images mentally) which makes it a better fit for GUIs.

41 points by dragonquest 17y ago

gruseom 17y ago

Can anyone give an example of what he means by expressions carrying an implicit environment around with them in REBOL?

83457 17y ago
My impression from this statement is that to resolve dependencies objects can/should be designed to reference the primary environment where they are to be run instead of the having these details passed per object creation and/or functions calls. I could be totally wrong but that was my first thought while reading it.
JulianMorrison 17y ago
Sounds like lisp "special variables".

middayc 17y ago

"At Apple ATG, I worked with many from the Xerox Smalltalk team, and we pushed for stronger models of OO within software designs. And, we resisted as much as possible the introduction of C++ , which in fact Larry Tesler jokingly called it C+- (approriate, actually.)" I already read this (I use REBOL), this paragraph was very funny to me :)

hassy 17y ago
What sort of software do you write in Rebol? I've only read about it and I find it fascinating. It'd be great to hear something from an experienced user.
- middayc 17y ago
  my last 4 webapps are made in 100% REBOL and it's cheyenne webserver. They are http://www.site-assistant.com http://www.site-assistant.com , http://www.cebelca.biz http://www.cebelca.biz http://www.qwikitodo.com http://www.qwikitodo.com http://www.qwikitxt.com http://www.qwikitxt.com (last two, first two I've made are more of miniapps)
btilly 17y ago
I've long commented that one of the ironies of C++ is that it demonstrates that the idiom is better written ++C.

damienkatz 17y ago

I think a problem Rebol might have is it's name sounds very outdated, like a strange cousin of COBOL.

davidw 17y ago
The real problem, IMO, is that it's got some kind of closed-source licensing model. That may work for Microsoft, but not too many other people can get away with it IMO.
- middayc 17y ago
  I used rebol 10 years ago and left it after few years because of it's closeness and artificial limitations set. The general closeness was a huge factor IMHO. I'm back now. With direct communication between community members and REBOL author the feel of closeness is gone now even in R2 (also free versions of R2 can talk to dll/so -s now also which was the main hurdle back then). R3 is about to fix the things discovered wrong in R2. It's development is highly interviewed with community. With very active development chat, open buglists, wiki based documentation, weekly releases, autor's blogposts that ask for opinions I can say the closeness factor isn't there any more. I am not sure but I think in R3 everything except very narrow core of language will be open sourced.
  - plinkplonk 17y ago
    "I am not sure but I think in R3 everything except very narrow core of language will be open sourced." I am not sure if that would be very attractive to hackers. Why would anyone want to use a non open source language these days? Making a language closed source (even in parts) these days is to guarantee that it remains a niche language (unless it has been lucky enough to have a lot of pervasive legacy code, which Rebol certainly doesn't). I, for one, would never choose a closed source language for one of my projects.

timwiseman 17y ago

This is one of the reasons I have become a big fan of Python. It lets you easily use objects and OO concepts when they are the best approach, but it does not force you to use them when the particular problem is more functional (or even more procedural for many short, simple scripts.).

logicalmind 17y ago
Isn't this true of any OO language? I've seen former COBOL programmers write COBOL-like code in Java. As well as C-Like code in Java. Nothing stops you from having a single java class with numerous functions at the same level and static/global variables.
- scott_s 17y ago
  But you are forced to use classes and instantiate objects, even if the resulting program you write is procedural. Languages like, say, Python, don't force you to ever declare a class.
  - logicalmind 17y ago
    I wouldn't recommend it, but you are only required to declare one class in a java program that contains the static "main" method. If you strictly use primitives and static methods there would be no instantiation needed. I think the only real difference is that in python your methods would be scoped at the global level. While in a single class java program your methods would be scoped within the class.
    - scott_s 17y ago
      Right, but you are required to declare a class. You are required to acknowledge that the object system exists. Python has no such requirement. Mechanically, what can be accomplished in one language can be accomplished in the other. But that's not what this distinction is about.
      - 17y ago

praptak 17y ago

"I realize that in today's programming world, I am a heretic." Yeah, right. Nobody ever questioned this "everything should be OO" paradigm. Except that Java was actually the last language influenced by it. Someone should tell this guy about Python, Clojure, Ocaml, Haskell or even Javascript.

jshen 17y ago
No, scala was clearly sticking to the everything is an object model. clojure, ocaml, and haskell combined have maybe 1% of the market share. This supports his point. Javascript is widely used only because it's the only game in town for non proprietary programming on the client side. Also, most people that do heavy js try to bolt typical OO features on to javascript and are even pushing to add it to the standard. I think is point holds. Some people have certainly questioned OO, pg is one of them, but they are clearly in the minority.
- joe_the_user 17y ago
  Ah, so that's scala seems so obtuse...
- kls 17y ago
  "JavaScript is widely used only because it's the only game in town for non proprietary programming on the client side. Also, most people that do heavy js try to bolt typical OO features on to JavaScript and are even pushing to add it to the standard." Be that as it may, OO lends itself very well to UI programming. widget, containers et al. lend thenselves very well to becoming encapsulated black boxes that notify the larger system through defined event contracts to publish out changes. I believe that the problem has historically been between the UI and business logic. UI is a natural fit for OO where as business logic is a good candidate for procedural services based workflow that expose their functionality to the UI. The problem is alot of developers try to solution the entire problem domain with one tool a.k.a the gold hammer. This is why I think Ajax and JavaScript coupled with toolkits like Dojo are a huge step forward they allow the UI developers to work with in the best toolthat fits their problem domain while the service developers can do the same with the best tools for that problem domain. The nice part is that their is a hard contract between the two and you cannot cross the barrier with the other tool. As their are built on messaging JSON or XML contracts to and fro.

vlucas 17y ago

Lately I have been finding myself thinking along the same lines. Everything in moderation. There is no universal tool for anything. OO is just a tool that should be used when appropriate. Lately I have found myself preferring to model data with OO and use procedural/functional code for the rest. This is especially handy for simple sites like feed readers, etc. Python and PHP handle switching back and forth between the two styles very easy (and acceptable).

billswift 17y ago

I am not much of a programmer, and have never understood OO development, despite a fair bit of reading. I was thinking about it earlier today, and I think part of the reason OO seems so difficult is that it does not fit human languages. Languages have separate nouns and verbs and various modifiers (adjectives/adverbs) and connectives. OO with its "unifying" attributes and methods is like a language with preformed phrases rather than words, and which can be modified in only limited, preset ways. This works much better for visual images (since it seems to be closer to how we manipulate images mentally) which makes it a better fit for GUIs.