0

Please help brainstorm/dream about an important problem (I believe this is a valid question, if you think it's not a valid question, please give me concrete critique so I can work on it).

Almost every language used is text- and file-based. This has drawbacks, e.g. refactoring, renaming symbols is often painful (renaming a symbol touches many files), moving a block of code is not very clean when you need to review the diffs. There are also advantages, e.g. universality of tools, like text editors and version control systems (like git).

Assuming that it is desirable to create a language that stores code directly in a object-graph store (or document store), what are the biggest obstacles to designing a viable programming environment and language.

I imagine two critical components necessary:

  • A program editor, like a Google docs editor designed to edit the program object model
  • A storage engine + synchronization + versioning component, that allows synchronizing to a code repository, merging, etc.
  • When you say "stores directly" - how do one create a program in that language? – duros Feb 7 '17 at 0:41
  • 3
    Smalltalk is text based but does not have files, it has a bunch of objects inside of a system image. There's also the Scratch environment built on top of Squeak Smalltalk that does some graphical programming things. LabVIEW is a fairly popular visual programming language. There's actually a whole list of them at en.wikipedia.org/wiki/Visual_programming_language - I'd suggest you at least look them over before putting any serious thought into this. – Sean McSomething Feb 7 '17 at 1:11
  • @duros in a specialized editor, something like an JSON/XML editor. Something along the lines of altova.com/authentic.html or altova.com/xmlspy/json-editor.html or jetbrains.com/mps – Otto Feb 7 '17 at 1:30
  • What kind of code might be stored directly in an object-graph? Text? Or something else? Objects (with or without names?) in relationships? – Erik Eidt Feb 7 '17 at 1:37
  • @ErikEidt: think ASTs, just richer. E.g. that's how both MPS and the Domain Workbench work. "Programming" is done using structured editors which project the semantic graph into text, graphs, tables, whatever you want. – Jörg W Mittag Feb 7 '17 at 1:53
3

Yes, the two things you identified are pretty much the two critical components. Well, the third one is of course the language itself.

Take Language Workbenches for Language-Oriented Programming like the Intentional Domain Workbench by Intentional Software or MPS – Meta Programming System by JetBrains, for example: both of these work very similar, the actual program is represented as a semantic graph of objects; it is viewed and edited through projectional editors, i.e. editors which show you a projection of that semantic graph, as text, as a table, as a graph, whatever, and the editing actions you perform are then interpreted as graph transformations on the semantic graph. Both of them also have their own version control system which stores graphs and graph transformations instead of text files and diffs.

Typical Smalltalks are another example: everything is an object, even classes, methods, stack frames, local variables, the debugger, the editor, the IDE, the compiler, are objects. If you want to create a new subclass of String with some methods, you don't fire up the editor to write a new class, no, you call the subclass: method on String and it will return to you a class which is a subclass of String. In fact, you couldn't write a class if you wanted to: there is no syntax for writing classes in Smalltalk. Now, to add a method, you open a class browser and click on "Add method", or alternatively, you just call the method, and in the NoMethodError message that comes up (actually, Smalltalk uses the OO messaging metaphor much more pervasively than other languages, so the error is actually called MessageNotUnderstood), there will be a button that says "add method". And since Smalltalk exceptions are resumable, unlike Java's, C♯'s, Ruby's, Python's, ECMAScript's, etc., when you have added the method, you can just resume the program at the point right before the exception was raised. (Really, in Smalltalk you debug in the editor and you code in the debugger.) Again, you couldn't write a method even if you wanted to: there is no syntax for method definitions in Smalltalk, instead you define a method by calling a method to define a method and pass it the bytecode, which you in turn got by calling the compiler and passing it the method body. (Or, well, the IDE does that for you.)

There is no textual representation of a Smalltalk program. A Smalltalk system is just an object graph. You don't start or stop Smalltalk programs, they are always running. When you "stop" a Smalltalk program, what you are really doing, is just serialize the entire object graph to disk (this is called "creating an image" of the object memory), and the other way around for "starting" a program. It's actually the same as hibernating your laptop. You never "stop" a Smalltalk program, and you never create a new version. You edit the running program, while it is running, there is no distinction between design time and runtime, programming and debugging, IDE and program. And again, Smalltalks have their own version control systems, or more recently, different Smalltalk dialects have begun to standardize on Montecello.

Lisp is of course another example: the Lisp programming language is defined in terms of data structures, not in terms of text. A function definition is not defined as "the letter d followed be the letter e followed by the letter f followed by space followed by an identifier denoting the name followed by the character ( followed by …". A function definition is defined as "a list with four elements, the first element being the symbol (a built-in datatype similar to an interned string in Java) def, the second element being a symbol denoting the name, the third element being a list of symbols denoting the parameters and the fourth element being a list denoting the body of the function". All code is defined in terms of data structures. A function call is defined as a list of n+1 elements, the first being a symbol denoting the name of a variable which references a function object, followed by n arguments.

One difference between Lisp and the other examples is that Lisp has a standardized textual representation for parentheses-delimited, space-separated lists, quote-delimited strings, numbers, symbols, etc.

Graphical languages like Thyrd are also relevant.

Actually, if you think about it, modern IDEs also work this way: they work very hard to construct a full semantic model from your flat boring text files. Then, they work very hard to turn this rich, powerful, expressive semantic model back into a flat, slightly less boring (because its now colored, yay!) text editor. And when you edit something in that editor, they then again work very hard to infer from the textual input you made, the actual semantic transformations of the semantic graph. So, a modern IDE basically does what you want, except blindfolded and with its hand tied behind its back. You can sort-of see this in IDEA, which actually uses the same semantic tree for all languages, and where you can e.g. copy some code from a Scala file and paste it into a Java file, and it will actually appear as Java code.

| improve this answer | |
  • Thanks, very interesting, I've never used smalltalk. It seems to me that standard tooling is the main obstacle to the "everything is an data/objects approach" instead of text-based. There's so much momentum of text-based languages (C, Java, JS, etc.) and the knowledge invested in tools like Git, text editors, IDEs is a huge part of what it means to be a programmer. – Otto Feb 7 '17 at 19:09
  • Also neat trick that you can copy code from a Scala file into a Java file in IntelliJ IDEA, didn't know that one (I don't think it would work between ruby/JS/Java though, right?) – Otto Feb 7 '17 at 19:11
  • I think it also works with Clojure, at least. And Kotlin. That's the thing: since all languages are represented using a single unified semantic graph, all you need to do is project into and out of the semantic graph, and you need to do that anyway, for things like refactoring. Once the code ends up in the semantic graph, it doesn't matter what language it came from. Obviously, there are serious limitations to this, but it does work for simple code, at least. – Jörg W Mittag Feb 7 '17 at 22:41
  • Some thoughts on Smalltalk: I downloaded Squeak, no idea how to use it. No "hello world" example. (May try Pharo next). Smalltalk looks unfriendly especially for anyone coming from C/Java/JS. How do I create a class with a method that does something useful? I can't find a simple example. An important goal I have is a language that is intelligible for a beginner as well as an experienced programmer. Smalltalk doesn't seem to fit either of those criteria. This confirms to me that a language should at least have a textual representation for the purpose of demonstration and learning. – Otto Feb 7 '17 at 23:39
1

Many have tried to make non-text based programming languages. None have really caught on. I think your biggest obstacle is the fact that: By the time you are programming, you have been writing for at least ten years (This is assuming you started programming at 15). So text based programming works with skills you have been cultivating for most of your life and will continue to cultivate for the rest of it. Trying to do some sort of object-based or symbolic language is going to require the user to learn something completely new that they don't have any existing skills to leverage.

In other words, your biggest obstacle is your user's human nature. Perhaps you should consider working with existing skills rather than fighting it, allowing the user to code in text and then saving it as an object graph. However, at that point, why not just save the text? Any edits will require a rebuild of the graph anyway, might as well do it when you load the files. And once you do allow text, how do you maintain your advantages when the user cut & pastes their written code outside your application and then copy & pastes it back in?

You're going to have a lot of thinking ahead of you. I wish you luck.

| improve this answer | |
  • Point taken. I generally like text (I prefer writing in markdown than in an word processor). Yet when I program, I think in trees, not text or words. Maybe this is not the nature of most people. I gave two examples of why storing as text is not great (renaming symbols, moving code block). I agree saving blocks of statements as text makes sense, but it makes less sense for the bigger pieces of structure to be encoded as text (function, modules, etc.). – Otto Feb 7 '17 at 1:23
  • @Otto Your examples don't make much sense though... You still need to change the 'symbol' or 'name' in many 'files' or 'objects' regardless of how it is stored... why is modifying many files bad but many objects okay? Likewise moving code, you would still have to change which object is belongs to (just like which file it belongs to), what is the difference? – Milney Feb 7 '17 at 16:53
  • 1
    @Milney Presumably the objects in code would be identified by a GUID, rather than the display name. That way the name is located in one spot that can be changed without affecting other objects, who only care about the GUID that will never change. The IDE would handle the lookup of the display name from the GUID (and vice versa) every time it has to display or use the object, so all the user deals with is the display name. Same deal with moving code, it would be changing a GUID. The idea has merit, which is why it's so often considered. – Kevin Fee Feb 7 '17 at 17:00
0

Look at LabView (http://www.ni.com/labview/). You have to use National Instrument's development environment, and by virtue of the special editor, you are quickly tied to it.

I am not sure that version control would actually do something reasonable with it - I suspect not.

That said, it is fairly easy to pick up and relatively easy to teach someone to use.

| improve this answer | |
-1

I would think trying to run the object.

How would you run it without a text- or symbol-based system?

The only real way to accomplish that is to let your data dictates what get's executed.

You still have to write the code, unless you are looking at some of the new technologies where code keeps rewriting itself (like in Microsoft's Machine Learning, but the machine learns to add/change code).

Still, the function of a computer is to: move data, change data, merge data, calculate information, retrieve and display information, and store information.

In the end, Google Docs imports images, types and changes texts, so how is that going to work any different? (This is not a new question, just retorical).

And there are storage engines and such. XML was a poor attempt to change a markup language and somehow turn it into both a data storage and programming language with very mixed results.

With the little to go on, it is hard to visualize what it is you are trying to accomplish.

Maybe with an example application of what this new processing paradigm is to achieve, I could give you a better response.

I will tell you this, I do know a programmer who has just about perfected in storing code and documents inside any image file. And I am not talking about EXIF data!

Is that what you are envisioning? A photo that stores both code and text and is executed by an unknown process?

| improve this answer | |
  • 1
    "How would you run it without a text- or symbol-based system?" – Almost all interpreters today work on object trees (ASTs), not text. "Running the object" is how interpreters work anyway, the OP just wants to cut out the middleman: have the programmer write and manipulate the objects representing the computation directly instead of as a textual representation from which the interpreter then constructs the objects. – Jörg W Mittag Feb 7 '17 at 1:52
  • 1
    XML isn't a programming language. – Lie Ryan Feb 7 '17 at 2:05
  • I know, but when it was first being considered by W3C, Microsoft tried to make it both. The W3C decided to allow CSS to XML, which was not in the originial specs back in 1995. And think DTD? – George McGinn Feb 7 '17 at 2:47
  • Oh, I'm recalling from memory when I was asked to write a third-party parser back in 1997. XSL was supposed to combine the execution of code and the XML markup language. There was so many fights between MS and Netscape that I think this is what did Netscape in, or the last nail to the coffin. And don't forget about the integration of DOM (Document Object Code). – George McGinn Feb 7 '17 at 2:51
  • Jorg, I agree. I know it as event-driven processing. In Windows that code is in a DLL or COM file, and only executed when needed when he Object is used. Still, you need to initially program it in something, text-based language or symbol-based. Yes, once it is there, then the object, or the data drives the processing, not the program. – George McGinn Feb 7 '17 at 2:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.