It is said that the number of programmers doubles every five years with fresh CS, CE, and EE grads. Assuming that's true, then at any one time over half the developer community are novices in the early stages of their career.

My entire life's been spent in software and I've been in it now for about 15 years and I've seen a lot of people make alot of things and I've seen a lot of people fail at alot of things. My observation is that the doers are the major thinkers, the people that really create the things that change this industry are both the thinker doer in one person. It's very easy to take credit for the thinking the doing is more concrete. It's very easy for somebody say "oh, I thought of this three years ago" but usually when you dig a little deeper you find that the people that really did it. Were also the people that really worked through the hard intellectual problems.

Many people falsely believe that a great idea constitutes 90% of the work. However, there is a significant amount of craftsmanship required to bridge the gap between a great idea and a great product. As you evolve that great idea it changes and grows it never comes out like it starts because you learn a lot more as you get into the subtleties of it and you also find there's tremendous amount of trade-offs that you have to make.

There are certain things you can't make electrons do, certain things you can't make plastic or glass, certain things you can't make factories or robots do. and as you get into all these things, Designing a product involves juggling 5,000 different concepts, fitting them together like puzzle pieces, and exploring new ways to combine them. Every day brings new challenges and opportunities to push the boundaries of what's possible, and it's this ongoing process that is the key to successful product development. That process is the "magic"

I was today years old when I realized I could unzip with 7zip a excel, word, ppt files. Which then lead me down a rabbit hole of finding other OLE type files.. altium schematic files, brd files etc

Let’s rant… Web 3.0

3
2
1
…..
Opinions fire away!…

Tips for architecture for authentication in microservice driven application.

All ms contain the code to authenticate? (Breaks single responsibly principle)

Edge level authorization?(gateway)
Service level?

Question.. architecting a large system. I’ve broken it down to microservices for the DB and rest API / gateway

I want there to be some some processes that run continuously not event driven via rest. Say analytics for example what is the best way todo that? Just another service running on on a server? And said service has its own API? That when the other rest APIs are called could then hop and call the new service?

Or say we had a PDF upload via rest should that service then do the parsing before uploading to DB .. or should the rest api that does the uploading then call another rest api to another service dedicated todo the parsing and uploading to the db?

I think the bigger way to explain the question is the encapsulation between DAL.. data access layer which I have existing.. but then there’s the BLL .. buisness logic layer which I don’t know if it should have its own APIs via own microservices running in the background.

Need to go old school again, go back to hosting their own servers and peer to peer mesh networks. Eliminate the shackles of big tech... Eliminate the control and power they have over you. The only reason they are used is the idea of simplicity and low entry cost. But you pay for that later, when they deem you to be a competition, or don’t align with their goals.

I’m down.. we did 2020 ... let’s do 2021 essentially 2020.. but SPACE THEMED!!! Let’s go let’s go let’s go!!! Start the game!!!! Seems soo fitting since space force and the whole galactic federation foreshadowing a few weeks ago!!!

So good to see flash finally be put to pastor. Am I sad no flash sucked from a developer standpoint but even more from a business standpoint! Why? Here’s why!

....Yes it was fast in the sense of quickly getting content out and functioning BUT this ment you are at the mercy of Adobe / Macromedia (depending on the timeframe) for support AND mercy of the company whom create the browsers for support.

Meaning your product is fully reliant on others for existence and can easily not exist if one of two other beings choose.

For developers shame on you for accepting this you should never have supported this.. if you did it was just for a job you are suppose to be experts in your field and when management came to you for guidence you allowed this technology to be used rather than saying no this isn’t good! It’s too risky...

Fuck... how many people choose a career path that made them flash only developers.. well guess what becuase you niched yourself now your out of a job... rethinking now?

CAN ANY OF YOU TELL ME WHAT OTHER WIDLY USED TECHNOLOGY IS RELIANT ON A SEPARATE ENTITY?!

geee it would be a shame if one day that technology was phased out or no longer supported and then a date was picked and boom shutdown... geee that would suck...

I remember for years before it was announced it would be ending ... I said development around flash should be avoided at all costs because of it’s reliance on someone else for your product to function and exist...

Let this be a foreshadowing/ warning... learning experience/ AMAGE.. to those who use similarly situated technologies...

Developers you were warned.

Businesses you were warned.

Let’s all try to agree collectively, if we can rid the world of one IDE and/or Text Editor what one would that be...

3

2

1

GO!

Been reviewing ALOT of client code and supplier’s lately. I just want to sit in the corner and cry.

Somewhere along the line the education system has failed a generation of software engineers.

I am an embedded c programmer, so I’m pretty low level but I have worked up and down and across the abstractions in the industry. The high level guys I think don’t make these same mistakes due to the stuff they learn in CS courses regarding OOD.. in reference how to properly architect software in a modular way.

I think it may be that too often the embedded software is written by EEs and not CEs, and due to their curriculum they lack good software architecture design.

Too often I will see huge functions with large blocks of copy pasted code with only difference being a variable name. All stuff that can be turned into tables and iterated thru so the function can be less than 20 lines long in the end which is like a 200% improvement when the function started out as 2000 lines because they decided to hard code everything and not let the code and processor do what it’s good at.

Arguments of performance are moot at this point, I’m well aware of constraints and this is not one of them that is affected.

The problem I have is the trying to take their code in and understand what’s its trying todo, and todo that you must scan up and down HUGE sections of the code, even 10k+ of line in one file because their design was not to even use multiple files!

Does their code function yes .. does it work? Yes.. the problem is readability, maintainability. Completely non existent.

I see it soo often I almost begin to second guess my self and think .. am I the crazy one here? No. And it’s not their fault, it’s the education system. They weren’t taught it so they think this is just what programmers do.. hugely mundane copy paste of words and change a little things here and there and done. NO actual software engineers architecture systems and write code in a way so they do it in the most laziest, way possible. Not how these folks do it.. it’s like all they know are if statements and switch statements and everything else is unneeded.. fuck structures and shit just hard code it all... explicitly write everything let’s not be smart about anything.

I know I’ve said it before but with covid and winning so much more buisness did to competition going under I never got around to doing my YouTube channel and web series of how I believe software should be taught across the board.. it’s more than just syntax it’s a way of thinking.. a specific way of architecting any software embedded or high level.

Anyway rant off had to get that off my chest, literally want to sit in the corner and cry this weekend at the horrible code I’m reviewing and it just constantly keeps happening. Over and over and over. The more people I bring on or acquire projects it’s like fuck me wtf is this shit!!! Take some pride in the code you write!

Am I the only one who when they are super focused writing code and debugging starts acting like Bob Ross painting a picture?(without a filter... of course)

And here we’ll add another little god damn breakpoint so we can watch our fucked up variables report the wrong thing..

Oh and over here will just add another little happy simple if statement.

Oh look at the happy if statements in a row.. maybe we’ll add little switch statement here.

From 1978 comes the original, go to C programming language book. About 200 pages, packed full of the details of the C language. It’s a book that sits on your desk. No matter how many times I’ve read this book I always find something new in it.

Great book written.

Only recently purchased the physical books edition 1 and 2.. in the past I only ever read it on pdf or someone else’s hardcopy.

Being a embedded engineer, shame on me for not having this book at a desk ornament sooner lol.

Been busy, received this book today. Got some time and reading it on this nice evening.

I have no review as I’m still reading it.

Been really busy with things haven’t got around to posting a book in like a week or so..

But I’ll post one today..

This book...

This book, available for free online or you can buy it, written in 1994. But so under appreciated by people for some reason most people never have seen it or know about it. But this is the ONLY book I know of that actually covers this topic.. the only book in existence that specifically goes thru how OOP can be done with C.

NOW hold up before you say just use C++ stop and think for a second.. bear with me.

First off this book is purely for informational purposes and educational use to deepen your understanding of what OOP is actually doing behind the scenes in languages like C++ where keywords exist for these things and you just blindly use them without thinking about under the hood.

This book contains a lot of code and builds you up a complexly library from scratch to make OOP in C... now I don’t take this book literally and this but I have implemented some concepts from this book in projects in the past, and it helps a lot.

Also in my honest opinion If you finish this book, you will be a better C programmer AND c++ programmer, C programming because it teaches you a lot about complex things that you never thought about doing with the language. It proves you can do polymorphism can do inheritance and encapsulation. And it’s not really bloated either.

This books is an awesome book, if you don’t understand C pointers you definitely will after this book.. if you don’t understand OOP in C++ what’s really going on.. you will after this book. After all C++ began as just a preprocessor of C.

Great book for writing reusable, extendable large scale embedded c systems.

Anyway.. rare book of which should not be rare considering it’s free.

I am on a mission to go thru all the of bibliographies of all the books I have, and create a checklist of the books I have and don’t have, and continue to buy all the books in that list, add to the list for each new book I buy that references another book. UNTIL! The day I have a closed loop reference. to essentially “in this room all the books that each book references may also be found in this room, if the book isn’t in this room no other book references it.”

I’m slacking been so busy, forgot to post yet another book..

Soo here ya go..Engineering A Compiler.

For those who don’t like the Red Dragon compiler book for whatever reason, most don’t like it because they don’t believe the dragon book covers topics in a “Teachy way” and doesn’t explain certain things. As well as not cover one topic.

Then this may be the book for you. It’s significantly newer than the “Dragon book” and I believe it does do a better job laying out for “learning”.. I could see this book being used in universities.. I’m sure it is, but mine never had a compiler course so whatever. Good book

Fun fact.. it references the dragon book, as well as the other books the dragon book authors wrote as well as articles in the ACM..AND! It also references Knuths art of computer programming and other books of knuth AND references the Algorithms book. All books I have previously posted.

I have not read this book, only skimmed as I have recently received it this one. May do a follow up or even at it to the list to make a YouTube playlist going chapter by chapter thru the book.

Here’s the second book for today.

Another small 100 page or so book.

It’s called advanced programming techniques, personally I don’t like the title, I don’t consider most of the items in here advanced, I would consider them more “better ways of solving a problem”, they do talk about recursion and linked lists, so I guess that could be a little advanced.

But like table based solutions is not advanced it’s just a technique that allows for simpler, scale able and main table code.. I been doing it for a long time, most easiest way to determine if something can turn into a table solution is look for a function that has a bunch of calls to the same function or something of that nature lots of repeated code with slight changes in a function or range of functions .. those of simplist way of “tablefiying”a solution I will picture the example from the book below.

The book, is all in java except for linked lists Thats in C..

But anyway this book is a great quick reference book, into the pile with programming pearls book, and those like that.

Forgot to post a book yesterday, so maybe I’ll post two books today...

Anyway, this book, I found it recently never seen it before. But boy is it great.

It’s similar to the programming pearls book as far as what it’s about. Think of the refactoring book, clean code, programming pearls, and the mythical man month books, thrown in a blender, added some new spice and some new things, and filtered down into 100 or so page book, simple quick and enjoyable actually.

This book the references staple books by Sedgwick, knuth, Brooks, Myers, and so many others. It’s funny how things come full circle.

My favorite quote from the book. I’ve been essentially saying this for years, but to see it on a book, it’s lovely... more people need to realize it too.

“Understanding how things work at a low level becomes a base for making good decisions at the high level”

Followed up with if you’ve never built a computer from scratch your missing out... get yourself a breadboard and some TTL logic.. and build a 4 bit CPU, once you know how to program in assembly the next step is building your own computer ... if your university didn’t teach a class that did this they ripped you off....

Don’t bitch at me.. the book said that.. and I agree! 100% because it’s true, you can’t debate that.

Oh and btw this is another book written by a female developer.. kudos to her for nailing so many topics in such a short book!

Here’s book most of you have either read a newer edition or some variant based on this book, as computer science students you had to take an intro to logic course.. prior to digital logic.. or atleast that’s how it went for me and many others I know.
Which regardless how much the universities screwed up teaching comp sci and programming.. this is one aspect I think they nailed. Requiring philosophical logic course for comp sci.

Again this isn’t a digital logic book. It’s just philosophical logic. The first edition of this book came out in 1953... and I think they are edition 14 or 15... for a book to have this many editions and last this long thru time it’s a good book.

It’s a book that should be a must read for anyone venturing into AI and working on human machine thought processing.

It’s a great book to have around as reference, considering philosophical logic is not a walk in the park atleast not in the beginning because it requires you to change the way you view things.. more specifically it requires you to think objectively and make decisions objectively rather than subjective emotional reasoning.

Programmers need to think objectively with everything they do. The moment you begin thinking subjectively .. ie personal style, wishes and wants, or personal reasons and put that into code for a code base with a team u just put the team at risk.

Does this book teach objective thought? No... indirectly yes, because it teaches the objective rules of logic... you don’t get to have an emotional opinion on wether you agree or disagree or whatnot, logic is logic even philosophical. Many people failed the logic course I was in university.. infact the bell curve was c- / D ... many people had to take the course more than once.. they even had to change the way the grading was done.. just to get more people to pass...

But here’s the thing it’s not about it being taught wrong.. people just couldn’t adapt to thinking objectively, with rules as such in philosophical logic courses. Grant it the symbols takes time getting use to but it literally wasn’t the reason people failed.. it was their subjective opinions and thought process interfereing with the objectiveness of the course exams and homework.

Very few general embedded systems books exist, most are specific to chip, or architecture. Very few cover overall ideas, and concepts that are common across ALL embedded systems regardless of architecture and things you must keep in mind while designing software for them.

I think this a a good book. As a primer for deep diving into embedded systems design philosophy

I really like this book on the basis of the philosophy overall, no this doesn’t solve all problems but it’s a good baseline of “guidelines/rules” to program by. Good metrics or goals to architect and design software projects high and low level projects.

Fight Software Rot
Avoid duplicate code
Write Flexible, dynamic, adaptable code
Not cargo cult programming and programming by coincidence.
Make robust code, contracts/asserts/exceptions
Test, Test, and TEST again and Continue testing.. this is a big one.. not so much meaning TDD.. but just testing in general never stop trying to break your software.. FIND the bugs.. you should want to find your bugs. Even after releasing code the field continue testing.

It’s throw back Thursday folks...

Today’s post sets us back to a time long before the internet. Before C ... from the days of FORTRAN.. COBOL .. and LISP... How was info not taught in classes and published in large books shared???? Well it’s was journals like these, sent out monthly and quarterly for some. They would publish their findings to these type “magazines” but extremely technical.

This is one of the oldest editions have. Trying to collect them.

I believe in Knuths TAOCP, he references the first article of this edition... I’ve seen that article referenced in one of my books but i forgot which book.. pretty sure TAOCP.. anyway..

Just a fun throw back. Btw... just because it’s from 59’ doesn’t mean the information is irrelevant.. the information is facts the equations are true.

If you are reading Coding for dummies book to learn software you are doing it alllll wrong lol ... Please while I appreciate your effort and willingness to try but no.. just no.. put the book down that book won’t teach you shit.

Same thing if you are one of those folks who got conned into believe “you can land a programming gig by signing up and paying for this 6 week course!!” Bullshit.. I like your initiative but there’s soooooo much more than that and it won’t even touch the surface. You will end up believing a false reality that you think you know what your doing but you don’t know how much you really don’t know. But like it doesn’t even scratch the surface don’t even attempt Get a job after those courses or coding for dummies book. You will be laughed at..

In fact I almost want to buy the coding for dummies book to have it in my collection of software books to not read. Which I will say is very small. There’s more really good books than really bad.. and obviously plenty of average. But the bell curve lands above the better half.

If there is 2 books you should read before trying to tackle TAOCP... this might be on it.. as well as the Concrete Mathematics book.

Anyway. This book covers not just the fundamentals of modern algorithms and data structures but it also makes the leap to understanding multithreading and algorithms using multithreading.

Some argue the certain concepts in this book are presented without explanation of how they work, but I guess that should be something the reader try’s to figure out from another book or constructive thinking critically. Keeps the reader on their toes for understanding.

This is also the reason many people suggest the sedgewick algorithm books, of which will be posted another day.

This Book....

Before doing any systems programming you should definitely read this book... most people think they know what they are doing but in fact they are completely clueless and the worst part is you don’t realize how clueless you are... you don’t know what you don’t know nor do you know how much you really don’t know.. a most people are part of this group, including myself lol.

Computers are much more than a bunch of CPUs, buses and peripherals. (Embedded folks realize this). But this goes beyond embedded this is a systems book, on architecture of computers in general.

Learning only java and the java/C# python and the others SDK/Api and spending your life with horse blinders for what’s going on below only sets you up for failure in the future, and when you that point it’s gonna be a shocker. Could be tomorrow could be 20 years from now, but most people with those horseblinders get to that point and have that “experience” no avoiding the inevitable lol.

I really enjoyed this book in their quantitative approach to teaching the subject. Especially understanding parallelism and multi core systems.

I know I’ll get mixed views for this one...

So I’ll state my claim. I agree with the philosophy of uncle bob, I also feel like he is the high level language - older version of myself personality wise.. (when I learned about uncle bob I was like this guy is just like me but not low level haha).

Anyway.. I don’t agree with everything because I think he thinks or atleast I get the vibe he thinks everything can be solved by OOP, and high level languages. This is probably where Bob and I disagree. Personally I don’t touch ruby, python and java and “those” with a 10 foot pole.

Does he make valid arguments, yes, is agile the solve all solution no.. but agile ideas do come natural and respond faster the feedback loop of product development is much smaller and the managers and clients and customers can “see things” sooner than purly waterfall.. I mean agile is the natural approach of disciplined engineers....waterfall is and was developed because the market was flooded with undisciplined engineers and continues to flood, agile is great for them but only if they are skilled in what they are doing and see the bigger picture of the forest thru the trees.. which is the entire point of waterfall, to see the forest.. the end goal... now I’m not saying agile you only see a branch of a single tree of the forest.. but too often young engineers, and beginners jump on agile because it’s “trendy” or “everyone’s doing it” or whatever the fuck reason. The point is they do it but only focus on the immediate use case, needs and deliverables due next week.

What’s wrong with that?? Well an undisciplined engineer doing agile (no I’m not talking damn scrum shit and all that marketing bullshit).. pure true agile.
They will write code for the need due next week, but they won’t realize that hmm I will have the need 3 months from now for some feature that needs to connect to this, so I better design this code with that future feature in mind...

The disciplined engineer would do that. That is why waterfall exists so ideally the big picture is painted before hand.

The undisciplined engineer will then be frustrated in the future when he has to act like the cool aid man thru the hard pre mature architectural boundaries he created and now needs links or connections that are now needed.

Does moving to agile fix that hell no.. because the undisciplined engineer is still undisciplined.

One could argue the project manager or scrum secretary... (yes scrum secretary I said that right).. is suppose to organize and create and order the features with the future in mind etc...

Bullshit ..soo basically your saying the scrum kid is suppose to be the disciplined engineer to have foresight into realizing future features and making requirements and task now that cover those things? No!
1 scrum bitch focuses too much on pleasing “stake holders” especially taken literally in start ups where the non technical idiots are too involved with the engineering team and the scrum bastard tries to ass kiss and get everything organized and tasks working so the non technical person can see pretty things work.

Scrum master is a gate keeper and is not needed and actually hinders the whole process of making a undisciplined engineer into a disciplined engineer, makes the undisciplined engineer into a “forever” code grunt... filling weekly orders of story points unable to see the forest until it’s over because the forest isn’t show to the grunt only the scrum keeper knows the big picture..... this is bad this is why waterfall is needed.

Waterfall has its own problems, But that’s another story for another day..

ANYWAY... soooo where were we ....

Ahh yess....

Clean code..

Is it a good book, yes.. does uncle bobs personality show thru the book .. yes lol.
If you know uncle bob you will understand what I just did with this post lol. I had to tangent ( at least mine was related to the topic) ...

I agree with the principles of the book, I don’t agree with the extreme view point. It’s like religion there’s the modest folks and then there are the extremists. Well he’s the preacher of the cult and he’s on the extreme side.. but that doesn’t mean he’s wrong.. many things he nails... he just hits the nail thru the wall just a bit.

OOP languages are not the solution... high level languages do not solve everything.. pininciples and concepts can be used across the board and prove valuable.. just don’t hold everything up like the 10 commandments of which you cannot deviate from.. that’s the difference here I think..

Good book, just don’t take it as the Bible as a beginner, actually infact DONT read this book as a beginner. Wait a bit learn then reflect by reading this.

Here’s Today’s book, a little late in the day but we had a storm here and lost power. Powers back

Anyway Programming Pearls, this books isn’t so much a tutorial book, or like “how to program book” it’s more an influential book and thought book. Similar to the mythical man month book.

It’s short book little over 200 pages, of short essays on problems that have irritated programmers over the years. Hence the amage to pearls as a pearl is developed from grains of sand that irritate oysters. This book is a collection of irritants of programmers. (No not the social or business side of things) but technical problems we all face.
These articles are compiled from the original postings that occurred in the Communications of ACM journal, back in the late 90s.

This books offers workable solutions to these “pearls”.

Think of this like one of the precursors to what we have now as stack overflow .. information was shared via journals since the internet wasn’t available but not so much question then respond like we do more of hey I had this problem here’s the solution sort of system.

It’s the type of book, when your bored and you don’t want to read some “how to book” you read this, just like mythical man month and others.

This book references items from knuths books. As well as references to others.

So here’s to the pearls the plague us all.

Working in the embedded systems industry for most of my life, I can tell you methodical testing by the software engineers is significantly lacking. Compared to the higher level language development with unit tests and etc, something i think the higher level abstracted industry actually hit out the of park successfully.

The culture around unit testing and testing in general is far superior in java and the rest.

Down here in embedded all too often I hear “well it worked on my setup... it worked at my desk”.. or Oh I forgot to test that part.. or I didn’t think that perticular value could get passed in... etc I’ve heard it all. Then I’ve also heard, you can’t do TTD or unit tests like high level on embedded... HORSESHIT!

You most definitely can! This book is a great book to prove a point or use as confirmation you are doing things correctly. My history with this book was I gonna as doing my own technique of unit testing based on my experience in the high level. Was it perfect no but I caught much more than if I hadn’t done the testing. THEN I found this book, and was like ohh cool I’m glad I’m on the right thought process because essentially what they were doing in the book is what I was doing just slightly less structured and missing a few things.

I’ve seen coworkers immediately think it’s impossible to utilize host testing .. wrong.

Come to find out most the of problems actually are related to lack of abstraction or for thought out into software system design by many lone wolf embedded developers.. either being alone, or not having to think about repercussions of writing direct register writes in application or creating 1500 line “main functions” because their perception is “main = application”. (Not everyone is like this) but it seems to be related to the EEs writing code ( they don’t know wha the CS knows) and CS writing over abstraction and won’t fit on Embedded... then you have CEs that either get both sides or don’t.. the ones to understand the low level need but also get high level concepts and pariadigms and adapt them to low level requirements BOOM those are the special folks.

ANYway..the book is great because it’s a great beginner book for those embedded folks who don’t understand what TDD is or Unit testing and think they can’t do it because they are embedded. So all they do is AdHoc testing on the fly no recording results no concluding data very quick spot check and done....

If your embedded software engineers say they can’t unit test or do TDD or anything other than AdHoc Testing...Throw the book at them and say you want the unit test results report by next week Friday and walk away.

Lol

Probably the MOST complete software book on a very broad subject.

This is book to read for those of you are near college grad, first job in the industry. But to the level of detail and broad coverage this book has I think it’s actually a great book for everyone in the industry almost as a “baseline”

From requirements, project planning, workflow paradigms. Software Architecture design, variable naming, refactoring, testing, releasing the book covers everything, not only high level but also in reference to C.

Why C ...because in the consumer electronics, automotive industry, medical electronics and other industries creating physical products c is the language of choice, no changing that. BUT it’s not a C book... it contains C and goes into dept into C but it’s not a C book, C is more like a vehicle for the book, because there are long established, successful industry’s built around it. Plenty of examples.

When I say it’s the most complete on a broad subject seriously like example the chapter about the C language is not a brief over like many other books, for example 10 pages alone are dedicated to just pointer! Many C books have only a few paragraphs on the subject. This goes on depth.

Other topics, recursion, how to write documentation for your code.

Lots of detail and philosophy of the construction of software.

Even if you are a veteran software engineer you could probably learn a thing or two from the book.

It’s not book that you can finish in weekend, unless you can read and comprehend over 1000 pages.

Very few books cover such a broad topic ALL while still going into great detail on those subtopics. the second part is what lacks in most “broad topic books” ..

Code Complete.. is definitely “Complete”

So the image doesn’t match the rest of my book images because I tried to make an amage to cover of the book, inception style kinda haha 😂

It’s throw back Thursday!

Back to 1979... before the time of the red dragon book compiler book, (forgetting about the green dragon book) ... there was a time where only a few well written compiler and assembler “theory” books existed.

What’s special about this one? Well Calingaert was the co patentor of the OS/360. .. “okay soo? ... well Fred Brook’s Mythical Man-Month book I posted the other day. Calingaert is basically the counterpart of brooks on the OS/360.

Anyway, the code is in assembly (obviously) and the compiler code is basic.

Other than this book and from my understanding 2-3 other books that’s all that was available on compilers and assemblers as far as books written goes at the token.

ALLL the rest of knowledge for compilers existed in the ACM and other computing journals of the time.

Is this book relevant today, eh not really, other than giving prospective, it’s a short in comparison to the red dragon books.

If you did read it, it’s more of a book that gives you more lecture and background and concepts.. rather than here’s a swath of code.. copy it and run.. done.. nope didn’t happen in this book.. apply what you lean here