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

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.

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.

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

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

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

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.

Sounds like lisp "special variables".

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.

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

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.

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.

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.

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.

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.

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.

Perhaps "OO Structure" or "OO Syntax" would have been a better choice of words. You can abuse java by declaring your class with a static main and then write things procedurally within that, but you have to have that class and its OO Structure.

In Python, that is not needed. Objects are there when they make sense(such as most gui design), but not required, even in structure or syntax, when they do not make sense.

Precisely, and even if you do write it in a procedural fashion from that point forward you have the clutter of the OO code around it.

(It is of course not clutter if you are actually writing in an OO fashion where it makes sense and is very useful.)

I cannot place the source of this quote, but to paraphrase:

    Judge a language not by what it makes hard, but what it makes easy.

Uh, if a language makes some common, reasonable things hard, it's hard not to judge is harshly.

It depends on how dispensable those common and reasonable things are. There are a lot of ways to skin a cat, and one strong quality of a language is how well it gives you one overarching, consistent cat-skinning paradigm that is sufficient to skin cats. If it does, then it can be excused to some degree for not supporting other methods of skinning.

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

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.

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

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.

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.

Ah, so that's scala seems so obtuse...

Nor has anyone else ever realized that a pen doesn't write: a human uses a pen to write something on something.

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

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.

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)

I've long commented that one of the ironies of C++ is that it demonstrates that the idiom is better written ++C.