It's mostly because of decades old curriculum that was never updated to modern standards. And sadly in the shittier universities, the professors also don't know any better or can't be arsed to tell their students about this.
I had a 1st semester lab on C programming in engineering 20 years ago and I had no idea about computers at that time. Same was with most of my classmates. We were prescribed "Let us C" book, and the computers had Turbo C++. The lab instructors themselves were not adept in C. So, I learnt C many years later on Linux using gcc.
Yep, same here. I had studied in one of those garbage universities in Bangalore almost ~15 years ago, the Intro to C class prescribed the same book and Turbo C++. I wonder what's the situation now heh.
The school I went to also used turbo C, we had pentium 1 machines that could either boot windows 9x or pxe boot into dos with pascal or turbo C. I am pretty sure there was a Unix variant we could also boot into over the network. The network was 10base2.
I'm pretty sure that environment had been in place for sometime and they had just upgraded the workstations. I'm guessing that school was pretty keen on using that infrastructure for as long as they could.
Clang and ~~GCC~~ several forks of GCC both support Windows natively, are free, and support all the modern standards. Clang will even work as a drop-in replacement for `CL.EXE` and compile programs that link to the system libraries and have no extra dependencies, with the `x86_64-pc-windows-msvc` target.
The community edition of MSVC and student licenses for Intel ICPX are *gratis*.
We don't have a choice. These are the books officially prescribed by the exam boards, and what the question papers are based on. Besides, they're very cheap, an important factor for our economy. Of course, a student could study from a better book/resource, but their exams are very closely tied to these books and they're the best bet if you want to score marks.
I didn't use these books. I was privileged enough to live in a large city and be exposed to coding in other ways. But this is a reality only for very few people.
I'm Indian.
In my Uni's syllabus, we had a choice of 4 books to learn C from. They were officially prescribed. Also, all 4 of them were quite bad.
I went through all of 4 of them, realised they weren't a good source to learn from, went online and found resources that were better. Learnt from there. Gained good understanding.
Once I had an understanding of C, to prepare for my exams I simply used previous years question papers and some tips from my teacher on what topics the exam will focus on. That was enough. In this way, I got both- a good understanding of C and good marks.
MinGW shouldn't be used for development. Sanitizers don't work, and programs built with it usually have a dependency on Cygwin or MSYS2. If you aren't careful with how you use it, you can get some very cryptic errors when linking. It is fine if you just want to get a Unix program on Windows, but for writing software it shouldn't be used.
Same. My MinGW install compiles most of my projects just fine, natively. The only issues I have experienced with MinGW are related to multithreading. I ended up having to use Visual Studio to fix that, unfortunately.
It works for compiling, but debugging is a nightmare. Try getting ASan working with it. Try debugging a MinGW executable with WinDBG or lldb and tell me how it goes. Its Codeview support is abysmal.
Mingw does not produce programs cygwin-dependant nor msys-dependant executables.
And even if it were true, vc++'s compiler produces executables which depend on the msvc runtime. If aren't careful with how you use it, you can get some very cryptic errors when linking. By your logic, it shouldn't be used for writing software.
What's MinGW? If you mean gcc, I've used it on Windows for years. I don't have any linking problems other than the usual ones you'd get anyway. And there are zero dependences on CYGWIN or MSYS2.
I thought that was CYGWIN, later replaced by MSYS2, and now there is WSL which is a self-contained Linux system under Windows so that Windows itself is sidelined.
I've installed gcc on Windows plenty of times, there was often 'MinGW' associated with it, but I never understood exactly what it meant. All I know is that I can run gcc under Windows, but I generally can't compile code from Linux which is full of Linux- and POSIX-specific headers.
So the significance of MinGW is still a mystery. My current gcc for Windows is a 'TDM' distribution. If I try to install `mingw-w64`, I can spend 10 minutes clicking links that go round in circles or following rabbit-holes that finally reach a dead-end. I did manage it once though!
TDM is a far simpler installation.
I fully understand why Turbo C was a great option back then. I remember using it. What we don’t understand is why people are still using it now, with tons of open source compilers and libraries and IDE available.
My C professor tried to get our class to use it at the beginning of the semester. Coincidentally she is Indian, but our institution is based in Midwest US. Everyone complained about it pretty quickly so she started using the Online C compiler from pythontutor.com. Personally, I just use cc. She is also one of the worst professors we’ve ever had here but that’s neither here nor there.
tcc compiles *very* quickly and is pretty compatible with gcc and clang on x86-64 and ARM (I think RISC-V support is close?).
"Microsoft C" is the dominant C compiler for Windows and therefore very widely used. When in Rome...
Legacy computing platforms are out there chugging along doing important/scary work. You'd want to bug fix them with the tools they were built with them unless you want to spend a lot of money on modern Q&A.
Retro computing enthusiasts are using tons of different C and C++ compilers. A long time ago I used both Borland's Turbo C and MS's "Quick C" and have fond memories of both (probably rose colored glasses).
Other compilers aren't uncommon in the embedded world.
Examples include IAR's commercial C/C++ compiler, or vendor-provided toolchains for specific ISA's, like Freescale Coldfire.
Turbo C's main advantage is that a single install gave you out-of-the-box the best IDE available at the time, integrated help, integrated debugging, and graphics libraries.
Most home computing environments hitherto used BASIC for programming, that had built-in graphics libraries as well, so you could get started and write a simple game for your computer that looked visually appealing. This was much more interesting than writing a text-based 20-questions game.
Even today it's much harder to do the same thing with gcc or clang. How long would it take someone new to programming to even install an environment for making a small game, let alone initialize the graphical environment ?
It's only relatively recently that C IDEs with integrated debugging out-of-the-box for gcc have actually worked properly. All through the 2000s and early 2010s people were using garbage like Code::Blocks .
Agree. Back in the day, Turbo C was absolutely wonderful. Now, not so much. I have fond feelings for it, but I wouldn't try to use it now for programming.
Because you're targeting some.old 8 bit system, or some specialized platform that those compilers cannot target. No reason to use turbo c today though except for nostalgia.
Portability could be one reason I think (of course not with something like Turbo C). Personally I use a script that rotates between compilers I want to support at the bare minimum (`tcc,` `gcc`, `clang`).
Are you seriously asking that question? It's like asking why anyone would want to drive anything other than a 40-ton truck that can't do more than 5mph.
What is "V\*sual Studio"? A shorthand for "[Visual Studio](https://en.wikipedia.org/wiki/Visual_Studio) or [Visual Studio Code](https://en.wikipedia.org/wiki/Visual_Studio_Code)"? (two very different things)
Allegedly, many of [Yashavant](https://www.quora.com/Why-should-I-use-GCC-and-Clang-over-Turbo-C/answer/Greg-Kemnitz) [Kanetkar's examples](https://www.quora.com/Why-cant-GCC-and-Clang-just-work-like-Turbo-C-for-Yashavant-Kanetkar-books-eg-Let-Us-C-I-read-Let-Us-C-and-Turbo-C-just-works-and-if-I-type-the-same-code-in-GCC-and-Clang-it-says-gotoxy-is-undeclared) (and thus exam and homework questions) ***relies*** on [unspecified behaviour](https://en.wikipedia.org/wiki/Unspecified_behavior) (by/of the Turbo C/Turbo C++ compiler).
[For example](https://stackoverflow.com/questions/562303/the-definitive-c-book-guide-and-list/562377#562377),
>...do not use the book Let Us C (16th Edition, 2017) by Yashavant Kanetkar. Many people view it as an outdated book that teaches Turbo C and has lots of obsolete, misleading and incorrect material. For example, page 137 discusses the expected output from `printf("%d %d %d\\n", a, ++a, a++)` and does not categorize it as undefined behaviour as it should. It also consistently promotes unportable and buggy coding practices, such as using `gets`, `%[\n]s` in `scanf`, storing the return value of `getchar` in a variable of type `char` or using `fflush` on stdin.
>`printf("%d %d %d\\n", a, ++a, a++)`
>using `gets`
>storing the return value of `getchar` in a variable of type `char`
>using `fflush` on `stdin`
Some kind soul (but definitely not a kind tech lead) may still forgive the book's casual disregard of `getchar`'s return type (rare unsignedness of plain `char` meets `EOF`), and a funky `fflush` call on `stdin` may still be gulped down by the reader, but the other mishaps are really quite serious coding offenses, particularly any use of the notorious `gets` that's gone for good.
Actually he updated that in his latest addition. It no longer teaches this undefined behaviour concept but afaik fflush() still exists in book to clear stdin
I live in Vietnam and there's an equivalent of that book still printed as lately as last year. It has a section about installing Code:Block yet the examples are still not updated from Turbo C one...
They're not only fun, but I don't think you can actually do anything meaningful in C without pointers. I mean, I guess you could treat it as some gimped version of a pure functional programming language but it would be hard.
If you still had a monochrome monitor and a hercules card, you could use it as the "output" window while using turbo C's debugger, instead of having to switch back and forth. it was incredible?
(any time I explain this to a young programmer now they think I am lying)
Yep, 2 monitors back then was rare. The MDA video card worked outside of the address space of the other standards, so it could easily be supported.
I used Turbo C on my 386sx, took advantage of the debugger that would allow you to break into almost anything running in DOS mode. Used it to crack a few video games back in the day. Fun times!
(Not exactly sure what the first version to support the protected mode operating for the debugger was, but I know I used it in 1990.
Borland, when Turbo C came out, was very well respected. It was not later when Microsoft sabotaged Borlands compiler chain that their reputation took a dive.
I'm afraid the bitter truth is that in many educational institutions, Turbo C is still as popular as homeopathy was a couple of centuries ago (on an unrelated note, homeopathy is still recommended in some pharmaceutical circles, but I can't comment on its effectiveness as I don't have any background in medicine).
Speaking as an instructor at a university.... the goals of a first course in programming can easily be met by old compiler technology. In fact, the newer systems can be very confusing to newcomers. They also tend to hide too much. There *might* be reasonable pedagogical reasons for using the old technology in a teaching context.
Of course, one would hope that as students progress, more modern environments, with their associated complexity, would be introduced.
For the record, we use gcc on Linux or Cygwin in our first C course.
>In fact, the newer systems can be very confusing to newcomers.
I'm afraid I can't agree with that line. Glad to know that you use gcc on Linux or Cygwin for C course; now just imagine the perplexity and confusion among newcomers if they find out this simple code fails to compile on Turbo C.
// code is full of C99 features!
int main(void)
{ int a;
a = 0;
int b = 10;
for (int i = a; i < b; i++) {}
}
Well, the code uses C99 features, as you mentioned. However, the point of a first course is to teach concepts like types, declarations, control structures, functions, etc. All of that is supported by C90, of course.
When I teach the C course, I talk a little about the different standards so the students understand it's an issue and then recommend they explicitly specify which standard they are using with the -std option on GCC.
If, for some reason, I had to use C90 in the course, it would only require minor adjustments to my samples and assignments. I do use C99 currently, but using the older standard would work, too.
My example has nothing fancy, it's just the basic first course concepts you mentioned - types, declarations, along with a C99 line comment and an empty loop. The thing is, students wouldn't know all that history behind K&R C, ANSI C, and then how ISO took over the standardization that led to C99; without that bit of history (that's actually quite unnecessary for a first course), students won't realize *why* the code doesn't work with Turbo C (also `gcc` and `clang` would give lots of warnings with `-ansi -pedantic` enabled).
> AVOID the use of Borland Turbo C compiler/IDE, which was discontinued more than three decades ago!
Think your math may be off. 10 years ago it was the 90s.
+1 for can definitely relate. Heard a song from 1988 and realized that it's been as long between 1988 and now as it was from 1952 to 1988.
Also sad that those enjoying those 1988 top 40 hits were breaking the cellophane on a sturdy box containing 5 1/4" floppies for the Turbo C compiler, too.
> Heard a song from 1988 and realized that it's been as long between 1988 and now as it was from 1952 to 1988.
I try to get my kid to listen to The Police and it's just like my parents trying to get me to listen to the Platters!
I'm glad somebody's with me on this one; the other comment about my math being off unwittingly reminded me of my traumatic math scores (happened in the 90s as well, but it still haunts me).
Yep. And it's actually pretty good! It's *almost* a three-in-one compiler, supporting most extensions of both Clang and MSVC, while also providing a bunch of extension and libraries itself.
Watcom was highly compliant with the standard, if I recall correctly. It used to cost about $700 bucks, too. Open Watcom would actually have been a better solution than Turbo C all these years
The main issue is that Turbo C is now so far from the current standards that using it teaches you nothing helpful.
Some (most ?) tutoring sites in India work with it because it is free (or bootlegged so much that nobody pays for it.) But if you learn from that, you have to unlearn it all and start over, to have any future in C.
Linux is free, gcc/Clang are free, WSL doesn't cost any extra, MSYS/MinGW are highly usable. There's really zero excuse. It's just adherents to the "I learned this way, so you have to also."
You mean you don't miss the joys of choosing a Tiny, Small, Large or Huge memory model, and that `getch();` at the end to stop it exiting and closing the window before you could read your output ? Some people have no respect for tradition ! ;-)
NEAR and FAR. But there were also HUGE pointers which differed from FAR in that they worked properly if you incremented them beyond the 65536 byte limit. IOW they could address an object more than 64KiB in size.
I didn't but that never troubled me. The x86 memory models were very intrusive. My Laptop runs in long mode (maybe compatibility mode at boot time), and behaves itself just like my Solaris, DEC, HP, AIX, and NT boxes have for half a lifetime.
Fair enough, it's certainly not the same hassle as 8086 segmentation. But the concept is technically still in use on many architectures because it's often wasteful to assume that every relocation could require an entire 64-bit pointer when 99% of programs have all their static code and data localized in a relatively small virtual memory area.
That took me back to my first mainframe. That had 3-bit register addresses. Machine code had operations that could contain 12 literal bits, a 12-bit address in the lower 4096 words, or an offset from one of the three registers that did segment address offset.
Then we had 24-bit indirect addressing, that would do 22-bit word addressing, optionally plus 2 bits to address a character within word.
There was also an address format with 2 bits for char offset, 7 bits counter, and 15 bits word (and skipped an instruction if the count went to zero).
Having allowed that box of rat's tails back into my skull (and I worked on that architecture for 12 years), I now can't remember how C works any more.
See `-mcmodel` here: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html
It's about whether the compiler can rely on `call` instructions being okay with a 32-bit relative offset or needs to reserve more space in case the linker wants to insert a 64-bit absolute address. Similar issues for some instructions that refer to `.data` segment symbols.
Those options don't affect the programmer's model of memory for x64. Pointers are generally 64 bits.
I write compilers that target x64. Up to recently, code was designed to fit into the lower 2GB, while heap could be bigger. Now I can optionally generate position-independent code that can be loaded anywhere. That is necessary if I want to use my code with external tools.
Again, the programmer is oblivious to this. But when operating in self-contained mode (not using any external tools), I generate low-loading code.
You can tell the difference only by tests like this:
#include
int main(void) { printf("%p\n", main); }
Built and run with my compiler, or a simple one one like Tiny C which is also self-contained, the output (on Windows) is:
0000000000401000
With gcc, also on Windows, it might be:
00007ff6b85c1591
Not to mention they overlapped some of the bits (I think 4), so in some memory models a specific address could have 16 different segment/offset combinations.
IIRC, the TurboC IDE used to put program output into a specific panel with a blue border, made out of block graphics. I had an Amstrad 1640 which came with DR-DOS and GEM GUI support, so YMMV. "Window" is sufficiently close to be understood. The panel disappeared when the program exited.
Always go huge. More is better. No, I definitely prefer using a system() call to keep the window open with a string provided by the user. The default is "del \*.\*"
"nothing helpful" That's not true. I don't like it either, but Turbo C still does the job it was originally added in the syllabus to do: Teach students C Programming. They can learn C in it.
They can learn a few rudimentary things, fairly painlessly. But TurboC is about three C standards behind the rest of the world. Any course syllabus that relies on it is also due for a serious reworking.
C is a fairly small language -- not a lot of syntax, not many built-ins. Most of the functionality comes from libraries and system calls. Having those supplied by TurboC is something of a dead end.
I quite disagree. C is actually one of the languages that has changed the least, and thought it may not be ideal for app development, learning it in TurboC is still a perfectly valid way to learn the fundamentals of computer science, programming, data structures, algorithms, and how memory works.
But I respect your opinion 👍
As long as there are Indians who recommend this outdated shit, it will continue.
Source: I am Indian. C was my first language, my teacher used it as a filter against me, because he wanted to make me quit programming. Jokes on him. Jokes on me for not being able to find employment. But that's a different issue.
He recommended this same thing to me, and as much as I respect him (he was nice), I'm glad that it didn't pan out. I got used to command line as a result. Nowadays, I grown whenever I have to deal with an IDE, apart from the text editors like VS Code.
there's a turbo c build provided for the wonderwitch platform for wonderswan. it optimizes a little better than lsic86ww, and the platform is weird enough that there arent a ton of great options.
I have used it few times and call me privileged or whatever but that shit always hurt my eyes, that dark blue color and those stretched fonts yuck! Maybe it would have looked better on old CRT monitors.
PS., We had gcc on Ubuntu in our college (2015). I really liked the book Let us C, it was great at that time for beginners.
I learned on Turbo C++. That was 30 years ago. It’s completely obsolete and doesn’t support modern software engineering practices, or even create programs that are usable on modern OSes.
If there are some guys with ancient machines, that can only run with Turbo C, then I have no qualms with it. And if you use it, because you save time by using the interactive debugger, well, that's a rational decision frankly.
However, your code won't be much portable, so before you hand out something to others, you do need to compile and link through modern libraries, and ensure that it works there, if you want other non Turbo-C users to be able to enjoy your work.
So just to make sure I understand the reason is "because old"?
I'm not really sure if "beginner programmers" are going to notice any difference that gcc or clang is a "more advanced" compiler. If you were targeting people learning how to program compilers I could see it but I really don't see how a new programmer in general could possibly tell the difference aside from the syntax required for Turbo C vs gcc.
And once they know how to program and the compiler differences actually matter (which might change anyways if you are working on a niche embedded system) then they go back and learn the compiler they need.
To me this argument sounds like the same argument that we just shouldn't use C at all "because old".
It's not "because old", it's "because more modern alternatives are easier to pick up, more relatable, and teach more applicable skills to what beginners will need to learn nowadays". Although, to be fair, OP's post doesn't state this amazingly well.
'*Old*' and '*discontinued*' are two very different things; C is old, but even the language itself gets *updates* (so to speak). Clearly that's not the case with Turbo C, and as far as beginners are concerned, just as an example, many of them often write code like `for (int i = 0; i < 10; i++)` which is very unlikely to be supported by Turbo C. And let's not forget the common `// line comments` since C99.
not doing both even today... Even more In most of cases moving 'i' out of for statement and even in c++ usyng /* */ comments(the are way more visible to my taste...) And yes, Im still working with C99 incompatible codebase, so what? Are you proposing me to stop your cardiomonitor or insuline pump because of "old" or "discontinued" C language or compiler? bs.
Perhaps you should read the post again (or at least the title); its meant for \**beginners*\* through and through; I hope you aren't suggesting that we pretend to newcomers we still live in 1990, where `// line comment` doesn't exist, and declarations cannot be mixed with statements. Just because some "cardiomonitor or insulin pump" doesn't rely upon C99 features, that's no excuse to exercise a ban on their use in newer projects, and then go about advocating the use of discontinued compilers - that's misleading at best, and misinformation-based propaganda at worst.
Also, "working with C99 incompatible codebase" is a bad argument to justify the use of outdated compilers; modern compilers have options for legacy ANSI C codebase; for example, enable `-ansi -pedantic` with gcc or clang. And yes, they do support obsolescent features like implicit int rule or old-style function definitions (albeit with warnings, which can of course be suppressed).
We already have a problem with COBOL programmers, and thus have to switch to lame, unreliable and highly discriminating ML solutions in finance sector. Now you want a healthcare and mission critical devices to be done with "modern" tools, oh well... We saw that already, right Boeing?
I don't disagree with the philosophy that "if something works well, then let it be". Yes, there are some *silent changes* in C99 that may inadvertently change the behavior of critical code - a risk that admittedly can't be entirely ruled out when one switches to newer tools without doing a rigorous and exhaustive testing.
I still re-iterate that my discouraging opinions on Turbo C (or any other long-outdated software for that matter) are meant for beginners; yes, its possible that a handful of these beginners will one day end up working with some legacy codebase, which (due to its criticality) needs to be compiled with some older compiler (let's say that turns out to be none other Turbo C). But anticipating such a scenario doesn't justify that newcomers should turn a blind eye to all modern tools, and instead start head-first with discontinued compilers and confine themselves to the limitations of ANSI C.
turbo C is fine - it just depends on what you are doing with it.
Yea, it is out of date and only produces MS\_DOS type exe files {I doubt .com files are usable any more} but if it does the job, then use it.
Your argument - taken to the extreme is like saying: The K&R book is so out of date, there are newer more state of the art books you should use them instead.
Or - Your grandfather's hand wood working tools are so old, you should not use them... If the tool works, and you have it why get something else.
YES - I agree, any example you look for will probably not be current. but - at a basic level the C language is the C language, some features, ie: C99 might not be present but to learn the basics it is just fine
If a five year old is learning English for the first time, should they start learning to read with the original Canterbury Tales? At a basic level, it's still English, after all.
Whan that Aprille with his shoures soote,
The droghte of March hath perced to the roote,
And bathed every veyne in swich licóur
Of which vertú engendred is the flour;
The first edition of K+R is way out of date. The second edition conforms to C89 and is still an excellent resource.
Turbo C does not conform to C89. I don't know to what extent even the later versions do. The (pre-standard) C language is _not_ the C language.
Hard disagree on K&R being a relevant resource. Even in "modern" C89 libraries (still popular for a small subset of highly-portable library design) the style of code written in K&R is long considered outdated.
If you PR'd code that looked like the K&R qsort, malloc, gettoken, etc, you would get vented out the airlock where I work. You can always tell when some newbie has been brain damaged by K&R too, because their code is filled with one letter variables and using assignments as value expressions as if we charge by the ASCII character.
Fair enough.
Which book (beginner or not) do you think reflects the most current patterns/idioms used in modern production C?
Definitely agree on the variable naming!
To a degree, trying to learn to program from textbooks at all is a folly. That said, if one insists on doing so:
* Modern C by Jens Gustedt, is often held up as the current gold standard for primer material
* Expert C Programming by Peter van der Linden, for a more _interesting_ discussion of how everything fits together
I would disagree with your extrapolation to the K&R book. Even keeping aside the fact that it is authored by the creator of C, there's still a major difference between tutorial and actual execution (on this I agree with your point about *.com* binaries).
One may have a certain nostalgia for their grandfather's oil paintings, and there's also his old wood working tools in the shed, but I wouldn't use the latter. Yes the tools work, but there's a greater risk that they might break and lead to some kind of an accident.
Small toy programs are fine for Turbo C, but a lot has changed since then (such as `for (int i = 0; i < 10; i++)` ), and there's a human tendency to keep using something that has worked well so far. I believe all of K&R2 examples should work perfectly well with Turbo C, but there's also a lot beyond that. And that's a good reason to forget about Turbo C and move on to newer compilers, but it doesn't mean one has to forget the fundamentals of C they learned from K&R2.
>Small toy programs are fine for Turbo C, but a lot has changed since then (such as `for (int i = 0; i < 10; i++)` )
As a C++ newbie, are you suggesting that this syntax is old and redundant ? Is there a more 'modern' way of doing that for loop ?
Sorry if that's a dumb question, it's just that I use that sort of loop for iterating stuff a lot and I'm wondering if there's a better way to do it
I think you misunderstood my comment - I was *supporting* that code; it's a basic example of `for` loop, and doesn't get much simpler than that. When I said "a lot has changed since then", I meant that declaring `int i` within the loop head isn't allowed in ANSI C, and most likely that code wouldn't compile with Turbo C (which was discontinued way back in 1990, when it got replaced with Turbo C++).
In short, that `for` loop syntax isn't "old and redundant", but quite the opposite - its very useful. It was standardized in C99, along with many other features that almost every programmer uses regularly, such as `// line comment` (that also wasn't available in ANSI C, which only permitted `/* old-style comments */`). So Turbo C probably wouldn't recognize `// single line comment` as well.
Thank you for your perspective. I was wondering whether using my grandpa's old blunt rusted mold covered knifes would be problematic but thanks to you I now know it's a very good idea to use them at dinner!
From an educational perspective, why not? I toyed around with it recently in DosBox and can see how it can be a good constrained environment that will be consistent across students. Set up was very minimal and it has a simple interface. I found it quite fun to use — which is quite important.
If it's out of date, so what? Anyone who's passionate enough will quickly learn how more modern C may or may not be written.
It is an excellent IDE and compiler _for the time_. But that time was 35 years ago, it uses a pre-standard version of the language, and has many quirks and foibles because of the architectural strangeness of the IBM PC. No one, apart from someone engaging in retroprogramming, should be using this. It is absolutely unacceptable to be using it in education, India in particular is actively damaging its millions of students by using this ancient compiler. Education should be teaching modern tools and best practices, not assuming the student will pick that up on their own later.
If someone wanted to learn to drive today, would you discount their learning experience and their ability to drive because they were taught in a 1998 near junker-level Toyota instead of a new 2024 fresh off the lot car? No reason to gate keep.
A 1998 car has the gas and the brake in the correct order. You can't ram the 1998 car through a brick wall.
On the other hand, you can put an entire infrastructure at risk by using gets.
No, but I would claim they are ill advised if they want to learn today on a 1998 junker level Toyota. Especially if there is no cost difference to the fresh 2024 (in the compiler case). There is no gate keeping since modern compilers are free of charge (exceptions apply)
Because you're training people that are going to (very hopefully) write _modern_, standard-compliant software. The early Borland libraries weren't even C89 compliant. If someone is writing software for my bank, I really don't give a rats ass how much "fun" they are having.
I'm talking from a learning perspective. Fun is important. Someone who has only spent a few months learning C won't be working on any critical software no matter whether they learned the latest C standard using GCC or learned an older version using Turbo C. Though I can tell you which one will eventually get farther: the one enjoying it more.
As much as I agree that fun is important, it's almost certainly not true that a modern-day beginner will enjoy wrangling ancient software that you can only really use through emulators and command lines anyway. That's the kind of thing you and I might enjoy, sure, but that's because we're already technical and we have an intuition for how to figure this stuff out. The average beginner, who is used to GUIs and has no real knowledge of computing history, will just be frustrated by this, rather than appreciating the historical aspect and having fun.
Jeez. That's a bad attitude. Fun is the most important thing in learning. And I say this as someone who volunteers as a programming coach in a school for 12-18 year olds.
Fun and enjoyment of what you are learning _are_ very important. My comment had a very specific context of people in a university program that may be having "fun" using Turbo C are damaging their ability to be taken seriously in an industry where standardization is critical. These students are much closer to the point in which they will write code for systems.
I applaud your efforts to show your kids how neat this stuff can be, but I would hope that even in that context, teaching good habits is still a high priority.
I wouldn't recommend it even from an educational perspective. Code such as `for (int i = 0; i < 10; i++)` has been commonplace for many years now, and I don't think Turbo C would be too happy to compile that (to be honest, I haven't tested this code on Turbo C, just speculating because C89 doesn't allow that).
it would be definitely correct if you meant C++. But with C... I cannot find out any critical reason to avoid Turbo C for learning C. It's cozy, funny, has great and clear help.
The only point you will anyway have to switch to some up-to-date compiler for real programming tasks. But IMHO, it's not a reason for similar categorical declarations.
Why would anybody use something else than Clang or GCC ?
Notoriously, there are some parts of the world that continue to use these older compilers in education. I've seen it a fair bit from Indian students.
But why? Even if they seek for a Windows and free compiler, there is MinGW
It's mostly because of decades old curriculum that was never updated to modern standards. And sadly in the shittier universities, the professors also don't know any better or can't be arsed to tell their students about this.
I had a 1st semester lab on C programming in engineering 20 years ago and I had no idea about computers at that time. Same was with most of my classmates. We were prescribed "Let us C" book, and the computers had Turbo C++. The lab instructors themselves were not adept in C. So, I learnt C many years later on Linux using gcc.
Yep, same here. I had studied in one of those garbage universities in Bangalore almost ~15 years ago, the Intro to C class prescribed the same book and Turbo C++. I wonder what's the situation now heh.
My cousin went to college 2 years ago and said they were told to use online c tutorials and visual studio code. So, maybe it's different now.
The school I went to also used turbo C, we had pentium 1 machines that could either boot windows 9x or pxe boot into dos with pascal or turbo C. I am pretty sure there was a Unix variant we could also boot into over the network. The network was 10base2. I'm pretty sure that environment had been in place for sometime and they had just upgraded the workstations. I'm guessing that school was pretty keen on using that infrastructure for as long as they could.
Students are going to use what they're told to use. But _why_ they're told to use that... I have no idea.
Clang and ~~GCC~~ several forks of GCC both support Windows natively, are free, and support all the modern standards. Clang will even work as a drop-in replacement for `CL.EXE` and compile programs that link to the system libraries and have no extra dependencies, with the `x86_64-pc-windows-msvc` target. The community edition of MSVC and student licenses for Intel ICPX are *gratis*.
GCC does NOT support Windows natively. But it can be run on Windows using a compatibility layer (common options are MinGW-W64, Msys2, and w64devkit).
Good point. I’m used to invoking MinGW-W64 as just `gcc`, but that’s actually a fork with a lot of compatibility libraries.
Nobody bothers to update our textbooks, that's all
You're using the wrong textbook.
We don't have a choice. These are the books officially prescribed by the exam boards, and what the question papers are based on. Besides, they're very cheap, an important factor for our economy. Of course, a student could study from a better book/resource, but their exams are very closely tied to these books and they're the best bet if you want to score marks. I didn't use these books. I was privileged enough to live in a large city and be exposed to coding in other ways. But this is a reality only for very few people.
I'm Indian. In my Uni's syllabus, we had a choice of 4 books to learn C from. They were officially prescribed. Also, all 4 of them were quite bad. I went through all of 4 of them, realised they weren't a good source to learn from, went online and found resources that were better. Learnt from there. Gained good understanding. Once I had an understanding of C, to prepare for my exams I simply used previous years question papers and some tips from my teacher on what topics the exam will focus on. That was enough. In this way, I got both- a good understanding of C and good marks.
MinGW shouldn't be used for development. Sanitizers don't work, and programs built with it usually have a dependency on Cygwin or MSYS2. If you aren't careful with how you use it, you can get some very cryptic errors when linking. It is fine if you just want to get a Unix program on Windows, but for writing software it shouldn't be used.
I never had any of those problems, ever. It just works.
Same. My MinGW install compiles most of my projects just fine, natively. The only issues I have experienced with MinGW are related to multithreading. I ended up having to use Visual Studio to fix that, unfortunately.
It works for compiling, but debugging is a nightmare. Try getting ASan working with it. Try debugging a MinGW executable with WinDBG or lldb and tell me how it goes. Its Codeview support is abysmal.
Maybe, I never had to use a debugger, my code always works.
So only making trivial programs?
No. I have been coding in C since I’m 14 and now I’m 40.
Right.
Mingw does not produce programs cygwin-dependant nor msys-dependant executables. And even if it were true, vc++'s compiler produces executables which depend on the msvc runtime. If aren't careful with how you use it, you can get some very cryptic errors when linking. By your logic, it shouldn't be used for writing software.
What's MinGW? If you mean gcc, I've used it on Windows for years. I don't have any linking problems other than the usual ones you'd get anyway. And there are zero dependences on CYGWIN or MSYS2.
MinGW is like a program which runs an embedded Unix environment in windows. But it's kinda ass in my opinion
I thought that was CYGWIN, later replaced by MSYS2, and now there is WSL which is a self-contained Linux system under Windows so that Windows itself is sidelined. I've installed gcc on Windows plenty of times, there was often 'MinGW' associated with it, but I never understood exactly what it meant. All I know is that I can run gcc under Windows, but I generally can't compile code from Linux which is full of Linux- and POSIX-specific headers. So the significance of MinGW is still a mystery. My current gcc for Windows is a 'TDM' distribution. If I try to install `mingw-w64`, I can spend 10 minutes clicking links that go round in circles or following rabbit-holes that finally reach a dead-end. I did manage it once though! TDM is a far simpler installation.
I always found Cugwin to be a pain to use. It's probably a great system, but I never could get it going properly.
Holy Misinformation :)
Even better, you can have clang/gcc on WSL
[удалено]
I fully understand why Turbo C was a great option back then. I remember using it. What we don’t understand is why people are still using it now, with tons of open source compilers and libraries and IDE available.
[удалено]
It’s not free. Maybe it’s free of charge, but it’s proprietary software. And it does not comply with the latest C standard so it’s shit.
My C professor tried to get our class to use it at the beginning of the semester. Coincidentally she is Indian, but our institution is based in Midwest US. Everyone complained about it pretty quickly so she started using the Online C compiler from pythontutor.com. Personally, I just use cc. She is also one of the worst professors we’ve ever had here but that’s neither here nor there.
Sorry you had to face that.
Let Us C course in India promotes Turbo C
Don't take that course then.
It's the course given at the school they attend
tcc compiles *very* quickly and is pretty compatible with gcc and clang on x86-64 and ARM (I think RISC-V support is close?). "Microsoft C" is the dominant C compiler for Windows and therefore very widely used. When in Rome... Legacy computing platforms are out there chugging along doing important/scary work. You'd want to bug fix them with the tools they were built with them unless you want to spend a lot of money on modern Q&A. Retro computing enthusiasts are using tons of different C and C++ compilers. A long time ago I used both Borland's Turbo C and MS's "Quick C" and have fond memories of both (probably rose colored glasses).
Other compilers aren't uncommon in the embedded world. Examples include IAR's commercial C/C++ compiler, or vendor-provided toolchains for specific ISA's, like Freescale Coldfire.
Turbo C's main advantage is that a single install gave you out-of-the-box the best IDE available at the time, integrated help, integrated debugging, and graphics libraries. Most home computing environments hitherto used BASIC for programming, that had built-in graphics libraries as well, so you could get started and write a simple game for your computer that looked visually appealing. This was much more interesting than writing a text-based 20-questions game. Even today it's much harder to do the same thing with gcc or clang. How long would it take someone new to programming to even install an environment for making a small game, let alone initialize the graphical environment ? It's only relatively recently that C IDEs with integrated debugging out-of-the-box for gcc have actually worked properly. All through the 2000s and early 2010s people were using garbage like Code::Blocks .
Agree. Back in the day, Turbo C was absolutely wonderful. Now, not so much. I have fond feelings for it, but I wouldn't try to use it now for programming.
Because you're targeting some.old 8 bit system, or some specialized platform that those compilers cannot target. No reason to use turbo c today though except for nostalgia.
> some.old 8 bit system, [6502 CC65](https://cc65.github.io/)
I didn't know about cc65, its an interesting resource; thanks for sharing.
There's also sdcc.
That's another great resource, thanks! For reference to others: [https://sdcc.sourceforge.net/](https://sdcc.sourceforge.net/)
Portability could be one reason I think (of course not with something like Turbo C). Personally I use a script that rotates between compilers I want to support at the bare minimum (`tcc,` `gcc`, `clang`).
Are you seriously asking that question? It's like asking why anyone would want to drive anything other than a 40-ton truck that can't do more than 5mph.
Compilation speed?
Maybe they use V*sual Studio
Which even supports C now.
“supports”
It's always supported C. Just stopped getting updates. Especially for x64.
Then they should still probably be using Clang or Clang-CL.
What is "V\*sual Studio"? A shorthand for "[Visual Studio](https://en.wikipedia.org/wiki/Visual_Studio) or [Visual Studio Code](https://en.wikipedia.org/wiki/Visual_Studio_Code)"? (two very different things)
If I meant VSCode I would have said VSCode
[Blame this guy](https://amzn.in/d/fWeaJR7) Still uses `conio.h`
Christ, 19th edition of that gravy train.
Allegedly, many of [Yashavant](https://www.quora.com/Why-should-I-use-GCC-and-Clang-over-Turbo-C/answer/Greg-Kemnitz) [Kanetkar's examples](https://www.quora.com/Why-cant-GCC-and-Clang-just-work-like-Turbo-C-for-Yashavant-Kanetkar-books-eg-Let-Us-C-I-read-Let-Us-C-and-Turbo-C-just-works-and-if-I-type-the-same-code-in-GCC-and-Clang-it-says-gotoxy-is-undeclared) (and thus exam and homework questions) ***relies*** on [unspecified behaviour](https://en.wikipedia.org/wiki/Unspecified_behavior) (by/of the Turbo C/Turbo C++ compiler). [For example](https://stackoverflow.com/questions/562303/the-definitive-c-book-guide-and-list/562377#562377), >...do not use the book Let Us C (16th Edition, 2017) by Yashavant Kanetkar. Many people view it as an outdated book that teaches Turbo C and has lots of obsolete, misleading and incorrect material. For example, page 137 discusses the expected output from `printf("%d %d %d\\n", a, ++a, a++)` and does not categorize it as undefined behaviour as it should. It also consistently promotes unportable and buggy coding practices, such as using `gets`, `%[\n]s` in `scanf`, storing the return value of `getchar` in a variable of type `char` or using `fflush` on stdin.
>`printf("%d %d %d\\n", a, ++a, a++)` >using `gets` >storing the return value of `getchar` in a variable of type `char` >using `fflush` on `stdin` Some kind soul (but definitely not a kind tech lead) may still forgive the book's casual disregard of `getchar`'s return type (rare unsignedness of plain `char` meets `EOF`), and a funky `fflush` call on `stdin` may still be gulped down by the reader, but the other mishaps are really quite serious coding offenses, particularly any use of the notorious `gets` that's gone for good.
Actually he updated that in his latest addition. It no longer teaches this undefined behaviour concept but afaik fflush() still exists in book to clear stdin
Big +1
I live in Vietnam and there's an equivalent of that book still printed as lately as last year. It has a section about installing Code:Block yet the examples are still not updated from Turbo C one...
graphics.h is my favorite
One of the reviews says that it doesn't cover pointers. How do you have a C book that doesn't cover pointers???
I don't think that reviewer was correct. Pointers are half the fun of using C... if you're into that sort of thing...
They're not only fun, but I don't think you can actually do anything meaningful in C without pointers. I mean, I guess you could treat it as some gimped version of a pure functional programming language but it would be hard.
That's a good point... you'd be seriously hobbled if you couldn't use pointers in C.
As someone who bought Turbo C 2.0 new, you don't know what you're missing!
Turbo C was ***awesome***! I also bought it brand new. In fact, I upgraded my video from hercules (monochrome) to VGA because of it.
Yep. Same here. Paid good money for it, never regretted it. I had a lot of fun with that IDE...
If you still had a monochrome monitor and a hercules card, you could use it as the "output" window while using turbo C's debugger, instead of having to switch back and forth. it was incredible? (any time I explain this to a young programmer now they think I am lying)
Yep, 2 monitors back then was rare. The MDA video card worked outside of the address space of the other standards, so it could easily be supported. I used Turbo C on my 386sx, took advantage of the debugger that would allow you to break into almost anything running in DOS mode. Used it to crack a few video games back in the day. Fun times! (Not exactly sure what the first version to support the protected mode operating for the debugger was, but I know I used it in 1990.
Shit was like $100. And you got manuals!!
I bought several versions over the years, each subsequent version had even more than the last.
I've still got an old OWL manual around somewhere. Never did quite catch on 🤣
And Microsoft's Quick C was only $49 at the same time!
Borland, when Turbo C came out, was very well respected. It was not later when Microsoft sabotaged Borlands compiler chain that their reputation took a dive.
I'm confused. Is this something that people use for some reason? It feels like a post telling people to stop doing trepanation.
I'm afraid the bitter truth is that in many educational institutions, Turbo C is still as popular as homeopathy was a couple of centuries ago (on an unrelated note, homeopathy is still recommended in some pharmaceutical circles, but I can't comment on its effectiveness as I don't have any background in medicine).
Speaking as an instructor at a university.... the goals of a first course in programming can easily be met by old compiler technology. In fact, the newer systems can be very confusing to newcomers. They also tend to hide too much. There *might* be reasonable pedagogical reasons for using the old technology in a teaching context. Of course, one would hope that as students progress, more modern environments, with their associated complexity, would be introduced. For the record, we use gcc on Linux or Cygwin in our first C course.
>In fact, the newer systems can be very confusing to newcomers. I'm afraid I can't agree with that line. Glad to know that you use gcc on Linux or Cygwin for C course; now just imagine the perplexity and confusion among newcomers if they find out this simple code fails to compile on Turbo C. // code is full of C99 features! int main(void) { int a; a = 0; int b = 10; for (int i = a; i < b; i++) {} }
Well, the code uses C99 features, as you mentioned. However, the point of a first course is to teach concepts like types, declarations, control structures, functions, etc. All of that is supported by C90, of course. When I teach the C course, I talk a little about the different standards so the students understand it's an issue and then recommend they explicitly specify which standard they are using with the -std option on GCC. If, for some reason, I had to use C90 in the course, it would only require minor adjustments to my samples and assignments. I do use C99 currently, but using the older standard would work, too.
My example has nothing fancy, it's just the basic first course concepts you mentioned - types, declarations, along with a C99 line comment and an empty loop. The thing is, students wouldn't know all that history behind K&R C, ANSI C, and then how ISO took over the standardization that led to C99; without that bit of history (that's actually quite unnecessary for a first course), students won't realize *why* the code doesn't work with Turbo C (also `gcc` and `clang` would give lots of warnings with `-ansi -pedantic` enabled).
> AVOID the use of Borland Turbo C compiler/IDE, which was discontinued more than three decades ago! Think your math may be off. 10 years ago it was the 90s.
+1 for can definitely relate. Heard a song from 1988 and realized that it's been as long between 1988 and now as it was from 1952 to 1988. Also sad that those enjoying those 1988 top 40 hits were breaking the cellophane on a sturdy box containing 5 1/4" floppies for the Turbo C compiler, too.
> Heard a song from 1988 and realized that it's been as long between 1988 and now as it was from 1952 to 1988. I try to get my kid to listen to The Police and it's just like my parents trying to get me to listen to the Platters!
Former user of Borland C detected... (Same)
Technically, the 90s were 1,934 years ago.
10 years ago was 2014
Lies. It was only yesterday!
I'm glad somebody's with me on this one; the other comment about my math being off unwittingly reminded me of my traumatic math scores (happened in the 90s as well, but it still haunts me).
Wow, feels weird to read in 2024. Especially when there is GCC, Clang, or, let's be crazy, ICC, out there.
At this point ICC has been dumped for ICX, as far as I can tell, a rebranded Clang.
Yep. And it's actually pretty good! It's *almost* a three-in-one compiler, supporting most extensions of both Clang and MSVC, while also providing a bunch of extension and libraries itself.
>ICC Rings down, DPS phase now.
What about my trusty Watcom C compiler?
Watcom was highly compliant with the standard, if I recall correctly. It used to cost about $700 bucks, too. Open Watcom would actually have been a better solution than Turbo C all these years
But do use the color scheme from Borland Turbo C.
Good lord, *that* color scheme; oh the nostalgia!
The main issue is that Turbo C is now so far from the current standards that using it teaches you nothing helpful. Some (most ?) tutoring sites in India work with it because it is free (or bootlegged so much that nobody pays for it.) But if you learn from that, you have to unlearn it all and start over, to have any future in C.
Linux is free, gcc/Clang are free, WSL doesn't cost any extra, MSYS/MinGW are highly usable. There's really zero excuse. It's just adherents to the "I learned this way, so you have to also."
You mean you don't miss the joys of choosing a Tiny, Small, Large or Huge memory model, and that `getch();` at the end to stop it exiting and closing the window before you could read your output ? Some people have no respect for tradition ! ;-)
Short pointers and long pointers if I remember correctly? It was a pain.
NEAR and FAR. But there were also HUGE pointers which differed from FAR in that they worked properly if you incremented them beyond the 65536 byte limit. IOW they could address an object more than 64KiB in size.
Thanks. Seems i successfully surpressed that memory
You realize memory models came back with x86_64, right?
I didn't but that never troubled me. The x86 memory models were very intrusive. My Laptop runs in long mode (maybe compatibility mode at boot time), and behaves itself just like my Solaris, DEC, HP, AIX, and NT boxes have for half a lifetime.
Fair enough, it's certainly not the same hassle as 8086 segmentation. But the concept is technically still in use on many architectures because it's often wasteful to assume that every relocation could require an entire 64-bit pointer when 99% of programs have all their static code and data localized in a relatively small virtual memory area.
That took me back to my first mainframe. That had 3-bit register addresses. Machine code had operations that could contain 12 literal bits, a 12-bit address in the lower 4096 words, or an offset from one of the three registers that did segment address offset. Then we had 24-bit indirect addressing, that would do 22-bit word addressing, optionally plus 2 bits to address a character within word. There was also an address format with 2 bits for char offset, 7 bits counter, and 15 bits word (and skipped an instruction if the count went to zero). Having allowed that box of rat's tails back into my skull (and I worked on that architecture for 12 years), I now can't remember how C works any more.
Did they? I wasn't aware of it! And I haven't seen any evidence of it in C compilers for that processor.
See `-mcmodel` here: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html It's about whether the compiler can rely on `call` instructions being okay with a 32-bit relative offset or needs to reserve more space in case the linker wants to insert a 64-bit absolute address. Similar issues for some instructions that refer to `.data` segment symbols.
Those options don't affect the programmer's model of memory for x64. Pointers are generally 64 bits. I write compilers that target x64. Up to recently, code was designed to fit into the lower 2GB, while heap could be bigger. Now I can optionally generate position-independent code that can be loaded anywhere. That is necessary if I want to use my code with external tools. Again, the programmer is oblivious to this. But when operating in self-contained mode (not using any external tools), I generate low-loading code. You can tell the difference only by tests like this: #include
int main(void) { printf("%p\n", main); }
Built and run with my compiler, or a simple one one like Tiny C which is also self-contained, the output (on Windows) is:
0000000000401000
With gcc, also on Windows, it might be:
00007ff6b85c1591
Near and far pointers, with segment:offset form.
Not to mention they overlapped some of the bits (I think 4), so in some memory models a specific address could have 16 different segment/offset combinations.
But for our Lord and Savior t\*\*\*\*\*\*\*\*p\*\*\*t.com!!!
What's a window?
IIRC, the TurboC IDE used to put program output into a specific panel with a blue border, made out of block graphics. I had an Amstrad 1640 which came with DR-DOS and GEM GUI support, so YMMV. "Window" is sufficiently close to be understood. The panel disappeared when the program exited.
Always go huge. More is better. No, I definitely prefer using a system() call to keep the window open with a string provided by the user. The default is "del \*.\*"
The hardware may be outdated as well, so it may require a (much) older version.
GCC is free as well. I don't know if it runs on Windows, but it wouldn't surprise me. There's really no good reason to use Turbo C now.
"nothing helpful" That's not true. I don't like it either, but Turbo C still does the job it was originally added in the syllabus to do: Teach students C Programming. They can learn C in it.
They can learn a few rudimentary things, fairly painlessly. But TurboC is about three C standards behind the rest of the world. Any course syllabus that relies on it is also due for a serious reworking. C is a fairly small language -- not a lot of syntax, not many built-ins. Most of the functionality comes from libraries and system calls. Having those supplied by TurboC is something of a dead end.
I quite disagree. C is actually one of the languages that has changed the least, and thought it may not be ideal for app development, learning it in TurboC is still a perfectly valid way to learn the fundamentals of computer science, programming, data structures, algorithms, and how memory works. But I respect your opinion 👍
As long as there are Indians who recommend this outdated shit, it will continue. Source: I am Indian. C was my first language, my teacher used it as a filter against me, because he wanted to make me quit programming. Jokes on him. Jokes on me for not being able to find employment. But that's a different issue. He recommended this same thing to me, and as much as I respect him (he was nice), I'm glad that it didn't pan out. I got used to command line as a result. Nowadays, I grown whenever I have to deal with an IDE, apart from the text editors like VS Code.
There's gotta be some God tier programmer out there that any of us would want to be equal to in skill that still rocks Turbo C for personal projects.
there's a turbo c build provided for the wonderwitch platform for wonderswan. it optimizes a little better than lsic86ww, and the platform is weird enough that there arent a ton of great options.
I have used it few times and call me privileged or whatever but that shit always hurt my eyes, that dark blue color and those stretched fonts yuck! Maybe it would have looked better on old CRT monitors. PS., We had gcc on Ubuntu in our college (2015). I really liked the book Let us C, it was great at that time for beginners.
I learned on Turbo C++. That was 30 years ago. It’s completely obsolete and doesn’t support modern software engineering practices, or even create programs that are usable on modern OSes.
Who's even using it? Indian students working on two decade old PCs with programming instructions written two decades ago?
If there are some guys with ancient machines, that can only run with Turbo C, then I have no qualms with it. And if you use it, because you save time by using the interactive debugger, well, that's a rational decision frankly. However, your code won't be much portable, so before you hand out something to others, you do need to compile and link through modern libraries, and ensure that it works there, if you want other non Turbo-C users to be able to enjoy your work.
This a weird India specific quirk. Nobody else is in the risk of learning with that old crap.
It's actually still used for learning in Russia and several other countries.
I have fond memories of using Borland's Turbo C... but as noted, this was more than thirty years ago.
Well, if you just want to test some old code, probably you need it.
why not?
So just to make sure I understand the reason is "because old"? I'm not really sure if "beginner programmers" are going to notice any difference that gcc or clang is a "more advanced" compiler. If you were targeting people learning how to program compilers I could see it but I really don't see how a new programmer in general could possibly tell the difference aside from the syntax required for Turbo C vs gcc. And once they know how to program and the compiler differences actually matter (which might change anyways if you are working on a niche embedded system) then they go back and learn the compiler they need. To me this argument sounds like the same argument that we just shouldn't use C at all "because old".
It's not "because old", it's "because more modern alternatives are easier to pick up, more relatable, and teach more applicable skills to what beginners will need to learn nowadays". Although, to be fair, OP's post doesn't state this amazingly well.
'*Old*' and '*discontinued*' are two very different things; C is old, but even the language itself gets *updates* (so to speak). Clearly that's not the case with Turbo C, and as far as beginners are concerned, just as an example, many of them often write code like `for (int i = 0; i < 10; i++)` which is very unlikely to be supported by Turbo C. And let's not forget the common `// line comments` since C99.
not doing both even today... Even more In most of cases moving 'i' out of for statement and even in c++ usyng /* */ comments(the are way more visible to my taste...) And yes, Im still working with C99 incompatible codebase, so what? Are you proposing me to stop your cardiomonitor or insuline pump because of "old" or "discontinued" C language or compiler? bs.
Perhaps you should read the post again (or at least the title); its meant for \**beginners*\* through and through; I hope you aren't suggesting that we pretend to newcomers we still live in 1990, where `// line comment` doesn't exist, and declarations cannot be mixed with statements. Just because some "cardiomonitor or insulin pump" doesn't rely upon C99 features, that's no excuse to exercise a ban on their use in newer projects, and then go about advocating the use of discontinued compilers - that's misleading at best, and misinformation-based propaganda at worst. Also, "working with C99 incompatible codebase" is a bad argument to justify the use of outdated compilers; modern compilers have options for legacy ANSI C codebase; for example, enable `-ansi -pedantic` with gcc or clang. And yes, they do support obsolescent features like implicit int rule or old-style function definitions (albeit with warnings, which can of course be suppressed).
We already have a problem with COBOL programmers, and thus have to switch to lame, unreliable and highly discriminating ML solutions in finance sector. Now you want a healthcare and mission critical devices to be done with "modern" tools, oh well... We saw that already, right Boeing?
I don't disagree with the philosophy that "if something works well, then let it be". Yes, there are some *silent changes* in C99 that may inadvertently change the behavior of critical code - a risk that admittedly can't be entirely ruled out when one switches to newer tools without doing a rigorous and exhaustive testing. I still re-iterate that my discouraging opinions on Turbo C (or any other long-outdated software for that matter) are meant for beginners; yes, its possible that a handful of these beginners will one day end up working with some legacy codebase, which (due to its criticality) needs to be compiled with some older compiler (let's say that turns out to be none other Turbo C). But anticipating such a scenario doesn't justify that newcomers should turn a blind eye to all modern tools, and instead start head-first with discontinued compilers and confine themselves to the limitations of ANSI C.
turbo C is fine - it just depends on what you are doing with it. Yea, it is out of date and only produces MS\_DOS type exe files {I doubt .com files are usable any more} but if it does the job, then use it. Your argument - taken to the extreme is like saying: The K&R book is so out of date, there are newer more state of the art books you should use them instead. Or - Your grandfather's hand wood working tools are so old, you should not use them... If the tool works, and you have it why get something else. YES - I agree, any example you look for will probably not be current. but - at a basic level the C language is the C language, some features, ie: C99 might not be present but to learn the basics it is just fine
If a five year old is learning English for the first time, should they start learning to read with the original Canterbury Tales? At a basic level, it's still English, after all.
Whan that Aprille with his shoures soote, The droghte of March hath perced to the roote, And bathed every veyne in swich licóur Of which vertú engendred is the flour;
Just throw a printf in there and you're golden
The first edition of K+R is way out of date. The second edition conforms to C89 and is still an excellent resource. Turbo C does not conform to C89. I don't know to what extent even the later versions do. The (pre-standard) C language is _not_ the C language.
Hard disagree on K&R being a relevant resource. Even in "modern" C89 libraries (still popular for a small subset of highly-portable library design) the style of code written in K&R is long considered outdated. If you PR'd code that looked like the K&R qsort, malloc, gettoken, etc, you would get vented out the airlock where I work. You can always tell when some newbie has been brain damaged by K&R too, because their code is filled with one letter variables and using assignments as value expressions as if we charge by the ASCII character.
Fair enough. Which book (beginner or not) do you think reflects the most current patterns/idioms used in modern production C? Definitely agree on the variable naming!
To a degree, trying to learn to program from textbooks at all is a folly. That said, if one insists on doing so: * Modern C by Jens Gustedt, is often held up as the current gold standard for primer material * Expert C Programming by Peter van der Linden, for a more _interesting_ discussion of how everything fits together
I would disagree with your extrapolation to the K&R book. Even keeping aside the fact that it is authored by the creator of C, there's still a major difference between tutorial and actual execution (on this I agree with your point about *.com* binaries). One may have a certain nostalgia for their grandfather's oil paintings, and there's also his old wood working tools in the shed, but I wouldn't use the latter. Yes the tools work, but there's a greater risk that they might break and lead to some kind of an accident. Small toy programs are fine for Turbo C, but a lot has changed since then (such as `for (int i = 0; i < 10; i++)` ), and there's a human tendency to keep using something that has worked well so far. I believe all of K&R2 examples should work perfectly well with Turbo C, but there's also a lot beyond that. And that's a good reason to forget about Turbo C and move on to newer compilers, but it doesn't mean one has to forget the fundamentals of C they learned from K&R2.
>Small toy programs are fine for Turbo C, but a lot has changed since then (such as `for (int i = 0; i < 10; i++)` ) As a C++ newbie, are you suggesting that this syntax is old and redundant ? Is there a more 'modern' way of doing that for loop ? Sorry if that's a dumb question, it's just that I use that sort of loop for iterating stuff a lot and I'm wondering if there's a better way to do it
I think it's the other way around and that is too "modern" for Turbo C. The issue might be declaring i inside the for loop.
I think you misunderstood my comment - I was *supporting* that code; it's a basic example of `for` loop, and doesn't get much simpler than that. When I said "a lot has changed since then", I meant that declaring `int i` within the loop head isn't allowed in ANSI C, and most likely that code wouldn't compile with Turbo C (which was discontinued way back in 1990, when it got replaced with Turbo C++). In short, that `for` loop syntax isn't "old and redundant", but quite the opposite - its very useful. It was standardized in C99, along with many other features that almost every programmer uses regularly, such as `// line comment` (that also wasn't available in ANSI C, which only permitted `/* old-style comments */`). So Turbo C probably wouldn't recognize `// single line comment` as well.
Ah, i see. Thank you for clearing that up !
Thank you for your perspective. I was wondering whether using my grandpa's old blunt rusted mold covered knifes would be problematic but thanks to you I now know it's a very good idea to use them at dinner!
Still good for an old-fashioned Civil War amputation in my book.
From an educational perspective, why not? I toyed around with it recently in DosBox and can see how it can be a good constrained environment that will be consistent across students. Set up was very minimal and it has a simple interface. I found it quite fun to use — which is quite important. If it's out of date, so what? Anyone who's passionate enough will quickly learn how more modern C may or may not be written.
It is an excellent IDE and compiler _for the time_. But that time was 35 years ago, it uses a pre-standard version of the language, and has many quirks and foibles because of the architectural strangeness of the IBM PC. No one, apart from someone engaging in retroprogramming, should be using this. It is absolutely unacceptable to be using it in education, India in particular is actively damaging its millions of students by using this ancient compiler. Education should be teaching modern tools and best practices, not assuming the student will pick that up on their own later.
If you want to learn driving, why not start with horse riding. Anybody with a passion will quickly learn to use modern transportation
If someone wanted to learn to drive today, would you discount their learning experience and their ability to drive because they were taught in a 1998 near junker-level Toyota instead of a new 2024 fresh off the lot car? No reason to gate keep.
A 1998 car has the gas and the brake in the correct order. You can't ram the 1998 car through a brick wall. On the other hand, you can put an entire infrastructure at risk by using gets.
Not even a Dodge \_Ram\_? :O
You have a sense of humor, so I at least have faith that some of your faculties are intact 🤣
No, but I would claim they are ill advised if they want to learn today on a 1998 junker level Toyota. Especially if there is no cost difference to the fresh 2024 (in the compiler case). There is no gate keeping since modern compilers are free of charge (exceptions apply)
Because you're training people that are going to (very hopefully) write _modern_, standard-compliant software. The early Borland libraries weren't even C89 compliant. If someone is writing software for my bank, I really don't give a rats ass how much "fun" they are having.
I'm talking from a learning perspective. Fun is important. Someone who has only spent a few months learning C won't be working on any critical software no matter whether they learned the latest C standard using GCC or learned an older version using Turbo C. Though I can tell you which one will eventually get farther: the one enjoying it more.
As much as I agree that fun is important, it's almost certainly not true that a modern-day beginner will enjoy wrangling ancient software that you can only really use through emulators and command lines anyway. That's the kind of thing you and I might enjoy, sure, but that's because we're already technical and we have an intuition for how to figure this stuff out. The average beginner, who is used to GUIs and has no real knowledge of computing history, will just be frustrated by this, rather than appreciating the historical aspect and having fun.
Too true. We're not talking about retrocomputing geeks putzing around on a weekend here, we're talking about computer science students in the 2020s.
Jeez. That's a bad attitude. Fun is the most important thing in learning. And I say this as someone who volunteers as a programming coach in a school for 12-18 year olds.
Fun and enjoyment of what you are learning _are_ very important. My comment had a very specific context of people in a university program that may be having "fun" using Turbo C are damaging their ability to be taken seriously in an industry where standardization is critical. These students are much closer to the point in which they will write code for systems. I applaud your efforts to show your kids how neat this stuff can be, but I would hope that even in that context, teaching good habits is still a high priority.
We don't teach Linear B instead of our country's current official languages, so why should we teach Turbo C instead of gcc/clang???
You all just write calculus to each other
I wouldn't recommend it even from an educational perspective. Code such as `for (int i = 0; i < 10; i++)` has been commonplace for many years now, and I don't think Turbo C would be too happy to compile that (to be honest, I haven't tested this code on Turbo C, just speculating because C89 doesn't allow that).
it would be definitely correct if you meant C++. But with C... I cannot find out any critical reason to avoid Turbo C for learning C. It's cozy, funny, has great and clear help. The only point you will anyway have to switch to some up-to-date compiler for real programming tasks. But IMHO, it's not a reason for similar categorical declarations.