29 ms·

Omega - Language of the Future

68 points by alrex021 16y ago

humbledrone 16y ago
The first thing I want to see when I hear about a new programming language is an example. The best examples of Omega that I've found so far are part of the test suite for the interpreter: http://code.google.com/p/omega/source/browse/#svn/trunk/tests http://code.google.com/p/omega/source/browse/#svn/trunk/test...
- wkornewald 16y ago
  Reading code like that makes me want to puke. So, he wants to increase productivity by making us think about and write theorems in addition to our normal code (don't underestimate the time you invest in this), making our code even more static and less reusable in the hope that the reduction in time for bug hunting and testing will make up for the time invested in thinking about and creating more complex code? Hard to believe. Do those language designers create this stuff to show off how intelligent they are or just for the sake of having fun or are they seriously trying to make development easier? I can't imagine building a website with this. But then again, maybe those languages are designed for satellites, space shuttles, and simulations (i.e. where correctness is far more important than productivity)? Well, I think most of us have to make a compromise between productivity and correctness. It's the same as having 100% code coverage. Nice in theory, but it makes refactorings and development too costly and still doesn't guarantee that your software is 100% correct. Here's a nice post if you still believe 100% code coverage is the ultimate #1 goal of your project: http://blogs.msdn.com/b/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx http://blogs.msdn.com/b/cashto/archive/2009/03/31/it-s-ok-no...
  - aaronblohowiak 16y ago
    aggree with most of what you said. As a matter of finesse, I think that the correctness vs productivity argument is a specious one when it comes to language design. If correctness is a business requirement then providing language support is a productivity booster for the team (when you consider the timelines of the verification process as part of the development time.) you alluded to different problem domains perhaps requiring formal proof, I just want to suggest that it may decrease the iteration time for the team as a whole.
    - voxcogitatio 16y ago
      There is also the matter that the whole "correctness vs. productivity" debate is a false opposite. There is nothing mutually contradictive with correctness and productivity, so there is no reason why you can't have both.
      - prodigal_erik 16y ago
        Correctness stems from expressing not only the algorithm but also the results you expect from running it (as types and/or test cases) so they can be verified. But if you somehow convince yourself that you haven't made any mistakes, it's always less work to just write the algorithm (and omit the expected results).
  - silentbicycle 16y ago
    I think most of the programming advantages from static typing come from the basics (when done well), rather than the high-end research project type system stuff. A language with inferred (H-M-ish) static types and a good module system will give you reality checks from the compiler, you won't have to write frigging null checks everywhere, and it will avoid the visual clutter and rewriting tedious annotations as code changes. It's probably not as exciting as research, though. The whole static / dynamic typing thing is its own flamewar waiting to happen, so I'm going to leave it at that.
  - loup-vaillant 16y ago
    A web site with no bug (I mean, no error) is a web site with no vulnerabilities. Wouldn't that be interesting when your customers trust you with their credit card number?
    - wkornewald 16y ago
      Of course I want to have secure code. However, do I have to write 100% of my code in such a verbose language in order to guarantee security? I don't think that any security expert would claim that. It's sufficient if the relevant parts of the system and the communication protocols between your components provide a secure foundation. Writing all of your code in a verbose language would be total overkill and a huge waste of effort. So, in the end a combination of both systems might be the solution. The issue here is that this news post is about "the language of the future". It's definitely far from the language of the future. If at all, it might be a small component of the language(s) of the future (and even for that it should better improve on readability). There's just too much research going into verifiable systems and language theory and by far not enough research into making the majority of our code more expressive and reusable from a very practical point of view.
      - loup-vaillant 16y ago
        I didn't see significant examples of Omega, but… I'd be surprised if a language with a Haskell-like syntax is verbose. The verbosity most likely didn't come from the language itself, but from the proofs. Once you've built the foundations, and proven a host of invariants about them, then you don't need to prove much more when you write the rest of the program. I bet Omega supports the very programming model you advocate: invulnerable foundations, and quickly written "rest of the program". If the code you saw was verbose, that's probably because it was foundation code. (After all, standard data structures are par of the foundations.)
    - Groxx 16y ago
      You're implying all vulnerabilities are bugs due to coding error. To take a high-profile recent case: this would do nothing to prevent padding oracle attacks. Or future crypto attacks using techniques unknown to us now. Why? Because the encryption is working as it should. As advertised. As proven. Or imagine you used Rot13 for encryption. Your DB could hold people's credit cards in clear-text; how will this language prevent that from happening? Your website has no authorization tools, so you can access others' data by simply going to their URL; this is still a provably-correct logic structure.
mahmud 16y ago
There is a really nice prototype language by Gunther Blaschek also called Omega, and it predates this by at least 15 years. It was Self with mathematical rigor and some MOP elements, IIRC.
- silentbicycle 16y ago
  Yes, Blaschek has a book on it, _Object-Oriented Programming with Prototypes_.
jfager 16y ago
It seems somewhat obvious that sooner than later all code will be written in this (or a similar) way. LtU is just outright adorable sometimes.
- rbanffy 16y ago
  Such cheerful optimism in an early Saturday morning brightens my whole weekend.
- derefr 16y ago
  It makes sense when you parse "sooner or later" in the way people use it outside the technological domain: - Sooner or later we'll go back to the moon. - Sooner or later we'll understand how the brain works. - Sooner or later the earth will crumble to dust. ...and so on. But seriously, we've only been programming for 50 years now. There's still plenty of time for some revolutions and paradigm-shifting—just because the Mythical Man-Month has been heart-rendingly applicable for the last 50 years, doesn't mean that things can't change. For example: 1. If everyone agrees to target some highish-level bytecode or another, every language will basically have access to every other language's libraries (let's hope it doesn't end up being the JVM, though things seem to be heading there.) 2. If we stick content hashes in function and class names, there will no longer be such a thing as API versioning conflicts, because you'll always know what you're calling—and you can just import random code from remote sites (i.e. invoking on a URL as an identifier = loading whatever bytecode is available at that URL), because you'll just hash it and guarantee that it matches its name before jumping to it. 3. If we can stop requiring that the source code we write be exactly the same source code the compiler parses, we can treat code files as a serialization format for an AST data structure (in XML or SEXPs if you want to keep the source-source human-readable), and work with it however we like in an IDE, even "rendering" it as one old-style-"language" or another. And so on. These are problems that just need to overcome 20 or 30 years of inertia, and, ever-so-slowly, we're doing it.
  - DeusExMachina 16y ago
    As I read around, the JVM seems to be the state of the art for language runtimes. Can you elaborate why you hope it will not be the unified one in the future? Just curious.
rbanffy 16y ago
On the problem of using "omega" a its name, I recall a discussion I had, a long time ago, about Zope. Zope is an application server. In a given point in its history, Zope Corp, then Digital Creations, decided to "do it right" and fix each and every design wart from version 2 on version 3. The end result is that Zope 3 is more or less incompatible with Zope 2, specially with the kind of app we were developing with it in 2001 (IIRC). A friend of mine joked Zope 3 should no longer be called "Zope", but, since "Z" is the last letter of the alphabet, the only reasonable choice would be "Yope" and that would suggest a step backwards instead of the jump forward it was. With that in mind, I never built a product whose name started with Z.
- ebiester 16y ago
  AAope?
  - mahmud 16y ago
    Aaope you're kidding.
baguasquirrel 16y ago
The post is a bit of fluff, but the paper is better. Haskell already has GADTs, as the paper points out. Those of you crying out for examples, just read the paper. The real gem are these extensible kinds, which I haven't seen mentioned in Haskell before. I don't mean to keep throwing water on the fire but the research community already made trees that can't be unbalanced because they wouldn't typecheck, by encoding the depth of the tree into its type. Okasaki demonstrated the concept in Haskell, I believe. Getting it to work for RB-trees sounds new though.
- thesz 16y ago
  http://hackage.haskell.org/package/she http://hackage.haskell.org/package/she - "The Strathclyde Haskell Enhancement is a somewhat inglorious bodge, equipping ghc with automatic lifting of types to kinds, pattern synonyms, and some kit for higgledy-piggledy literate programming." From one of the authors of Epigram: http://e-pig.org http://e-pig.org I heard they intend to include functionality of SHE into GHC.
kingkilr 16y ago
> programs must be written for people to read, and only incidentally for machines to execute.
GeoffWozniak 16y ago
It seems nice, but it's more of the same: programming by specification. There's a place for that, but the future of programming languages, in my mind, lies in changing the metaphor of the process from specification to experimentation. After all, the problem with the specification metaphor is figuring out what the specification actually _is_. To me, the best route to get there is experimentation. Make programming more about experimentation and I think we'll get somewhere. (I'm still going to read more about Omega. It looks interesting enough.)

68 points by alrex021 16y ago

The first thing I want to see when I hear about a new programming language is an example. The best examples of Omega that I've found so far are part of the test suite for the interpreter: http://code.google.com/p/omega/source/browse/#svn/trunk/tests http://code.google.com/p/omega/source/browse/#svn/trunk/test...

wkornewald 16y ago
Reading code like that makes me want to puke. So, he wants to increase productivity by making us think about and write theorems in addition to our normal code (don't underestimate the time you invest in this), making our code even more static and less reusable in the hope that the reduction in time for bug hunting and testing will make up for the time invested in thinking about and creating more complex code? Hard to believe. Do those language designers create this stuff to show off how intelligent they are or just for the sake of having fun or are they seriously trying to make development easier? I can't imagine building a website with this. But then again, maybe those languages are designed for satellites, space shuttles, and simulations (i.e. where correctness is far more important than productivity)? Well, I think most of us have to make a compromise between productivity and correctness. It's the same as having 100% code coverage. Nice in theory, but it makes refactorings and development too costly and still doesn't guarantee that your software is 100% correct. Here's a nice post if you still believe 100% code coverage is the ultimate #1 goal of your project: http://blogs.msdn.com/b/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx http://blogs.msdn.com/b/cashto/archive/2009/03/31/it-s-ok-no...
- aaronblohowiak 16y ago
  aggree with most of what you said. As a matter of finesse, I think that the correctness vs productivity argument is a specious one when it comes to language design. If correctness is a business requirement then providing language support is a productivity booster for the team (when you consider the timelines of the verification process as part of the development time.) you alluded to different problem domains perhaps requiring formal proof, I just want to suggest that it may decrease the iteration time for the team as a whole.
  - voxcogitatio 16y ago
    There is also the matter that the whole "correctness vs. productivity" debate is a false opposite. There is nothing mutually contradictive with correctness and productivity, so there is no reason why you can't have both.
    - prodigal_erik 16y ago
      Correctness stems from expressing not only the algorithm but also the results you expect from running it (as types and/or test cases) so they can be verified. But if you somehow convince yourself that you haven't made any mistakes, it's always less work to just write the algorithm (and omit the expected results).
- silentbicycle 16y ago
  I think most of the programming advantages from static typing come from the basics (when done well), rather than the high-end research project type system stuff. A language with inferred (H-M-ish) static types and a good module system will give you reality checks from the compiler, you won't have to write frigging null checks everywhere, and it will avoid the visual clutter and rewriting tedious annotations as code changes. It's probably not as exciting as research, though. The whole static / dynamic typing thing is its own flamewar waiting to happen, so I'm going to leave it at that.
- loup-vaillant 16y ago
  A web site with no bug (I mean, no error) is a web site with no vulnerabilities. Wouldn't that be interesting when your customers trust you with their credit card number?
  - wkornewald 16y ago
    Of course I want to have secure code. However, do I have to write 100% of my code in such a verbose language in order to guarantee security? I don't think that any security expert would claim that. It's sufficient if the relevant parts of the system and the communication protocols between your components provide a secure foundation. Writing all of your code in a verbose language would be total overkill and a huge waste of effort. So, in the end a combination of both systems might be the solution. The issue here is that this news post is about "the language of the future". It's definitely far from the language of the future. If at all, it might be a small component of the language(s) of the future (and even for that it should better improve on readability). There's just too much research going into verifiable systems and language theory and by far not enough research into making the majority of our code more expressive and reusable from a very practical point of view.
    - loup-vaillant 16y ago
      I didn't see significant examples of Omega, but… I'd be surprised if a language with a Haskell-like syntax is verbose. The verbosity most likely didn't come from the language itself, but from the proofs. Once you've built the foundations, and proven a host of invariants about them, then you don't need to prove much more when you write the rest of the program. I bet Omega supports the very programming model you advocate: invulnerable foundations, and quickly written "rest of the program". If the code you saw was verbose, that's probably because it was foundation code. (After all, standard data structures are par of the foundations.)
  - Groxx 16y ago
    You're implying all vulnerabilities are bugs due to coding error. To take a high-profile recent case: this would do nothing to prevent padding oracle attacks. Or future crypto attacks using techniques unknown to us now. Why? Because the encryption is working as it should. As advertised. As proven. Or imagine you used Rot13 for encryption. Your DB could hold people's credit cards in clear-text; how will this language prevent that from happening? Your website has no authorization tools, so you can access others' data by simply going to their URL; this is still a provably-correct logic structure.

mahmud 16y ago

There is a really nice prototype language by Gunther Blaschek also called Omega, and it predates this by at least 15 years. It was Self with mathematical rigor and some MOP elements, IIRC.

silentbicycle 16y ago
Yes, Blaschek has a book on it, _Object-Oriented Programming with Prototypes_.

jfager 16y ago

It seems somewhat obvious that sooner than later all code will be written in this (or a similar) way. LtU is just outright adorable sometimes.

rbanffy 16y ago
Such cheerful optimism in an early Saturday morning brightens my whole weekend.
derefr 16y ago
It makes sense when you parse "sooner or later" in the way people use it outside the technological domain: - Sooner or later we'll go back to the moon. - Sooner or later we'll understand how the brain works. - Sooner or later the earth will crumble to dust. ...and so on. But seriously, we've only been programming for 50 years now. There's still plenty of time for some revolutions and paradigm-shifting—just because the Mythical Man-Month has been heart-rendingly applicable for the last 50 years, doesn't mean that things can't change. For example: 1. If everyone agrees to target some highish-level bytecode or another, every language will basically have access to every other language's libraries (let's hope it doesn't end up being the JVM, though things seem to be heading there.) 2. If we stick content hashes in function and class names, there will no longer be such a thing as API versioning conflicts, because you'll always know what you're calling—and you can just import random code from remote sites (i.e. invoking on a URL as an identifier = loading whatever bytecode is available at that URL), because you'll just hash it and guarantee that it matches its name before jumping to it. 3. If we can stop requiring that the source code we write be exactly the same source code the compiler parses, we can treat code files as a serialization format for an AST data structure (in XML or SEXPs if you want to keep the source-source human-readable), and work with it however we like in an IDE, even "rendering" it as one old-style-"language" or another. And so on. These are problems that just need to overcome 20 or 30 years of inertia, and, ever-so-slowly, we're doing it.
- DeusExMachina 16y ago
  As I read around, the JVM seems to be the state of the art for language runtimes. Can you elaborate why you hope it will not be the unified one in the future? Just curious.

rbanffy 16y ago

On the problem of using "omega" a its name, I recall a discussion I had, a long time ago, about Zope. Zope is an application server. In a given point in its history, Zope Corp, then Digital Creations, decided to "do it right" and fix each and every design wart from version 2 on version 3. The end result is that Zope 3 is more or less incompatible with Zope 2, specially with the kind of app we were developing with it in 2001 (IIRC). A friend of mine joked Zope 3 should no longer be called "Zope", but, since "Z" is the last letter of the alphabet, the only reasonable choice would be "Yope" and that would suggest a step backwards instead of the jump forward it was. With that in mind, I never built a product whose name started with Z.

ebiester 16y ago
AAope?
- mahmud 16y ago
  Aaope you're kidding.

baguasquirrel 16y ago

The post is a bit of fluff, but the paper is better. Haskell already has GADTs, as the paper points out. Those of you crying out for examples, just read the paper. The real gem are these extensible kinds, which I haven't seen mentioned in Haskell before. I don't mean to keep throwing water on the fire but the research community already made trees that can't be unbalanced because they wouldn't typecheck, by encoding the depth of the tree into its type. Okasaki demonstrated the concept in Haskell, I believe. Getting it to work for RB-trees sounds new though.

thesz 16y ago
http://hackage.haskell.org/package/she http://hackage.haskell.org/package/she - "The Strathclyde Haskell Enhancement is a somewhat inglorious bodge, equipping ghc with automatic lifting of types to kinds, pattern synonyms, and some kit for higgledy-piggledy literate programming." From one of the authors of Epigram: http://e-pig.org http://e-pig.org I heard they intend to include functionality of SHE into GHC.

kingkilr 16y ago

> programs must be written for people to read, and only incidentally for machines to execute.

GeoffWozniak 16y ago

It seems nice, but it's more of the same: programming by specification. There's a place for that, but the future of programming languages, in my mind, lies in changing the metaphor of the process from specification to experimentation. After all, the problem with the specification metaphor is figuring out what the specification actually _is_. To me, the best route to get there is experimentation. Make programming more about experimentation and I think we'll get somewhere. (I'm still going to read more about Omega. It looks interesting enough.)