OSDev.org

What is the probable quantity of programmers that currently are coding in machine code?

For example, only 1 programmer is currently coding in machine code?

2? 5?

What is the probable percentage of programmers that currently are coding in machine code?

1%? 2%?

What is the probable quantity of programmers that currently are coding in Assembly?

For example, only 1 programmer is currently coding in Assembly?

4? 10?

What is the probable percentage of programmers that currently are coding in Assembly?

2%? 4%?

manhobby wrote:What is the probable quantity of programmers that currently are coding in machine code?

For example, only 1 programmer is currently coding in machine code?

2? 5?

All you're likely to get is an uninformed guess. There may be some people writing tiny amounts of machine code for devices with tiny amounts of memory which do very specific things, but most of them will just use assembler instead. For anything bigger and more complex, you need to have some sort of system to automate the adjustments of addresses and jump distances as code is edited (whenever chunks of code or variables get relocated), and that needs an indexing system (which also provides the functionality of a dynamic link library for every piece of code in the machine). I only know of one system that does this, and only one person uses it - it has still not been released in a form that makes it practical for anyone else to join in, and by the time it's been tidied up enough, its designer will no longer be programming in machine code, so this is not a route that you should be looking at.

What is the probable percentage of programmers that currently are coding in machine code?

1%? 2%?

It's so close to 0% that you shouldn't still be thinking about this unless your interest is in writing compilers.

What is the probable quantity of programmers that currently are coding in Assembly?

For example, only 1 programmer is currently coding in Assembly?

4? 10?

I suspect you could multiply that by thousands, but most of them will only be doing small amounts of it while the bulk of their work uses higher level languages.

What is the probable percentage of programmers that currently are coding in Assembly?

2%? 4%?

1% is more likely, and that may be too high. Your research into this is so slow that you're wasting time that would be much better spent on learning to program in multiple ways, though you also need to ask if you're suited to programming at all. How much programming have you done, and which languages have you used for it?

42

DavidCooper wrote: I only know of one system that does this, and only one person uses it

@DavidCooper

Wich is the system that does this?

Who is the person that uses it?

DavidCooper wrote: it has still not been released in a form that makes it practical for anyone else to join in, and by the time it's been tidied up enough, its designer will no longer be programming in machine code, so this is not a route that you should be looking at.

@DavidCooper

Why its designer will no longer be programming in machine code?

DavidCooper wrote: How much programming have you done, and which languages have you used for it?

Few programming in Pascal, Visual Basic, Delphi, C and Java.

manhobby wrote:Which is the system that does this?

Mine.

Why its designer will no longer be programming in machine code?

Because machine code isn't portable. It only makes sense to program in machine code in a big system if you are a compiler, but a compiler should be software rather than a person. My aim from the start has been to replace myself with an intelligent compiler that writes code in the same way I do, except that it should do the job much better than I can - I usually only have time to get routines working, but an intelligent program which crafts its machine code and carries out experiments to optimise it should always produce code that gets the best out of the machine, and it will be able to replace all the code that I wrote with perfect code. There's no point in me spending a year or more tidying up my code when an intelligent system will be able to do that job better within the space of a few hours, so it's better for me to focus all my effort into building the intelligent system. The only reason I ever programmed in machine code was that I wanted to understand how such an intelligent compiler should operate, and the best way to do that was to imagine that I was the intelligent compiler and to work in the way that it would - while doing this, I think a lot about the thinking skills that I use to solve problems and try to work out how to replicate those skills in software so that an intelligent system can carry out the same work in the same way. Once that system is built, there will be no need for me to write in machine code ever again, and the intelligent system will be able to switch to using any other kind of machine code for any other processor, so it will be able to port itself to any new kind of hardware.

There are other people trying to build intelligent systems where the human programmer uses natural language to write programs, but they're building them using higher-level programming languages. I don't think that puts them at any great disadvantage - it's really just a matter of working in whichever way you're comfortable, and for me that happens to be machine code because that's what I used when I learned to program. But there's no future in it for anyone else, and my aim has always been to switch away from it to using natural language, so why would you want to move into a place that practically everyone else has avoided for decades and where the one person who has found a way to make machine code programming practical wants to switch away from using it? You should forget about working in machine code - you need only take a big interest in it if your want to write a compiler.

Few programming in Pascal, Visual Basic, Delphi, C and Java.

Then you should continue to work with those (or the ones that are most in demand), and extend your range by learning one or two other languages that look as if they might become more important in the future. You should maybe do a little work with assembler (just so that you can put that on your C.V. and back it up with proof - even if no one employs you for that ability, it will show that you are versatile and that you can adapt well to different ways of working). Your main priority should be to become expert at using a range of mainstream languages so that you aren't seen as a less capable candidate than your rivals for any job you apply for, and if you also have expertise with a couple of exotic languages which the others don't have, then that will make you stand out above the crowd, but knowledge of machine code and assembler won't impress any employers unless you've already matched everything else that everyone else has. Choosing languages is a gamble, but you can push the odds in your favour by studying job adverts to see the trends - that's something you need to do yourself so that you can see what's in demand where you are. So get on with doing that, then make your decisions, and then commit to them and get on with learning without wasting time looking back. You are in a race against hordes of other people who are learning an extra programming language or two in the time that you're wasting trying to decide which languages to learn.

@DavidCooper: I don't recall if I ever asked you if you have read Massalin's papers on Synthesis OS, and what you think of that. While her intention in using code synthesis is quite different from your goals, it does seem relevant to your work, in much the same way it does to mine.

DavidCooper wrote:But there's no future in it for anyone else, and my aim has always been to switch away from it to using natural language,

@DavidCooper

What is natural language?

Natural language is Assembly language?

Natural language is high-level language?

manhobby wrote:What is natural language?

Languages of the kind that people use to speak to each other, such as English, Chinese, Nahuatl, etc. (although artificial languages like Esperanto would also qualify in this context). Our ultimate aim should be to stop using programming languages and switch to speaking to machines as if they are people, simply asking them to do things and having them understand and act correctly on our requests. Ideally, they should also spot faults in the task they're being asked to do and suggest corrections, and they should also refuse to do anything immoral. All of that needs intelligence in the machine though, and we haven't built enough of that yet to make this a reality, so I'm talking about future developments rather than anything that's available for use today.

DavidCooper wrote:But there's no future in it for anyone else, and my aim has always been to switch away from it to using natural language, so why would you want to move into a place that practically everyone else has avoided for decades and where the one person who has found a way to make machine code programming practical wants to switch away from using it? You should forget about working in machine code - you need only take a big interest in it if your want to write a compiler.

If is truth that practically everyone else has avoided the use of machine code for decades, why I need take a big interest in about working in machine code only if I want to write a compiler?

Schol-R-LEA wrote:@DavidCooper: I don't recall if I ever asked you if you have read Massalin's papers on Synthesis OS, and what you think of that. While her intention in using code synthesis is quite different from your goals, it does seem relevant to your work, in much the same way it does to mine.

Henry Massalin? Ah - Alexia. I''m not going to pretend to understand much of what I've just read. Some of the purpose appears to be to cut out context switches (which I don't have), but quajects may have some connections with an idea that I had a few months ago. I now have noun classes to hold information about what things are (which can be used to produce objects), and verb classes to hold information about how actions can be performed (which can be used in combination with noun classes to guide the generation of procedures to handle specific objects, and these may need to be generated on the fly and then be deleted afterwards to free up space, just as we often have to think carefully about how to carry out an action on an unusual object - this may need a unique procedure to handle it which has never been programmed for before, and you can't store all such procedures permanently). I'm still working on formats for these so that I can build the most important classes and get enough of them together to be able to start building simple programs using them.

manhobby wrote:If is truth that practically everyone else has avoided the use of machine code for decades, why I need take a big interest in about working in machine code only if I want to write a compiler?

For compilers, you don't work in machine code, but work with machine code (meaning that you're writing code at a higher level which will produce the machine code), and you can't do that without knowing a lot about machine code.

manhobby wrote:

DavidCooper wrote:But there's no future in it for anyone else, and my aim has always been to switch away from it to using natural language, so why would you want to move into a place that practically everyone else has avoided for decades and where the one person who has found a way to make machine code programming practical wants to switch away from using it? You should forget about working in machine code - you need only take a big interest in it if your want to write a compiler.

If is truth that practically everyone else has avoided the use of machine code for decades, why I need take a big interest in about working in machine code only if I want to write a compiler?

Well, to be precise, you would need to know about the system's machine code in order to write an assembler, a linker, a linking loader, or a compiler (specifically a compiler which produces native code directly, as opposed to one targeting an assembly language or some other readable language).

Even then, you really would only need to know how to generate the machine code. You wouldn't need to know how to write in machine code yourself.

And for a table-driven assembler or compiler, you wouldn't even need to know the opcodes yourself - you would just need to know how to have the assembler/compiler look the appropriate ones up in the tables. Since most compiler's code generators today are at least partially table-driven, and those which aren't generally target assembly rather than machine code, chances are the ones writing the code generator will never need to look at the opcode tables except when changing the data.

(Furthermore, some which are table-driven, like most GCC back-ends, still target the assembly language in order to avoid redundancy, though those generally can pipe the output directly to their target assembler.)

DavidCooper, many thanks!

All the OS Dev.org Forums moderators will answer all the questions that I posted in this topic?

Schol-R-LEA, Brendan, simeonz, alexfru, you will answer all the questions that I posted in this topic?

iansjack wrote:42

@iansjack

42???

Which is the source of your answer?

manhobby wrote:

iansjack wrote:42

@iansjack

42???

Which is the source of your answer?

I'm sure he put Deep Thought into The Answer.