

The problem with OO Languages is not the OO - dragonquest
http://www.rebol.com/article/0425.html

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

~~~
davidw
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
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
"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.

------
vlucas
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).

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

~~~
83457
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.

------
billswift
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.

------
praptak
"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
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.

~~~
kls
"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.

~~~
jganetsk
People have to stop conflating the concept of OOP with that of encapsulation.
No one is arguing the value of encapsulated black boxes. Any good paradigm
will have that concept! The question is, do you want OO-style black boxes, or
functional style black boxes (ML-style modules or Haskell-style type classes)?

Functional style encapsulation is a really good contender for handling UIs,
especially given the ease of use of first-class functions, and especially
especially reactive programming frameworks.

~~~
kls
The inheritance mode is natural to OO for the UI. It flows quite well and
helps provide reuse of components by slighly mutating that component into new
functionality. Lets take select box --> FilteringSelectBox, I reuse the select
box and extend it by adding a method that captures user input runs a match on
the internal data store and overrides the display to only display results that
are within the partial entered text. With the addition of a method and the
overriding of a display method I have created novel functionality. This is
harder to reproduce in a purely procedural language.

I have been around for a while and used about all of them and I have never
seen the efficiency that OO provides for UI in a non OO language.

For instance in OO I can encapsulate all functionality related to a pop up
with that pop-up, so it can have a member variable of content, while also
providing a show and hide method. The strong point of OO is that is is easy to
encapsulate the data with the functionality (In most cases this is a bad thing
but in UI, you are at the end of the rode the functionality and the data start
to merge to present it to a human) and scope it so to decide the scope of that
dialog, I can create and instance of that dialog and call show on that dialog,
it will show that instance of the dialog.

Whereas, if I want that dialog to be a singleton and only share the reference
among functionality to guarantee that there is only one true dialog, I can
also do that.

Representing a black box like that in functional languages can be done, I am
not saying that it cannot. I just have never seen that it is as clean as OO.
Now in saying that, languages are subjective. What may be clear to me could
seem obtuse to someone else.

For me though Object encapsulation and inheritance model (or mix-in /
Interface) makes it far easier to slightly adapt code and make it behave well
for The UI. The only other place that I have realized the benefit of OO, was
in AI development. In my time as an AI developer, I can not see how we could
have realized the systems that we did without OO.

Outside of those realms and a few other problem domains I question the value
of OO and it's benefits are marginal at best. Structures handle everything
that is needed in a great percentage of places. Though it would be nice to be
able to apply Interfaces to structures.

"Functional style encapsulation is a really good contender for handling UIs,
especially given the ease of use of first-class functions, and especially
especially reactive programming frameworks."

I don't think you can convince me that dumping OO entirely from the UI is
going to be a step forward. There is a place for procedural work-flow (I call
it a page controller for web) in the UI.

That is why in my original post I was arguing for JavaScript it is actually
the perfect language for UI development. It was not created by accident it
directly strikes at the heart of the problem.The problem is that the browser
implementation until recently have been abominable and used incorrectly it can
create a mess. But the basic tenants of the language are sound.

------
timwiseman
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
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
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
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
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.

~~~
logicalmind
The distinction I am making is based on this:

"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.)"

I was disagreeing with the point that OO languages "force" you to use OO
concepts. OO concept to me means encapsulation/inheritence/polymorphism. Java
in particular does not force you to use any of these OO concepts. You do have
to declare one class, but "class" in that sense is purely for scoping. You
don't have to instantiate it or acknowledge its object-ness.

~~~
scott_s
And my point is that while you are not forced to design an OO program, you are
forced to use OO mechanics. Considering that other multiparadigm languages
don't force this (C++, Python, Ruby, Perl, Objective C, Lisp), I think it's an
important distinction.

------
middayc
"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
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
my last 4 webapps are made in 100% REBOL and it's cheyenne webserver. They are
<http://www.site-assistant.com> , <http://www.cebelca.biz>
<http://www.qwikitodo.com> <http://www.qwikitxt.com> (last two, first two I've
made are more of miniapps)

