Object Oriented OS

[AndrewAPrice]

Basically; I don't know what ideal user interface for programming is, I only know it hasn't been discovered yet and it's not text.

Note that the most natural syntax for copying a register to another (for people who aren't assembly language programmers) is extremely obvious:

Code: Select all

ax = bx

Now you've got me thinking. If your IDE works with tokens instead of plain text, it could use symbols to represent constructs bx <- ax (if you imagine the <- being a graphical arrow that appears as you type.) Perhaps colour, motion, or changes in font size could actually be encoded into your binary source file.

It could be a graphical language, but for the sake of productivity I doubt it would be one where you spend most of your time visually organizing your nodes because it easily clutters.

[AndrewAPrice]

So Visual Studio is irrelevant for writing C#? Should I just be using Notepad.exe, and calling CSC.exe to compile?

Well any good text editor could do. I deal with multiple languages daily at work - C, C#, Java, Javascript, Perl, PL/SQL, PHP. Most of the I just use Ultraedit, Sublime. If the change is being made remotely, I may just use Emacs or Vi, depending on what is installed on the server.

Don't get me wrong, IDE's are great. I'm using Visual Studio to develop my OS. It manages building, debugging, jumping to definitions. If I'm developing a Winforms program, I'd hate to place widgets without the GUI designer. Autocomplete is nice, but if you spend enough time in dynamic languages, you learn to live without. A text editor with a "Find In Files" feature is generally just as efficient as jumping to definitions. Debugging though - that's useful - for example, I've worked on large HTML5 web applications, and the ability to run anything arbitrarily through Chrome's JS debugger - manipulating objects, calling functions even if they wouldn't normally trigger- is awesome.

I'd just like to point out, XML syntax is pretty simple. Only 6 symbols (<:="/>), and one keyword (xmlns).

There's more to a language than just learning the symbols. You still need to learn about registers, stacks, how to implement control flows (loops, branches, subroutines), how to implement and use data structures...

[SpyderTL]

You're letting "the tail wag the dog", if that makes sense.

Instead of designing a good programming language syntax (and then finding a way to implement tools that support the programming language syntax) you are doing the opposite - selecting the way you want to implement it, and letting the severe limitations of that "way you want to implement it" destroy the design of the programming language syntax.

A bit. But I prefer to think that I am being honest with the developer about what is actually going on. Even ASM compilers will "optimize" your code for you, and replace it with code that accomplishes what you asked for. I find it comforting knowing that every single byte that I code will be output exactly like I specified, with no fiddling with my code in any way. I can see exactly how many bytes are going to be written out just by looking at the code.

If/when I do create a high(er) level version that hides all of the verbose details about what is happening (like all other compilers), and you never see any of this code at this level, what difference does it make if it converts it to this verbose XML behind the scenes? I'm just using the verbose version directly until I can come up with something to put on top of it.

I've said numerous times that I wouldn't want to write XML code to create an actual cross-platform application. I would want something that's easier to type. But I would probably still compile it down to XML behind the scenes, like everything else.

Note that the most natural syntax for copying a register to another (for people who aren't assembly language programmers) is extremely obvious:

Code: Select all

ax = bx

True. Let's see what that would look like:

Code: Select all

// Count to ten
ax=0
cx=10
next:
ax++
bx=ax
bx+=32
[b8000]=bx
loop next
eax=[message]
[b8000]=eax
cli
hlt
message:
"done"

I like the assignment / copy statements. Very readable.
I like the label / loop statements. Could be a little more descriptive about using the CX register, for the noobs...
I don't like the cli/hlt statements. I started to write them as:

Code: Select all

disableInterrupts
waitForInterrupt

But I thought that you would object to them as being too verbose.

I also don't like that there is no way to differentiate between what is a CPU instruction, and what is a language keyword. It could really use some namespaces.

What do you guys think? I may take this idea a bit further when I get some time.

[SpyderTL]

Autocomplete is nice, but if you spend enough time in dynamic languages, you learn to live without.

But you do agree that it "would" be better if you had intellisense and autocomplete...

[SpyderTL]

Carnage Heart visual software editor:

[Bender]

Even ASM compilers[assemblers] will "optimize" your code for you, and replace it with code that accomplishes what you asked for

Never heard of anything like this. Hence proof wanted.

What do you guys think? I may take this idea a bit further when I get some time.

OK. Let's get it one step ahead.

push rax
push rbx
push rcx
push rdx
push rsi
push rdi
push rbp
push r8
push r9
push r10
push r11
push r12
push r13
push r14
push r15

StoreValueofRegisterataddressofRSPandDecrementRSP rax
StoreValueofRegisterataddressofRSPandDecrementRSP rbx
StoreValueofRegisterataddressofRSPandDecrementRSP rcx
StoreValueofRegisterataddressofRSPandDecrementRSP rdx
StoreValueofRegisterataddressofRSPandDecrementRSP rsi
StoreValueofRegisterataddressofRSPandDecrementRSP rdi
StoreValueofRegisterataddressofRSPandDecrementRSP rbp
StoreValueofRegisterataddressofRSPandDecrementRSP r8
StoreValueofRegisterataddressofRSPandDecrementRSP r9
StoreValueofRegisterataddressofRSPandDecrementRSP r10
StoreValueofRegisterataddressofRSPandDecrementRSP r11
StoreValueofRegisterataddressofRSPandDecrementRSP r12
StoreValueofRegisterataddressofRSPandDecrementRSP r13
StoreValueofRegisterataddressofRSPandDecrementRSP r14
StoreValueofRegisterataddressofRSPandDecrementRSP r15

Yeah, we improved readability.
Note: This may not be an accurate description of what PUSH does because I'm too lazy to press a few buttons on my keyboard.
P.S. This is literally getting offtopic, mods, can we move this discussion to somewhere else?

[embryo]

We must do something different or there's no point. "Different" can mean better or worse, but making things worse than pre-existing stuff isn't an attractive goal.

With this in mind, let's define 2 important words:

• Success: Producing something that is better than existing stuff for at least one purpose (not necessarily "better for all purposes")
  Failure: Failing to producing something that is "better for any purpose"; including:
  • Failing to produce something that works
  • Producing something that does work, but is not better than existing stuff

Then your success definition is absolutely legal for SpyderTL's work - he can tell that the purpose was just to make him happy about the result. And actually he looks happy. The purpose has met the result.

But I hope you can see the problem here - anything can be declared as a success. Then we need a criteria to distinguish a success from a failure. And all the thread is about the criteria.

From your point of view the criteria can be something like very efficient system with very easy to learn language and some means to help us to understand the purpose of a code and it's actual "value". And easy to learn here means you want it to resemble assembly style to be really easy for you.

I'm not trying to say that your point of view is incorrect, but it can be extended and maybe corrected in some way.

But let's look at SpyderTL's point of view. It seems he think, that the criteria can be as such - the system must be coded in XML, just must and there shouldn't be any objection. Next he think, that the XML-based language should be very easy to learn and has some means to help us to understand the purpose of a code and it's actual "value".

As we can see the difference between two points of view are the efficiency and the assembly syntax.

The efficiency is closely related with a base technology chosen by a developer. If it is XML, then we have to accept some inefficiency.

The assembly syntax has less ties with a technology, but the technology still affects developer decisions. And in case of XML OS the result of fighting technology constraints was the syntax SpyderTL demonstrates. But he agrees, that in some future versions there should be some more simple syntax and existing one should be hidden from a developer. In fact the syntax issue is going to be resolved in the future versions of the OS.

Then we have only the issue of XML as a base. And this leads us to the efficiency. Here we have an open question about what can deliver better results. And even more - what are the better results.

I can say, that "better" can be described as user friendly. But who is the user? The user is a developer. Then the "better" should include a speed of development issue. But the efficiency of the tools involved also is important. It helps to reduce development time and produces better performance for OS users (not developers).

From a developer point of view the XML-based approach is worse than other alternatives - all those closing tags and sparse representation are really disturbing. But I hope there can be some benefits with XML approach. At least it's declarative power and tooling support can help. But can we see such benefits in the existing version of OS? I'm afraid we can't.

May be in the future we can see something better.

[embryo]

Yes, the traditional approach is for the IDE to parse text when it enters the IDE (either typed by the user or loaded from file system) so that the IDE can do "fancy features"; and then that work is discarded so that the same text has to be "re-parsed" every single time the file is loaded (by the IDE or a compiler or anything else). Mostly all I'm doing is reducing "work done then discarded" - changing the file format used for source code (from plain text to tokens) doesn't change anything other than efficiency.

There was such attempts. Even Microsoft was looking to replace the NTFS with MS SQL Server. It's really a very interesting idea to have everything stored in a database in efficient manner with a lot of metadata available to users or developers. But for some reasons it was not accepted. May be such simple thing as pointing at a file and hitting F3 to view it (as text, of course) has prevented us from having database instead of file system? There should be A LOT of viewers. Every program must have it's viewer to show any file to a user. With text it is easy. But with database it is a problem. May be it can be accomplished with the help of OS-wide libraries, but we have to rewrite ALL programs to include the library usage. The Microsoft has decided not to make such a big step.

But in an ideal world can be a smart storage system with a lot of meta-information and easy means of accessing anything within it.

I refuse to believe that text is the most ideal user interface for programming possible.

I agree, the text is not the best.

The only problem I see is that the ideal user interface for programming hasn't been discovered yet.

Yes, I agree again.

One part of my project's goals is to make it easier for someone (maybe a future me) to discover the ideal user interface for programming.

It's a really good goal. But it's not a simple one. And your addiction to the efficiency will lead to a very great time waste on the way. I hope you will see that quick prototyping requires inefficient, but very fast to implement solutions. And here is a link to the XML - it supports not only quick writing, but with the help of a multitude of tools around it can support things like quick conversion of XSD to database schema, for example. It means XML is better suited for prototyping than assembly of even C.

The largest thing preventing the discovery of the ideal user interface for programming is people's imagination. It's extremely difficult for people (including me) to imagine anything that they haven't seen before;

In fact the imagination can create a very good thing, but we are too weak to implement it. The implementation is a real problem.

The idea of a 3D environment where CPU/s are represented as machines that follow a track might sound awkward (and to be honest, to me it sounds more like a children's game than something a professional programmer would want); but that's just a way to encourage people to try to imagine something they haven't seen before (another potentially significant step towards enabling the discovery of the ideal user interface for programming).

It is the implementation efforts, actually, that should be encouraged. But people need to be really excited to work for many years on something that doesn't pay them big $. Osdevers are a bit close to the kind of people that can be excited and driven by a great goal. But even osdevers also want to eat and sleep, want to be good parents and want to be lazy sometime.

[embryo]

And how many times, per second, do you build?

Actually, the build time is important. For example - I have a lot of time spent waiting for the GWT compiler makes it's job. It awfully slow comparing to Java or C compiler. And the speed is a result of Google's relaxation towards the quality of it's products. There is "acceptable" quality and the level of acceptability becomes lower and lower every day. It's a bad trend.

[embryo]

I would suggest that we all work together, on one project, but something tells me that would be a disaster!

The goal is really common, but our quirks are stopping us from achieving the goal quickly. It's all about our quirks.

[embryo]

The tools only translate one file at a time, which would take forever if you made a change to one file that impacted 20 other files.

Now you can see the importance of quality. A good tool can batch the work and select only changed documents to process. But you have no such tool and should invent it by yourself. It's not very good.

[embryo]

Let's see what that would look like:

Code: Select all

// Count to ten
ax=0
cx=10
next:
ax++
bx=ax
bx+=32
[b8000]=bx
loop next
eax=[message]
[b8000]=eax
cli
hlt
message:
"done"

I like the assignment / copy statements. Very readable.
I like the label / loop statements. Could be a little more descriptive about using the CX register, for the noobs...
I don't like the cli/hlt statements. I started to write them as:

Code: Select all

disableInterrupts
waitForInterrupt

But I thought that you would object to them as being too verbose.

Really good example. But the "assembly issue" (cli vs disableInterrupts) should be resolved in two ways - for "old guys" and "new guys". Old fashioned boys really like assembly names, then let them have it, why not to accept two versions of a same thing? Let there will be "cli" and "disableInterrupts" together.

[SpyderTL]

Really good example. But the "assembly issue" (cli vs disableInterrupts) should be resolved in two ways - for "old guys" and "new guys". Old fashioned boys really like assembly names, then let them have it, why not to accept two versions of a same thing? Let there will be "cli" and "disableInterrupts" together.

Old guys can keep using ASM. It's not like I'm taking it away.

[SpyderTL]

The tools only translate one file at a time, which would take forever if you made a change to one file that impacted 20 other files.

Now you can see the importance of quality. A good tool can batch the work and select only changed documents to process. But you have no such tool and should invent it by yourself. It's not very good.

The C# code is the "compiler" slash "assembler" slash "linker". Actually, it's probably more accurate to say that the XSLT files are doing a majority of the "compiling" and "assembling", and the C# code does the "linking". It's kind of a gray area.

But the XSLT files can't run themselves, just like .s files can't run themselves, or .java files can't run themselves. My approach is a little different than other programming languages, but it's not magic.

[Brendan]

Hi,

Using ASM was my original plan. But I assumed that the "tools" that were available nowadays were more, um, mature than they were 20 years ago. That turned out to be wrong. Basically I would be developing in NotePad.

That's when I decided to go my own route.

Existing assemblers are part of the reason I first started looking into developing my own tools too; but not because of things like tooltips, etc. One thing I've learnt from using existing assemblers is that, because there's no optimisation done by the assembler, programmers are forced to compromise between code maintainability and performance. I want an optimising assembler (e.g. something that will do constant folding, peephole optimisations and then re-order instructions) so that assembly can be easier to maintain without sacrificing as much performance. Of course once you start looking into things you find lots of additional improvements can be made in the way tools work, and in the way languages are mixed (e.g. C and assembly).

Do you honestly think that (e.g.) auto-complete or tool-tips are helpful for something like "lodsb" for any assembly language programmer that isn't a complete beginner?

Not for the "core" instructions, like MOV and LODSB, but there are a lot more instructions out there that could use some tooltips to help explain what it does and how it is used. Let's try an example... without google or intel manuals, can you tell me how to use the XLATB instruction? Or which instruction to use if I want to convert a short (16-bit) to an int (32-bit)? Or what happens if you set SP to 1 and then PUSHF?

For XLATB, I think it's equivalent to "mov al,[offset+al]" but I'd have to look it up to be sure. For the remaining questions I don't need any manual - to convert (signed) 16-bit integers into (signed) 32-bit integers you'd use "movsx" (for 32-bit code) or "cwd" (for 16-bit code); and setting SP to 1 then doing PUSHF causes a general protection fault (SS segment limit violation) even if you're in real mode.

Or how about writing ASM for an ARM9 without looking at the documentation? I can do that, and I have autocomplete, intellisense and tooltip documentation, and I didn't have to write my own IDE.

I've never really looked at ARM assembly language - I'd have to start by figuring out what the registers are (how many, what size/s and type/s, etc) and how they're used, and reading an instruction reference to find out which instructions exist and their names. For your assembler I'd have to do the same - when staring at a blank page tooltips do nothing, and autocomplete is worthless if you don't know what you want. Of course even for 80x86 assembly your tooltips and autocomplete would be useless to me because you've changed instruction names and I'd have to re-learn them all.

Seriously; why not post an example of your "XML assembly" code somewhere (like the #asm IRC channel on freenode, or alt.lang.asm newsgroup, or the FASM forums), and ask actual assembly language programmers to comment on the syntax? I'm sure that you'll get important feedback.

(I thought that's what this whole thread was about... )

The same reason that I don't post ASM code and ask C# developers what they think. Bias.

A language will seem familiar to the person that invented/implemented it because that person spent ages getting used to the language while it was being invented/implemented; even if the language is a hideously unusable nightmare (from everyone else's perspective). This is a trap. It means that the worst person to judge a language is the person that invented/implemented it.

The reverse actually - when there's severe limits on RAM and CPU speed you want to do everything you can to avoid wasting RAM and wasting CPU time.

Yeah, like loading an IDE into memory. Writing keystrokes to a file takes a lot less memory than a program that converts text to bytecodes in real time.

I was referring to usable systems with limited resources (e.g. from the 1980's) rather than primordial ooze from the beginning of time (systems incapable of supporting anything resembling an IDE).

Are you suggesting we should run a massively bloated XML mess on a system with 8 KiB of RAM?

Who cares if builds take 500 ms longer?

Um, what? You realise 500 ms is half a second?

For my current project; a script builds my own "build utility", then it checks everything and regenerates my any web pages that changed (docs, etc), builds any utilities that changed, uses those utilities to compile anything that needs to be recompiled, and generates a full backup (and manages my backup directory); and this typically takes less than 10 ms. Absolute worst case (everything fully rebuilt entirely from scratch) currently takes 820 ms.

And how many times, per second, do you build?

You're missing the point. Building should be fast enough that it a human can't notice the delay (e.g. less than about 100 ms).

More correctly; it should be possible to run the first few stages of a compiler (all the sanity checking, but none of the optimisation and code generation) extremely quickly. While using an IDE this sanity checking should be run continuously in the background, where the IDE uses the compiler's error messages to highlight errors in your code in real-time (while you type).

You shouldn't have to build things just to get all the compiler's error messages; but this is exactly what I do now - often I build everything several times in a minute just to update a list of error messages, with no intention of using any of the resulting executable code. Sadly, with existing tools I don't have much choice, partly because they're too slow, and partly because some of the errors aren't from the compiler at all (e.g. from linker).


Cheers,

Brendan