OSDev.org

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

-b, -ffreestanding and -mcmodel

Hi,

thepowersgang wrote: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).

You're right (my plans don't work well for source control systems).

I'm not very familiar with source control systems (I've never used one), and would need to figure out why people do use them, and then find ways to incorporate the advantages/features in the most elegant way.


Cheers,

Brendan

Hi,

Combuster wrote:

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

-b, -ffreestanding and -mcmodel

No libraries means no need for "-ffreestanding".

For "-b" and "-mcmodel":

Brendan wrote:

• 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".

Note: It's a little like ".NET" in that executables are portable byte-code and not native code. A computer compiles the byte-code to native code immediately before that computer executes the executable (unless there's a suitable cached copy of the native code for that specific computer).


Cheers,

Brendan

-ffreestanding isn't -nostdlib, in other words a lack of host OS rather than libraries. The hint was on how to compile a kernel, bootloader, or something not for your system.

Hi,

Combuster wrote:-ffreestanding isn't -nostdlib, in other words a lack of host OS rather than libraries. The hint was on how to compile a kernel, bootloader, or something not for your system.

Heh - I don't use high level languages for boot loaders and kernels anyway..


Cheers,

Brendan

Brendan wrote:Hi,

bluemoon wrote: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.

All of the above mentioned point has no conflict with C++ or even java, it's the features of a wonderful IDE.
But sure it's your own choice to design yet another language for more flexibility or other non-speakable features.

Brendan wrote:It's a little like ".NET" in that executables are portable byte-code and not native code.

executables are required in 3 cases:
First to save compile time,but actually it is posible to compile a program very fast (unless the toochain is bloated),so they are not really needed.
Second to protect the source code in comercial projects,for open source projects they are not needed.
Third ,if the compiler is not available.

why you need executable format for your hobby Os aplications?

And how do you plan to share code if aplications are single file?

Hi,

octavio wrote:

Brendan wrote:It's a little like ".NET" in that executables are portable byte-code and not native code.

executables are required in 3 cases:
First to save compile time,but actually it is posible to compile a program very fast (unless the toochain is bloated),so they are not really needed.
Second to protect the source code in comercial projects,for open source projects they are not needed.
Third ,if the compiler is not available.

why you need executable format for your hobby Os aplications?

Because the CPU has trouble executing source code that isn't in an executable format.

octavio wrote:And how do you plan to share code if aplications are single file?

There'd be some sort of "package manager" on top of this. Normally the package manager would install a package that contains the byte-code (and may compile the byte-code to native code optimised for that computer when the package is installed). This is fine for closed source/commercial projects.

Open source developers would do the same thing (provide a package containing the byte-code for people that don't want the source code) and also provide an alternative package containing the project file instead of byte-code (for people who do want to view/modify/build the original source code).


Cheers,

Brendan

thepowersgang wrote: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.

Okay, let's stop talking about graphical languages. This doesn't seem to be what any of you are talking about. We're purely talking about an IDE here. Originally suggested by Brendan was an IDE heavily based on drag&drop, but now you all seem to be saying "it's not that bad, you'll have keyboard shortcuts and they'll be really great". Which is probably a good idea.

But what we have now is an IDE for a boring old language like C that displays boxes instead of relying on indentation (may or may not be helpful, but it probably doesn't hurt) and that auto-completes 'w' to 'while'. This has very little to do with the thing originally suggested, but I can imagine that this would indeed by usable.

Now at this point we're almost back to plain text source files, so tools like diff would work again as well...

Brendan wrote: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).

You're doing the abstraction at the wrong level. Nobody said you should emulate your OS at the syscall level. This would be a crazy amount of work.

When writing a compiler, the OS functionality that you need is a) read from the source file, b) write to the output file, and maybe c) allocate some memory. And that's it, more or less. All the parsing, optimisation, code generation algorithms are purely userspace code and automatically portable between OSes. Have three functions that read from the source, write to the output and allocate memory, and this is what you need to replace when porting the Linux version to your own OS.

You don't need the fancy IDE on Linux for bootstrapping. You just write the code in a plain old text editor.

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")?

Good defaults are important. And so is being able to deviate from the defaults. My browser does allow me to increase the font size if I like. It allows me to change the default font, the link colors and whether they are underlined if I like. I believe I could even override the rest of the page layout defaults with custom CSS if I really like. And so on.

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.

So the one graphics format you have has really many subformats, and you just moved the option which one to use from the save dialog to somewhere else in the menu?

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?

Sure, I already mentioned going from BMP to MIDI by recognising notes rather than letters.

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).

I'm not sure if I agree here. "all warnings" is hardly productive. Have you ever tried to use all of them?

Related to this, during development I use -Werror, for a release maybe rather not. If you really want to limit choice, this could be part of your production vs. debugging option.

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.

And you're never going to extend it after the first release?

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).

When looking for a bug that is only revealed with optimisation enabled, sometimes you're glad if you can enable/disable single optimisations.

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.

What does having no libraries mean? Will all programs have to carry their own version of common code? That is, code duplication instead of reuse?

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

No, I think by giving the developer no choice about libraries, language extensions, optimisations and warnings you've pretty much excluded any other useful options. Maybe something to enable/disable some runtime checks as a tradeoff between more graceful failure and performance, but I expect that you know the right setting for everyone, so no need to have a choice there either...

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!

Heh, I'd love to watch you programming this way.

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

Right, as I said above it's a great drag&drop IDE that becomes usable by not using drag&drop. Well, kind of defeats the purpose, but yeah...

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).

I had to use these tools for some university projects, and we had to deliver both documents that included UML and code. The tools supported code generation, but it still took way too long to get the design into these crappy tools even if you could generate bad code out of it afterwards.

But eventually we did find an effective way of how to do it: Take a text editor, write the stubs in Java with Javadoc comments and use the reverse engineering functionality of the tool. It works so much better. And I believe this tells everything about graphical tools with drag&drop and fancy menus, dialogs and whatnot. In terms of productivity, writing plain text source code beats them by far.

Cross-quoting from the original thread:

Brendan wrote:I'm not sure if you're trolling or just stoned. Download the latest "bochs.tar.tz" and double click on the tarball, and tell me if it executes.

This raises interesting questions actually. Compiling bochs takes longer than just a fraction of a second, so the first time you start something like it on your OS, you'd have to wait. First important point is that the user needs some feedback, or the system appears to be hanging while it's really just compiling the program.

The second one is: Didn't you say that the result of a conversion (i.e. the compilation) is cached? This means that if you run out of disk space, the OS chooses some conversion results (i.e. binaries) to be removed because they can be reproduced, right? Now if I think about how long things like KDE or OpenOffice take to compile... Can it happen that I just want to have a quick look at a spread sheet, and surprsingly I need to wait a day or two until the background compilation has completed because I hadn't used the office program recently and so the OS decided that freeing the space used for the binaries was a good idea?

Hi,

Kevin wrote:

thepowersgang wrote: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.

Okay, let's stop talking about graphical languages. This doesn't seem to be what any of you are talking about. We're purely talking about an IDE here. Originally suggested by Brendan was an IDE heavily based on drag&drop, but now you all seem to be saying "it's not that bad, you'll have keyboard shortcuts and they'll be really great". Which is probably a good idea.

But what we have now is an IDE for a boring old language like C that displays boxes instead of relying on indentation (may or may not be helpful, but it probably doesn't hurt) and that auto-completes 'w' to 'while'. This has very little to do with the thing originally suggested, but I can imagine that this would indeed by usable.

If you ignore the "UML class diagram" layer and only look at writing code for methods; then the user could set the icon for "while" to a picture of a fluffy duck (or anything else they like); "break", "continue" and "goto" could all be the same thing (and be drawn as a big arrow pointing to where execution continues); left and right shift might be an animated picture of ones and zeros scrolling left/right. Of course these all just silly examples.

If you look at almost all programming languages you'll find that there's about 25 basic operations (call/ret, add/sub/negate, mul/shift/div, if/else, loops/goto, and/or/xor/not, assign/copy/move, etc); plus things like variables (and variable types), arrays, structures, the idea of scope, etc. I'm not saying that these basic things will cease to exist (or that the language itself is fundamentally different from most other languages); I'm only saying they'd be entered, displayed and stored differently (graphics, not text).

Kevin wrote:Now at this point we're almost back to plain text source files, so tools like diff would work again as well...

Underneath it all is something like a string of tokens. Nothing prevents these tokens from being cut & pasted, compared, merged, etc.

Kevin wrote:When writing a compiler, the OS functionality that you need is a) read from the source file, b) write to the output file, and maybe c) allocate some memory. And that's it, more or less.

And all that is very different. In addition the native compiler would be built as "stages", where each stage is a separate "event driven" thread that receives something, does something to it, and then passes the result to the next stage/thread; with no shared data between these stages/threads.

Kevin wrote:All the parsing, optimisation, code generation algorithms are purely userspace code and automatically portable between OSes.

The native compiler wouldn't do parsing or syntax checking (that's the IDE's job). For the Linux compiler I wouldn't bother with any optimisation (it's just more code to port into a different language later and can be omitted). That only leaves code generation.

Now let's talk about your "automatically portable between OSs" theory. Actually, let's make it even easier - let's talk about "automatically" porting code from one language (e.g. C) to a different language (e.g. Java) on the same OS. How do you do this "automatic porting"? Do you open all the files in your text editor, the go to the menus and click on "file -> export as Java" or something? Maybe it's one of those fancy features in emacs.

Kevin wrote:

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.

So the one graphics format you have has really many subformats, and you just moved the option which one to use from the save dialog to somewhere else in the menu?

I'm not sure why you'd think subformats would be needed.

Kevin wrote:

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

Sure, I already mentioned going from BMP to MIDI by recognising notes rather than letters.

Ok - in that case maybe the user could just open the BMP in a "musical note editor" (so the VFS converts from bitmap into the MIDI file format) and save it as a different file name (so that when the new file is opened in a music player the VFS converts it into the sound file format).

Kevin wrote:

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?

I'm not sure if I agree here. "all warnings" is hardly productive. Have you ever tried to use all of them?

I normally use "-Wall -Wextra" for GCC. I think there are some warnings that aren't included in this (e.g. conversions between signed and unsigned), which are often annoying because they warn about things that is perfectly valid/acceptable in C.

Kevin wrote:

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.

And you're never going to extend it after the first release?

I hope not; but I'll put a "version" field in the project file's header just in case.

Kevin wrote:

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).

When looking for a bug that is only revealed with optimisation enabled, sometimes you're glad if you can enable/disable single optimisations.

I'd be more glad to have executables that behave the same regardless of whether optimisation was enabled or not.

Kevin wrote:

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.

What does having no libraries mean? Will all programs have to carry their own version of common code? That is, code duplication instead of reuse?

There will never be any support for libraries/DLLs in the OS, IDE, compiler, executable file format or anything else. Instead of implementing something as a library you'd implement it as a "named service". To create a named service, you'd start by writing a formal "Request For Comments" that defines the messaging protocol for the proposed service. After peer review, etc; some organising body (me) would decide to either adopt the proposal, or not. Once adopted, you'd be able to start implementing that named service.

For the include path and header files; I don't see the need. There's only the kernel API and messaging protocols; and both of these could be imported ("copied") into the project.

Kevin wrote:

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

No, I think by giving the developer no choice about libraries, language extensions, optimisations and warnings you've pretty much excluded any other useful options. Maybe something to enable/disable some runtime checks as a tradeoff between more graceful failure and performance, but I expect that you know the right setting for everyone, so no need to have a choice there either...

I think we're looking at things from completely opposite perspectives. You think choices are good for users; while I think removing the burden of needing to choose is better.

If you don't understand what I mean by "the burden of needing to choose", trying buying a sandwich at Subway when you're in a hurry...

Kevin wrote:Cross-quoting from the original thread:

Brendan wrote:I'm not sure if you're trolling or just stoned. Download the latest "bochs.tar.tz" and double click on the tarball, and tell me if it executes.

This raises interesting questions actually. Compiling bochs takes longer than just a fraction of a second, so the first time you start something like it on your OS, you'd have to wait. First important point is that the user needs some feedback, or the system appears to be hanging while it's really just compiling the program.

Most of the problem with Bochs is that it's not designed for one compiler on one OS; but is designed for many different compilers on many different OSs - doing ".configure" takes more time than compiling.

The next problem is the tool chain - for each source file (for about 100 files) you're creating a new process, loading an executable into it, doing initialisation and dynamic linking, then destroying the process at the end. That's a lot of overhead on it's own.

Then there's "file system thrashing". Many utilities and lots of small files mean that (even if you're using SSD) you'd end up spending more time waiting for "open()" than you do for "read()". File IO bandwidth is crippled.

Then there's the source code itself. It's in text format, which means that it takes up twice as much space (and file IO bandwidth) than pre-tokenised source code would, and then the compiler is left with the overhead of tokenising it before it can do much.

Without all of those problems, you could probably compile something like Bochs 10 times faster.

Kevin wrote:The second one is: Didn't you say that the result of a conversion (i.e. the compilation) is cached? This means that if you run out of disk space, the OS chooses some conversion results (i.e. binaries) to be removed because they can be reproduced, right? Now if I think about how long things like KDE or OpenOffice take to compile... Can it happen that I just want to have a quick look at a spread sheet, and surprsingly I need to wait a day or two until the background compilation has completed because I hadn't used the office program recently and so the OS decided that freeing the space used for the binaries was a good idea?

The developer compiles the source code into byte-code; then the users install the byte-code (not the source code) and the byte-code is compiled into a native executable when it is installed. This means that normally there's no overhead of compiling when the application/GUI is started (but there is some overhead during package installation).

If the OS runs out of disk space, then there's plenty of stuff it can remove ("deleted" files, old versions of files, conversion results, redundant copies of files, etc). If the OS is so desperate for space that it removes an executable, then it's likely that the OS has been complaining about running out of disk space for months and the user has ignored it.

Despite this, if you start a spreadsheet and the OS actually does need to compile it first; then I'd expect to see a "Compiling" progress bar for about 30 seconds. Part of the reason for this is that the spreadsheet won't be a big complicated mess that has to handle 20 different file formats (and maths, and fonts, and pictures, and spell checking, and ...).


Cheers,

Brendan

Brendan wrote: Because the CPU has trouble executing source code that isn't in an executable format.

I'm talking about loading the source code and convert it into executable code in ram instead of have the executable files on the HD.

Hi,

octavio wrote:

Brendan wrote:Because the CPU has trouble executing source code that isn't in an executable format.

I'm talking about loading the source code and convert it into executable code in ram instead of have the executable files on the HD.

Ah - in that case think of it as caching if you like. It's faster to load a the executable from disk instead of loading the source and compiling.


Cheers,

Brendan

Brendan, it's really hard to discuss with you. You make claims, and when a weakness is pointed out in it, you jump to the next topic and claim different things, saying that they are much more important and that you original claim is practically irrelevant and unused anyway...

Brendan wrote:If you ignore the "UML class diagram" layer

Right, that's the worst part of it - I told you about our efficient way to create UML diagrams, by writing source code and then using the reverse engineering functionality of the UML tool. It tells everything. Still I don't expect that we'll agree on this one, nor that there are any new arguments, so ignoring it for now seems most useful.

and only look at writing code for methods; then the user could set the icon for "while" to a picture of a fluffy duck (or anything else they like); "break", "continue" and "goto" could all be the same thing (and be drawn as a big arrow pointing to where execution continues); left and right shift might be an animated picture of ones and zeros scrolling left/right. Of course these all just silly examples.

But I'm supposed to use keyboard shortcuts in order to work efficiently. So why would I care what those unused icons look like that take my valuable screen space away for no reason?

I'm not saying that these basic things will cease to exist (or that the language itself is fundamentally different from most other languages); I'm only saying they'd be entered, displayed and stored differently (graphics, not text).

Correct, and this is why we're talking about an editor rather than a language. The language is the same, only the presentation is different.

And all that is very different. In addition the native compiler would be built as "stages", where each stage is a separate "event driven" thread that receives something, does something to it, and then passes the result to the next stage/thread; with no shared data between these stages/threads.

Okay, so each of the stages uses the input and output functions, and you'll have to build a small wrapper that does the plumbing by putting pipes between the stages on Linux. You'll probably have an OS specific main loop, too, but we're talking about a few hundred lines of OS specific code here, not millions.

Now let's talk about your "automatically portable between OSs" theory. Actually, let's make it even easier - let's talk about "automatically" porting code from one language (e.g. C) to a different language (e.g. Java) on the same OS. How do you do this "automatic porting"? Do you open all the files in your text editor, the go to the menus and click on "file -> export as Java" or something? Maybe it's one of those fancy features in emacs.

Now you're trolling. Porting portably written code between OSes while using the same language is obviously much easier than porting between languages on the same OS. I can take the same piece of C code and as long as it doesn't use the OS (or uses it through the OS specific standard library - which could be very small for a successfully running compiler) it runs on any OS for which a C compiler exists. The same is true for any other language.

I'm not sure why you'd think subformats would be needed.

At least lossy vs. lossless vs. vector graphics. I'm not an expert for graphics formats, there may be more of such important choices that effectively create subformats.

Kevin wrote:

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

Sure, I already mentioned going from BMP to MIDI by recognising notes rather than letters.

Ok - in that case maybe the user could just open the BMP in a "musical note editor" (so the VFS converts from bitmap into the MIDI file format) and save it as a different file name (so that when the new file is opened in a music player the VFS converts it into the sound file format).

And so could he do with a text editor so that OCR is used. Sure.

But your assumption was that he opens the BMP neither in a "musical note editor" nor in a text editor, but with an audio player. So why is BMP -> Text -> Audio the obviously correct way to convert it and superior to BMP -> MIDI -> Audio?

Kevin wrote:I normally use "-Wall -Wextra" for GCC. I think there are some warnings that aren't included in this (e.g. conversions between signed and unsigned), which are often annoying because they warn about things that is perfectly valid/acceptable in C.

That's the whole point of warnings. They warn against things that are strictly speaking allowed, but there's a certain chance that it's not what you meant to do. And it's your very own choice which of these things you want to make use of anyway. That is, you need options to tell the compiler about your choice.

I'd be more glad to have executables that behave the same regardless of whether optimisation was enabled or not.

Impossible by definition. If the timing doesn't change, you haven't optimised anything.

There will never be any support for libraries/DLLs in the OS, IDE, compiler, executable file format or anything else. Instead of implementing something as a library you'd implement it as a "named service". To create a named service, you'd start by writing a formal "Request For Comments" that defines the messaging protocol for the proposed service. After peer review, etc; some organising body (me) would decide to either adopt the proposal, or not. Once adopted, you'd be able to start implementing that named service.

Okay, and these are registered globally and resolved dynamically with a string lookup, and each program can immediately access all of them (ignoring possible permission restrictions)? Certainly looks doable, and probably doesn't require the binaries to be present when compiling. You'll need the interfaces if you don't want to go completely type unsafe, but if they must be registered globally you can access them without additional options. You'll also need good mechanisms for versioning the interfaces, like shared libs do.

So yes, I can accept not having options for them, but I'm not sure if I'd call it "not libraries".

I think we're looking at things from completely opposite perspectives. You think choices are good for users; while I think removing the burden of needing to choose is better.

If you don't understand what I mean by "the burden of needing to choose", trying buying a sandwich at Subway when you're in a hurry...

The problem with Subway is not choice, but that they don't have defaults... You cut the part where I said that having choice is important, but only having good defaults makes it actually usable.

The developer compiles the source code into byte-code; then the users install the byte-code (not the source code) and the byte-code is compiled into a native executable when it is installed. This means that normally there's no overhead of compiling when the application/GUI is started (but there is some overhead during package installation).

But you were talking about a bochs.tar.gz. This is a source code tarball. So please, let's compare apples to apples.

With binaries the world looks different: If you wanted you could have a bochs.sh on Linux that extracted the embedded binaries into temporary files and started it. There's little room for you to differentiate here. It's the choice of bochs that they don't provide their software in this form, not a decision of the OS.

(And before you say that embedding multiple files in the .sh is cheating: You'd need the same, because bochs needs more than just the binary to run - like ROMs etc.)

Despite this, if you start a spreadsheet and the OS actually does need to compile it first; then I'd expect to see a "Compiling" progress bar for about 30 seconds. Part of the reason for this is that the spreadsheet won't be a big complicated mess that has to handle 20 different file formats (and maths, and fonts, and pictures, and spell checking, and ...).

Ah well. I believe reality looks different (either your spreadsheet lacks functionality or it becomes large), but it makes little sense to discuss this based on opposite assumption.

Hi,

Kevin wrote:

and only look at writing code for methods; then the user could set the icon for "while" to a picture of a fluffy duck (or anything else they like); "break", "continue" and "goto" could all be the same thing (and be drawn as a big arrow pointing to where execution continues); left and right shift might be an animated picture of ones and zeros scrolling left/right. Of course these all just silly examples.

But I'm supposed to use keyboard shortcuts in order to work efficiently. So why would I care what those unused icons look like that take my valuable screen space away for no reason?

For the same reason that a schematic diagram of an electronic circuit or an architect's blueprint of a house is better than any description in text; and for the same reason that things like flowcharts and all the different types of UML diagrams exist. Humans are able to understand pictures much faster because of the visual cues.

Take a look at any relatively large piece of source code (Bochs, Qemu, Linux, OpenOffice, any web browser, etc) that you've never seen before. How much time would it take you to become familiar with the project? Now imagine joining a large project that uses a language that you've never seen before - it could take months before you understand the existing source code enough to become a productive contributor.

If you think visual cues are bad and/or pointless; try writing software without them - try writing software without any indenting or any other source code formatting, without syntax highlighting, without "constants are upper case", etc. Visual cues are important because they improve readability. More visual cues (e.g. "graphical source code" that isn't restricted by the limitations of text) would improve readability more.

Kevin wrote:

I'm not saying that these basic things will cease to exist (or that the language itself is fundamentally different from most other languages); I'm only saying they'd be entered, displayed and stored differently (graphics, not text).

Correct, and this is why we're talking about an editor rather than a language. The language is the same, only the presentation is different.

C++, Java and C# all have the same fundamental things - there's variables, there's scope, there's classes, there's loops, there's operators for addition/subtraction, etc. They aren't fundamentally different from each other; but they are different languages.

At the start of this topic, people saw "graphical" and started thinking of something like LabVIEW or ROBOLAB, which are fundamentally different from languages like C++, Java, C#, etc (no classes, no functions, no variables, etc).

My language won't be fundamentally different to languages like C++, Java and C#. This does not mean that my language will be the same as any other language.

Kevin wrote:

Now let's talk about your "automatically portable between OSs" theory. Actually, let's make it even easier - let's talk about "automatically" porting code from one language (e.g. C) to a different language (e.g. Java) on the same OS. How do you do this "automatic porting"? Do you open all the files in your text editor, the go to the menus and click on "file -> export as Java" or something? Maybe it's one of those fancy features in emacs.

Now you're trolling. Porting portably written code between OSes while using the same language is obviously much easier than porting between languages on the same OS. I can take the same piece of C code and as long as it doesn't use the OS (or uses it through the OS specific standard library - which could be very small for a successfully running compiler) it runs on any OS for which a C compiler exists. The same is true for any other language.

It's not the same language, and I never said it was. Code written in one language is not "automatically portable" to a different (but fundamentally similar) language.

Kevin wrote:

I'm not sure why you'd think subformats would be needed.

At least lossy vs. lossless vs. vector graphics. I'm not an expert for graphics formats, there may be more of such important choices that effectively create subformats.

It's possible to design a format that makes these choices unnecessary.

Kevin wrote:

Kevin wrote:Sure, I already mentioned going from BMP to MIDI by recognising notes rather than letters.

Ok - in that case maybe the user could just open the BMP in a "musical note editor" (so the VFS converts from bitmap into the MIDI file format) and save it as a different file name (so that when the new file is opened in a music player the VFS converts it into the sound file format).

And so could he do with a text editor so that OCR is used. Sure.

But your assumption was that he opens the BMP neither in a "musical note editor" nor in a text editor, but with an audio player. So why is BMP -> Text -> Audio the obviously correct way to convert it and superior to BMP -> MIDI -> Audio?

You're right ("BMP -> Text -> Audio" isn't always the obviously correct way). Using the "most likely to be correct" way as default doesn't really make the idea of automated file format conversion any less appealing though.

Kevin wrote:

I normally use "-Wall -Wextra" for GCC. I think there are some warnings that aren't included in this (e.g. conversions between signed and unsigned), which are often annoying because they warn about things that is perfectly valid/acceptable in C.

That's the whole point of warnings. They warn against things that are strictly speaking allowed, but there's a certain chance that it's not what you meant to do. And it's your very own choice which of these things you want to make use of anyway. That is, you need options to tell the compiler about your choice.

Making the user choose is a design failure. Could the language and/or tools be modified so that the user has no need to make choices about what should and shouldn't be considered a warning? I think it can, and I don't think it'd be hard to do.

For an example; rather than making the user choose if conversions between signed and unsigned should generate a warning or not; how about we change the language to make conversion between signed and unsigned illegal without a type cast? That would fix one specific problem, but there's a more generic solution - how about we change the language so that any "potentially lossy" conversion is illegal without a type cast? That would solve the original problem, and also fix other similar problems.

Kevin wrote:

I'd be more glad to have executables that behave the same regardless of whether optimisation was enabled or not.

Impossible by definition. If the timing doesn't change, you haven't optimised anything.

You're still trying to solve symptoms.

In which cases does timing effect behaviour? I can only think of 2. The first case involves shared state, and I can completely eradicate this cause of "timing effects behaviour". The second case is trivial logic errors (e.g. functions/methods called in the wrong order), which are relatively easy to avoid and easy to debug.

Kevin wrote:

The developer compiles the source code into byte-code; then the users install the byte-code (not the source code) and the byte-code is compiled into a native executable when it is installed. This means that normally there's no overhead of compiling when the application/GUI is started (but there is some overhead during package installation).

But you were talking about a bochs.tar.gz. This is a source code tarball. So please, let's compare apples to apples.

With binaries the world looks different: If you wanted you could have a bochs.sh on Linux that extracted the embedded binaries into temporary files and started it. There's little room for you to differentiate here. It's the choice of bochs that they don't provide their software in this form, not a decision of the OS.

(And before you say that embedding multiple files in the .sh is cheating: You'd need the same, because bochs needs more than just the binary to run - like ROMs etc.)

Ok - in that case (source code and not a normal package, with both the byte-code and executable deleted by an OS that's desperate to find a few remaining shreds of free disk space), then I'd expect to see a "Compiling" progress bar for several minutes when the application starts up.


Cheers,

Brendan