(Graphical) Programming Languages

[Owen]

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.

Quite the opposite. ICs have gone from being designed by schematic to being written in VHDL or Verilog. You can't adequately manage the complexity on a schematic.

Schematic entry is good at expressing logical structure (e.g. what a PCB does, because PCBs generally just glue things together) but poor at expressing mechanics (how it does it). Modern ICs are purely programmed things.

That said, I find the idea of well designed "graphical programming" interesting, and think it would be a worthwhile thing to experiment with anyway.

[Kevin]

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.

Sorry, I think I misunderstood. I was thinking you meant icons somewhere in a toolbar from which I can drag them into the source, i.e. for input. Now it looks like you're really thinking about the output and how the source code is presented.

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 the language is sufficiently similar to languages I know, I don't think this will be a major impediment.

Now for the projects you mention, I think for myself Linux and Bochs qualify for your example (and probably parts of qemu as well, but claiming that I've close to never seen qemu code would be ridiculous ). It's not that I've never seen any part of the code of Linux or Bochs, but I only have the occasional look and for most parts I don't have the big picture.

Still, I suppose I could become a productive Bochs contributor today. With Linux, some subsystems are a bit more complicated and I think a visualisation could really help me there - but not on the single statement level, but rather information on which data structures are passed which way through the code and so on. But even without having any clue of most subsystems in Linux, being a productive contributor would be possible in almost no time in those areas of the code that are fairly self-contained components.

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.

Yes, I understand this. I'm not meaning to say that the language is literally the same as an existing one, but it shares the concept and so far there's little interesting things to discuss about it. The fundamentally different and therefore interesting part is not the language, but the editor. Is it more agreeable if I rephrase it like this?

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.

Same language as what?

I was suggesting that you build:
1. A compiler for your language written in C for Linux
2. A compiler for your language written in your language for Linux (this port is manual work and is an unavoidable step in bootstrapping)
3. A compiler backend for your OS
4. A native compiler for your OS (for the greatest part, this should just work by recompiling)

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.

By creating a superset that can contain lossy, lossless and/or vector graphics? If it's "or", we directly have subformats; if it's "and", we have a container format that can contain graphics in three different formats.

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.

Users will disagree on what the "most likely to be correct" way is.

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.

Yes, it's possible. It's also a bit nasty to use.

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.

Whether a program finishes its work after one minute or after five minutes is already a difference in behaviour in my book. Of course, it will also influence other things: Maybe it's just that the ETA and bandwidth display prints different numbers (and who knows, maybe it divides by zero if it goes too fast?), maybe it's that the game computes more frames, and so forth. It should be obvious that such changes may have many implications.

[Brendan]

Hi,

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.

Sorry, I think I misunderstood. I was thinking you meant icons somewhere in a toolbar from which I can drag them into the source, i.e. for input. Now it looks like you're really thinking about the output and how the source code is presented.

Do you ever write software without looking at the source code you're creating? I don't think input and output be considered separate things.

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 the language is sufficiently similar to languages I know, I don't think this will be a major impediment.

Now for the projects you mention, I think for myself Linux and Bochs qualify for your example (and probably parts of qemu as well, but claiming that I've close to never seen qemu code would be ridiculous ). It's not that I've never seen any part of the code of Linux or Bochs, but I only have the occasional look and for most parts I don't have the big picture.

Still, I suppose I could become a productive Bochs contributor today. With Linux, some subsystems are a bit more complicated and I think a visualisation could really help me there - but not on the single statement level, but rather information on which data structures are passed which way through the code and so on. But even without having any clue of most subsystems in Linux, being a productive contributor would be possible in almost no time in those areas of the code that are fairly self-contained components.

It normally takes me a while just to understand the directory structure and get the big picture. Then I end up spending more time just trying to decode the source (finding where functions are and what they actually do, finding pieces hidden in header files, etc). Bochs isn't too bad (it's fairly logical), but I've never become familiar with it enough to avoid getting frustrated and resorting to "grep some_function_that_could_be_anywhere".

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.

Yes, I understand this. I'm not meaning to say that the language is literally the same as an existing one, but it shares the concept and so far there's little interesting things to discuss about it. The fundamentally different and therefore interesting part is not the language, but the editor. Is it more agreeable if I rephrase it like this?

Ok.

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.

Same language as what?

I was suggesting that you build:
1. A compiler for your language written in C for Linux
2. A compiler for your language written in your language for Linux (this port is manual work and is an unavoidable step in bootstrapping)
3. A compiler backend for your OS
4. A native compiler for your OS (for the greatest part, this should just work by recompiling)

The problem with your step 2 is that I have no desire to build applications for Linux or support things like the Elf file format. For this reason:
1. A compiler in C for Linux that generates native executables for my OS
2. A native compiler for my OS in my own language (compiled with the first compiler).
3. Compile the native compiler on itself

Of course this still adds up to "write the same compiler twice in different languages".

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.

By creating a superset that can contain lossy, lossless and/or vector graphics? If it's "or", we directly have subformats; if it's "and", we have a container format that can contain graphics in three different formats.

I did a whole pile of research into the idea of using triangles and nothing else. The original idea was that an image would be made of triangles with a solid colour and triangles with gradients. There's a bunch of technicalities involved, but the end result of this research is that it's theoretically possible but not so good in practice; mostly because of the sheer number of triangles you'd need to push through a graphics pipeline (translation, clipping, hidden surface removal, etc) to render for a complex "screen full" of graphics.

By allowing triangles to be textured, all of the problems with the original idea vanish. It complicates the renderer (which is what I wanted to avoid), but for performance reasons it's a necessary compromise. Basically you end up with an image built out of triangles, where each triangle may be a solid colour, a gradient, or a texture.

To convert bitmap data into this format, you end up with a texture (the original bitmap data) and 2 textured triangles. That's very easy to do. To convert vector graphics into this format you do tessellation to turn it into triangles. That's fairly easy too. In both of these cases it's a "virtually lossless" conversion. To reduce detail, you can reduce the resolution of textures (e.g. without changing triangle data), or merge adjacent triangles, or maybe replace "textured triangles" with "gradient triangles", or...

Basically; there is no "lossy vs. lossless vs. vector graphics" choices and there are no subformats either. If you want to call it a container format (something that contains triangles and texture data), that's fine.

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.

Yes, it's possible. It's also a bit nasty to use.

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.

Whether a program finishes its work after one minute or after five minutes is already a difference in behaviour in my book. Of course, it will also influence other things: Maybe it's just that the ETA and bandwidth display prints different numbers (and who knows, maybe it divides by zero if it goes too fast?), maybe it's that the game computes more frames, and so forth. It should be obvious that such changes may have many implications.

Those examples are all "case 2, logic errors". If your application crashes due to a division by zero bug (because something was too fast) then it shouldn't be hard to track down the cause.

It's the first type of timing bugs that matter most - the hideous "Heisenbug" caused by an overlooked race condition or something.


Cheers,

Brendan

[Griwes]

It normally takes me a while just to understand the directory structure and get the big picture. Then I end up spending more time just trying to decode the source (finding where functions are and what they actually do, finding pieces hidden in header files, etc). Bochs isn't too bad (it's fairly logical), but I've never become familiar with it enough to avoid getting frustrated and resorting to "grep some_function_that_could_be_anywhere".

Any decent IDE (and a decent IDE is one of things you seem to be trying to achieve) already allows you to instantaneously jump to declaration/definition using something similar to Ctrl+Click.

[bewing]

I've been thinking about graphical programming, and I'm not sure how much it would help me. I have 2 different programming styles, depending on how hard the algoritm is that I'm working on.

If what I am doing is trivial, I tend to cut-and-paste 10 or 20 lines of code at a time and then do slight modifications of the pasted code to suit its new environment.

If what I am doing is hard, I tend to start by writing what I want to happen as comments -- and then convert the comments to more comments, and then to code.

And I don't see a real convenient way of doing either of those graphically. Graphical programming seems more suited to coding from scratch.

[XanClic]

Do you ever write software without looking at the source code you're creating? I don't think input and output be considered separate things.

Your IDE converts keyboard shortcuts to a graphical representation of the program code, right? Thus, the input is text, the output is an image. I don't really see the connection between those two.

It normally takes me a while just to understand the directory structure and get the big picture.

Well, so far I couldn't see the point where your programming language would abandon directories or anything like it in favor of a structure to be understood more easily. I guess you'd use a big diagram which connects all the single parts of a huge project. If that is the case, it does not keep anyone from choosing a bad structure anyway. In fact, such a structure could easily be accomplished through directories in the first place (and probably symlinks). If you don't find what you're looking for in such a directory structure, I guess no other tree-like structure could help to solve it – while trees are obviously one of the best ways of organizing data. Maybe a tag or hyperlink system could perform better, but overall it's probably best to implement such hyperlinks in IDEs without affecting the basic file system structure (as pointed out by Griwes).
tl;dr: I doubt whether this is a problem inherent to existing programming languages but is rather the result of a lack of organization skills inherent to existing programmers.

By allowing triangles to be textured, all of the problems with the original idea vanish. It complicates the renderer (which is what I wanted to avoid), but for performance reasons it's a necessary compromise. Basically you end up with an image built out of triangles, where each triangle may be a solid colour, a gradient, or a texture.

I don't see how this eliminates the differentiation between lossy and lossless compression. As you probably know, textures are just raster graphics, thus, their compression may in turn be either lossy or lossless.

To convert vector graphics into this format you do tessellation to turn it into triangles.

Actually, I would generally propose you take an existing vector format and allow at least some primitives (such as triangles or rectangles) to be textured. I don't think many people will be too glad if you convert their bezier curves into triangles (probably it will consume more space, too).

[Brendan]

Hi,

Do you ever write software without looking at the source code you're creating? I don't think input and output be considered separate things.

Your IDE converts keyboard shortcuts to a graphical representation of the program code, right? Thus, the input is text, the output is an image. I don't really see the connection between those two.

In that case, the input for a game like Quake is "text" (and not keypresses) - mostly strings of text like "wasd dssdwsa". Therefore Quake is exactly the same as the old text adventure games ("You are in a maze of twisty little passages, all alike"; "get log", "go north").

It normally takes me a while just to understand the directory structure and get the big picture.

Well, so far I couldn't see the point where your programming language would abandon directories or anything like it in favor of a structure to be understood more easily. I guess you'd use a big diagram which connects all the single parts of a huge project. If that is the case, it does not keep anyone from choosing a bad structure anyway. In fact, such a structure could easily be accomplished through directories in the first place (and probably symlinks). If you don't find what you're looking for in such a directory structure, I guess no other tree-like structure could help to solve it – while trees are obviously one of the best ways of organizing data. Maybe a tag or hyperlink system could perform better, but overall it's probably best to implement such hyperlinks in IDEs without affecting the basic file system structure (as pointed out by Griwes).
tl;dr: I doubt whether this is a problem inherent to existing programming languages but is rather the result of a lack of organization skills inherent to existing programmers.

May I assume that you've never actually seen a class diagram?

Just in case, here's a random one Google found:

By allowing triangles to be textured, all of the problems with the original idea vanish. It complicates the renderer (which is what I wanted to avoid), but for performance reasons it's a necessary compromise. Basically you end up with an image built out of triangles, where each triangle may be a solid colour, a gradient, or a texture.

I don't see how this eliminates the differentiation between lossy and lossless compression. As you probably know, textures are just raster graphics, thus, their compression may in turn be either lossy or lossless.

It doesn't eliminate the differentiation between lossy and lossless compression; it eliminates the need for users to choose one or the other.

To convert vector graphics into this format you do tessellation to turn it into triangles.

Actually, I would generally propose you take an existing vector format and allow at least some primitives (such as triangles or rectangles) to be textured. I don't think many people will be too glad if you convert their bezier curves into triangles (probably it will consume more space, too).

Any shape with more than 3 vertices adds too much complexity to the renderer, which is already far too complicated.


Cheers,

Brendan

[Kevin]

Do you ever write software without looking at the source code you're creating? I don't think input and output be considered separate things.

Yes, you need both; and no, it's not the same. Output is generally much more complex than input, because input is what you as a user have to generate with your limited input devices, and output is what the computer generates so much faster than you could. This is why want to only press 'w' to create a while loop (instead of dragging an icon to the right place or even painting the icon yourself on a tablet), and still expect the IDE to make nice graphics out of it.

I like your comparison with calling Quake a text adventure. You've ridiculed your own position with it.

It normally takes me a while just to understand the directory structure and get the big picture. Then I end up spending more time just trying to decode the source (finding where functions are and what they actually do, finding pieces hidden in header files, etc). Bochs isn't too bad (it's fairly logical), but I've never become familiar with it enough to avoid getting frustrated and resorting to "grep some_function_that_could_be_anywhere".

Get an editor that deserves this name; I for one use vim and it works fine. I often use grep to find the initial point from which I start to explore the code (in other cases I just start at main()), and then I use the editor's functionality to navigate through the code.

I actually did this fairly often with software that I've never seen before. Basically for any software I ported to tyndur when it wouldn't run correctly on the first attempt.

I was suggesting that you build:
1. A compiler for your language written in C for Linux
2. A compiler for your language written in your language for Linux (this port is manual work and is an unavoidable step in bootstrapping)
3. A compiler backend for your OS
4. A native compiler for your OS (for the greatest part, this should just work by recompiling)

The problem with your step 2 is that I have no desire to build applications for Linux or support things like the Elf file format. For this reason:
1. A compiler in C for Linux that generates native executables for my OS
2. A native compiler for my OS in my own language (compiled with the first compiler).
3. Compile the native compiler on itself

Of course this still adds up to "write the same compiler twice in different languages".

Yes, this works too. My approach is probably better when you need a step 3b, which is to write more parts of a cross-toolchain that could be reused for the native build environment, like in a classical environment assembler and linker. I'm not sure if you need any.

Basically; there is no "lossy vs. lossless vs. vector graphics" choices and there are no subformats either. If you want to call it a container format (something that contains triangles and texture data), that's fine.

So you basically convert everything to vector graphics, with only one type of objects. Valid approach in principle, but how large do such files get? Can you compress it at least as effectively as lossless bitmap formats?

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.

Whether a program finishes its work after one minute or after five minutes is already a difference in behaviour in my book. Of course, it will also influence other things: Maybe it's just that the ETA and bandwidth display prints different numbers (and who knows, maybe it divides by zero if it goes too fast?), maybe it's that the game computes more frames, and so forth. It should be obvious that such changes may have many implications.

Those examples are all "case 2, logic errors". If your application crashes due to a division by zero bug (because something was too fast) then it shouldn't be hard to track down the cause.

It's the first type of timing bugs that matter most - the hideous "Heisenbug" caused by an overlooked race condition or something.

You called them trivial logic errors that are easy to debug. I don't quite agree with this. The division by zero is a really trivial one, true, still it's a significant difference in behaviour if it happens or not. The additionally computed frame in the game should be very obvious to not be trivial any more. If this causes a difference in behaviour somewhere, the effects could become visible only a while later. Your case 2 certainly does include some heisenbugs as well.

May I assume that you've never actually seen a class diagram?

Okay, and now back to your examples... Imagine a complete class diagram for the Linux kernel whose directory structure you deem too complicated. I'm pretty sure you wouldn't see the wood for the trees and the class diagram would make things only worse.

[Combuster]

Imagine a complete class diagram for the Linux kernel whose directory structure you deem too complicated. I'm pretty sure you wouldn't see the wood for the trees and the class diagram would make things only worse.

That'd be the simplest diagram ever. It's C. Therefore there are no classes</troll>

In all seriousness, Brendan has quite a few good ideas indeed, and I must admit I've incorporated a few of them in my own design. There are also a few things that are just too much of a purist's view to be acceptable (and sometimes not even understandable) to the average software engineer.

Think about it, none of this would be an issue if computers did not exist yet. Brendan's simply changing the rules - or attempting to. It's like the smart kid playing with funny toys in the open, while having a secret underground lab where he can practice being the superhero. We just don't know if he'll come out and show he's the new and improved superman or if he breaks his neck over an physical exercise before that.

[Brendan]

Hi,

Do you ever write software without looking at the source code you're creating? I don't think input and output be considered separate things.

Yes, you need both; and no, it's not the same. Output is generally much more complex than input, because input is what you as a user have to generate with your limited input devices, and output is what the computer generates so much faster than you could. This is why want to only press 'w' to create a while loop (instead of dragging an icon to the right place or even painting the icon yourself on a tablet), and still expect the IDE to make nice graphics out of it.

I like your comparison with calling Quake a text adventure. You've ridiculed your own position with it.

I don't see how this comparison ridicules my position.

Claiming that Quake is a text adventure simply because you can use buttons/keypresses to control "things" you see on the screen is obviously retarded (and was obvious sarcasm). For my IDE, like Quake, you'd be able to use buttons/keypresses to control "things" you see on the screen. For my IDE, like Quake, it would be silly to claim that "using buttons/keypresses to control things you see on the screen" is the same as typing text.

Basically; there is no "lossy vs. lossless vs. vector graphics" choices and there are no subformats either. If you want to call it a container format (something that contains triangles and texture data), that's fine.

So you basically convert everything to vector graphics, with only one type of objects. Valid approach in principle, but how large do such files get? Can you compress it at least as effectively as lossless bitmap formats?

For an unspecified picture with unspecified detail, the difference in file size (and the amount of visible artifacts) between an unspecified lossy format (when set to an unspecified amount of loss) and my format would be a little hard to estimate. When it comes to file sizes and only file sizes (e.g. ignoring image quality), I think PCX wins for compression - the PCX file header is smaller, so when you convert a "many mega-pixel" photo down to one huge pixel the total file size is less than it would've been in other formats.

The only sane way to compare would be to create a graph for each format, with "subjective image quality" on one axis and file size on the other axis; and then compare those graphs. This would still depend on what the images are (e.g. if there's alpha data then the subjective image quality for JPEG is going to be really bad) and how they're displayed (e.g. images might have the same "subjective image quality", until they're scaled up and rendered at strange angles).

May I assume that you've never actually seen a class diagram?

Okay, and now back to your examples... Imagine a complete class diagram for the Linux kernel whose directory structure you deem too complicated. I'm pretty sure you wouldn't see the wood for the trees and the class diagram would make things only worse.

So you're saying I should abandon all of my plans, just in case someone wants to port Linux to my OS(!)?

If the class diagram for a project is too complex, then the project itself is too complex and needs to be split into several smaller projects (e.g. separate processes that cooperate via. IPC).


Cheers,

Brendan

[Kevin]

In all seriousness, Brendan has quite a few good ideas indeed, and I must admit I've incorporated a few of them in my own design. There are also a few things that are just too much of a purist's view to be acceptable (and sometimes not even understandable) to the average software engineer.

I'm not meaning to say that all of his ideas are crap, and for the sake of the discussion I'm consciously taking a more critical position in parts than I really have. I think it's important for ideas, especially for revolutionary ones, to be questioned so that they can evolve. Or just to work out what's the core idea of a new concept, it can often be applied to less (or different) revolutionary approaches as well.

I don't see how this comparison ridicules my position.

Claiming that Quake is a text adventure simply because you can use buttons/keypresses to control "things" you see on the screen is obviously retarded (and was obvious sarcasm). For my IDE, like Quake, you'd be able to use buttons/keypresses to control "things" you see on the screen. For my IDE, like Quake, it would be silly to claim that "using buttons/keypresses to control things you see on the screen" is the same as typing text.

You claimed that input and output were the same thing. So obviously when Quake gets text as input, it must also output only text and therefore is a text adventure. What you really were after, if I understand correctly, was to say that text and keypresses aren't the same; but claiming that Quake outputs key presses doesn't make it much better.

So while there obviously is a connection between input and output, they are most definitely not the same thing. They are completely different media.

For an unspecified picture with unspecified detail, the difference in file size (and the amount of visible artifacts) between an unspecified lossy format (when set to an unspecified amount of loss) and my format would be a little hard to estimate. When it comes to file sizes and only file sizes (e.g. ignoring image quality), I think PCX wins for compression - the PCX file header is smaller, so when you convert a "many mega-pixel" photo down to one huge pixel the total file size is less than it would've been in other formats.

The only sane way to compare would be to create a graph for each format, with "subjective image quality" on one axis and file size on the other axis; and then compare those graphs. This would still depend on what the images are (e.g. if there's alpha data then the subjective image quality for JPEG is going to be really bad) and how they're displayed (e.g. images might have the same "subjective image quality", until they're scaled up and rendered at strange angles).

Eh, yes. I was asking about lossless, but you're right that even there it depends on the image. I'm really just interested how it works out in "typical" cases. For example, how big would one of the smilies in this forum get? And what about a random photo of a landscape somewhere on the net? So I'm just looking for a comparison with gif/jpg/png on a handful of examples. If I understood right, you already put some effort into this format, so I'd expect you have a prototype that could be used to check it?

May I assume that you've never actually seen a class diagram?

Okay, and now back to your examples... Imagine a complete class diagram for the Linux kernel whose directory structure you deem too complicated. I'm pretty sure you wouldn't see the wood for the trees and the class diagram would make things only worse.

So you're saying I should abandon all of my plans, just in case someone wants to port Linux to my OS(!)?

Neither am I saying that you should abandon anything nor am I talking specifically about your OS. But Linux qualifies as an example for a rather big project, so it should be an interesting case when we're talking about software projects in general.

If the class diagram for a project is too complex, then the project itself is too complex and needs to be split into several smaller projects (e.g. separate processes that cooperate via. IPC).

So you're claiming that process = project?

And wouldn't you just move the complexity out of the class diagram without really getting rid of it, so that you now need a diagram across multiple projects in order to understand the relationships between the projects?

[Brendan]

Hi,

Claiming that Quake is a text adventure simply because you can use buttons/keypresses to control "things" you see on the screen is obviously retarded (and was obvious sarcasm). For my IDE, like Quake, you'd be able to use buttons/keypresses to control "things" you see on the screen. For my IDE, like Quake, it would be silly to claim that "using buttons/keypresses to control things you see on the screen" is the same as typing text.

You claimed that input and output were the same thing. So obviously when Quake gets text as input, it must also output only text and therefore is a text adventure. What you really were after, if I understand correctly, was to say that text and keypresses aren't the same; but claiming that Quake outputs key presses doesn't make it much better.

I didn't claim they are the same thing. What I said was:

Do you ever write software without looking at the source code you're creating? I don't think input and output be considered separate things.

Unless you've got a photographic memory, never make mistakes and only work solo; it's impossible to efficiently write software without viewing the source code. To efficiently write software, you need to be able to see what you're doing while you're doing it - a person can't do input and output separately. For example, you can't do input on Mondays and Wednesdays with your monitor turned off; and view output on Tuesdays and Thursdays with your keyboard and mouse unplugged.

When designing a user interface; it would be silly to assume the user will be doing input and output separately; and silly to design "input" without considering how output will be done, and silly to design "output" without considering how input will be done. It's one feedback loop (screen -> eyes -> brain -> fingers -> keyboard -> screen -> eyes -> brain), not separate unrelated things in isolation that can be designed separately.

For an unspecified picture with unspecified detail, the difference in file size (and the amount of visible artifacts) between an unspecified lossy format (when set to an unspecified amount of loss) and my format would be a little hard to estimate. When it comes to file sizes and only file sizes (e.g. ignoring image quality), I think PCX wins for compression - the PCX file header is smaller, so when you convert a "many mega-pixel" photo down to one huge pixel the total file size is less than it would've been in other formats.

The only sane way to compare would be to create a graph for each format, with "subjective image quality" on one axis and file size on the other axis; and then compare those graphs. This would still depend on what the images are (e.g. if there's alpha data then the subjective image quality for JPEG is going to be really bad) and how they're displayed (e.g. images might have the same "subjective image quality", until they're scaled up and rendered at strange angles).

Eh, yes. I was asking about lossless, but you're right that even there it depends on the image. I'm really just interested how it works out in "typical" cases. For example, how big would one of the smilies in this forum get?

For one of the forum smileys it depends on how it's encoded. For a pair of textured triangles it'd be the same quality (e.g. almost always look like crap due to scaling/transforming) and the file size would be about 4 times as much (mostly due to headers, etc; not the texture data itself, as it's a very small image). For "no textures" (solid and gradient triangles only) it'd be far better quality after rendering and the file size would be about twice as much as the original GIF (again, it's a very small image).

If the same smiley was a 100*100 GIF (more pixel data), then the original GIF would probably be 10 times what it is now, the "pair of textured triangles" would be a little larger than the "100*100" GIF, and the "no textures" version would be much smaller than the "100*100" GIF.

Of course nothing prevents the raw files from being compressed (e.g. using a lossless compression, like gzip). If someone attempts to open a compressed file as an image, then VFS does automatic file format conversion (decompression).

And what about a random photo of a landscape somewhere on the net? So I'm just looking for a comparison with gif/jpg/png on a handful of examples.

I don't know - would the top half of the picture be shades of blue (that can be converted into "gradient triangles" very efficiently), or would the photo have tall trees in the foreground (e.g. lots of fine detail/tree leaves)?

How much do users care about file sizes? How much do users care about things like image quality (after rendering) and rendering speed?

If I understood right, you already put some effort into this format, so I'd expect you have a prototype that could be used to check it?

I put effort into a slightly different "triangles only, no textures" format; and while I do have a "triangles to bitmap data" renderer for that format I never really perfected the opposite "bitmap data into triangles" conversion. I'm convinced I can solve the problems with the "bitmap data into triangles" conversion, and convinced the conversion will always be expensive (in terms of CPU time). I'm also fairly sure that the very high numbers of triangles necessary to avoid textures is going to cause performance problems for things like GUI rendering (e.g. a desktop full of windows with many pictures per window and millions of triangles per picture) and would have made it virtually impossible to do real time rendering in software while supporting other (unrelated) features.

So you're saying I should abandon all of my plans, just in case someone wants to port Linux to my OS(!)?

Neither am I saying that you should abandon anything nor am I talking specifically about your OS. But Linux qualifies as an example for a rather big project, so it should be an interesting case when we're talking about software projects in general.

I'm not talking about software projects in general - I'm talking about software projects for my OS (which is an OS motivated by a desire to abandon the existing "IT industry puke-fest", including "software projects in general" ).

If the class diagram for a project is too complex, then the project itself is too complex and needs to be split into several smaller projects (e.g. separate processes that cooperate via. IPC).

So you're claiming that process = project?

For my system; there are only processes/projects. What you think of as "an application" is multiple processes/projects - some that are internal and some that are public (named services).

For example, a spreadsheet might have a "front-end" process (the user interface) and a "back-end" process for each spreadsheet you're using. The back-ends might use a "maths" named service for calculating values in cells, and a "spell check" service for checking spelling.

If you start the spreadsheet application and open 3 spreadsheets, then you might end up 7 processes (a front-end, 3 back-ends, 2 maths services and one spell check service). It's intended as a distributed system - you might end up with the front-end running on the computer attached to your keyboard, 2 back-ends and a maths service running on a second computer, and one back-end and another maths service running on a third computer. The spell checker might be running on a fourth computer, and it might be being used by your spreadsheet and some other user's word-processor.

And wouldn't you just move the complexity out of the class diagram without really getting rid of it, so that you now need a diagram across multiple projects in order to understand the relationships between the projects?

No; you only need defined messaging protocols between processes/projects.

Could you write an FTP client without the class diagram (or source code) for an FTP server? Could you write an FTP server without the class diagram (or source code) for an FTP client? You only need a defined network protocol for these things.


Cheers,

Brendan

[Griwes]

Could you write an FTP client without the class diagram (or source code) for an FTP server? Could you write an FTP server without the class diagram (or source code) for an FTP client? You only need a defined network protocol for these things.

So, IPC even where it would make much more sense to do just a function call, and places where function call would be faster etc.? Just because *you* think that everything should be IPC, you think everyone else would be happy with creating IPC protocol, instead of *just* calling a function?

Oh, and don't get me wrong; separating some things can be quite good, like that spell-checking example; but you cannot make it a rule just because you'd like to follow pure µkernel design. Don't force end-users to follow all of your *kernel* design choices when writing *their* userspace programs; that would buy you nothing. You might have stated that "giving choice is design failure" (I know, I paraphrased that a bit ), but I think quite opposite: giving choice is equal to giving freedom. Think about closed platforms; wouldn't people like them more if they were able to change everything, and have complete control over what they are doing? I think *freedom of choice* is much more important that following rule of avoiding feature creep... especially when that feature creep is in your imagination and you call every place where user is given a choice a "feature creep"*.


---

* I think you didn't "feature creep" phrase in this thread, but I think it quite fits.

[Brendan]

Hi,

Could you write an FTP client without the class diagram (or source code) for an FTP server? Could you write an FTP server without the class diagram (or source code) for an FTP client? You only need a defined network protocol for these things.

So, IPC even where it would make much more sense to do just a function call, and places where function call would be faster etc.? Just because *you* think that everything should be IPC, you think everyone else would be happy with creating IPC protocol, instead of *just* calling a function?

So, with a FTP client on a computer on one side of the internet and an FTP server on a computer on the other side of the internet; you want to use a function call? With a "front-end" on a computer on one side of a LAN and a "back end" on a computer on the other side of the LAN, you want to use a function call? Perhaps you're saying that distributed systems shouldn't actually be distributed?

Don't force end-users to follow all of your *kernel* design choices when writing *their* userspace programs; that would buy you nothing. You might have stated that "giving choice is design failure" (I know, I paraphrased that a bit ), but I think quite opposite: giving choice is equal to giving freedom.

I'm glad you feel this way. I expect you to give users of your OS the freedom to choose any/all of my kernel API functions, my messaging protocols, my file formats, my file systems, my programming language/s, my network protocols, etc. Let me know when you're ready to start implementing all of this. Thanks.


Cheers,

Brendan

[Griwes]

Hi,

Could you write an FTP client without the class diagram (or source code) for an FTP server? Could you write an FTP server without the class diagram (or source code) for an FTP client? You only need a defined network protocol for these things.

So, IPC even where it would make much more sense to do just a function call, and places where function call would be faster etc.? Just because *you* think that everything should be IPC, you think everyone else would be happy with creating IPC protocol, instead of *just* calling a function?

So, with a FTP client on a computer on one side of the internet and an FTP server on a computer on the other side of the internet; you want to use a function call? With a "front-end" on a computer on one side of a LAN and a "back end" on a computer on the other side of the LAN, you want to use a function call? Perhaps you're saying that distributed systems shouldn't actually be distributed?

Don't force end-users to follow all of your *kernel* design choices when writing *their* userspace programs; that would buy you nothing. You might have stated that "giving choice is design failure" (I know, I paraphrased that a bit ), but I think quite opposite: giving choice is equal to giving freedom.

I'm glad you feel this way. I expect you to give users of your OS the freedom to choose any/all of my kernel API functions, my messaging protocols, my file formats, my file systems, my programming language/s, my network protocols, etc. Let me know when you're ready to start implementing all of this. Thanks.


Cheers,

Brendan

C'mon, now you're trolling.

First of all, I was not talking about FTP client-server, only referencing to that part; you really think that any project that consists of few subsystems used *only* by the application itself should be divided into multiple processes? That's what I was talking about.

Next, not everything must be distributed. Your design choices would make every project inherently distributed, even if it shouldn't be. Again, you're not giving end used enough options, in this case you've just decided for the developer that his project *must* be distributed, because if it was put in one project, it would produce too complicated class diagram (WTF?).

Finally, I'm not talking that end-user should choose *your* file systems, programming languages or network protocols. Quite the opposite.

I'm saying *you* shouldn't choose *end-user's* way of programming, format of files, rate of compression in his files etc.

The point is: while writing *your* OS, you have full freedom. Why wouldn't your end-user (that is, the *target* of the OS) be given similar freedom of *choice* (note that you're one of rare people saying that having a choice is wrong)?