Assembler is most diffused language

[oldtobor]

Is assembler the most diffused programming language ? Thinking of all the billion of controller chips in the world, all programmed in assembler, then this must by large be the most diffused language even though it isn't the most popular.

The most diffused would be in order of importance:

 

1) Assembler

 

2) C (only because MS Word and windows is written in it)

 

3) HTML-Javascript (millions of web pages)

 

4) COBOL

 

5) RPG

 

6) Fortran

 

 

This is the list, so then it is best to learn these languages! Any ideas ?

 

Also I heard that it is hard to find RPG programmers, would this be a good language to learn to land jobs ?

[timo]

Never heard of RPG which might be a good hint for its importance. What do you mean by a "diffused language" (non-native english speaker, in case you wonder about my question)?

[oldtobor]

RPG is an IBM AS/400 programming language. Diffused means popular. I would consider popular as meaning 2 different things:

 

1) popular as : number of lines of code of a given language times the number of machines running it. So Assembler may have 1,000 lines for a simple controller application (like cell phone) time number of machines containing the controller. So for assembler 10^3 X 10^10 machines (phones, cars, TVs etc.)

 

2) popular as number of programmers, so in this case HTML-Javascript is probably the most popular.

[Klaynos]

I would consider Assembler as a group of differnt languages, as there are different ones for different chip sets...

 

I would probably say that Java should probably be in there, and HTML should not be as it is just markup... And maybe even perl or python... It depends what you mean...

[oldtobor]

HTML is in there because it is always used together with some Javascript, even if it only contains a few lines of it. HTML all by itself may also be considered a programming language, even though very limited, since you can hyperlink to other pages and sooner or later some pages will have some minimum Javascript.

 

People just don't like the fact that it has become the most popular language after assembler.

[Klaynos]

No I don't consider it a programming language not because it is popular but because it is markup, and it is quite possible to write a nice webpage in html without any JS...

[ashennell]

I met a guy who wrote code for mobiles phones and he said that they mainly use c instead of assembler these days.

 

It's pretty common in univeristies to teach java first because it enforces the object orientated style of programming. People who learn c/c++ first and then write OOP tend not to stick to good programming practise as much. I am NOT saying that everyone who uses c++ wrties messy code but it is easier to ignore OOP in c++.

 

I wouldn't recommend learning assembler as a first language. It's pretty hard going.

 

HTML is not a programming language. it is by definition a markup language. If you look at xml anf html they are just a way of adding semantics to data really.

[oldtobor]

Is HTML programming language ? look it doesn't matter since it along with the dynamic part (HTML+Javascript) or (HTML+PHP) or HTML + visual basic etc. is probably the most popular programming environment ever. I just consider it one language more or less...

 

So you don't think it is worth it to learn RPG and grab some of those jobs that are still asking for it ?

[Klaynos]

I met a guy who wrote code for mobiles phones and he said that they mainly use c instead of assembler these days.

 

It's pretty common in univeristies to teach java first because it enforces the object orientated style of programming. People who learn c/c++ first and then write OOP tend not to stick to good programming practise as much. I am NOT saying that everyone who uses c++ wrties messy code but it is easier to ignore OOP in c++.

 

I wouldn't recommend learning assembler as a first language. It's pretty hard going.

 

HTML is not a programming language. it is by definition a markup language. If you look at xml anf html they are just a way of adding semantics to data really.

 

I agree entirely with you...

 

What programming language you learn and/or use depends entirely on what you are coding. I do mostly web apps and server apps so, php, java and c# using mono are the most usefull languages for me...

[Pangloss]

Just to toss a slightly different perspective out there, I think if your goal is to become a science programmer, high-level programmer, or computer scientist, then Java or C++ is the best place to begin. If your goal is business applications, client-server database work, etc, then Visual Basic .NET is the best place to start. Microsoft is truly the master of low-end, wizard-oriented programming, especially for small businesses, and backs it up with the best knucklehead-level training on the planet.

 

You can do higher level programming in VB as well, of course, but I think if your goal is to learn OOP concepts and programming "best practices", C++ or Java is really better. Computer Scientists should really focus on those languages rather than something like VB, which they could then pick up in a hearbeat if they needed to.

[ashennell]

What programming language you learn and/or use depends entirely on what you are coding. I do mostly web apps and server apps so, php, java and c# using mono are the most usefull languages for me...

 

Agreed. Too many dabates about this and that programming language seem to ignore this fact.

 

If you are a professional programmer then I would think that have a bit of general knowledge about the various languages around is handy. However, if you have mastered one language then learning a new one is quite easy, the underlying concepts are always the same. The most time consuming part of learning to program is all the bloody API's if you ask me.

 

If your aim is being a code guru then maybe it would be wise to learn a functional language and a procedural language. c/c++ (or c#) and ocaml. Functional languages arnt as popular but I think that they can be very powerful once you get to grips with them.

[oldtobor]

So no one knows what to think about learninig RPG ? Companies are still looking for it and since there are fewer and fewer programmers, you could pull it off and gain. Any opinions ?

[ashennell]

RPG is for high-level database access and report generation isn't it? I don't know much about it. It sounds more like a specialised tool rather than a general purpose language.

 

I would say that if you are interested in a careeer in bdms programming then it is worth learning. I know there is quite a bit of money in database programming.

 

If you already know relational database theory + SQL then an extra tool in the area will not hurt i guess.

 

Does anyone know how common RPG is?

[jeremyhfht]

I wouldn't recommend learning assembler as a first language. It's pretty hard going.

 

Well, after finding this forum again in my insanely-long list of dusty bookmarks it's about damn time I made at least one post. However I dislike reviving dead topics...yet this was the only one on assembly I could find.

 

I'm personally learning Assemblers language (also known as Assembly) as a first language. Specifically x86-32 or AMD-32.

Other types of programming languages (and tutorials) tend to utterly and incomprehensibly fail at telling you, or explaining to you, what goes on behind the scenes. I normally see tutorials go to the effect of "Here are 15 commands, I wont tell you what they do behind the scenes, but here they are anyway".

 

It's one of those weird fallacies where in programming they say "start out with something easy to know the basics". Erm, no. You start out by reading as much as you can so you get the basics hammerd into your skull, then learn assembly, then a high-level language. That way you know how it works, what it's doing, etc. It actually makes the end result a lot easier than doing it in reverse.

I also believe it makes for better programmers.

 

Sufficed to say, when you know what's going on behind the scenes, you know how to program better. There is a main reason programmers managed to develop software so well in the days of assembly...they were better programmers.

Now days you have high level languages such as C++ that serves as nothing more than a bloatware-infested programming language. There is, in fact, a saying about C/C++ that has been circulating.

"Real programmers use C. People that like to call themselves real programmers use C++"

 

As an example of bloatware, lets compare C to assembly. In C, "hello world" is about 15kb. In assembly? That same message is 2kb. Now imagine what 1MB of assembly programming would be (granted, depends on what you're doing) in C or C++ (which is even more bloated than C).

 

However, lets look at a very-main advantage of C. C is a Medium Level language, as it allows for code optimization and the person can actually APPLY their knowledge of assembly to it. Whereas in high-level languages, you cannot use assembly or much to the effect of code optimization. At least so I've read/been told.

 

And as for difficulty, assemblers language is fairly easy to learn if you actually somehow manage to find a tutorial and assembler (by some miracle) that doesn't seriously need rewriting.

[Ndi]

Pascal/Delphi, Java/JS, Basic/VB...

 

I guess it depends on the definition of programming language. If it includes scripting, is it pre-compiled? Does it matter? If it doesn't I guess shell scripting is quite high on the list since most people have/use them even without being aware. It also seems to matter how you count. If by usage I'd guess that C is by far the most used since most of everything we run is C. Most likely followed by HTML (if it counts, I wouldn't count it) and J/JS.

 

My (not-so-extensive) search by job offer seem to favour J/JS followed by PHP and other web-based scripts out here.

 

@jeremyhfht: (bit off-topic)

 

Yes an assembled hello world is 2k. However, a C/Delphi "hello world" takes around 2-3 seconds to build. Delphi, for example, being a RAD (Rapid Application Development) tool, you can File> New console application. A new project is created, cursor is positioned into the main sub so you type "Write('Hello World');" and hit F9. Insta-application, just add water.

 

Let us compare time taken to develop a less-than-simple application. Yes there are optimisation penalties, but is this impact worth the time and inherent instability of directly accessing everything? (I'm assuming non-guru here, people that DO make mistakes during a few hundred lines and that use exceptions, e.g.; not to mention stuff like reference counting)

 

I'm not saying it's not all good and I still use inline assembler when needed but since with available tools one can build a hello world within 9K and within 3 seconds it's not all bad. I did some ASM optimisations as well and I got this:

 

* Unoptimised: 70.000 items/sec

* Optimised by compiler: 250.000

* Optimised by compiler + my help (loop unrolling, variable storing, etc): 300.000

* ASM-aided: 320.000

 

It is more than one person's opinion that anything over 10% is not to be expected from direct assembler over code optimisation unless the code was bad to begin with. And while size is impressive for a hello world, it tends to lose edge when working with larger applications that actually use the bloatware. The larger it grows, assuming correct code, the more efficient it becomes, by reuse of bloatware (which is the purpose of building it into everything in the first place). One line takes 15K, but with 1.5M one can have 100.000 lines of code working behind it (I'm including on-the-fly compression here). Even without compression, I get 34 bytes/line on one of my projects.

 

Also, optimisation is predictable and you can "help" the compiler. For example, I := I * 2 is slower than I := I shl 2; because the SHL actually translates into a SHL instruction.

 

Not to mention portability. ASM is most likely the least portable ever whereas Delphi (not to mention C) can be convinced to move not only over to another OS but architecture with little to no modifications to the code if needed be.

 

I agree that in certain environments, such as microprocessors, assembler is a huge plus, but given the option I use C, even with 2K of code memory available.

 

My POV aside I DO agree with the backwards-learning and tutorial bits.

[doG]

Job matches at Dice.com

 

1) Assembler - 12

2) C - 221

3) HTML-Javascript - 444

4) COBOL - 503

5) RPG - 215

6) Fortran - 23

 

 

Language diffusion vs demand do not seem to be correlated.....

[jeremyhfht]

@jeremyhfht: (bit off-topic)

 

Yes an assembled hello world is 2k. However, a C/Delphi "hello world" takes around 2-3 seconds to build.

 

I never said anything about development time, now did I? It's common sense to know that higher level languages have better development time. I mean...they're designed for...*GASP* development!

 

 

I'm assuming non-guru here, people that DO make mistakes during a few hundred lines and that use exceptions, e.g.; not to mention stuff like reference counting

 

You've inadvertantly proven my point about assembly. Due to such a high chance of making a mistake, programmers had to do their damndest *not* to make a mistake with assembly. Overall, programmers in the days of assembly were better programmers. Not just for the mistakes reason, either.

 

 

Not to mention portability. ASM is most likely the least portable ever whereas

 

Erm...I think I mentioned ASM isn't portable. If I didn't I will now: ASM depends fully on CPU architecture. It's not portable.

 

In my post I was mentioning superiority over other languages in sheer programming. Not development time, portability, etc. I believe you may have misunderstood the intent.

[Ndi]

In my post I was mentioning superiority over other languages in sheer programming. Not development time, portability, etc. I believe you may have misunderstood the intent.

 

I did no such thing. I was simply making a counterpoint as you posted about higher level languages as being bloated and used a one-liner to prove it. I feel that "bloated" should be "featured" or "with helpers" since they are not clogging anything until you use them. One of the true beauties of OO development is that you can virtually bloat it to infinity and you still get decent efficiency - given accurate knowledge of how to use it. One of the bad things is that it tends to be too much for small applications, since it tends to work in "steps".

 

You say in your post that "You've inadvertantly [sic] proven my point about assembly". I didn't inadvertently prove anything, since I did not disagree. My point was that while you are correct you tend to see only one side of things, not both. Unless you consider that ASM programmers NEVER make mistakes they need to debug, in which care we do disagree. I hope I understood "sheer programming", I assumed you mean control over the result.

 

You say that assembler builds character because it's damn hard. I said that being not-so-damn-hard and having a compiler looking over your shoulder saves loads of time and opens a door for less than gurus to write software. That's why we have free tools, millions of various applications, etc. Yes you are forced to concentrate harder. It's like building -say- a car atom-by-atom. Granted you get a better car, but you only get 5. Computer-design it and robot-build it and you get a billion. Not as good, granted.

 

It's about being good enough. Yes executables are large and somewhat inefficient but it's a small price to pay. Many, many things were born simply because they were easy enough to sketch and build; they would have otherwise not existed. Point being that having a fly swatter that swats 99.9% of the flies it's thrown at but costs 500$ is a bust. One that swats 98% of the flies for 50 cents is way better. That's the point we disagree in, really. I say that the 98% swatter is better because it swats 50 billion flies a day. So while I agree that ASM gives you better control, it's quite a long way from being superior in sheer programming (or any kind of programming other than localised optimisations of tight loops or limited-environment devices) as it fails to keep up. Also, old-time programmers were better programmers by average, but it's like saying that olympic runners 20 years ago were on average better than today's runner because you include joggers. Yes they were but you shouldn't be comparing the averages.

 

Ah, and one more point I'd like to make: All this inefficiency has a good part after all. If all executables were under a MB, all images were tightly packed and the OS still ran in 1 MB or RAM, computers would have never evolved to this level since it really is pointless to push for a 4GHz, 4 GB RAM, 400 GB storage when there is no market to it. Unintentional as it is.

 

P.S. The point of overall efficiency is partly covered here but I'm too late somewhere to rewrite the post, sorry.

[jeremyhfht]

My point was that while you are correct you tend to see only one side of things, not both.

 

Wait, I only see one side of things not both? You've just generalized my entire behavioural pattern based on one post. I could have made a side-by-side comparison, but I only mentioned points where assembly is superior.

 

If it's one sided to show some good points about a language, then attack a few points some people believe is "superior" about another, then fine. You've called yourself one-sided. I'm really not sure what the hell you're getting at.

 

I said that being not-so-damn-hard and having a compiler looking over your shoulder saves loads of time and opens a door for less than gurus to write software.

 

And now you know why most software sucks. The "less than gurus" tend to know less about what they're doing. In the proccess they make less-than-good programs (in fact most of them are absolutely hideous).

 

Also, leave development time out of this. My statements say nothing about superior development time.

 

That's why we have free tools, millions of various applications, etc. Yes you are forced to concentrate harder. It's like building -say- a car atom-by-atom. Granted you get a better car, but you only get 5. Computer-design it and robot-build it and you get a billion. Not as good, granted.

 

But those people that DID build it atom by atom know an infinite more than those that just threw it together. You have 5 cars, and a ton of knowledge to start building cars faster and better. woo.

 

That's the point we disagree in, really. I say that the 98% swatter is better because it swats 50 billion flies a day. So while I agree that ASM gives you better control, it's quite a long way from being superior in sheer programming (or any kind of programming other than localised optimisations of tight loops or limited-environment devices) as it fails to keep up.

 

That's like saying it's better to buy swords that are factory made (aka: wall hangers) over hand-made ones. The wall-hangers fly appart rather quickly.

Also, you're going off on your own tangent here. Assembly gives you better control, smaller, faster, cleaner, etc. Also more knowledge of how it works.

Higher level languages: Faster development time, slower programs, relies fully on hardware advancements to keep up with the size increasements, etc.

 

I think assembly wins. Yet again, (must I repeat myself?) I mention nothing of assembly being faster. I will say, and as the evidence so far has shown, assembly is superior. Which is why my "argement" is aimed at people learning assembly first so they get a better idea of what the hell they are doing.

 

Let me use the sword example again: Factory made swords are made very quickly, but break very easily.

 

Hand-made blades are made very slowly, but can cut a tank in half.

 

Yeah, hand-made blades are better. Yes that's an exaggeration, but I believe you are being far too forgiving in your comparisons. it isn't 98% vs 99%. It's 50% vs. 99%.

 

Also, old-time programmers were better programmers by average, but it's like saying that olympic runners 20 years ago were on average better than today's runner because you include joggers. Yes they were but you shouldn't be comparing the averages.

 

No, see, I should be. "old-time" programmers were better by average because they had to know what they were doing. Which is another reason assembly should be learned first.

 

However, running and jogging are entirely different. You compared apples to buicks there. I'm not sure how the comparison even *works*. Do explain.

 

Ah, and one more point I'd like to make: All this inefficiency has a good part after all. If all executables were under a MB, all images were tightly packed and the OS still ran in 1 MB or RAM, computers would have never evolved to this level since it really is pointless to push for a 4GHz, 4 GB RAM, 400 GB storage when there is no market to it. Unintentional as it is.

 

Stop. Putting. Words. Into. My. Mouth. Enough straw-man tactics. I have conceded (repeatedly!) that development time is needed and superior in that aspect. Yet you seem to be focused on development time alone rather than my other statements.

 

Now let me explain this: As hardware improves, software becomes less compact (since it doesn't need to be compact). Programs become larger, and extra-features can be thrown out.

However at the same time less needs to be known about the finer-details. Less and less people know what they're doing at base levels and tend to make more and more mistakes (since the hardware can handle those mistakes, oh well!). There isn't a "requirement" for good programming. The more hardware can handle insanely large software, the less programmers will be required to be good at.

 

And, presently, despite all the development time current languages bring, companies have this policy (mostly microsoft): It compiles, SHIP IT! (this is because most OS's shipped by microsoft aren't really "completed" until SP1).

 

P.S. The point of overall efficiency is partly covered here but I'm too late somewhere to rewrite the post, sorry.

 

Development time doesn't mean superiority (I'm repeating myself again! Yay!). It just means development time.

 

Also, that link basically says what I've bene saying (another note: I've been saying nothing about superior development time! Maybe if I repeat that enough...)