OSDev.org

Antti wrote:There is more that. Beginners are also directed to their own playground that contains only toys not meant for any serious work. Advanced programmers keep the keys for their own workplace and think that beginners should be kept away from there. They think it is better to let beginners to be "safe" and make sure beginners would not make their work look bad (e.g. inventing something better).

Interesting you mention beginners. In the last hour I went out and bought(*) an Arduino starter kit for someone I'm going to teach about computers. It seems to be the right kind of toy, fairly similar to the 8-bit machines I learned programming on but with all those GPIO pins!!! It looks like it'll be a "low floor, high ceiling" platform for learning.

Edit: Oops forgot the point of the post. Basically, I think with FPGAs, development boards like the Raspberry Pi and Arduino, and the wealth of info on the net, there is a lot of scope for DIY. It's just a question of motivation I suppose. I think we're definitely heading into dangerous waters where the general public aren't being exposed to general purpose computing machines in the same way we were.

*) Literally walked about 150m into a shop and bought one, no buying on the web and waiting for delivery - amazing what you can get on the high street these days.

My previous post was quite bad if taken out of the context. The main point is simply that beginners should be able to use the same tools as professionals. It is possible if the programming language is easy to learn. I guess Brendan is heading to this direction.

Hi,

Antti wrote:My previous post was quite bad if taken out of the context. The main point is simply that beginners should be able to use the same tools as professionals. It is possible if the programming language is easy to learn. I guess Brendan is heading to this direction.

I like the idea of "Everything should be made as simple as possible, but not simpler."

My language is intended as a low level language (for writing boot code, kernels, device drivers, etc). There are 2 things (pointers and assembly language) that are needed for low level work and can't be removed without making it "simpler than possible". These same 2 things are the only things that make it unsafe, and they also make it "not as simple as possible" for high level work.

My plan is to create a higher level language later on (for things like scripting, etc) by removing assembly language and pointers and adding whatever is needed to fix the problems this causes (e.g. garbage collection); so that the high level language and the low level language are mostly the same where possible. People (beginners) would learn the high level language, and then learn pointers and memory management, and then (maybe) learn assembly.

Now for a few things that might seem strange. First; I've already mentioned elsewhere that the OS will use "file format conversion" to automatically convert files from one format (e.g. source code) into a different format (e.g. native executables). This means that source code can be executed "as is" (where compiling to native is just a side-effect of executing it the first time).

Second; my OS will use a GUI and there won't be any command line. Applications will be split into pieces (processes); including having a "front end" (user interface) process that talks to a "back end" process. These pieces will communicate with messages. If the user clicks on some sort of "record macro" button; then the OS can record the messages sent from each application's "front end" to its "back end" while the user is using applications like normal. When the user stops recording their macro, the recording would be converted into high level source code (mostly a bunch of "send message" calls, although it's not quite that simple). The "macro recording" (which is high level source code) would be used as is - e.g. double click on the recording, and the OS compiles it to native and executes it for you, and it repeats all the actions you recorded (by sending those messages to the application's "back end" without starting the application's "front end" at all). The "macro recording" (which is high level source code) could also be opened in the IDE and edited.

Imagine a normal user (no programming experience) that happens to do the same things relatively often. They're going to record little macros to speed up their work; but (apart from some very simple things) those little macros probably aren't going to be quite powerful enough. They might figure out that (by learning some high level language) they can add dialog boxes or loops or something, and make their macros a bit more powerful and automate more. Then learn some more high level programming, and start improving their code and adding more functionality. Maybe with a few simple functions they can avoid the need to use an existing application's "back end" and speed it up. Maybe their colleagues need something similar so they add some options for a few different cases. Before they realise it, they've written a simple application. As time goes passes they do more, and learn more. Maybe one day they buy some new hardware, find out the OS has currently doesn't support a few devices, and they realise device driver programming isn't much different to application programming and end up writing an ethernet card driver.

The end result is that people accidentally become programmers - not because they feel like spending several years and tens of thousands of $$$ by going to university, but because it's easy.

Of course I am exaggerating here. Some people won't be interested at all, some people might learn a little (e.g. simple macro tweaking) and not learn more. It also won't be that simple to make the transition from "normal user" to "advanced programmer" - they're going to need nice user friendly tools, and example code to learn from, and people to help them, and well written tutorials that explain various things (like algorithms, event based programming, concurrency, etc), and kernel API and messaging protocol reference guides. All of that can be provided easily enough though (most can be part of the default OS installation, half can probably be built into the IDE, etc).


Cheers,

Brendan

Brendan,

Did you ever try things like RPG Maker or Game Maker? Or even the 1997 Java Studio?

Hi,

Combuster wrote:Did you ever try things like RPG Maker or Game Maker? Or even the 1997 Java Studio?

I've tried Game Maker. It seemed reasonable (good for its intended purpose).


Cheers,

Brendan

Brendan wrote:These pieces will communicate with messages. If the user clicks on some sort of "record macro" button; then the OS can record the messages sent from each application's "front end" to its "back end" while the user is using applications like normal. When the user stops recording their macro, the recording would be converted into high level source code (mostly a bunch of "send message" calls, although it's not quite that simple). The "macro recording" (which is high level source code) would be used as is - e.g. double click on the recording, and the OS compiles it to native and executes it for you, and it repeats all the actions you recorded (by sending those messages to the application's "back end" without starting the application's "front end" at all). The "macro recording" (which is high level source code) could also be opened in the IDE and edited.

But what about state? Applying same macros to different states is not a good idea. There should be many constraints and having them create a problem of very simplistic macros. Such simplification may render the macros useless.

Brendan wrote:As time goes passes they do more, and learn more. Maybe one day they buy some new hardware, find out the OS has currently doesn't support a few devices, and they realise device driver programming isn't much different to application programming and end up writing an ethernet card driver.

Device driver is all about good documentation. Is it a common situation when vendor releases good documentation with a new hardware? Also it is interesting - how users can write safe interrupts? How they can access hardware registers? How they can use DMA? It seems that user written drivers will always be a dream (unless some AI will help the user).

Brendan wrote:The end result is that people accidentally become programmers

There are text editors with macro capabilities. For example, the Word or Excel offer Visual Basic in addition, and even some users are trying to use the Basic. But they are very far from writing drivers. In the end the programming won't be less time consuming without very different tools and technologies. The scripting isn't such technology.

embryo wrote:Device driver is all about good documentation.

As is anything other type of program. Device drivers are not special. In fact, device driver development is fairly straight forward.

Here are some of my opinions (subject to change) that may be essential to make a project like Brendan's to succeed.

Target audience. In the long run, programmers should be a minority. Normal users are the ones that will get things rolling so it is extremely important make the system "user friendly". Of course, normal users will learn programming if it is easier but that is not the point here.

Internationalism. The target audience will increase enormously if there are localized versions available.

Organization/company. It would be a lot of easier to get plausibility if there is a real organization or a company behind the project. It does not mean that the OS should be commercial.Note! This assumes that the goal is to grow out from the hobbyism.

Change policy. At this stage it is possible to start from scratch when it is necessary. That is the way to make things right and not get stuck with bad design decisions. However, it is not so simple after people are committed to the OS. Breaking backward compatibility will be very problematic.

Technical superiority. The OS must be technically better than others.

Fascinating. This goes hand in hand with the technical superiority. The OS must be interesting and get attention based on other than technical things. This could be comparable to free software. "The license in itself is interesting". This was just an example.

Reputation. The author must be trustful. Long-term devotion to the project helps a lot. Things like malware would ruin the reputation forever even if it was not related to that specific product.

Antti wrote: Technical superiority. The OS must be technically better than others.

Technical superiority is seldom a critical factor for success. It seems that technically good enough and great marketing makes the sale. Unless of course you're talking game changing indistinguishable-from-magic style technology. That would be different.

...and I just again wrote offtopic in my last post. Things I listed are so self-evident that I now regret the whole previous post. Please skip it as a noise between the signals. However, the "Change policy" is something that really applies to programming languages.

bwat wrote:Technical superiority is seldom a critical factor for success.

A good point. However, it is better to just make it also technically superior. It helps the long-term strategy.

bwat wrote:

embryo wrote:Device driver is all about good documentation.

As is anything other type of program. Device drivers are not special. In fact, device driver development is fairly straight forward.

The software outside of the drivers is a bit different. At least there are some visible entry points with (hopefully) descriptive method names and arguments and the points help even without documentation. But to access hardware it is required to know it's memory addresses and ports - it is impossible to get all those numbers without documentation. Also there is the hardware detection problem (even if we know port numbers). Next goes register content - what numbers should be written there? So, every step just must be documented. With the software libraries life is easier.

Antti wrote:...and I just again wrote offtopic in my last post.

But the point in unions and other stuff is in the improvement of programming. So, it is very hard to draw a line between the topic and off topic here.

Antti wrote:Here are some of my opinions (subject to change) that may be essential to make a project like Brendan's to succeed.

In general it is about new technologies to arrive.

Antti wrote:Target audience. In the long run, programmers should be a minority.

Yes, but unfortunately the efforts required to attract ordinary users are too expensive (time and money).

Antti wrote:Organization/company. It would be a lot of easier to get plausibility if there is a real organization or a company behind the project.

It's just about financial support. For it to be real the system should attract the business attention. And having such attention it is possible to get funding. And having funding it is possible to make features to attract users. And having users it is possible to attract more funding. And so on.

Antti wrote:Technical superiority

It is in fact not so important, I agree with the comments above.

Antti wrote:Fascinating. This goes hand in hand with the technical superiority. The OS must be interesting and get attention based on other than technical things.

It is important point to attract developers. May be it is possible to attract enough developers to create attractive features for ordinary user. Then there could be no dependence on funding. But such scenario is hard to implement.

embryo wrote:

bwat wrote:

embryo wrote:Device driver is all about good documentation.

As is anything other type of program. Device drivers are not special. In fact, device driver development is fairly straight forward.

The software outside of the drivers is a bit different. At least there are some visible entry points with (hopefully) descriptive method names and arguments and the points help even without documentation. But to access hardware it is required to know it's memory addresses and ports - it is impossible to get all those numbers without documentation. Also there is the hardware detection problem (even if we know port numbers). Next goes register content - what numbers should be written there? So, every step just must be documented. With the software libraries life is easier.

You're describing a documentation problem. A badly documented anything is difficult to interface with. This isn't limited to hardware devices that need drivers to be written for them. When you're working with non-desktop PC hardware the amount of documentation available gets better. Manufacturers often give example code for devices. These companies can't make a sale if the buyers can't use it.

Brendan, I think your idea is pretty good. I vaguely remember wanting to do something kinda similar about 6 years ago. So if you do it I would find it extremely cool.

1. Being able to record the interaction between the front end and back end then turn it into programming code is just cool and quite useful in it's self. Kind of like a bash script running on linux.

2. Then having the ability to edit the programming code will surely get normal uses feet wet in programming. Even them just having a glimpse of what the code looks like is a big plus. That is what I feel like happens with Linux. People get to see that shell code and they get interested. Or, they try to fix something and end up learning.

3. A language designed to be easy to use is great, and then having the ability to go low-level is perfect.

4. If all your applications conformed to that specification of being able to drive the back-end directly with out the front end that would be fantastic. That is a problem with applications that are completely GUI driven. It can be very awkward trying to create a macro for them because I think it is just harder trying to iterate through child windows looking widgets or controls and trying to manipulate them.

I think programming should be learned by everyone and WILL be learned by everyone in the future. Computers are just a very powerful device for doing things with and to me it just seems like the natural progression is for people to get more and more advanced and programming (or macro making especially with conditional execution, input operations, and control flow) is essentially the same. You find people everyday wishing they could automate a process at work or at home to make it easier. So that is the direction things are moving in naturally.

<edit>
I just wanted to add that the future of the human race is advancement in technology and skills. That is why I like working on the wiki because it makes it easier for others to go farther. And, the same should happen with an OS. It should provide the users with the ability to advance in the amount and quality of work. It also provides entertainment too, but entertainment is built on the same foundation because someone has to actually program the service or application that provides this to the users. You know I have said this before but if we force each other to go through the same rigorous trials we would get nowhere because they would spend all their time tracing your own steps and generally take the same amount of time. Now, when someone can use your work as a stepping stone they have more time to get further and achieve more.

I do not mind things being easier. The problem is when things get easier and more limited or the removal of functionality. This applies to any type of software or operating system. You want to have the ability for users to only have to tackle what they need but have the option or ability for them to use more advanced features of the software (OS/application/game/tool). So yes programming languages designed around this idea will succeed in that less advanced users can use the language and more advanced users can also use the language. The same is said of applications.

That is the program with C. I love C do not get me wrong. But, it forces you to learn some not only advanced things like pointers but you actually have to manage them and making a mistake can be quite detrimental because of the difficulty of figuring out the bugs it causes. I remember when I started playing with C and found out about the malloc function. I remember people telling me how badly I was going to hurt myself messing with it. Now, if I had listened I would have got nowhere. Just some food for thought. But, the journey was difficult and it took a LOT of time. A language that can give me the power of C when I need it (performance and low level work) yet provide me with a high level environment for less performance sensitive things to reduce how much code I write and how easy it is to create bugs is going to be my language of choice. There exist languages out there right now that do this, but they are bulky and not really usable for everything at least not OS development with out a lot of boiler plate code and foundation code.

But, if Brendan can come up with a language that addresses this problem then I can see myself using it. I personally love Java and C and wish I could more easily combine them. I know the .NET language offers this but it has so much foundation that needs to be in place to use it that it turns me away AND the performance of it is not so great. So I generally prefer Java performance wise and also just having Microsoft's fingers in it (.NET) makes me not like it because I feel like they care more about money than actually pushing the world forward.

So Brendan get to working on it! LOL
</edit>