
Omega programming language - LiveTheDream
http://langnostic.blogspot.com/2010/12/omega.html
======
RodgerTheGreat
Lisp and ML (as in Haskell) are dark magic from the early days of computing
that are continually rediscovered. Currently they form an undercurrent, not
just of language features but programming philosophy, that is shaping the new
and emerging languages of today. Many of us have observed how learning a
language like Lisp and becoming familiar with the idioms of programming with
it can have a profound impact on how we write in other languages.

In this spirit, consider a lesser-mentioned language from the same era- Forth.
Discard any preconceptions you may have about stack-oriented languages and
take a few days to sit down and read "Thinking Forth"[1], which delves deeply
into the architectural philosophy that goes along with the language. Forth is
at once mind-numbingly close to hardware and surprisingly well-suited to
readable, high-level expression.

[1]<http://sourceforge.net/projects/thinking-forth/>

~~~
Inaimathi
I haven't had a chance to play with it seriously yet, but I went over a
"getting started" tutorial a while back. forth-mode is installed and ready on
Emacs in case I get some spare time; it's on my to-do list along with some
more serious Python, Clojure, Scala and Smalltalk experimentation.

------
shasta
Wow, since the author starts talking about "Omega" without introducing it as a
concept of some ultimate language, I assumed he was talking about the Omega
Programming Language (In fact, it looks like there are two:
<http://code.google.com/p/omega/> and
<http://www.pervasive.jku.at/About_Us/Staff/_Blaschek/Omega/>) and was
thoroughly confused.

~~~
Inaimathi
Sorry about the confusion.

"Omega" was a reference to the Seibel talk I quote from, in which he casually
postulates Omega as the most powerful language that might be built for current
architectures.

------
lukev
He indicates Haskell and Lisp as the two leading candidates for Omega, but I
think that just illustrates the wrongness of the premise that there is a
singular end-game as far as languages go.

The thing is, you couldn't have a convergence of Lisp and Haskell without
destroying what makes them good at the same time. The _essence_ of Lisp is
that it is endlessly dynamic, the _essence_ of Haskell is its insanely strong
type system. I can't think of any way these could be effectively combined.

These languages aren't converging on a as-yet-unknown Omega point, they
_started_ at more or less the same point and then took off in completely
different directions, and they aren't looking back.

~~~
Inaimathi
Agreed, except with the "they aren't looking back" part. If that were true,
Lisk and Liskell wouldn't exist (and people wouldn't be wondering aloud "How
can I get pattern matching-definitions or point free style in Lisp?")

The conclusion of the article was more or less that you can't get a perfect
combination of the two, and that any unification that might emerge will have
to make decisions about which features to cherry-pick.

I'm also not clear on what you mean by "they started at more or less the same
point".

~~~
lukev
Point taken about Lisk and Liskell. But I think that that is, as you say,
cherry picking features, not actually merging the philosophies of the two
languages.

As for the same starting point, both had their origins in academic programming
language research. It's true they don't have a _direct_ common ancestor, but
the point I was making was that their creators were aware of the issues, and
chose very different directions as solutions to basically the same problem.

------
dillon
The reasons why these languages are created is because they are meant to solve
your problem the correct way.

Java is a scalable language, for example, and using it correctly makes a good
programmer. This goes for every language, whether it's C, Python, Javascript,
ect. Good programmers know a wide variety of languages and when it comes to
'Omega' I think it's the combination of the languages used what they are meant
for.

~~~
Inaimathi
That's the argument I fundamentally disagree with.

It may be true for things like SQL (or PS or the many, many DSLs out there),
but general-purpose programming languages are implicitly (perhaps
tautologically) supposed to be good for the general case.

It goes without saying that if your list of requirements includes something
like "our deployment environment will have 16 kb of memory and an 8 mhz
processor and no network interaction", you don't want to use something like
Erlang. But except for such extremes (which I probably should have explicitly
stated I'm not thinking about), it is possible (and necessary) to distinguish
between two languages on the basis of power.

I probably should have just linked to <http://www.paulgraham.com/avg.html>
instead of writing anything, because the "Blub Paradox" section makes the
above argument much more eloquently.

------
joe_the_user
"I'm defining 'power' as a non-specific mix of expressiveness, terseness,
maintainability, readability and flexibility"

There might be room for some unspecified mix of these qualities on an argument
over the "bestness" of a language.

But I'll quibble here and mention that _power_ is conventionally defined as
ONLY expressiveness/terseness with no consideration of maintainability.

In the J programming language:

    
    
        quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^: (1<#)
    

<http://en.wikipedia.org/wiki/J_(programming_language)>

Now that's _raw power..._ (and may not fit all requirements!)

~~~
Inaimathi
Heh.

The traditional snippet associated with that argument is the Game of Life in
APL. <http://www.youtube.com/watch?v=a9xAKttWgP4>

And yes, this is specifically why I opted to redefine "power" in my post; the
standard definition leaves out some points that I've found to be essential.

------
endtime
Omega is undefined when the relative weights of [expressiveness, terseness,
maintainability, readability, flexibility] are undefined. For any given set of
weights you could perhaps come up with a reasonable answer (even then you have
to try to quantify things like maintainability), since some languages are more
terse but less readable, or more readable but less expressive, etc.

If all the weights are equal, then I'd argue for Python, though I'm sure
plenty of Rubyists and Lispers and Haskellians would disagree.

~~~
Inaimathi
This is true, and I don't have extensive enough experience to weigh those
correctly (and even if I did, I would be heavily biased by the languages I
currently use). This is why I opted to wuss out rather than risk getting it
horribly wrong.

And yes, from what I've seen/heard, plenty of Rubyists, Lispers, Haskelliens,
etc. would certainly disagree with you.

~~~
endtime
I don't think there's one true set of weights - rather, I think it's a matter
of personal preference (and, to a certain extent, the task at hand -
maintainability is irrelevant for some tasks and vital for others).

~~~
Inaimathi
I could see this in the extremes (a one-of data-munging script has no
maintainability requirement, for example), but accepting the weights as
completely subjective seems dangerously close to saying "All languages are
equally powerful, and it's just a matter of preference", which I disagree with
because it would invalidate the Blub Paradox.

It may be the case that the weights are affected by individual tastes and
requirements, but the construction of the language (and therefore some
inherent property of the language, rather than of the user or of the
situation) would almost certainly affect those weights as well.

~~~
endtime
>accepting the weights as completely subjective seems dangerously close to
saying "All languages are equally powerful, and it's just a matter of
preference"

I don't agree with this statement...I would say that Java is worse than Python
for just about any given set of weights.

------
stcredzero
_How do you blur read/compile/run time when one of your goals is to have a
complete type system?_

By putting all of the type system in the parser, but leave the runtime as a
fully dynamic late-bound JIT VM. There is already a precedent for this in Java
and in the Strongtalk variant of Smalltalk. To complete the picture, we just
need a way to map the types before the code-change to the types that exist
afterwards. There's already been some work towards this. (Java/Eclipse)

------
norswap
Oz (<http://www.mozart-oz.org/>) unifies a ton of programming paradigms. It is
compiled and could be made fast.

