(Graphical) Programming Languages

[Kevin]

write my own language/toolchain and then write the OS in that new language. In this case I'd need to write the toolchain twice (e.g. once as a set of tools for Linux that I can use to write the OS, then again as native tools for my OS).

I believe this sounds worse than it really is. The things you have to write twice are the compiler (obviously, if it should be self-hosting in a completely new language) and backends to some suitable abstraction layer. When you get Linux programs compiled with your compiler and binutils, you can start writing the rest of the toolchain in your language. The core algorithms in the toolchain should be perfectly portable.

Part of the idea for my OS is that (as far as applications know) all files are in a specific "native" format. For example, instead of having to deal with BMP, JPG, TIFF, PCI, GIF, PNG, etc, an application would only have to care about my native graphics file format. To make this work the OS has "file format converters".

Does this imply that you think all graphics formats are the same? Wouldn't the user want to specify which format to use (for interoperability), whether to save it lossless or what lossy compression to use, with which options, etc. How about vector graphics? Would they automagically be rasterised? If so, with which resolution, how can the VFS know?

If an application tries to open a BMP picture, the VFS is responsible for finding a suitable "BMP to native file format converter" and transparently converts the BMP file into the native format. Multiple file format converters might be involved - e.g. an application might open "foo.bmp" as a sound file, and the VFS might convert BMP into native graphics format, then native graphics into native text (via. OCR), then convert native text into speech/sound (via. speech synthesiser).

And your OS figures out automagically which conversion to use? Maybe BMP -> MIDI -> Sound would be the more appropriate conversion for my graphics file?

This reminds me of implicit casts between types (and this doesn't even involve multiple steps). Can be useful sometimes, but if you overdo it, things start to become very confusing.

Now think about compiling, assembling and linking - the tools would use the same "file format converter" idea. If the OS opens "foo.c" as an executable; then the VFS might use a "C to byte-code converter", then a "byte code to assembly converter" then an "assembly to executable" converter (and then cache/store the resulting executable file).

Your compiler and linker don't need any options?

What I'd like to do is build a graphical design tool, where (for a hypothetical example) a programmer drags boxes, etc onto a worksheet to create something like a UML class diagram, and can then click on methods, etc in the class diagram to add code to that method. An entire project's source code (including class diagram, resources, methods, etc) would exist in a "pre-tokenised" form within a single project file; and it's this single project file that file format converters would convert into executable form.

Maybe start with writing a good UML tool then. I have yet to meet one that doesn't suck badly. Paper and pencil is the best one that's around.

I am interested in getting rid of typing - e.g. rather than typing "while(foo < 6) { foo++; }" into a text box a programmer might drag an "while box" onto the page and then drag other things (an icon representing "foo", a "const integer" icon, an "increment" icon, etc) into appropriate places in the middle of the "while box".

Are you serious? Why do you want to hurt productivity so hard?

[Brendan]

Hi,

write my own language/toolchain and then write the OS in that new language. In this case I'd need to write the toolchain twice (e.g. once as a set of tools for Linux that I can use to write the OS, then again as native tools for my OS).

I believe this sounds worse than it really is. The things you have to write twice are the compiler (obviously, if it should be self-hosting in a completely new language) and backends to some suitable abstraction layer. When you get Linux programs compiled with your compiler and binutils, you can start writing the rest of the toolchain in your language. The core algorithms in the toolchain should be perfectly portable.

If anyone ever gets Linux programs compiled with my compiler; then I've completely an utterly failed to meet any of the project's goals.

Part of the idea for my OS is that (as far as applications know) all files are in a specific "native" format. For example, instead of having to deal with BMP, JPG, TIFF, PCI, GIF, PNG, etc, an application would only have to care about my native graphics file format. To make this work the OS has "file format converters".

Does this imply that you think all graphics formats are the same?

No, it implies that I think all graphics formats are pointlessly different for no sane reason; and these stupid differences end up being far more hassle than they're worth for both software developers and end users.

Wouldn't the user want to specify which format to use (for interoperability), whether to save it lossless or what lossy compression to use, with which options, etc.

No, the user would want a system that saves them the hassle of being forced to care about trivial details like that.

How about vector graphics? Would they automagically be rasterised? If so, with which resolution, how can the VFS know?

Vector graphics too, but not rasterised. I've been working on a "meta-format" for a while now (triangles!).

If an application tries to open a BMP picture, the VFS is responsible for finding a suitable "BMP to native file format converter" and transparently converts the BMP file into the native format. Multiple file format converters might be involved - e.g. an application might open "foo.bmp" as a sound file, and the VFS might convert BMP into native graphics format, then native graphics into native text (via. OCR), then convert native text into speech/sound (via. speech synthesiser).

And your OS figures out automagically which conversion to use? Maybe BMP -> MIDI -> Sound would be the more appropriate conversion for my graphics file?

This reminds me of implicit casts between types (and this doesn't even involve multiple steps). Can be useful sometimes, but if you overdo it, things start to become very confusing.

Most conversions would be very obvious (e.g. legacy graphics file format to native graphics file format, legacy "plain text" format to native text format, etc). I can't think of any conversions that aren't obvious that actually make sense.

Now think about compiling, assembling and linking - the tools would use the same "file format converter" idea. If the OS opens "foo.c" as an executable; then the VFS might use a "C to byte-code converter", then a "byte code to assembly converter" then an "assembly to executable" converter (and then cache/store the resulting executable file).

Your compiler and linker don't need any options?

Is the toolchain you're currently using so completely broken that you actually need compiler and linker options, just to build normal/native applications? Why?

I am interested in getting rid of typing - e.g. rather than typing "while(foo < 6) { foo++; }" into a text box a programmer might drag an "while box" onto the page and then drag other things (an icon representing "foo", a "const integer" icon, an "increment" icon, etc) into appropriate places in the middle of the "while box".

Are you serious? Why do you want to hurt productivity so hard?

I don't think it'd hurt productivity at all. I think (if it's done right) new programmers will learn how to design software better and faster, will write software faster, and will enjoy the work more.

It probably will take a while for old programmers to get used to (in the same way that an old "paper and pen" architect would take a while to get used to CAD), but old programmers aren't really the target audience.


Cheers,

Brendan

[XanClic]

I am interested in getting rid of typing - e.g. rather than typing "while(foo < 6) { foo++; }" into a text box a programmer might drag an "while box" onto the page and then drag other things (an icon representing "foo", a "const integer" icon, an "increment" icon, etc) into appropriate places in the middle of the "while box".

Are you serious? Why do you want to hurt productivity so hard?

I don't think it'd hurt productivity at all. I think (if it's done right) new programmers will learn how to design software better and faster, will write software faster, and will enjoy the work more.

It probably will take a while for old programmers to get used to (in the same way that an old "paper and pen" architect would take a while to get used to CAD), but old programmers aren't really the target audience.

I grew up with LEGO Mindstorms, which uses (as far as I understand you correctly) a programming language very similar to your proposal. I haven't liked it since I started working with “traditional” languages.

[NickJohnson]

We should force all writers to only do storyboards. Movie adaptations of books are always better anyway.

[Brendan]

Hi,

I grew up with LEGO Mindstorms, which uses (as far as I understand you correctly) a programming language very similar to your proposal. I haven't liked it since I started working with “traditional” languages.

I'm not too sure which programming language you're referring to. Is it ROBOLAB?



I was thinking something a bit more like Alice:




Cheers,

Brendan

[XanClic]

I was talking about this one:

[bluemoon]

Graphical programming, so to speak, are good for workflow and scripting (eg. AppleScript / Automation), but it would be way more flexible to write the nodes in (a mixture of) traditional language and the graphical language (as a collection of features) itself.

[Kazinsal]

The graphical programming language that springs to mind for me is Kismet, the map scripting language of the Unreal Engine. It works for map scripting, since that isn't particularly engine-modifying, and is fairly complex, but it's damn near useless for "real" programming tasks in the engine. This leaves you to work with UnrealScript, which is more of a traditional C++-like language.

Brendan, it seems like your OS has no real target demographic other than yourself. The people who don't care about the difference between lossy and lossless compression are not likely going to be the same people who carry a bunch of source files on their computer.

$0.02.

[Brendan]

Hi,

I'm not sure why so many people are having so much trouble imagining this.

This is what a (simple) class diagram looks like:



Now look at the box at the bottom left. This is a class called "CheckingAccount". It has 2 methods - "processCheck()" and "withdrawal()". I'm sure you can all imagine a tool for creating these diagrams if you haven't actually used one yet.

Now imagine if you click on the "withdrawal()" method and the IDE zooms in on that method, and shows you something like this:



Note: Obviously the method's code would be in a child window with the class diagram in the background; and if you click on several methods in several classes you'd end up with several child windows.

Now imagine a toolbar somewhere with a bunch of keywords on it - "variable", "constant", "while", "until", "sizeof", etc. To write the method's code, you'd just "drag and drop" stuff from this toolbar (and "drag and drop" stuff from the class diagram) into the method's little window.

The language itself could be similar to Java or C#. The only real difference is that it's graphical rather than plain text.


Cheers,

Brendan

[bluemoon]

Now that looks like an RAD tool(not only interface editor, but also equip with core-data style node editor) with extensive auto-completion and context-aware assistance/insertion/deletion.
Guess what? I look at my HTML editor and think that it's totally possible.

[Kevin]

If anyone ever gets Linux programs compiled with my compiler; then I've completely an utterly failed to meet any of the project's goals.

This is hard to believe, unless you have an explicit goal of not supporting any existing OS. The sad truth is that I wouldn't be surprised if this was really one of your goals, but it doesn't make such negative goals less stupid.

Linux doesn't magically make languages less than Turing complete, so it's entirely possible to write the core algorithms in a way easily portable to Linux.

Wouldn't the user want to specify which format to use (for interoperability), whether to save it lossless or what lossy compression to use, with which options, etc.

No, the user would want a system that saves them the hassle of being forced to care about trivial details like that.

Indeed I don't mind having all graphics files (or maybe videos?) uncompressed, if the OS makes sure that I'll always have a large enough hard disk and fast enough internet connection so that I don't even notice. In practice, such things don't exist and this is a tradeoff. Tradeoffs require a choice, there's no one-size-fits-all.

Most conversions would be very obvious (e.g. legacy graphics file format to native graphics file format, legacy "plain text" format to native text format, etc). I can't think of any conversions that aren't obvious that actually make sense.

Your very own example: BMP -> Text -> Sound. This is not the obvious right way for opening a graphics file as audio.

Your compiler and linker don't need any options?

Is the toolchain you're currently using so completely broken that you actually need compiler and linker options, just to build normal/native applications? Why?

s/need/allow/

My compiler does work without any other options than just the source file. I never use it this way because I want to configure it right. And I don't claim that my value of "right" is the same as yours.

I am interested in getting rid of typing - e.g. rather than typing "while(foo < 6) { foo++; }" into a text box a programmer might drag an "while box" onto the page and then drag other things (an icon representing "foo", a "const integer" icon, an "increment" icon, etc) into appropriate places in the middle of the "while box".

Are you serious? Why do you want to hurt productivity so hard?

I don't think it'd hurt productivity at all. I think (if it's done right) new programmers will learn how to design software better and faster, will write software faster, and will enjoy the work more.

The just punishment for you would be having to work with the tool you're imagining.

You haven't done anything innovative on the language itself here. You could just take C or whatever existing language you like. All that you have achieved is giving users an IDE that is cumbersome to use. Because for entering more than very little data, keyboard > mouse. Dragging an "if" keyword from a toolbar to the right position in the source takes longer than typing the two keys on the keyboard, even if you type with a single finger and don't know exactly where the keys are. With a touch screen instead of a mouse it might become less horrible, but still inferior to a keyboard.

It probably will take a while for old programmers to get used to (in the same way that an old "paper and pen" architect would take a while to get used to CAD), but old programmers aren't really the target audience.

Ah well, maybe I should start getting used to that fact that I'm considered old by some...

Now look at the box at the bottom left. This is a class called "CheckingAccount". It has 2 methods - "processCheck()" and "withdrawal()". I'm sure you can all imagine a tool for creating these diagrams if you haven't actually used one yet.

More than one. They all suck. They slow me down because getting my ideas into these fscking tools takes so long.

[Brendan]

Hi,

Now that looks like an RAD tool(not only interface editor, but also equip with core-data style node editor) with extensive auto-completion and context-aware assistance/insertion/deletion.
Guess what? I look at my HTML editor and think that it's totally possible.

Yes

It's not "extremely different", and I don't even think it'd be that hard to implement.

The main points are:

• Very little typing needed (just for giving names to classes, methods and variables); which means that someone without a keyboard (e.g. just touch screen or mouse) could be productive. Of course if someone has a keyboard there'd be keyboard shortcuts (e.g. so they can press "w" instead of dragging the "while" icon into their code).
• Syntax errors are impossible. This means less compile-time errors (no "can't find variable foo", no "missing bracket", etc), which means that the developer's "edit then test" cycle doesn't get interrupted by compiler errors as often (which should improve productivity).
• Source code stored in a "pre-tokenised" form (possibly including indexing/lookup tables, etc) to improve the efficiency of the IDE and the compiler
• Can be internationalised or personalised. E.g. an English user might see a loop as a box with the text "while" drawn in it, and a Japanese user might see the exact same loop as a box with Japanese symbols in it instead.
• Entire project stored as a single file (rather than many text files scattered everywhere)
• No user visible tools. The compiler/s and assembler are implemented as "file format converters" to create the illusion that source code can be executed as is.
• No need for "make", scripts, linkers, etc. The project file is compiled/converted to byte-code, which is compiled/converted to assembly, and the assembler generates an executable.

Of course this is all just the basic/initial idea. There's a lot of extra features that could be added (like letting unit tests be embedded into classes, integrated debugging, multi-user support, etc) and I'm going to have to do a lot of research when I start designing it.

All I'm really saying though is that I don't really want to implement all this in Linux (in a language like C) before I start writing the OS; then rewrite it all later in my own language (and my own APIs, my own "asynchronous messages everywhere" environment, my own versioning file system, etc). A minimal version of the OS is likely to be smaller and easier to rewrite than the IDE and "file format converters".


Cheers,

Brendan

[Antti]

No need for "make", scripts, linkers, etc.

This feature may end up being very neat as far as the normal user application developing is concerned. Currently, the whole building process of a program is usually quite complicated. User application programmers should not need to make any special adjustments just for being able to compile a program. If they do need to adjust the settings, it may be that the whole infrastucture (OS + programs) needs to be redesigned. Most of the settings are related to the executable format or other purely infrastructure design dependent things. However, this has been already said but I just made it clear to me.

However, it is debatable whether people find, for example, GNU Automake generated scripts being very elegant or not. Visual Studio project folders do not seem much better.

[thepowersgang]

Despite the stigma attached to visual programming languages (see the Lego Mindstorms screenshot from earlier) I also think that they could work rather well, when combined with keyboard shortcuts.

The biggest issue with drag-drop interfaces is needing to locate the item with the cursor, this (as I think almost all of us are aware) is very slow. With shortcuts such that an action (function call, loop, assignment, addition, ...) can be added at the 'cursor' with one/two keystrokes a visual language could almost end up faster than a "classic" one.

However, one project in a single file presents issues for source control (at least with current systems) so I would use a collection of text files as backing storage for the editor (something that is easily tokenisable but can have diffs cleanly performed).

[Brendan]

Hi,

If anyone ever gets Linux programs compiled with my compiler; then I've completely an utterly failed to meet any of the project's goals.

This is hard to believe, unless you have an explicit goal of not supporting any existing OS. The sad truth is that I wouldn't be surprised if this was really one of your goals, but it doesn't make such negative goals less stupid.

One of the main goals of the project is to see what computers could be like if everything was redesigned from scratch (with the benefit of hindsight, and without limitations imposed by compatibility).

Linux doesn't magically make languages less than Turing complete, so it's entirely possible to write the core algorithms in a way easily portable to Linux.

I have actually tried this before. The first step was to implement code that emulates the behaviour of my asynchronous messaging using datagrams/sockets. The next step is to implement a process that uses the "IPC emulation" to emulate the behaviour of my VFS (fully asynchronous IO, with a versioning file system where existing files can't be modified and you can only create new versions of them). After that you'd want to extend the "IPC emulation" code to support emulating other parts of the micro-kernel's API - specifically memory management (allocating and freeing pages at specific virtual addresses) and scheduling ("spawnThread()" and "spawnProcess()", and thread priorities, etc).

Finally, you get to start implementing any services that your application might want. For something like an IDE this would include a service that implements the "user interface protocol" (which includes keyboard/mouse events, scripts that tell the video driver what to draw, etc).

Wouldn't the user want to specify which format to use (for interoperability), whether to save it lossless or what lossy compression to use, with which options, etc.

No, the user would want a system that saves them the hassle of being forced to care about trivial details like that.

Indeed I don't mind having all graphics files (or maybe videos?) uncompressed, if the OS makes sure that I'll always have a large enough hard disk and fast enough internet connection so that I don't even notice. In practice, such things don't exist and this is a tradeoff. Tradeoffs require a choice, there's no one-size-fits-all.

Imagine if every time you open a web page in your web browser the web browser pops up hundreds of dialog boxes asking you what size different pictures should be, how much detail you want, where the page borders should be, if links should be underlined, what colour and size various pieces of text should be, etc. In this case, would you say that being forced to make all these choices would be good (or would you say that being forced to make choices is a massive design failure, and is far inferior to "it just works")?

If the user actually does want to reduce the detail of a picture (e.g. to save disk space), then they can open it in an image editor and reduce the detail.

Most conversions would be very obvious (e.g. legacy graphics file format to native graphics file format, legacy "plain text" format to native text format, etc). I can't think of any conversions that aren't obvious that actually make sense.

Your very own example: BMP -> Text -> Sound. This is not the obvious right way for opening a graphics file as audio.

Can you think of an alternative set of conversions from BMP to sound that actually makes sense, and describe how each step is performed?

Your compiler and linker don't need any options?

Is the toolchain you're currently using so completely broken that you actually need compiler and linker options, just to build normal/native applications? Why?

s/need/allow/

My compiler does work without any other options than just the source file. I never use it this way because I want to configure it right. And I don't claim that my value of "right" is the same as yours.

Ok - which options do you use and why? More importantly; how can the design of these tools be improved to avoid your desire to use these options?

For GCC, the only things I use are:

• the input file name and output file name. The "file format converter" idea makes this entirely redundant.
• the output file type. The "file format converter" idea makes this redundant too.
• options that enable warnings. This is stupid ("all warnings" should be default).
• language options (e.g. which C standard, "pedantic", etc). I'm only having one dialect of one high level language so this isn't needed.
• optimiser settings. There only really needs to be 2 choices ("production/optimised" and "debugging/unoptimised") and I can have that without options (e.g. 2 different "executable" file types - one for normal executables and one for debugging).
• options to include libraries (e.g "-pthread") and set the include path. I'm not having any libraries or header files to begin with, so these aren't needed.
• architecture options (e.g. for cross-compiling, if things like SSE should be used, etc). For the compiler that converts HLL into portable byte-code this doesn't make sense. The compiler/s that convert byte-code to assembly only ever need the equivalent of GCC's "-march=native".

Let me know if I missed any "can't live without" compiler options.

Are you serious? Why do you want to hurt productivity so hard?

I don't think it'd hurt productivity at all. I think (if it's done right) new programmers will learn how to design software better and faster, will write software faster, and will enjoy the work more.

The just punishment for you would be having to work with the tool you're imagining.

I'm looking forward to it. I'll even buy a good "multi-touch" screen so I can drag and drop up to 10 things at once!

You haven't done anything innovative on the language itself here. You could just take C or whatever existing language you like. All that you have achieved is giving users an IDE that is cumbersome to use. Because for entering more than very little data, keyboard > mouse. Dragging an "if" keyword from a toolbar to the right position in the source takes longer than typing the two keys on the keyboard, even if you type with a single finger and don't know exactly where the keys are. With a touch screen instead of a mouse it might become less horrible, but still inferior to a keyboard.

You're forgetting keyboard shortcuts. Why would you want to type "while" when you can just press one key?

For the language itself, I didn't say it would be innovative. In fact I think it should be similar to existing languages (e.g. C, Java/C#) to make it easier for existing programmers to learn.

Now look at the box at the bottom left. This is a class called "CheckingAccount". It has 2 methods - "processCheck()" and "withdrawal()". I'm sure you can all imagine a tool for creating these diagrams if you haven't actually used one yet.

More than one. They all suck. They slow me down because getting my ideas into these fscking tools takes so long.

While I do agree, most of the problem is that the tools I've used have only been UML editors (and weren't able to generate code from the class diagram, for example). This means that everything you do in the class diagram has to be typed in a second time when you start writing the code, which is a duplication of work (and doesn't help to save any time). There are better tools that are able to generate code from the class diagram (it's just that I haven't used them).


Cheers,

Brendan