Cook Ding was cutting up an ox for Lord Wenhui. As every touch of his hand, every heave of his shoulder, every move of his feet, every thrust of his knee — zip! zoop! He slithered the knife along with a zing, and all was in perfect rhythm, as though he were performing the dance of the Mulberry Grove or keeping time to the Jingshou music.
“Ah, this is marvelous!” said Lord Wenhui. “Imagine skill reaching such heights!”
Cook Ding laid down his knife and replied, “What I care about is the Way, which goes beyond skill. When I first began cutting up oxen, all I could see was the ox itself. After three years I no longer saw the whole ox. And now — now I go at it by spirit and don’t look with my eyes. Perception and understanding have come to a stop and spirit moves where it wants. I go along with the natural makeup, strike in the big hollows, guide the knife through the big openings, and following things as they are. So I never touch the smallest ligament or tendon, much less a main joint.
“A good cook changes his knife once a year — because he cuts. A mediocre cook changes his knife once a month — because he hacks. I’ve had this knife of mine for nineteen years and I’ve cut up thousands of oxen with it, and yet the blade is as good as though it had just come from the grindstone. There are spaces between the joints, and the blade of the knife has really no thickness. If you insert what has no thickness into such spaces, then there’s plenty of room — more than enough for the blade to play about it. That’s why after nineteen years the blade of my knife is still as good as when it first came from the grindstone.
“However, whenever I come to a complicated place, I size up the difficulties, tell myself to watch out and be careful, keep my eyes on what I’m doing, work very slowly, and move the knife with the greatest subtlety, until — flop! the whole thing comes apart like a clod of earth crumbling to the ground. I stand there holding the knife and look all around me, completely satisfied and reluctant to move on, and then I wipe off the knife and put it away.”
“Excellent!” said Lord Wenhui. “I have heard the words of Cook Ding and learned how to care for life!”
I'm convinced slowing feeding students, and having them produce good low-level codebase(s) (e.g. OSs, compilers) is a great Way to "holistically" teach them CS, much better than what's happening usually. "C is a razor-sharp tool"!
The Master might say something like this, if translated crudely -
Software engineering is programming professionally, with a dialogue on quality. Everything else is details.
The IEEE has been riding this horse for a very long time, in the face of very serious criticism (see the ACMs comments from a quarter century ago).
The presentation of it is _not even wrong_. It reads like a mid level manager at a very old enterprise firm wrote out what important at their firm, and took no material care for other ways. The SWEBOK has been that way for as long as I can remember ( an aside: my experience of Software Engineering academia has been so deeply negative to the point I wrote the field off in 2013. Decoupled from reality, PM oriented, toy studies- irrelevant. The SWEBOK is an artifact of that world. I should dip back in... Maybe Google & MS Research have done the real work here...)
There's a body of _practice_ that is mildly incidental. Most acronyms are fads. Lots of ephemeral technologies that only exist as painful grimaces. IE- CORBA- SOAP, etc...
Project management and quality management are also essentially contingent. One company does this. One that. Waterfall here. Agile there. Whirlpool the other.
What you're left with as non contingent and timeless is in the area of compilers, algorithms, etc. Which is not SWE at all.
If I were to write a swe body of knowledge, it would be in koan form, more than likely.
> The IEEE has been riding this horse for a very long time
Well, there's your mistake right there. You're supposed to be riding an ox.
All this talk of oxen and horses got me curious about the PDF, so I went and took a look. It's really far worse than you've described.
I couldn't stomach it for too long, but here's some highlights:
(1) The first ~65 pages are about "requirements gathering." Page 60 offers up this gem of insight:
Priority = ((Value * (1 - Risk)) / Cost
(2) The next hundreds of pages go through topics in sequence, like "Architecture" and "Design" (who knew they were different?). Naturally, "Security" is slapped on several hundred pages later.
I couldn't make it through the whole PDF, in all honesty. But I'm quite certain the soul of software engineering is nowhere to be found in there; they've eliminated it entirely and replaced it with stamp-collecting and checklists.
There appears to be a lot of hate towards this in the comments (because it's not perfect?), but I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it.
Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge about software engineering. And they all lack fundamental knowledge about the processes used to do the work.
That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus, much less teach them about it on the job. But that's completely normal in software engineering today, because nobody is expected to have already learned a universal body of knowledge.
I get this thing isn't perfect. But not being perfect isn't a rational argument for not having one at all. And we certainly need to hold people accountable to have learned it before we give them a job. We need a body of knowledge, it needs to be up to date and relevant, and we need to prove people have actually read it and understood it. If this isn't it, fine, but we still need one.
(this is, by the way, kind of the whole fucking point of a trade school and professional licensing... why the fuck we don't have one for software engineers/IT, boggles my fucking mind, if this is supposed to be the future of work)
The day computing becomes subject to professional licensure is the day the field of computing will fall into hopeless stagnation, just like every other such field.
> The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), published by the IEEE Computer Society (IEEE CS), represents the current state of generally accepted, consensus-based knowledge emanating from the interplay between software engineering theory and practice. Its objectives include the provision of guidance for learners, researchers, and practitioners to identify and share a common understanding of “generally accepted knowledge” in software engineering, defining the boundary between software engineering and related disciplines, and providing a foundation for certifications and educational curricula.
So at the start of each chapter, the book has a table of abbreviations and their definitions, called 'Acronyms'. To whoever wrote or edited the book: please lookup the definition of the word 'acronym': "an abbreviation formed from the initial letters of other words and pronounced as a word (e.g. NASA)." Not all of the abbreviations listed are acronyms! Most are just plain old initialisms.
Since when has anyone ever tried to pronounce 'GPS' as anything other than G-P-S? Also "ECS" = "Ecosystem"? Maybe I'm just crazy but I've never heard or read anyone abbreviate ecosystem as 'ECS'. I've come across ECS as entity component system in video game engines, but never as just 'ecosystem'. Also it's defined exactly once in chapter 5 and then never used again in the book. Why even bother to mention it then?
Oh and publish it as a PDF, but then have no actual page numbers?
SWEBOK 4 adds a dedicated section for security, but it's painfully 2012 (testing, for instance, centers on the old industry-driven "SAST" vs. "DAST" distinction). It also promotes stuff like Common Criteria and CVSS. The "domain-specific" security section could have been pulled out of the OWASP wiki from 2012 as well: "cloud", "IOT", "machine learning".
After seeing so much negativity and controversy around this book in the comments, I'm quite convinced to giving it a read.
I've seen so little "engineering" in software world, regardless of the company and how many ivy league devs it hires to be fully convinced that a work of encoding software engineering knowledge is worth the effort, and even attempts like this are valuable reads in such a gigantic vacuum, even just to start a discussion and to be able to disagree on definitions and practices.
It's probably also worth reading Dijkstra's assessment of the "software engineering" field (roughly coextensive with what the SWEBOK attempts to cover) from EWD1036, 36 years ago.
> Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".
The ACM's criticisms, however, are much harsher and much more closely focused on the ill-conceived SWEBOK project.
The IEEE's continued involvement calls the IEEE's own credibility and integrity into question—as do its continued opposition to open-access publishing and its recent history of publishing embarrassingly incompetent technical misinformation in IEEE Spectrum (cf., e.g., https://news.ycombinator.com/item?id=41593788, though there are many other examples). What is going on at IEEE?
Wanted to call out the specific requirements for what the ACM wanted out of their participation in creating a core body of knowledge (from the linked reasoning):
* It must reflect actual achievable good practice that ensures quality consistent with the stated interest; it is not that following such practices are guaranteed to produce perfect software systems, but rather that doing so can provide reasonably intuitive expectations of quality.
* It must delineate roles among the participants in a software project.
* It must identify the differential expertise of specialties within software engineering.
* It must command the respect of the community.
* It must embrace change in each and every dimension of its definition; that is, it must be associated with a robust process for ensuring that it is continually updated to account for the rapid change both in knowledge in software engineering and also in the underlying technologies.
It then details exactly how SWEBOK fails to meet those (which all still seem to be relevant) and comes to the following scathing conclusion:
Overall, it is clear that the SWEBOK effort is structurally unable to satisfy any substantial set of
the requirements we identified for bodies of knowledge in software engineering, independent of
its specific content.
I haven't read the SWEBOK but some spot checking and a review of the ToC seems to indicate they have not meaningfully taken that criticism into an account.
> The ACM canceled its involvement for excellent reasons which are worth reading
Interesting, thanks for the hint; the paper is from 2000 though, and as it seems it would need an update; just checked e.g. the "roles" point and it seems there were significant changes. I also think ACM has rather different goals than IEEE.
> It's probably also worth reading Dijkstra's assessment of the "software engineering" field
Well, was there anything or anyone that Dijkstra didn't rant about ;-)
As much as I like Dijkstra and this particular article of his (it is an assigned reading in my "Software Engineering" class), developing any large scale software that we have today starting from formal methods is just a fantasy.
I understand the importance of learning formal methods (discrete math, logic, algorithms, etc.), but they are not nearly enough to help someone get started with a software project and succeed at it.
So, if not "software engineering", then what should we teach to a student who is going to be thrown into the software world as it exists in its current form?
Very interesting. Particularly their notion (paraphrasing) that SWEBOK attempts to record generally recognised knowledge in software engineering while excluding knowledge about more specific subdomains of software.
That over-deference towards general knowledge coupled with some sort of tie to a similar Australian effort probably explains why the software engineering degree I began in Australia felt like a total waste of time. I remember SWEBOK being mentioned frequently. I can't say I've gotten terribly much value out of that learning in my career.
The thing here is, this reads like a prissy textbook that no-one can really disagree with but is still not gripping the reality. More HR handbook than blood-red manual.
For example, project management. The book covers this but does the usual wrong headed way of imagining there are executives with clear eyed Vision and lay down directives.
This is of course not how most projects in most companies are started. It’s a mess - reality impinges on the organisation, pain and loss and frustration result in people making fixes and adjustments. Some tactical fixes are put in place, covered by “business as usual”, usually more than one enthusiastic manager thinks their solution will be the best, and a mixture of politics and pragmatism results in a competition to be the one project that will solve the problem and get the blessed budget. By the time there is an official project plan, two implementations exist already, enough lessons learnt that the problem is easily solved, but with sufficient funding all that will be abandoned and have to be rebuilt from scratch - and at a furious pace to meet unrealistic expectations that corners will be cut leading …
You know that you could be speaking about mining operations or building highways in your post rather than software and everything would apply the same?
I really don't see the argument against the book here in your comment.
Runtime errors surface when a program
runs into an unexpected condition or situation
such as dividing by zero, memory overflow, or
addressing a wrong or unauthorized memory
location or device, or when a program tries to
perform an illegitimate or unauthorized operation
or tries to access a library, for example.
The programs must be thoroughly tested for
various types of inputs (valid data sets, invalid
data sets and boundary value data sets) and
conditions to identify these errors. Once identified,
runtime errors are easy to fix.
I had to open the PDF and find this line to confirm. It really says that. It reads as if claiming that any program that accesses a library will then have a runtime error. That is obviously not what they intended, but I have read it over a few times now and cannot see another interpretation.
That line is referring to shared libraries linked to a dynamic executable. If a shared library isn't installed or available you will receive an error similar to the following:
$ ./main
./main: error while loading shared libraries: librandom.so: cannot open shared object file: No such file or directory
Which is indeed a runtime error.
There is also the common use case of hot-reloading compiled code which dynamically loads and unloads shared libraries without restarting the entire application. It needs to be done carefully but you've likely used an application that does this. Failure to load a library, or loading an incompatible one will also create a runtime error.
Looks like there is a lot of bad generalizations in here, but they are technically correct on this one.
I understand that is what they meant, but it is not what they wrote. They should have qualified the statement as you did, with the conditions that yield a runtime error. Even if they generalized those conditions that would have been fine.
for example:
or tries to access a library that it is unable to for some reason without handling the resulting error.
I suppose, yeah, when I figure out the exact reason why the error occurred, fixing it is often easy. The finding, however, can often take a long time, which leaves me feeling "once you have driven across the continent, finding your desired endpoint is a quick process". "Once constructed, installing the door on your new house is a simple and easy task". Well, sure, if you take out the time-consuming parts, it's quick and easy.
Except for all those runtime errors where the fix required major refactoring, or the problem is in a third party library, the OS, or some other unchangeable component.
What exactly is wrong with it? That is a definition fit for someone who does not have prior knowledge of what a runtime error is. It might be boring to us, and I might word it a little different, but it's fine.
Swebok is an attempt to look at the whole ox
Cook Ding was cutting up an ox for Lord Wenhui. As every touch of his hand, every heave of his shoulder, every move of his feet, every thrust of his knee — zip! zoop! He slithered the knife along with a zing, and all was in perfect rhythm, as though he were performing the dance of the Mulberry Grove or keeping time to the Jingshou music.
“Ah, this is marvelous!” said Lord Wenhui. “Imagine skill reaching such heights!”
Cook Ding laid down his knife and replied, “What I care about is the Way, which goes beyond skill. When I first began cutting up oxen, all I could see was the ox itself. After three years I no longer saw the whole ox. And now — now I go at it by spirit and don’t look with my eyes. Perception and understanding have come to a stop and spirit moves where it wants. I go along with the natural makeup, strike in the big hollows, guide the knife through the big openings, and following things as they are. So I never touch the smallest ligament or tendon, much less a main joint.
“A good cook changes his knife once a year — because he cuts. A mediocre cook changes his knife once a month — because he hacks. I’ve had this knife of mine for nineteen years and I’ve cut up thousands of oxen with it, and yet the blade is as good as though it had just come from the grindstone. There are spaces between the joints, and the blade of the knife has really no thickness. If you insert what has no thickness into such spaces, then there’s plenty of room — more than enough for the blade to play about it. That’s why after nineteen years the blade of my knife is still as good as when it first came from the grindstone.
“However, whenever I come to a complicated place, I size up the difficulties, tell myself to watch out and be careful, keep my eyes on what I’m doing, work very slowly, and move the knife with the greatest subtlety, until — flop! the whole thing comes apart like a clod of earth crumbling to the ground. I stand there holding the knife and look all around me, completely satisfied and reluctant to move on, and then I wipe off the knife and put it away.”
“Excellent!” said Lord Wenhui. “I have heard the words of Cook Ding and learned how to care for life!”
I'm convinced slowing feeding students, and having them produce good low-level codebase(s) (e.g. OSs, compilers) is a great Way to "holistically" teach them CS, much better than what's happening usually. "C is a razor-sharp tool"!
Even he admits, he had to start somewhere.
The Master might say something like this, if translated crudely -
Software engineering is programming professionally, with a dialogue on quality. Everything else is details.
The IEEE has been riding this horse for a very long time, in the face of very serious criticism (see the ACMs comments from a quarter century ago).
The presentation of it is _not even wrong_. It reads like a mid level manager at a very old enterprise firm wrote out what important at their firm, and took no material care for other ways. The SWEBOK has been that way for as long as I can remember ( an aside: my experience of Software Engineering academia has been so deeply negative to the point I wrote the field off in 2013. Decoupled from reality, PM oriented, toy studies- irrelevant. The SWEBOK is an artifact of that world. I should dip back in... Maybe Google & MS Research have done the real work here...)
There's a body of _practice_ that is mildly incidental. Most acronyms are fads. Lots of ephemeral technologies that only exist as painful grimaces. IE- CORBA- SOAP, etc...
Project management and quality management are also essentially contingent. One company does this. One that. Waterfall here. Agile there. Whirlpool the other.
What you're left with as non contingent and timeless is in the area of compilers, algorithms, etc. Which is not SWE at all.
If I were to write a swe body of knowledge, it would be in koan form, more than likely.
> The IEEE has been riding this horse for a very long time
Well, there's your mistake right there. You're supposed to be riding an ox.
All this talk of oxen and horses got me curious about the PDF, so I went and took a look. It's really far worse than you've described.
I couldn't stomach it for too long, but here's some highlights:
(1) The first ~65 pages are about "requirements gathering." Page 60 offers up this gem of insight:
(2) The next hundreds of pages go through topics in sequence, like "Architecture" and "Design" (who knew they were different?). Naturally, "Security" is slapped on several hundred pages later.I couldn't make it through the whole PDF, in all honesty. But I'm quite certain the soul of software engineering is nowhere to be found in there; they've eliminated it entirely and replaced it with stamp-collecting and checklists.
> If I were to write a swe body of knowledge, it would be in koan form, more than likely.
Please do! You can continue with standalone HN comments, which can be upvoted to enlighten human and AI bot alike.
There appears to be a lot of hate towards this in the comments (because it's not perfect?), but I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it.
Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge about software engineering. And they all lack fundamental knowledge about the processes used to do the work.
That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus, much less teach them about it on the job. But that's completely normal in software engineering today, because nobody is expected to have already learned a universal body of knowledge.
I get this thing isn't perfect. But not being perfect isn't a rational argument for not having one at all. And we certainly need to hold people accountable to have learned it before we give them a job. We need a body of knowledge, it needs to be up to date and relevant, and we need to prove people have actually read it and understood it. If this isn't it, fine, but we still need one.
(this is, by the way, kind of the whole fucking point of a trade school and professional licensing... why the fuck we don't have one for software engineers/IT, boggles my fucking mind, if this is supposed to be the future of work)
> if this is supposed to be the future of work
The day computing becomes subject to professional licensure is the day the field of computing will fall into hopeless stagnation, just like every other such field.
> The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), published by the IEEE Computer Society (IEEE CS), represents the current state of generally accepted, consensus-based knowledge emanating from the interplay between software engineering theory and practice. Its objectives include the provision of guidance for learners, researchers, and practitioners to identify and share a common understanding of “generally accepted knowledge” in software engineering, defining the boundary between software engineering and related disciplines, and providing a foundation for certifications and educational curricula.
So at the start of each chapter, the book has a table of abbreviations and their definitions, called 'Acronyms'. To whoever wrote or edited the book: please lookup the definition of the word 'acronym': "an abbreviation formed from the initial letters of other words and pronounced as a word (e.g. NASA)." Not all of the abbreviations listed are acronyms! Most are just plain old initialisms.
Since when has anyone ever tried to pronounce 'GPS' as anything other than G-P-S? Also "ECS" = "Ecosystem"? Maybe I'm just crazy but I've never heard or read anyone abbreviate ecosystem as 'ECS'. I've come across ECS as entity component system in video game engines, but never as just 'ecosystem'. Also it's defined exactly once in chapter 5 and then never used again in the book. Why even bother to mention it then?
Oh and publish it as a PDF, but then have no actual page numbers?
From Merriam Webster:
a word (such as NATO, radar, or laser) formed from the initial letter or letters of each of the successive parts or major parts of a compound term
also : an abbreviation (such as FBI) formed from initial letters : initialism
It appears the meaning of the word has changed over time.
SWEBOK 4 adds a dedicated section for security, but it's painfully 2012 (testing, for instance, centers on the old industry-driven "SAST" vs. "DAST" distinction). It also promotes stuff like Common Criteria and CVSS. The "domain-specific" security section could have been pulled out of the OWASP wiki from 2012 as well: "cloud", "IOT", "machine learning".
After seeing so much negativity and controversy around this book in the comments, I'm quite convinced to giving it a read.
I've seen so little "engineering" in software world, regardless of the company and how many ivy league devs it hires to be fully convinced that a work of encoding software engineering knowledge is worth the effort, and even attempts like this are valuable reads in such a gigantic vacuum, even just to start a discussion and to be able to disagree on definitions and practices.
For me "BOK" is correlated with the creation of false industry and certification.
A competing and altogether more entertaining and comprehensive body of knowledge: https://grugbrain.dev/
It's so unfortunate that this effort is still alive. The ACM canceled its involvement for excellent reasons which are worth reading: https://web.archive.org/web/20000815071233/http://www.acm.or...
It's probably also worth reading Dijkstra's assessment of the "software engineering" field (roughly coextensive with what the SWEBOK attempts to cover) from EWD1036, 36 years ago.
> Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".
https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF
The ACM's criticisms, however, are much harsher and much more closely focused on the ill-conceived SWEBOK project.
The IEEE's continued involvement calls the IEEE's own credibility and integrity into question—as do its continued opposition to open-access publishing and its recent history of publishing embarrassingly incompetent technical misinformation in IEEE Spectrum (cf., e.g., https://news.ycombinator.com/item?id=41593788, though there are many other examples). What is going on at IEEE?
Wanted to call out the specific requirements for what the ACM wanted out of their participation in creating a core body of knowledge (from the linked reasoning):
It then details exactly how SWEBOK fails to meet those (which all still seem to be relevant) and comes to the following scathing conclusion: the requirements we identified for bodies of knowledge in software engineering, independent of its specific content.I haven't read the SWEBOK but some spot checking and a review of the ToC seems to indicate they have not meaningfully taken that criticism into an account.
On a tangent here, but...
> The ACM canceled its involvement for excellent reasons which are worth reading: https://web.archive.org/web/20000815071233/http://www.acm.or...
This jumped out at me from the first para there:
" ... also stating its opposition to licensing software engineers, on the grounds that licensing is premature ... "
I wonder what ACM's current thinking on licensing software engineers is almost 25 years further on?
> The ACM canceled its involvement for excellent reasons which are worth reading
Interesting, thanks for the hint; the paper is from 2000 though, and as it seems it would need an update; just checked e.g. the "roles" point and it seems there were significant changes. I also think ACM has rather different goals than IEEE.
> It's probably also worth reading Dijkstra's assessment of the "software engineering" field
Well, was there anything or anyone that Dijkstra didn't rant about ;-)
As much as I like Dijkstra and this particular article of his (it is an assigned reading in my "Software Engineering" class), developing any large scale software that we have today starting from formal methods is just a fantasy.
I understand the importance of learning formal methods (discrete math, logic, algorithms, etc.), but they are not nearly enough to help someone get started with a software project and succeed at it.
So, if not "software engineering", then what should we teach to a student who is going to be thrown into the software world as it exists in its current form?
Since we’re talking Dijkstra, perhaps “structured programming” is a starting place.
Very interesting. Particularly their notion (paraphrasing) that SWEBOK attempts to record generally recognised knowledge in software engineering while excluding knowledge about more specific subdomains of software.
That over-deference towards general knowledge coupled with some sort of tie to a similar Australian effort probably explains why the software engineering degree I began in Australia felt like a total waste of time. I remember SWEBOK being mentioned frequently. I can't say I've gotten terribly much value out of that learning in my career.
Any suggestion for a handbook or compendium that you consider to be a worthy alternative?
The thing here is, this reads like a prissy textbook that no-one can really disagree with but is still not gripping the reality. More HR handbook than blood-red manual.
For example, project management. The book covers this but does the usual wrong headed way of imagining there are executives with clear eyed Vision and lay down directives.
This is of course not how most projects in most companies are started. It’s a mess - reality impinges on the organisation, pain and loss and frustration result in people making fixes and adjustments. Some tactical fixes are put in place, covered by “business as usual”, usually more than one enthusiastic manager thinks their solution will be the best, and a mixture of politics and pragmatism results in a competition to be the one project that will solve the problem and get the blessed budget. By the time there is an official project plan, two implementations exist already, enough lessons learnt that the problem is easily solved, but with sufficient funding all that will be abandoned and have to be rebuilt from scratch - and at a furious pace to meet unrealistic expectations that corners will be cut leading …
That manual needs to be written.
You know that you could be speaking about mining operations or building highways in your post rather than software and everything would apply the same?
I really don't see the argument against the book here in your comment.
You seem to have quite a bit of lived experience with that particular version of project management. Why not write it yourself?
> software engineering has accepted as its charter "How to program if you cannot.".
Is that supposed to be a negative? Isn't that the point of any profession? Like are any of these analogs negative?:
Medicine has accepted as its charter "How to cure disease if you cannot."
Accounting has accepted as its charter "How to track money if you cannot."
Flight schools has accepted as its charter "How to fly if you cannot."
300 pages* is perhaps not quite the length one would expect for Version 4.0 of such an ambitious undertaking.
* Actual page count less front/back matter and a rough guess at pages of matrices and references.
> Popular OOP languages include C++, C#, Cobol 2002, Java, Python, Lisp, Perl, Object Pascal, Ruby and Smalltalk.
:)
If you really want someone interested in software development to run away, hand them books like this one.
This is meant for engineers, a certification-like body of the core knowledge of the field.
This was my first thought.
If this ever starts to get thought in CS university courses the amount of devs would dramaticaly reduce due to trauma.
Software quality may increase though, because there's a desperate lack of solid engineering practices across the industry.
> or tries to access a library
I had to open the PDF and find this line to confirm. It really says that. It reads as if claiming that any program that accesses a library will then have a runtime error. That is obviously not what they intended, but I have read it over a few times now and cannot see another interpretation.
That line is referring to shared libraries linked to a dynamic executable. If a shared library isn't installed or available you will receive an error similar to the following:
Which is indeed a runtime error.There is also the common use case of hot-reloading compiled code which dynamically loads and unloads shared libraries without restarting the entire application. It needs to be done carefully but you've likely used an application that does this. Failure to load a library, or loading an incompatible one will also create a runtime error.
Looks like there is a lot of bad generalizations in here, but they are technically correct on this one.
I understand that is what they meant, but it is not what they wrote. They should have qualified the statement as you did, with the conditions that yield a runtime error. Even if they generalized those conditions that would have been fine.
for example:
Ah, but the existence of a suitable library in the environment is assumed. So not having it is an unexpected condition.
Perhaps if they said "tries and fails to access a library". Merely attempting to access (possibly successfully) a library is not an error.
I suppose, yeah, when I figure out the exact reason why the error occurred, fixing it is often easy. The finding, however, can often take a long time, which leaves me feeling "once you have driven across the continent, finding your desired endpoint is a quick process". "Once constructed, installing the door on your new house is a simple and easy task". Well, sure, if you take out the time-consuming parts, it's quick and easy.
Except for all those runtime errors where the fix required major refactoring, or the problem is in a third party library, the OS, or some other unchangeable component.
What exactly is wrong with it? That is a definition fit for someone who does not have prior knowledge of what a runtime error is. It might be boring to us, and I might word it a little different, but it's fine.
Yes