Is There Any Future For Closed Languages?

willmurat writes: "I read about Rebol in an article in UnixInsider months ago. It seems to me a very interesting language, with new features and trying to bring new paradigms in programming. But (always there is a but ...), it isn't Open Source and no institution is responsible to maintain that language. The only responsible party is Rebol Technologies. I'm not saying this is the right way to failure; there are examples of success following this way (Visual Basic and Delphi, for example), but I think a business strategy like that isn't good anymore. See the current developing of Perl version 6 for a very good example of language discussion. Seems to me the owners of Rebol language are limitating the popularization of that language choosing that way of dealing in this issue ... Is there any future to popularize a language that way?"

Re:But surely..

[Anonymous Coward]

Ok, here http://www.gnome.org/gb

Re:No future for closed anything

[Mr. Slippery]

Most programmers just want to get their product finished, rather than zealously convert the world to open source, and so far there isn't a compelling argument to switch most people

Hmmm...do you think that most programmers have never had the experience of being stuck with some flaw in, or question about, a closed-source product that could be answered by looking at the source?

My current project involves a closed-source voice recognition package. We've got several questions about the exact behavior of some API calls that simply aren't answered in the documentation...so we get to shell out kilo-dollars in support costs to get to ask questions that we could answer ourselves in ten minutes given the source. That's why my manager is completely open to open source in other aspects of the project.

On my last project, I ended up writing a replacement IPC system for the closed-source middleware that they were never able to get working, and never able to get the vendor to fix. They could have saved several programmer-months if they'd gone with an open-source product that they could fix themselves, rather than getting dragged into a morass of unsupported software.

Are these experiences so unusual?

Tom Swiss | the infamous tms | http://www.infamous.net/

standard functionality

[TomL]

imho what gives a language a future, whether it's closed source or not, are standards and functionality. if rebol can provide a good standard language that doesn't change in syntax, i feel that they then have a good shot at success. rebol looks to me at least like it has functionality down.

languages develop into what?

[Bingo Foo]

...examples of success following this way (Visual Basic and Delphi, for example), but I think a business strategy like
that isn't good anymore. See the current developing of Perl version 6 for a very good example of language
discussion. Seems to me the owners of Rebol language are limitating the popularization of that language choosing
that way of dealing in this issue ...

I initially read this as "See the current developing of Perl version 6 for a very good example of language that isn't good anymore."

Ha ha.

Bingo Foo

---

Re:Is There Any Future For Open Languages?

[flounder_p]

He does have a point. Even though he is being kind of a smartass :-) I do think that they are talking about compilers and interpreters not the language spec. I wonder what an open spec on a lagnuage would be like. I don't think it would work at all. I think we better just stick to open source compilers and interpreters.

Stop the Insanity!

[bmckeever]

There is no such thing as an "Open Source language"! Language = Syntax + Semantics. Which of these can possibly be Open Source, and what could that conceivably mean?

Re:I disagree

[haruharaharu]

What, better error messages? Perhaps you could name a couple places where VC++ is less portable than other C++ compilers.

Rebol

[MarkusQ]

I had looked at using Rebol for a project a few years back, and wound up passing on it specifically because they were unable to point me to a definition of the language; their ultimate answer to all questions of semantics was "ask Rebol--it does what it does, and it works the same on all platforms." Not only was the implementation closed but (respecting the distinction between a language and its implementation) the language itself was unpublished. (They may have gotten further in the last few years; I haven't had a chance to check back.)

I might have gone with a closed-but-published language, but without a language (i.e., a definition of what is supposed to happen when I type "xyzzy foo") I would be a fool to choose it. Which was a shame, because I liked what I saw. Suppose, though, I got some distance into the project and discovered that something wasn't working the way I expected. How could I distinguish between:

1. A failure in my understanding of the language
2. A bug in my code
3. A bug in REBOL

without some definition of what how each construct is expected to behave? Any assumption I make leads to trouble, especially if I expect to be able to upgrade to a later implementation of the language (which may, for example, fix a bug that was the same on all platforms to work correctly on all platforms). I have great respect for Carl, and liked what I was able to infer about his language by looking at his implementation of it. But that wasn't enough to risk the project on.

Bottom line: there may be a future for closed source implementations of languages but I don't hold out much hope for languages with unpublished, proprietary definitions.

--MarkusQ

I can run it anywhere.

[bot-man]

I like open source because it gives me the feeling of control. I can modify the source to do what I want, when I want, hacking it up however it suits my need. REBOL, on the other hand goes the opposite direction. REBOL's aim is to allow a program that runs on one platform to run on any other platform, without modifications. It's a sort of unification principle that requires a high level of cross-platform consistency because it's a distributed computing technology, not just a programming language. That consistency comes at the price of openess. That's what REBOL is going after. A worthy goal.

Re:Going proprietary is risky

[Anonymous Coward]

There were a lot of "Y2K" projects where applications had to be rewritten in new languages. The languages in which the original applications had been written no longer existed, and had been running for years on systems configured to still support them.

Look around at the old versions of IBM mainframe OSes, old Solaris/BSD boxes -- many of those were still running because old apps required them. I personally have been involved with two such situations in the past two years -- one was not a Y2K situation, it was just an app written to an old API for which there was no compatibility supported in the latest version.

Going proprietary is risky

[Anonymous Coward]

I think choosing proprietary technology is always a risky choice. The project using it might very well outlive the company owning that technology.
A programming language is something that require time to learn it (and I don't mean just learning the basics which is usually done in a few hours but learning how to best use it).
I try to invest my time in something that's worth it. I'll never regret my knowledge of C/C++ but the time I spent using Visual Basic (by my employers at the time choice not mine) is just a complete waste.

Re:No future for closed anything

[sjames]

If you're good at debugging the tools in addition to your own code, that may be a good direction to go.

Of course, unless you're just banging out RAD, you necessarily have people who ARE good at debugging on hand.

I prefer to avoid proprietary libraries and compilers. It's not that they won't get the job done, many of them will. However, in 5 years when the software needs a revision, will the proprietary tools still be up to the job? Hove they been upgraded? Did the upgrades break your code?

There's also a need to distinguish between totally proprietary stuff and proprietary implementations of open standards. The latter probably won't cause nearly as much trouble down the road as the former.

Re:Closed source is a good thing.

[flounder_p]

Hmmm,

A thought Perl, Python, Ruby...

They are bigger because they are much larger general purpose languages and not just for one thing. Rebols niche is clean networking as far as I can tell. closed and open source has nothing to do with any of it. I prefer a laguange to be open but I will use it if it is good if it is not. I wrote a full GUI based picture viewer organizer, slideshow thing in Perl/Tk and it runs on Linux(which I developed it on) and Windows without any changes. I have not tested on other systems but if they support perl/tk it should run. Both of them are open source

Re:But surely..

[Ayende Rahien]

Where is the Gnu/VB compiler?

But surely..

[popeyethesailor]

The license isnt much different from a VB or Delphi license, you just have to pay for the Rebol compiler.

Most large corporations use only commercial compilers, so the business model is pretty sound.

Even cc in most *nix boxes dont come for free, you'd have to buy 'em separately.

The point is, once the specs are known, someone will make Grebol , so dont worry :)

No future for closed anything

[Anonymous Coward]

Within approximately 3-4 days, Microsoft, Apple, and every other major closed source vendor will be bankrupt, and everyone will have switched to Linux. We will be a happy planet overjoyed at being liberated from closed source, as that is the #1 gripe of every computer user on the planet. Suddenly, the sun will always shine, AIDS and cancer will be cured, rainbows will shoot out of Linus Torvald's ass, and....

Well, if you haven't caught on by now, just look at the history of what's used, and WHY it's used, put away your GNU colored glasses, and see the world as it is. Closed source will continue to be the dominant player in programming languages, or at the very least proprietary extensions to more open languages. Most programmers just want to get their product finished, rather than zealously convert the world to open source, and so far there isn't a compelling argument to switch most people, once they realize the 'free as in beer' doesn't mean they get free beer for using OSS.

What does "closed language" mean?

[Pseudonym]

Part of the confusion here is what we mean by "closed languague". I think of three separate things:

• Language has only one proprietary implementation. This is really only a problem if the language has no "standard" (as opposed to a "de facto standard"). Consider an open source implementation of Visual Basic, for example. Microsoft would play with the language definition so the open source implementors would forever chase a moving target. A smart proprietary language implementor, of course, would not do this, but rather would capitalise on the interest to push their own products.
• Kernighan's definition: The standard language is insufficiently expressive for practical use, therefore must be extended. Every vendor's extensions are different from everyone else's.
• The actual language definition is copyrighted and precludes open source implementations.

On the last one, does anyone use Miranda(TM) any more? We used to, back in the days when we had no choice if we wanted lazy functional programming. But now we have Haskell [haskell.org], with at least three solid open source implementations and a number of other research platforms. Even Microsoft has taken an interest (hiring half of the Cambridge University Haskell research group).

There's a lesson in here somewhere.

"Closed language" or "proprietary language"?

[yerricde]

The article does not describe closed languages but instead describes a language for which the only extant implementation is proprietary. This is different from a closed language such as standard Basic or Pascal, which is inadequate for real applications without vendor-specific extensions (QB/VB, TP/Delphi). According to Kernighan [tuxedo.org]:

The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to replace the defective run-time environment with a sensible one, unless one controls the compiler that defines the "standard procedures". The language is closed.

People who use Pascal for serious programming fall into a fatal trap. Because the language is impotent, it must be extended. But each group extends Pascal in its own direction, to make it look like whatever language they really want. Extensions for separate compilation, FORTRAN-like COMMON, string data types, internal static variables, initialization, octal numbers, bit operators, etc., all add to the utility of the language for one group but destroy its portability to others.

I feel that it is a mistake to use Pascal for anything much beyond its original target. In its pure form, Pascal is a toy language, suitable for teaching but not for real programming.

GNU Visual Basic compiler

[yerricde]

Where is the Gnu/VB compiler?

They're working on it [multimania.com]. Or you can use Glade [gnome.org] to design your GTK+ program's interface layout. Besides, VB sucks for real projects.

Re:I disagree

[Rogerborg]

• proprietary control: VisualBasic, Java, Delphi

And let's not forget Microsoft Visual C, which is "more or less" like gcc in the same way that J++ is "more or less" like Java. ;)

Sometimes Closed is Best...

[Woodie]

Hey -

food for thought. Sometimes closed is best, at least for the initial development of a project / product. When you look at some of the current opensource projects out there, a good many of them came out of small teams of people working in a largely closed fashion until they had achieved a certain critical mass.

Some advantages of closed development (at least initially):

1> Clarity of Vision -
You all know the saying about how a Camel is a Horse designed by commitee...

2> Consistency of Implementation -
Because only one or just a few people are working on this implementation details will likely be more consistent. Ideally the source code (not that we have access to it) should look like it was written by one programmer.

3> Ease of Refactoring and Deprecation -
Because the source is only at Rebol Technologies, they have the freedom to refactor the source more easily - eliminating inconsistencies, gaining in optimization, and clarity. They can also more easily deprecate features and functions that were either poorly implemented, or not well thought out.

Opensource, despite it's manifold benefits doesn't tend to foster any of these 3 goals.

1> Clarity of Vision is sacrificed unless there is a leader who makes (in the eyes of some of the community) arbitrary decisions. e.g. Linus, and Guido.

2> Consistency of Implementation is generally not even well achieved on small commercial teams. In the world of open source, in order to do similar tasks, you might use a "for" loop, I might use a "while" loop, and still another will use a "do while". Not that this matters that much, but it can make understanding of the source more difficult than it needs to be.

3> Ease of refactoring and Deprecation is generally sacrificed in OSS projects. Once the source is available people will build code around it. You will then have trouble refactoring the code base, and deprecating interfaces - cause it could break existing code. The freedom that is afforded the end user of OSS, in turn can be used to restrict the freedom of the original coders.

I'm not saying either way is particularly bad - there is a place for both. Of course, as someone posted earlier about taking off the glasses I was reminded of the following saying:

"When the only tool you have is a hammer, every problem looks like a nail."

Opensource is the answer to a lot of things - just not everything.

- Porter Woodward

I think so

[OpCode42]

I think any language can have a future - closed source or not - if you achieve the result you want.

Many people dont care if a language is open source. They might want to produce a windows program and choose VB to develop it. If VB does what they want and they get the application at the end of it, they are happy. The same person might produce a web site using PHP. Two widly differing languages produced by widly differning communities/companies - but each suits the task in hand.

Just remember - closed source does not mean poorly maintained 100% of the time.

I disagree

[selectspec]

I would say that languages have been sucessful that have proprietary control: VisualBasic, Java, Delphi. Microsoft hopes C# will also be successful. However, what makes a language successful has nothing to do with who controls it, but with its effectiveness. C++ for example has been bogged down in standards committees for years, and yet clearly established itself due to its incredible effectiveness and inter-compatibility with C. Java failed to become to the new defacto platform for GUI but, landed a home run with net service applications. VB is just a quick way to do Windows GUI work, but its a horrible language by anyone's admission. I don't think Perl's more open approach to design has much of an effect on the user base. Perl's success is due more in part to its natural ability as a workhorse. Python's sudden rise to the scene is a credit to its natural form and cross-platform glue, not its open source. For that matter, I don't use Linux because it's open source. I use Linux because its a damn good OS and extremely cost effective. Open Source projects do not garauntee a project will be successful. It is simply an alternative model of development.