[SOLVED] Available Computer Languages for Linux (Ubuntu)
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I actually found C fairly easy to learn ... but sometimes _very_ difficult to debug. It allows me to do (almost) everything. At the expense of protecting me from (almost) nothing
Crikey! I'm overwhelmed! I really appreciate all these excellent replies.
Thanks for the gForth link. I'll definitely do some nostalgic(?) tinkering with it.
I've never looked at C++ but have toyed with C in the past. When I discovered Forth, I forgot C (literally.)
Two votes for Lua, eh? Gotta look at that. I'm also curious about Squeak, and why the subject of flashcards brings it up. I've noticed that the word "Perl" never comes up -- just when I was about to try it. Hmmm.
No BASIC bashing please! I worked in QC for a large company that used a lot of VB and I have great respect for it. When VB programmers told my boss that it was impossible in VB to do what she asked, she just had me make up little functioning programs demonstrating her wishes and sent them to those guys (with what comments I hate to think.) They musta hated my guts....nyuk, nyuk....
"stay away from Assembly for X86": I've always loved assembly, especially with the clean little versions embedded in the early TRS machines, but I've already assumed that it gets a little dysfunctional in current, much-developed machinery. I still intend to look at it though, especially if I settle on a language that lets me embed assy snippets.
Caml and Haskell: I'm unfamiliar with their formalized use of the word "functional" but it might be what I'm looking for. (I do read a lot of Francais, mostly fiction, so that adds some jollies to it....) I'm only half-way through the "...for the Masses" article so that's yet another bookmark to follow.
You'd have trouble getting me to try Java, especially since I have no interest in web programming.
Anyhoo, thanks again to everyone. Lots of stuff to look at, to say the least. I have an added distraction with the realization that I have to abandon Ubuntu after many years, as the Mickey-Mouse 11.10 version is colossally flawed, including trying to tear up my hard drive, and I just don't see any chance for it to get fixed via little updates. (sigh) But I'm staying in Linux, for sure.
I appreciate the relocation of my thread -- I wouldn't have been surprised if it had gotten "moved" right out of the forum, but I'm glad to be seeing such good stuff.
...
Two votes for Lua, eh? Gotta look at that. I'm also curious about Squeak, and why the subject of flashcards brings it up. I've noticed that the word "Perl" never comes up -- just when I was about to try it. Hmmm.
...
Perl is my default language, but didn't you want a strictly typed language ?
If you decide to try Perl, remember that it's not "C".
...
Caml and Haskell: I'm unfamiliar with their formalized use of the word "functional" but it might be what I'm looking for. (I do read a lot of Francais, mostly fiction, so that adds some jollies to it....) I'm only half-way through the "...for the Masses" article so that's yet another bookmark to follow.
...
Perl is my default language, but didn't you want a strictly typed language ?
If you decide to try Perl, remember that it's not "C".
I consider that a compliment for Perl (arf?)
...And thanks for the HOP reference. That's sort of got me turned on (mentally, only...) If that makes its functional aspect anything like a code generator, I'm especially interested because I've programmed a lot of code generators in my QC work and found it engrossing.
Geez, you guys are giving me a lot of stuff to check on. Much appreciated....
I've always loved assembly, especially with the clean little versions embedded in the early TRS machines, but I've already assumed that it gets a little dysfunctional in current, much-developed machinery. I still intend to look at it though,
Since you hate C and haven't explained why, I expect you will be severely handicapped in approaching X86 assembler, but I'll try to give some constructive advice anyway.
The most important question before learning X86 assembler is what kind of X86 assembler to learn. There are two dimensions to that question:
A) 16-bit vs. 32-bit vs. 64-bit
One of my sons is taking a university course in x86 assembler. The instructor decided to teach 16-bit x86 assembler writing full DOS programs. My opinion of university professors was always low and CS professors even lower. But this bozo manages to push my opinions even lower. 16-bit X86 is a super quirky assembler language. When it was the language of the most important CPU in use, it was worth the trouble to learn that quirky language even though doing so gave you very distorted views about assembler in general (I once knew every detail of 16-bit x86). Once it was obsolete, teaching it became far stupider than teaching other obsolete languages.
32-bit x86 is still a fairly quirky language and not very representative of assembly language in general. It is now obsolete and is worthless to teach because it is obsolete.
64-bit x86 is a much less quirky language. Programming in assembler at all might be largely obsolete, but knowing 64-bit x86 is a powerful tool for programmers even if you won't directly program in it. There are far fewer online resources and even fewer paper books for 64-bit x86 vs. 32 or 16. That's tough luck. 64-bit is still worth learning. 32 and 16 are not. Go to the extra effort to learn 64 bit x86 or don't go to the effort to learn x86 assembler at all.
B) Target application. You should learn how to write assembler functions that are callable via the C calling standard (ABI). Any other target application is a waste of time to learn.
Most books and online tutorials want to teach you how to write whole DOS programs or whole Windows programs or whole Linux programs in x86 asm. That is a total waste of time. There is an enormous amount of stupid (and OS specific) detail you need to learn to write whole programs in assembler. That ends up distracting the student from ever actually learning assembler. You get only form and not content. Other online resources teach assembler for bare x86 machines starting from boot code. An x86 is in such a weird state on boot up (for historical reasons) that getting it from boot up to usable is an even bigger collection of otherwise useless detail than writing whole programs. Again, the good parts are completely missed as you focus on useless detail.
If you learn how to write C callable function in asm, you go directly into what is important and valuable about writing in asm rather than in a high level language. Even more important: you learn those aspects of asm that will help you be a better software engineer outside of asm programming. You also learn a powerful skill for diagnosing difficult bugs in C and C++ and many other languages.
You might not need to write C programs to call/test your C callable asm functions. Forth and C++ and Java and lots of other languages have ways of calling C callable functions.
Since you hate C and haven't explained why, I expect you will be severely handicapped in approaching X86 assembler, but I'll try to give some constructive advice anyway.
The most important question before learning X86 assembler is what kind of X86 assembler to learn. There are two dimensions to that question:
A) 16-bit vs. 32-bit vs. 64-bit
One of my sons is taking a university course in x86 assembler. The instructor decided to teach 16-bit x86 assembler writing full DOS programs. My opinion of university professors was always low and CS professors even lower. But this bozo manages to push my opinions even lower. 16-bit X86 is a super quirky assembler language. When it was the language of the most important CPU in use, it was worth the trouble to learn that quirky language even though doing so gave you very distorted views about assembler in general (I once knew every detail of 16-bit x86). Once it was obsolete, teaching it became far stupider than teaching other obsolete languages.
32-bit x86 is still a fairly quirky language and not very representative of assembly language in general. It is now obsolete and is worthless to teach because it is obsolete.
64-bit x86 is a much less quirky language. Programming in assembler at all might be largely obsolete, but knowing 64-bit x86 is a powerful tool for programmers even if you won't directly program in it. There are far fewer online resources and even fewer paper books for 64-bit x86 vs. 32 or 16. That's tough luck. 64-bit is still worth learning. 32 and 16 are not. Go to the extra effort to learn 64 bit x86 or don't go to the effort to learn x86 assembler at all.
B) Target application. You should learn how to write assembler functions that are callable via the C calling standard (ABI). Any other target application is a waste of time to learn.
Most books and online tutorials want to teach you how to write whole DOS programs or whole Windows programs or whole Linux programs in x86 asm. That is a total waste of time. There is an enormous amount of stupid (and OS specific) detail you need to learn to write whole programs in assembler. That ends up distracting the student from ever actually learning assembler. You get only form and not content. Other online resources teach assembler for bare x86 machines starting from boot code. An x86 is in such a weird state on boot up (for historical reasons) that getting it from boot up to usable is an even bigger collection of otherwise useless detail than writing whole programs. Again, the good parts are completely missed as you focus on useless detail.
If you learn how to write C callable function in asm, you go directly into what is important and valuable about writing in asm rather than in a high level language. Even more important: you learn those aspects of asm that will help you be a better software engineer outside of asm programming. You also learn a powerful skill for diagnosing difficult bugs in C and C++ and many other languages.
You might not need to write C programs to call/test your C callable asm functions. Forth and C++ and Java and lots of other languages have ways of calling C callable functions.
But this bozo manages to push my opinions even lower. 16-bit X86 is a super quirky assembler language.
Usefulness/quirkiness are irrelevant and your professor is smarter than you think. Teaching assembler is a good idea because it will give you basic understanding of the way processor works. That there are registers, that "if/else" blocks are really jumps/gotos, etc. And in real-time dos mode you won't have to mess with OS too much (one process, unrestricted memory access, etc), and you won't have to cram into student's head understanding of protected mode. It is a very good way to get started with programming. Also, in MS-DOS it will be easier to have fun soon. You can switch display mode, mess with screen, and make simple graphical demos. With anything higher with DOS, you'll have to study API (possibly several) before you'll be able to do anything interesting - you'll get stdin/stdout and that's it.
Teaching assembler is a good idea because it will give you basic understanding of the way processor works.
I totally agree.
Quote:
That there are registers, that "if/else" blocks are really jumps/gotos, etc.
Those are things you would learn earlier and understand better if learning to write functions in 64-bit x86 than if learning to write DOS programs in 16-bit.
Quote:
And in real-time dos mode you won't have to mess with OS too much
When learning to write functions, you won't have to mess with the OS at all. Learning to write DOS programs, my son has spent weeks learning about how an asm program needs to interact with DOS. Any real assembler learning must come later.
Quote:
you won't have to cram into student's head understanding of protected mode.
Why would you ever? If you're writing 16-bit Windows programs (as very distinct from 16-bit DOS programs runnable in Windows) then you need to learn about "protected mode". Same if you're trying to learn how to write a useful X86 OS or useful X86 boot code.
But to write 32-bit or 64-bit asm functions (or even Windows or Linux programs) you don't need to know "protected mode" even exists. Sure you and I know it's there and your 32-bit or 64-bit program can't run without it. But the same is true of lots of quantum theory details that went into the design of the semiconductors inside the CPU. If no one knew that quantum theory stuff or no one knew that protected mode stuff then I couldn't program functions in 64-bit x86 asm. But my knowing that protected mode stuff is just as irrelevant to programming in 64-bit asm as my not knowing the quantum theory stuff.
Quote:
Also, in MS-DOS it will be easier to have fun soon. You can switch display mode, mess with screen, and make simple graphical demos.
True and I hope irrelevant. I hope learning something important can be interesting without needing childish feedback defined as "fun".
I do understand that some students do need flashier feedback to hold their attention. If that is the expected class then the professor should put in the extra effort to prepare to teach something more useful anyway, rather than teach something worthless just because the flashy feedback is already available.
A competent software engine could set up a frame program and assembler bindings to GLUT with only a moderate amount of work. Having done that before the semester starts, a professor could provide that (as a black box, not for the students to need to understand) to allow real 64-bit asm programming to have immediate access to flashy graphics and keep the attention of immature students.
I expect the bozo teaching 16-bit x86 asm at my son's university is not a competent software engineer and couldn't accomplish anything like that. If he had any integrity as a teacher, he would either decide his students aren't immature enough to need that or he would find one of the smartest students who would be able to set that up for him (but then he might need to learn asm programming himself, rather than teaching from a obsolete text book a topic he doesn't actually know).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.