OSDev.org

Griwes wrote:Next, not everything must be distributed. Your design choices would make every project inherently distributed, even if it shouldn't be.

But it wouldn't hurt if technology is advanced enough that the overhead become neglectable - I'm talking about 10 years later.

A simular case is that OS starts to force(or encourage) application to use GUI.

Brendan wrote:

Kevin wrote:

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

What reasons do you have to believe that software projects for your OS will be so fundamentally different that everything that has been found to be true of software projects across all other platforms for the last 50 years or so isn't valid for them?

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

Okay, we have a different understand of the term "project". For me a project is the organisation in which people work together to achieve some goal. This might correspond to the scope of "applications" in your terminology, or even involve multiple applications.

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

Let's say the project (in my terminology) involves some web frontend with JavaScript code, some AJAX, you have a web server that accesses several databases and communicates with servers of other installations of the same software, and for some reason besides SOAP messages it also uses FTP to transfer data. Knowing the FTP protocol may or may not be useful information depending on what you look at in this system. What it doesn't do is give you an overview of the architecture of the whole system, like what a class diagram would give your for a single project (in your terminology) to a certain degree.

Just for the sake of completeness:

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

Feel free to assume it, but your assumption would be incorrect. In fact, I heard a lecture about UML diagrams (and class diagrams as an obvious subset) just last semester, and if I may believe the results of the exam afterwards, I know them quite well.

I didn't talk about class diagrams because I deemed them to be far too fine-grained for managing a complete project. Thus, I was talking about “some kind of diagram” in general (and basically I was correct). I would now ask for a class diagram of the Linux kernel, if Kevin hadn't done so before.

If you really were to use class diagrams for the whole structural organization, this would imho greatly restrain your freedom of implementation, since you would always be forced to implement all classes in a tree-like hierarchy in order to not completely lose track. I guess you now would argue “such designs are the better ones anyway” and you may be right. At least, I don't feel too inclined to argue with you on that point.

Brendan wrote:I'm not talking about software projects in general - I'm talking about software projects for my OS

Well then, why did you take the Linux kernel as an example in the first place?

Hi,

XanClic wrote:If you really were to use class diagrams for the whole structural organization, this would imho greatly restrain your freedom of implementation, since you would always be forced to implement all classes in a tree-like hierarchy in order to not completely lose track.

Why? There's no need for class diagrams (or something like it) to be hierarchical.

XanClic wrote:I guess you now would argue “such designs are the better ones anyway” and you may be right. At least, I don't feel too inclined to argue with you on that point.

Well no, a tree-like hierarchy of classes would be just plain broken.

XanClic wrote:

Brendan wrote:I'm not talking about software projects in general - I'm talking about software projects for my OS

Well then, why did you take the Linux kernel as an example in the first place?

I used Linux as an example of "plain text files in directories don't make it easy for people to understand the big picture". Class diagrams are one way to make it easier for people to understand the big picture (e.g. the relationships between classes). Splitting large monolithic things into smaller separate things is a way of making sure the big picture isn't too big.


Cheers,

Brendan

Brendan wrote:I used Linux as an example of "plain text files in directories don't make it easy for people to understand the big picture". Class diagrams are one way to make it easier for people to understand the big picture (e.g. the relationships between classes). Splitting large monolithic things into smaller separate things is a way of making sure the big picture isn't too big.

Except the spreadsheet app is probably still monolithic even though it's multiple processes (and I may want a diagram which shows what class in process A talks to a service in process B)

Hi,

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

For an OS that supports multiple CPUs; software should try to spread load across multiple CPUs so that the benefits of having more than one CPU aren't wasted. A single thread can't be running on different CPUs at the same time; therefore using multiple threads is just common sense in this case.

For a distributed OS; software should try to spread load across multiple computers so that the benefits of having more than one computer aren't wasted. A single process can't be running on different computers at the same time; therefore using multiple processes is just common sense in this case.

I'm not saying that applications should be split into multiple processes just to make the class diagram smaller. I'm saying that applications should be split into multiple processes for other reasons (performance); and that if your process is large/complicated (and your class diagram is large/complicated), then you've probably failed to split the application into multiple processes for other reasons (performance).

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

You're not seeing the irony here?

You're telling me I should have no control over my OS project and that I should just do whatever the potential end user (e.g. you) wants; and that's meant to be "a good idea".

I'm telling you that you should have no control over your OS project and that you should just do whatever the potential end user (e.g. me) wants; and now that our roles are reversed it's suddenly not "a good idea"?

Griwes wrote: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)?

I'm saying that pointless/unnecessary hassle is bad; and that some of the things you call "choices" are what I call "pointless/unnecessary hassle".

For a simple example, for HTML you can choose to use "any" character encoding. Even though nobody cares (and everyone just uses UTF8 or a subset of UTF8); because this choice is allowed all of the tools that deal with HTML need to support any character encoding. The choice (that nobody really cares about) adds up to pointless complexity/bloat throughout all of these tools. If W3C said "for HTML6 and later, all HTML will be UTF8 and there is no other choice" it would allow that pointless complexity/bloat to be removed from all those tools, and it'd be an improvement. Now, why don't W3C do this? Are they pushing hassle onto everyone else simply because they're too incompetent to make a decision?

How about graphics files? Do we really need BMP, JPEG, PCX, GIF, TIFF, RAW, WebP, etc? Is there someone somewhere who is responsible for pushing hassle onto everyone else simply because they're too incompetent to make a decision? Unfortunately, in this case there isn't a single person/group/organisation that is responsible. What if you were creating your own little world, and you were responsible for your little world - would use push hassle onto everyone that chooses to be part of your little world, simply because you're too incompetent to make a decision?


Cheers,

Brendan

Hi,

Kevin wrote:Let's say the project (in my terminology) involves some web frontend with JavaScript code, some AJAX, you have a web server that accesses several databases and communicates with servers of other installations of the same software, and for some reason besides SOAP messages it also uses FTP to transfer data. Knowing the FTP protocol may or may not be useful information depending on what you look at in this system. What it doesn't do is give you an overview of the architecture of the whole system, like what a class diagram would give your for a single project (in your terminology) to a certain degree.

You're right. The IDE should have some sort of "meta diagram" that shows how the individual processes fit together, where you can click on a process within the "meta diagram" to see the class diagram for that process (and click on a method in that class diagram to see the code for that method).

This could probably be extended further - zooming in/out to see more/less detail. Maybe the highest level could be a list of all "meta diagrams" on the system, where you can click one to go down to a specific "meta diagram", then go down to a specific process/class diagram, then go down to an individual method's code, then down to the byte-code for that method?


Cheers,

Brendan

Brendan wrote:Well no, a tree-like hierarchy of classes would be just plain broken.

I'd call it “massive usage of inheritance” and not exactly broken, but well…

Brendan wrote:Class diagrams are one way to make it easier for people to understand the big picture (e.g. the relationships between classes).

This might be true. I doubt it in general, but I would especially doubt it for the way you intend to use class diagrams (i.e., a single one per project) – I am however not sure whether I may do so, since you seem to have an understanding of projects which leads to them being pretty small. Thus, maybe your projects consist of less than ten classes and even I could keep track of everything when looking at their class diagrams. If that is the case, the following argumentation will obviously be not correct, since it assumes having more than a couple of classes per project.

Brendan wrote:There's no need for class diagrams (or something like it) to be hierarchical.

OK, your class diagrams will lack any kind of hierarchical structure. You'll split the whole project into all its classes and present them with equivalent importance.

Brendan wrote:I used Linux as an example of "plain text files in directories don't make it easy for people to understand the big picture".

I already argued that I think this is because of a poor choice of directory naming, but in any case this structure allows at least some kind of hierarchy.

Brendan wrote:Splitting large monolithic things into smaller separate things is a way of making sure the big picture isn't too big.

I'd like to change this to “splitting large monolithic things into not too many smaller separate things […]”. If there was a project written in an object-oriented language of similar complexity as Linux with all files contained in the root directory (where each file contains a single class) and an image containing a class diagram, I guess I'd lose my mind instantly. But if the project was split into several “subpackages” and these are in turn split into packages and so on, it would be a lot easier to understand – at least for me.¹
tl;dr: Personally, I get easily confused without any kind of hierarchy in large projects. If that is not the case for you, I greatly envy you.

Therefore, the class diagrams you intend to use will probably help me not at all.

However, you yourself admitted indirectly with that last quote that the old directory system is not inherently bad: Directories indeed are one way of splitting large monolithic things into smaller separate things.

———
¹Maybe this is just what you'd define as a project: A thing which I'm here calling a “package”.

———
OK, I just read your next to last post and I think it clarifies some things. You don't intend to write an OS and an IDE (structuring projects through their class diagrams only) for use by others but by yourself only. Actually, I now don't see why I have been arguing with you anyway. If you like such structuring, there is of course no point in telling you that I don't like them. At least, if you don't care what others think about it. And this is obviously completely understandable: You're designing a system which you (and some or many others thinking the way you do) want to use.
This also makes clear why you don't want any of the existing e.g. image formats but create one instead which in some way unites them all. If you don't see why many people even bother to choose between JPEG, PNG, SVG and many others, there is no point in telling you to let the user choose – since that user will be you (and others thinking the same way, as said before).

(And please, don't get me wrong (because it sounds somehow ironic when I read it again): I really understand such choice.)

Brendan wrote:This could probably be extended further - zooming in/out to see more/less detail. Maybe the highest level could be a list of all "meta diagrams" on the system, where you can click one to go down to a specific "meta diagram", then go down to a specific process/class diagram, then go down to an individual method's code, then down to the byte-code for that method?

I guess so. In fact, I think something like this is inevitable if you want to keep things managable.

Hm, heretical question: Would this end up being what other people tend to call a file system?

Hi,

Kevin wrote:

Brendan wrote:This could probably be extended further - zooming in/out to see more/less detail. Maybe the highest level could be a list of all "meta diagrams" on the system, where you can click one to go down to a specific "meta diagram", then go down to a specific process/class diagram, then go down to an individual method's code, then down to the byte-code for that method?

I guess so. In fact, I think something like this is inevitable if you want to keep things managable.

Hm, heretical question: Would this end up being what other people tend to call a file system?

Let's have a concrete example. Let's say there's 3 different processes (A, B and C) and 3 different protocols (D, E and F). Process A and process B communicate with each other using protocol D. Process B and process C communicate with each other using protocol E. Process C and process A communicate with each other using protocol F. Note: this might be easier to visualise if you draw it on some paper!

For the "meta diagram" - you'd have boxes representing processes (that you can click on to see the class diagram), and lines between the boxes representing messaging protocols (that you can click on to see the definition of the messaging protocol).

Now try to explain how you'd force this "round peg" into your file system "square hole". What would the directory structure look like?


Cheers,

Brendan

I'm not necessarily saying that it's a strictly hierarchical file system. You do have a directory hierarchy in the sense that each project (file) or meta diagram (directory) has a parent, up to some root meta diagram. What's different from a classical file system is that you don't only have a list of files in each directory, but that you have additional structure by modelling relationships between these files.

Maybe this turns out to be useful even outside the context of software projects?