Your First THINK C Program
beyondloom.com
beyondloom.com
Whatever people will say, I still miss these "one pass" compilers, they were amazing and peaked with CodeWarrior, the best development suite, ever, in my nearly 40 years experience.
Nowadays we see autoshit "configure" stuff and compilers like gcc (some) or clang (oh my frigging GOD!!) trawl their way slowly and painfully thru the most simple projects without even support for plain basic stuff like automatic precompiled headers.
Wow look, we've NEARLY got Link Time Optimization working (took decades), in 2020 whoohoo, I'm so delighted. I could compile hundred of thousands of lines of light C++ or (better) plain C 25 years ago on a much, MUCH slower machine, with an simple editor that used the compiler lexer output so you had highlighting, real indexing it was 'just there' and always right, and always blinding fast.
I'm pretty sure we are way worse than we were 20 years ago for tooling. I'm sure some people will disagree, these people haven't seen CodeWarrior chew thru hundreds and hundreds of files in seconds.
Xcode is not bad now, though, and I think I'd miss the extremely robust autocomplete.
Heck, Turbo C for DOS would have been more productive.
Rest in peace.
Edit: not that TempleOS isn't beautiful, and I'm glad it exists and believe he achieved what he set out to do. I was just selfishly musing that if he hadn't lost his mind the way he did, maybe he would his ideas would have been adopted more in the mainstream. I'm also glad TempleOS exists in its incarnation, so it's conflicting.
JS has been able to do roughly what C did in the 1990's, in terms of raw performance, for some time now. The folks that need typechecking can pick up Typescript or Haxe or whatever else is attractive.
It's the bottom of the stack that really suffers - all the folks that want to work on stuff touching I/O and low level resources directly - and that is hardest to justify investing in. Unix and its baggage remain "untouchable", as these things go, and there are only some hints of promising developments otherwise.
Basically, what you are saying is that JS slows modern computers down to the speed comparable to 90's computers.
A benchmark like this [1] (showing c++ < js < java) is absolutely useless as the person writing it has no idea what they are doing, e.g. using vector in java.
Looking at most benchmarks java beats js more often than not, but they are often neck in neck.[2]
C++ always beats both, often by a huge margin (when written well).[3]
[1] https://www.linkedin.com/pulse/algorithmic-performance-compa...
[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[3] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
The one for k-nucleotide looked like it pushed JS the hardest for some reason. Interesting to compare how different languages fare:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
In this one, Java was 2.3x slower than C++, and Node.js 6.6x.
Oof, I concede. "JS has been able to do roughly what C did in the 1990's."
gcc is slow when you turn on all the optimizations. when computers were run by SysOps and every program needed to be recompiled from scratch for each slightly-different machine, it wasn't worth making the compiler ten times slower to make the program five percent faster. today, when browsers are compiled once and then run by millions of users for billions of hours a day, the tradeoff is different.
sure, autoconf is bad, particularly today when it's used completely wrong, but is it really worse than when programs had to be completely manually ported between different Unix versions, in a day when "package manager" had yet to be a twinkle in anybody's eye?
is everything great now? no, of course not. but you're grasping at the completely wrong straws here.
I wrote applications that were shipped on millions of computers in the 90s and I didn't have to make hard choices for building, the debug version were quicker to build sure, but the Release versions weren't a chore to make, and I was often building PPC/68k/debug/release in one go.
Also, this is a ridiculous defence of autoshit stuff. It hasn't been needed for well over 20 years, it's only purpose is self propagation where "oh I need autoconf blah because otherwise I can't build everywhere" where there is so much standardisation these days that there are MOSTLY TWO choices for nix systems. Not only that but it fails* all the time, on embedded for example; it doesn't 'save' and give you portability, it just gives you a false assurance that you are doing 'the right thing' by using it, while it's broken is many other ways.
More often than not, you can replace all that garbage with a 1/2 page Makefile. Who the hell needs to check wether the compiler /works/ or strdup /exists/ and all that idiocy. Or add dependencies for stuff while 'pkg-config' exists anyway. Who the hell actually /needs/ 'libtool' when there's about (perhaps) 3 ways of making a shared library on a unix system? And who the hell want or have the time to go and debug some stupid arcane 'm4' file to fix the weird problems that comes up?
Disclaimer: I build embedded distros for fun and profit, I deal with that stuff /all the time/ and most of my 'compile time' for distros is not even spent actually 'compiling' stuff, it's spent in the 'configure' stage, and 90% of my time fixing portability problem isn't in the code, it's in the autoshit stuff that somehow breaks in some new, interesting way.
Note that i refer to the compilers specifically, but even the IDEs you mentioned aren't that great. Visual C++ has went mostly downhill since VC6, becoming slower and even removing features (e.g. last time i tried it i couldn't use a bitmap font) or obfuscating them (installing a library "system-wide" is trivial in older versions of VS, but after 2008 or 2010 i think that feature was removed). C++ Builder's UI/IDE also went downhill after they got rid of the Delphi 7 interface and tried to become Eclipse and it also has became too unstable and slow. It does have a few niceties (i like that when you save your project it automatically updates the header file includes at the top), but nothing that makes it worth the negatives (though TBH i haven't spent much time with it because i refuse to rely on anything with DRM so i might be missing some gem covered under that bloat). Qt Creator is neat, but i could never get used to its interface (also it is free, so i'm not sure why you included it in a list of paid products).
Also IMO all the above do not hold a candle to the older Borland C++ Builder when it came to development experience. I do not think there is any C++ development environment that comes close nor i think it is possible to make one by stitching together a frankenstein of a product out of otherwise independent bits and pieces that are oblivious about each other (in other words anyone who thinks that something "based on" Clang or GCC or whatever, stitched together with LLDB, GDB or whatever and some GUI framework thrown in - usually Qt - would fit the bill is totally missing the point).
I included QtCreator, because for the full experience you need the commercial Qt offerings as well.
Windows now has a C++ package manager (vcpkg), so you can install libraries as you want.
Actually Clang provides the necessary IDE hooks that GCC doesn't.
I also consider the UI designers (UWP C++/CX is not that bad), graphical debuggers, pre-compiled headers database, incremental compiler, incremental linker, PGO integration, and being able to drive them without memorizing a ton of switches, part of the whole experience.
Realistically the paying subset of users of a language is always going to be a small number of people.
I am more than happy if on Windows, C gets reduced to the subset required by ISO C++.
Time to move on, C was already outdated in the mid-90, versus C++ARM, Modula-2 and Object Pascal.
Microsoft Security center is quite clear on the damage it has brought to the industry.
Objectively false, given the consistent popularity of C.
Plus, of course, the bad things about C are also bad about C++, in that C++ is more similar to C than different from it.
C's copy paste compatibility in C++ is the Trojan horse that ended up being its security Achilles heel.
However even with that, the C++ community and ISO C++ actually care to improve the language security story.
The same cannot be told for ISO C.
Actually even Microsoft does more for it with its Checked C research and SAL security annotations.
Very few posts on the WWW have the same attention to detail and wonderful playfulness as this one. It's an incredibly rare thing, and insanely pleasant to read.
That explains how that it had that classic Macintosh feel. Thanks!
document.head.appendChild(document.createElement('style')).sheet.insertRule('img:not(:hover) { image-rendering: crisp-edges !important; }', 0)
https://aphyr.com/posts/340-reversing-the-technical-intervie...
When compiling, there was a modal dialog that would show the name of each file being compiled...they went by fast even on early macs. Michael Kahl sped it up even more by figuring out that QuickDraw’s DrawText routine was still slow enough to be impacting compile time. So a custom blitter was made to replace it and a fast compiler got even faster.
macOS today is attractive and useful and colorful, but it feels so serious.
I'm a web programmer and I cannot wrap my head around how those machines rendered the graphics. I draw a 512 x 342 canvas on a webpage, if I loop pixel by pixel to draw an image using an array, the fans of my powerful computer start to scream. I'm not a graphics programmer maybe I am doing it wrong, but how the hell does an 8 Mhz computer with 128kb do it.?
Modern machines have huge overheads because of the indirection, virtualisation, and protection mechanisms we desire. On a webpage, you obviously don't have direct access to the framebuffer, but are drawing into some in-memory canvas. Drawing a single pixel in Javascript is going to go through many function calls, with probably orders of magnitude more instructions than you would have on an old Mac. There are still ways of getting (near) direct graphics access that is screaming fast, since people do write games and play videos and such, but there is much more ceremony to it now.
One interesting thing is that the ANSI library is relatively large, so I try not to use it, instead relying on ROM routines or reimplementing bits of stdlib that I need.
That's oddly specific. Mind, I approve; it's nice to see people trying things on less-common platforms and documenting the way:)
- download the minivmac said linked web site.
- you need to download also the vmac.rom and the system7.dsk.
- you can run the "mini Vmac.app" by clicking and drag and drop first the vmac.rom then the system7.dsk.
- your own disk needed to be created and drag-and-drop to the mini Vmac.app.
- follow the instruction.
- press control (and hold it) press H and other commands under H (you need to press control).
- it is a Mac the original one and hence you have to press the menu all the time :-). Forget that.
- and within a couple of minutes you have your first think C program in Mac 7.
Not sure I will go through the whole volume of Think C. One day may be one day.
And the alarm sound (for bug etc.) is a bit harsh as alarm sound go. Not sure how to change this.
There are benefits to modern operating systems with memory protection.
also:
./setup_t -t xl64 >setup.sh Unknown value for -t
attention to details indeed.
[edit]: I assume this'll only work on a Mac. Too bad, looked fun.
I use it daily and test and compile my programs on both Windows and Linux.
On the other hand I also stay away from projects that don't use cross-platform build-systems like Ninja, or CMake. Shell scripts are sometimes incompatible even between different distributions and shells.
The worst offender (that I know of) by far is GNU Octave. On Windows they basically ship a snapshot of a Linux dev box (complete with the whole directory tree, compiler suite and everything) with userland binaries compiled for Windows. So much for being "cross-platform"...
One of these is gratis and libre, and the other isn't. If you want to stand on that side with Windows and expect other people to help you out, then what you're asking for is for them to shell out money and a lot of effort for you. Whereas the reverse is not true; in comparison, the picture of a Windows user having to get access to a FOSS toolchain for themselves looks trivial—and with the abundance of ready-made system images that you can spin up without even having to reboot your computer, it is.
"Windows user" is not an ADA-protected class.
As recently noted in the build documentation, compiling it yourself is not recommended for most people. (First, the result will be much less efficient than the official binary unless you tweak things for your particular compiler. Second, there is the chance of running into compiler bugs and bugs in Mini vMac that show up only on some compilers - the official binaries are much better tested.)