Slashdot Mirror

Spreadsheets are often used for purposes which go above and beyond their intention, acting in some cases as almost a general-purpose programming environment.

Since this abuse is so common, why not take it to the next level and make a programming language which acts like a spreadsheet?

http://www.subtextual.org/

I think the "no code change is safe" claim is bogus because it assumes that the code works properly to begin with! This is typically not the case, unless test coverage is used, in which case it can be used again.

Also, saying "In order to get this done, I am going to reorganize classes, rename variables, and split/move functions around" is probably not more informative to the rest of the team than "I am going to do some refactoring". Detailing the exact changes is an orthogonal issue that can be done regardless of whether you use the term "refactoring".

Some changes can be known to not alter functionality, in some languages. Refactoring tools can perform changes on the code that create provably equivalent code.

With programming environments/languages of the future like Subtext, refactoring becomes trivial and always side-effect-free.

Like most problems, textual code reuse has via copy & paste has already been studied, and a language based on first-class copy & paste is being developed; it's called the Subtext language. See a more detailed discussion of it on lambda-the-ultimate. Academia is not so far remove from everyday programming as people seem to think!

Like most problems, textual code reuse has via copy & paste has already been studied, and a language based on first-class copy & paste is being developed; it's called the Subtext language. See a more detailed discussion of it on lambda-the-ultimate. Academia is not so far remove from everyday programming as people seem to think!

Are you over 30, and desperate to show you can still be a worthwhile disruptive thinker?? What you're saying sounds similar to the proposals for the next ReiserFS.

Nope, I am less than 25...
But I do believe people over 30 can make worthwhile contributions.

I am a big fan of this guy's work on Subtext, which happens to address a lot of the issues that plague languages today, including language fragmentation.

I believe that a lot of the issues you raise, regarding multiple ways to express the same things, is mainly a result of the fact languages are still based on simple text. Because they are limited to text as the only medium to communicate with the programmer, they cannot be optimized for all kinds of tasks at the same time. A very very smart text editor aware of the language could ofcourse optimize the work for any given purpose, but even then, the text representation might be unoptimized for this or that purpose. Subtext addresses this by separating the internal representation of the program from the way you edit and view it. This allows creating views/edit-controls of the program which are optimized for certain purposes. The same environment will finally get rid of the silly "right tool for the job" crowd and make that one tool right for almost all jobs, via optimized frontends of the "language" for different tasks.

This will mean that there is just one semantic, and syntax is replaced with a GUI. GUI's can be self-explanatory, and semantics need only be learned once.

Are you over 30, and desperate to show you can still be a worthwhile disruptive thinker?? What you're saying sounds similar to the proposals for the next ReiserFS.

Nope, I am less than 25...
But I do believe people over 30 can make worthwhile contributions.

I am a big fan of this guy's work on Subtext, which happens to address a lot of the issues that plague languages today, including language fragmentation.

I believe that a lot of the issues you raise, regarding multiple ways to express the same things, is mainly a result of the fact languages are still based on simple text. Because they are limited to text as the only medium to communicate with the programmer, they cannot be optimized for all kinds of tasks at the same time. A very very smart text editor aware of the language could ofcourse optimize the work for any given purpose, but even then, the text representation might be unoptimized for this or that purpose. Subtext addresses this by separating the internal representation of the program from the way you edit and view it. This allows creating views/edit-controls of the program which are optimized for certain purposes. The same environment will finally get rid of the silly "right tool for the job" crowd and make that one tool right for almost all jobs, via optimized frontends of the "language" for different tasks.

This will mean that there is just one semantic, and syntax is replaced with a GUI. GUI's can be self-explanatory, and semantics need only be learned once.

That said, I'm not totally convinced Haskell will take off even if FP does become hugely mainstream. As a language it has pretty atrocious usability. More likely, mainstream imperative languages will incorporate extensions that allow for function programming: after all, parametric polymorphism and lambda functions (sort of) already entered mainstream imperative languages.

Alternatively, something like Subtext may prove to be the way forward. All I know is I'm convinced there is a better way to do lazy function programming than Haskell ;)

Oh, and for what it's worth, while learning Haskell and Floyd-Hoare logic is mind expanding, graduates that can write code which compiles are probably more desirable long term. The free market doesn't demand languages like Java because it's McCrap, they demand it because it makes the most sense for many commercial projects (aka getting things done outside of academia).

Check out Subtext. At the moment, it seems to still be in the conceptual stages. Be sure to watch the interesting Flash demonstration. (However, the fact that it needs a movie to properly demonstrate the concept is itself an indicator of how cumbersome it is to deal with visual languages.)

For another take on post-textual programming, check out Intentional Programming. A little-known screencast demo is at http://www.cse.unsw.edu.au/~cs3141/ip.asf/. Unfortunately all their work is shrouded in mystery and non-disclosure agreements. The most complete account I have found is in Generative Programming

I believe that in the not-to-distant future the practice of programming in ASCII text will seem as antiquated as punched-cards

Languages need to evolve out of the pure text medium. This has been happening as incremental hacks to classic languages through code folding editors and AST-aware, intelligent IDEs like Eclipse, literate programming and Python's doctest module. High-level development tools like Delphi were early adopters of the philosophy that code doesn't need to be visualized as text when it's better to visualize it graphically.

The next step is to store not text but structure. For example, why shouldn't I be able to comment on -- annotate -- a specific number in a mathematic formula in my code? With current text-based languages this would be a headache:

double phi = 1 - 1 / (1 + Math.exp(-(cv * /* weight */ 0.3 - range) / sigma));

Instead, I could just select the value in my editor, click on the annotate key, and enter (in nice WYSIWYG HTML or whatever) my comment there. As a result, the editor will show a tiny icon next to the number, or perhaps in the margin, indicating that there's an annotation.

And why are formulas like that represented with such a poor syntax? Why can't I easily use proper Greek letters and standard math notations such as dots for multiplication, a horizontal line for divisions/fractions, etc.? Why can't I insert images into the source file which illustrate the concept it implements?

What I'm talking about isn't just "rich source code", which Donald Knuth's literate programming concept covers to some extent. Languages will experience a revolutionary leap when they start treating language elements as flexible blocks of content as opposed to tokens in an AST. Consider internationalization; instead of looking up a string from a language-specific message table, your source code can include the string in every possible language, hidden away in a single visual representation -- it might look something like:

showDialog("File not found" [English, Swedish, (8 more languages)]);

where "English ..." is a link that opens up a nice GUI letting you change the strings in different languages. The logic to select the string to choose at runtime exists in the string "component" itself.

A common problem in dynamically-typed language is that it's hard to implement optional static typing at the language level. It adds a lot of noisy syntax, and unless you add a lot of syntax, it's hard to solve many ambiguities and special cases. With a rich source format, you can hide away the details, similar to my annotation example.

Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination. You can have both! Rich source code can be represented as text -- it's just not convenient to edit it like text. Instead, you add intelligence and convenience to your tools. You don't edit your PNG files with Vi -- you use a tool like GIMP or Photoshop.

Languages need to evolve out of the pure text medium. This has been happening as incremental hacks to classic languages through code folding editors and AST-aware, intelligent IDEs like Eclipse, literate programming and Python's doctest module. High-level development tools like Delphi were early adopters of the philosophy that code doesn't need to be visualized as text when it's better to visualize it graphically.

The next step is to store not text but structure. For example, why shouldn't I be able to comment on -- annotate -- a specific number in a mathematic formula in my code? With current text-based languages this would be a headache:

double phi = 1 - 1 / (1 + Math.exp(-(cv * /* weight */ 0.3 - range) / sigma));

Instead, I could just select the value in my editor, click on the annotate key, and enter (in nice WYSIWYG HTML or whatever) my comment there. As a result, the editor will show a tiny icon next to the number, or perhaps in the margin, indicating that there's an annotation.

And why are formulas like that represented with such a poor syntax? Why can't I easily use proper Greek letters and standard math notations such as dots for multiplication, a horizontal line for divisions/fractions, etc.? Why can't I insert images into the source file which illustrate the concept it implements?

What I'm talking about isn't just "rich source code", which Donald Knuth's literate programming concept covers to some extent. Languages will experience a revolutionary leap when they start treating language elements as flexible blocks of content as opposed to tokens in an AST. Consider internationalization; instead of looking up a string from a language-specific message table, your source code can include the string in every possible language, hidden away in a single visual representation -- it might look something like:

showDialog("File not found" [English, Swedish, (8 more languages)]);

where "English ..." is a link that opens up a nice GUI letting you change the strings in different languages. The logic to select the string to choose at runtime exists in the string "component" itself.

A common problem in dynamically-typed language is that it's hard to implement optional static typing at the language level. It adds a lot of noisy syntax, and unless you add a lot of syntax, it's hard to solve many ambiguities and special cases. With a rich source format, you can hide away the details, similar to my annotation example.

Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination. You can have both! Rich source code can be represented as text -- it's just not convenient to edit it like text. Instead, you add intelligence and convenience to your tools. You don't edit your PNG files with Vi -- you use a tool like GIMP or Photoshop.