I fell down a Wikipedia hole on the earlier discussion about keyboard layouts and learned that the modifier set by modifier keys (command, option, control, hyper…) is called the "bucky bit," where "Bucky" was Niklaus's college nickname. I wanted to share this info with HN, but since TIL post titles aren't welcome here, I wasn't sure the right way to point out _why_ it was interesting.
> I wanted to share this info with HN, but since TIL post titles aren't welcome here, I wasn't sure the right way to point out _why_ it was interesting.
It's not that "Today I Learned" specifically is unwelcome, but rather that editorializing titles is frowned upon. I think this applies most when there's a perfectly suitable title to use or the title itself is subjective instead of objective- I don't get the sense that a "Today I Learned" title with a Wikipedia link is particularly shunned[1]. As dang will tell you if you run afoul of editorializing, "If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's."
It would seem entirely normal to see "Bucky Bit" as a title for the link, and if you were to post it, a first comment is a perfect spot to mention this relationship. In fact, there's an opportunity right now! https://news.ycombinator.com/item?id=38888008
One of my favourity Wirth stories is he came to give a talk at my friend's university and they asked him how to pronounce his surname, whether you say it "wirt" or "worth" and he said "Well you can call me by name or you can call me by value".
Apparently it was a joke he used often but as a comp sci dad joke it totally rules.
To be a geek of geeks in computer science you have to write an OS or a Compiler and professor Wirth did both. To top it up he wrote the hardware to run it all. Now that’s when you call someone a king of geeks.
First, most software methodologies are for teams. Wirth himself was more concerned with the individual programmer.
Second, most software methodologies are for getting at least a constant performance out of teams. Improving the performance is a concern, too, but most and for all a constant performance will enable managers to be able to plan. That's also nothing Wirth would thought about.
Wirth would have wanted to get the most out of the individual programmer. Be the best programmer you can be to discover the best design that is inherent to a problem.
I can also see how that might be at odds with the idea of incremental design.
i think it's true that xp is for building a team with dependable performance, but i don't think that's true of incremental design in general, and i think what you're saying about 'discovering the best design' is actually backwards
incremental design by refactoring is, quite precisely, intended to cope with the situation of not knowing how to design a system at the outset. however, inevitably at the outset you don't understand the problem well enough to discover the best design for solving it. there may exist some problems you understand well enough at the outset to come up with a workable design; there certainly exist others you do not, however wise and talented you are. the workable design consists entirely of things you know will work, and it does something you know is sufficient to solve the problem. sometimes you should do this
but it will never give you the best design, and sometimes it doesn't work at all. your initial design will probably do some things that, while sufficient to solve the problem, aren't necessary. the optimal design would avoid spending effort on those things. because you don't know all the things that will work yet, it's likely that the optimal design would incorporate things that you don't know will work at the outset. finally, there are problems you don't understand well enough to even come up with a workable design for, at the outset, but which you can learn enough to solve in the process of solving them
and that's what refactoring and incremental design is about: enabling your design to benefit from the things you learn in the process of building your system, so it actually can be the best design for solving the problem
But "Incremental Design"/"Refactoring" as practiced by XP/Agile/Scrum crowd is not that at all. It is giving up on "Upfront Design" altogether because Requirements/Design is subject to change anyway. The fact that you will have unknowns should not be an excuse to not come up with a blueprint i.e. Design for the overall system. The focus should be on the long-term with decisions/allowances/techniques made for extension/maintainability/refactoring within the blueprint. That is the point of "Upfront Design". The XP/Agile/Scrum crowd have effectively thrown the "baby out with the bathwater" with the result that their methodology has degenerated to "think short-term and make shit up as you go long-term".
incremental design can indeed degenerate into no design, but i think the real intent of xp is continuous design, not no design. most of the core practices of xp are focused on extensibility and maintainability. it's difficult to do well, but i'm undecided on whether it's more difficult to do well than the big-design-up-front practice, and i think the answer is probably 'it depends', specifically because of the factors i explained in the grandparent comment
boehm suggests iterating through the different stages every 2–3 months. xp suggests iterating through the different stages every 2–3 minutes. scrum doesn't have any development practices at all, just management practices
when i look at the software barry boehm has written and the software kent beck has written i think it's clear that kent beck is far more accomplished. i don't know how good or bad boehm's designs were because i haven't been able to find any. reading his papers it seems to me that probably this is not because of his own ineptitude but because he was embedded in a company whose organization and incentives made it impossible to deliver quality software. this crippled his professional development as a programmer. trw in the 01980s made its living from defense contracts where they can billed customer hourly for their employees' time, so as long as their ass was covered with enough documentation, the more man-hours they spent on a project, the more money they made. consequently, as far as i can tell, they never wrote any software worth using, because for them software was just a cost of doing business, and neither has barry boehm after he left
reorganizing your own company to mimic trw in the 01980s is likely to sink you unless you, too, make your living from cost-plus contracts
not to say that there's nothing to be learned from boehm's work, but you'll have to pick carefully
by the way, possibly you are not a native speaker of english, but 'upfront design', 'requirements', and 'design' are not proper nouns, so should not be capitalized as perhaps they would be in german
> i think the real intent of xp is continuous design,
But that is the problem, when everything is malleable, you have no fixed "Underlying Structure" which is what Design is all about. Iteration should always happen within a framework of understanding and not a free-for-all. This is why you have prototyping, plan one to throw away etc.
> most of the core practices of xp are focused on extensibility and maintainability.
I don't think this is specific to XP/Agile.
> i'm undecided on whether it's more difficult to do well than the big-design-up-front practice, and i think the answer is probably 'it depends'
True, this depends on what stage the product/project is at in its lifecycle.
> boehm suggests iterating through the different stages every 2–3 months.
It is a suggestion which can be lengthened/shortened according to project needs.
> xp suggests iterating through the different stages every 2–3 minutes.
Totally unworkable not to mention silly! I still have "Extreme Programming Explained: Embrace Change by Kent Beck" lying around somewhere so have to look it up on whether it is mins/days/weeks and at what stage of a project.
> when i look at the software barry boehm has written and the software kent beck has written i think it's clear that kent beck is far more accomplished. i don't know how good or bad boehm's designs were ... <rest of the para>
Violently Disagree! Barry Boehm's credentials - https://en.wikipedia.org/wiki/Barry_Boehm Writing mere software is no measure of how much you have thought/researched about important meta-issues surrounding the same i.e. "Software Development as Engineering Discipline". Kent Beck (https://en.wikipedia.org/wiki/Kent_Beck) offers nothing much here (consultant) while Barry Boehm (researcher/programmer/scientist/professor) is a giant in this field. The depth and importance of the latter's work far outstrips the former's. Also note the differences between Scientist/Engineer/Technician/Programmer/Coder roles.
> reorganizing your own company to mimic trw in the 01980s is likely to sink you unless you, too, make your living from cost-plus contracts
Not what i am talking about nor implying.
> not to say that there's nothing to be learned from boehm's work, but you'll have to pick carefully
There is much to be learned from Boehm's work if only to not reinvent the wheel.
> by the way, possibly you are not a native speaker of english, but 'upfront design', 'requirements', and 'design' are not proper nouns, so should not be capitalized as perhaps they would be in german
I use capitalization/scare quotes often to signal importance/nuance to the reader.
> I use capitalization/scare quotes often to signal importance/nuance to the reader.
well, it certainly does do that, but probably not in the way you were intending
UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS
'course, i'm one to talk...
anyway, i think that if you want advice on programming, you should get it from people who are good at it. people who think software is 'mere software' are never going to achieve anything in the field and can be safely disregarded, however many awards and other credentials they receive. wirth's achievements as a Scientist/Engineer/Technician/Programmer/Coder were because he took software seriously, the opposite extreme from the 'mere software' viewpoint
> well, it certainly does do that, but probably not in the way you were intending
Well, you have to leave something to the Intelligence of the Reader :-)
> anyway, i think that if you want advice on programming, you should get it from people who are good at it. people who think software is 'mere software' are never going to achieve anything in the field and can be safely disregarded, however many awards they receive.
Again, Violently Disagree! People who think Djikstra/Hoare/Boehm/other greats had not written much "code" to warrant being taken seriously and were "mere theorists" do not understand the first thing about Science/Research/Meta-whatever and Engineering/Implementation; the former is the bedrock on which the latter stands.
> wirth's achievements as a Scientist/Engineer/Technician/Programmer/Coder were because he took software seriously, the opposite extreme from the 'mere software' viewpoint
Not opposite, he was both a Scientist and an Engineer which is the source of his greatness. Languages/Compilers/OS/HDL/Processor design/Applications the man did it all.
dijkstra wrote an extremely influential operating system, hoare wrote several influential compilers and worked with wirth on algol w, and they both made extensive progress on formal methods. neither of them would ever utter the phrase 'mere software'; the excellent body of theory they developed is about software and investigates software in detail. boehm's does not. instead he theorized about how to manage programmers, which is not at all the same thing, because your theories are not falsifiable. he does not rise to the level of being a theorist
all of dijkstra, wirth, and hoare were instances of your 'Scientist/Engineer/Technician/Programmer/Coder' polymath. hoare still is
The original discussion we were having was about Barry Boehm vs. Kent beck and not what you are moving to here.
> boehm's does not. instead he theorized about how to manage programmers,...
Absolutely not! "Software Engineering" is far far more than just "manage programmers". Either you are unaware of his work or are intentionally downplaying it. His wikipedia page lists his works/achievements for everybody to read/study. He was a first-class theorist in the fields of "Software Engineering Economics", "Software Process Methodologies" and "Software Engineering" to name a few.
I am well aware of the works of Djikstra/Hoare/Wirth/etc. and how their work is different from that of Boehm's/Parnas'/etc. For the purposes of our discussion i am lumping them under the term "the greats" to highlight their fundamental and complimentary contributions to the field.
> Having described —admittedly in the broadest possible terms— the nature of computing's novelties, I shall now provide the evidence that these novelties are, indeed, radical. I shall do so by explaining a number of otherwise strange phenomena as frantic —but, as we now know, doomed— efforts at hiding or denying the frighteningly unfamiliar.
> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. 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 popularity of its name is enough to make it suspect. In what we denote as "primitive societies", the superstition that knowing someone's true name gives you magic power over him is not unusual. We are hardly less primitive: why do we persist here in answering the telephone with the most unhelpful "hello" instead of our name?
> Nor are we above the equally primitive superstition that we can gain some control over some unknown, malicious demon by calling it by a safe, familiar, and innocent name, such as "engineering". But it is totally symbolic, as one of the US computer manufacturers proved a few years ago when it hired, one night, hundreds of new "software engineers" by the simple device of elevating all its programmers to that exalting rank. So much for that term.
> The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
> Besides the notion of productivity, also that of quality control continues to be distorted by the reassuring illusion that what works with other devices works with programs as well. It is now two decades since it was pointed out that program testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence. After quoting this well-publicized remark devoutly, the software engineer returns to the order of the day and continues to refine his testing strategies, just like the alchemist of yore, who continued to refine his chrysocosmic purifications.
you're bringing up the very real achievements of people like dijkstra and parnas in order to confuse the reader into putting boehm in the same category, as if he had achieved something similar. perhaps he could have, he was a smart guy, but he didn't, probably because he believed in 'mere software'. he ended up as a snake oil merchant, a successful one who found a lot of buyers. you're in danger of wasting your life the same way
I am afraid calling Barry Boehm a "Snake oil merchant" and that he didn't achieve much merely betrays your ignorance. You need to really study up on the history of the Software Engineering field and how it came to be what it is today before giving advice to others who may know more than you. Again, go through Boehm's wikipedia page and follow links from there. Here is his "Awards" section - https://en.wikipedia.org/wiki/Barry_Boehm#Awards
I am fully aware of Djikstra's criticism and i am not sure what you hope to show by pasting a wall of text. Just to clarify, his criticism was appropriate at that time since the field was just coming into existence and there wasn't much nailed down. The situation now is very different, we have decades of research/models/experience for a sound basis mainly due to folks like Parnas/Boehm.
It is actually funny for me to see you quote Djikstra since the whole XP/Agile rigmarole is the very antithesis of everything he stood for i.e. writing programs which are "correct" by design using Predicate Logic and not the XP/Agile method of "design and refactor a self-created mess as you go".
when i said 'snake oil' i was quoting dijkstra, who continued to hold that opinion of 'software engineering' (yes, including xp, perhaps especially including xp) until he died in 02002. so the logical implication of what you're saying is that dijkstra was ignorant—compared to you, apparently?
if you think six paragraphs is a 'wall of text' you'd better stay away from libraries; if you ever saw a book you might die of shock
parnas did actual software work. don't insult him by lumping him with boehm
You might want to rethink how you communicate with people regarding subjects you have no clue about. A little humility goes a long way.
The original discussion started with XP/Agile and Kent Beck where you quite clearly had nothing to defend their achievements against Barry Boehm's whose works you seem to know nothing about. So instead you drag in Djikstra's works which are not under discussion here and somehow think that is valid? Also twisting my words to read non-existent meanings into them is merely a feeble attempt at trying to mask one's ignorance.
i read all these process guys back in the 90s: boehm, yourdon, mills, weinberg, beck. and, like boehm, i worked in dod-funded software projects on cost-plus contracts. i am dismissing boehm's work not just because dijkstra described it as snake oil but because decades of experience have shown most of it to be worthless
Merely to show the group of "the greats" in which i included Boehm. But we are not discussing his works here.
> i read all these process guys back in the 90s: boehm, yourdon, mills, weinberg, beck.
I too have read the works of these folks in the early 90s. Their work is all in different domains and not all of them "Process". Beck most certainly does not belong in this group. FYI, i was introduced to XP in 2000 at the company i worked for in Austin, Texas when they got Kent Beck himself to come in and teach us this new fangled concept called "Extreme Programming". I think i asked him about how he hoped to design and implement something like a OS with this "constant change" methodology; the answer was not satisfactory to say the least. Then of course the totally daft idea of forced "Pair Programming" which anybody who knew anything about Human Psychology/Organizational Behaviour would tell you is not workable unless the concerned people themselves seek it out. Nobody in the company practiced XP thereafter. If anybody is selling snake-oil it is the XP/Agile/Scrum proponents.
> i am dismissing boehm's work ... because decades of experience have shown most of it to be worthless
I am dismissing your dismissal of Boehm's work since through out this chain of comments you have not presented any evidence of any knowledge of Boehm's works. Do you know what is the COCOMO model and where it may/may not be applicable? Do you know what exactly is the Spiral Model and how to use it? I have pointed you to his distinguished career, awards earned and general standing in the industry and yet i have had no proof at all that you have read anything i pointed out. In short, you need to demonstrate competence with his work before anybody can take you at your word.
> you deprecated achievements like oberon as 'mere software'
This is a straight-up intentional misrepresentation of what was said. It was in response to your claim of Kent Beck's achievements and nothing whatever to do with Wirth's.
If that is what you understood then you need remedial English comprehension classes.
He's deriding the agile movement. He's saying if you don't know how to properly design software (up front), then he supposes that doing it in an iterative fashion is an acceptable alternative. The way he says it implies that he disapproves of it.
In opinions such as this it pays to remind yourself that not everyone is faced with the same challenges. For all the esteem Wirth garners, I feel (at least at that time) his work on compilers and programming language design involves challenges that are very different from the challenges that inspired Extreme Programming.
And not everyone has the same abilities. Tayloresquece methodologies like Agile are great for getting mediocre results for mediocre projects using mediocre developers (if they are not mediocre to begin with, certainly they will become so) in a repeatable and reportable fashion.
> Tayloresquece methodologies like Agile are great for getting mediocre results for mediocre projects using mediocre developers (if they are not mediocre to begin with, certainly they will become so) in a repeatable and reportable fashion
Nuanced, humble, and thoughtful opinion. Thank you.
For those who may not know, "Tayloresque" refers to techniques pioneered by Frederick Winslow Taylor (https://en.wikipedia.org/wiki/Frederick_Winslow_Taylor) who introduced "Scientific Management Techniques" to increase worker productivity and efficiency in Factories. To the detriment of Humankind, his methods have been taken as gospel by the larger "Management Industry" from where they have bled into the "Knowledge Management Industry" causing all knowledgeable Software Engineers to rue their jobs/careers/lives.
And that Worth worked primarily on systems that are many times smaller (maybe many orders of magnitude smaller) than today's biggest systems. It's no surprise, then, that the successful techniques are different. The right techniques to build a house, a skyscraper, a city, and a garden are different.
> systems that are many times smaller (maybe many orders of magnitude smaller) than today's biggest systems.
This is a dangerous and misleading metric. You're right that different scale needs different techniques, but comparing sizes of actually existing systems in this way it's very easy to conclude your strongest designers who successfully wrangled a large problem into a simple system are your weakest designers because what they designed is so small.
the empire state building is a bit more than an order of magnitude smaller than the great pyramid of khufu, if you go by weight
that's why it can be taller, was built much faster, and has much more room inside. also, it has served its intended purpose, while as far as we can tell, khufu's pyramid failed to make him immortal; this is because it was based on flawed theories
wirth's work should be an inspiration to see if we can make systems that are many times smaller, maybe many orders of magnitude smaller, than the systems we are unfortunately currently forced to maintain; and yet are more powerful than those systems
It reminds me of the famous exchange (which may have been apocryphal) between Dustin Hoffman and Sir Laurence Olivier. Hoffman was describing the "method" in which he got into the mind of the character he was going to portray by living as much as possible as the character did, wearing the same type of clothing, and trying to think like the character. Olivier, being a more traditional actor was said to have said "My boy, have you tried acting?"
"Extreme Programming (XP)" (https://en.wikipedia.org/wiki/Extreme_programming) was the precursor to and origin of current Agile/Scrum and similar methodologies whose main tenet is that "Upfront Design is unnecessary" and "Design & Program as you go".
Niklaus Wirth (along with Edsger Djikstra and other greats) had established the field of "Structured Design & Programming", "Top-Down Design", "Program Development by Stepwise Refinement" and similar techniques which laid the foundations of modern software development all of which had an emphasis on "Upfront Design"; You always Think before you Code.
I am totally with Wirth (and the other greats); XP/Agile/Scrum are all lazy excuses used by people "who don't know how to design software".
this is not a correct description of xp or of the history of software development
certainly wirth and dijkstra laid the foundations of modern software development; so, too, did mccarthy, perlis, sussman, steele, kay, minsky, mcilroy, ritchie, thompson, and perhaps most of all stallman
> you deprecated achievements like oberon as 'mere software'
This is a straight-up intentional misrepresentation of what was said. It was in response to your claim of Kent Beck's achievements and nothing whatever to do with Wirth's.
If that is what you understood then you need remedial English comprehension classes.
you deprecated beck's work as 'mere software'. this presupposes that software is 'mere', which is to say, less significant than the other topics at hand. this logically entails deprecation of oberon, which is also software
similarly, you said that when i repeated dijkstra's judgment that boehm's work, indeed boehm's entire field (and beck's!) was 'snake oil', i was betraying only my own ignorance. but that would logically entail that dijkstra, whose judgment i was relaying, was led to this judgment by his ignorance. of course this is possible but your disagreement with him is hardly strong evidence of it. this makes your pleas for intellectual humility on my part laughable
in short, the problem is not that i lack comprehension if english, but that i possess comprehension of logic
> you deprecated beck's work as 'mere software'. this presupposes that software is 'mere', which is to say, less significant than the other topics at hand. this logically entails deprecation of oberon, which is also software
Stating Beck's work as "mere software" (i.e. nothing noteworthy) DOES NOT mean all software (from others) is "mere software". A course in Set Theory/Propositional/Predicate logic is in order here. The set of software that Wirth produced vs. the set of software that Beck produced are completely different and a considered judgement of the latter cannot be generalized to the former. You get zero marks for doing this.
> similarly, you said that when i repeated dijkstra's judgment that boehm's work, indeed boehm's entire field (and beck's!) was 'snake oil', i was betraying only my own ignorance. but that would logically entail that dijkstra, whose judgment i was relaying, was led to this judgment by his ignorance.
This is a false statement and again betrays your ignorance. Dijkstra's comments as regards "Software Engineering" were general observations on the state of the field at that time and NOT a critique of Boehm's work. They are two different things. Here is a longish IEEE pdf A Conversation with Barry Boehm: Recollections from 50 years of Software Engineering - https://ieeexplore.ieee.org/iel7/52/8474478/08474492.pdf for your edification. Here Boehm mentions his interactions with Dijkstra and others and how they were all working together to solve what was then called "Software Crisis".
I have repeatedly pointed out (my other comments in this thread) your ignorance of Boehm's work and their significance but instead of acknowledging and rectifying it by some study, you are only making it worse by your comments where you are merely "Arguing for the sake of argument" wasting everybody's time and risking being seen as a caricature.
it's good to see you frantically backpedaling as you attempt to weasel out of what your previous words logically entail, but the evidence you adduce does not show what you claim it does
boehm speaks very highly of dijkstra's work in that interview (which is short), because dijkstra's work is universally acknowledged to be foundational, and deprecating it would only hurt boehm's own reputation; but nowhere will you ever find dijkstra speaking highly of boehm's work, or indeed in any but the most scathing terms. the very article you cite describes dijkstra renaming one of his papers to remove 'software engineering' from the title to prevent it from being associated with work like boehm's
the well-known text i quoted of dijkstra's is, contrary to your assertion, directed very directly at boehm's work, and not at how far the field had developed but at what it was attempting to accomplish (boehm was the leading proponent of that sort of 'software engineering' at the time, and, as the interview shows, continued to advocate it for the rest of his life.) as far as i can tell, this remained dijkstra's point of view until his death, which wasn't until 02002—plenty of time to re-evaluate boehm's work if contrary evidence had surfaced
to be generous, it's possible that you didn't know this because the article was even longer than the six-paragraph dijkstra quote you previously complained was too long for you to read (and are mischaracterizing here, presumably unintentionally)
i don't think you'll ever find wirth or hoare (who boehm also namedropped in the interview) saying anything complimentary about boehm either, though they weren't dutch enough to publicly lambast his work the way dijkstra did; definitely let me know if i'm mistaken. hoare at least didn't immediately abandon the term 'software engineering' to snake-oil merchants like boehm, continuing for decades his unsuccessful attempt to redefine the term to mean developing mathematics equipped to solve the problems of what you deride as 'mere software'
that's what electronic engineering, civil engineering, and mechanical engineering do; in an electronic engineering curriculum, for example, you learn to derive and apply formulas that describe the behavior of circuits (perhaps you would say 'mere circuits'), not of circuit designers
i don't entirely agree with dijkstra; i think, like hillel wayne https://www.hillelwayne.com/talks/crossover-project/, that software engineering is real engineering, in which it makes sense to talk about degrees of correctness other than 'perfect' and 'wrong', and testing is worthwhile, as is experience with actual physical computers. we have an enormous body of knowledge about how to do it effectively, including substantial and important contributions from dijkstra, hoare, and, yes, kent beck too. but not boehm
what boehm has contributed to it is mostly wrongheaded thinking we've had to battle against for decades, ultimately triumphing by outcompeting companies that practiced it wherever they aren't protected from market competition as trw was. also, getting the acm to withdraw from the hopelessly boehm-follower-corrupted swebok process
walk into any faang company or most startups and you'll find programmer-written unit tests for most of the code base, uniform code standards, refactoring, continuous integration, and small releases. these are four and a half of the 12 core practices of extreme programming, popularized by beck and friends though obviously not invented by him. (the other seven and a half, including tdd, are not so widely accepted.) you'll find algol-derived languages, structured control flow (if not structured programming as dijkstra visualized it), paged virtual memory, compiler-inserted virtual machine isolation, and semaphores. you'll find (again) algol-derived languages, quicksort, null pointers, often csp-based concurrency (erlang and golang), and sometimes even sound static type systems and formal methods. you'll find bytecode interpreters, top-down design, meta-key-based user interfaces, and sometimes even pascal derivatives if we count golang
by contrast, boehm's cocomo model, spiral model, wideband delphi, incremental cost model, and software cost estimation in general are nowhere to be found, because they're basically worthless and usually actually counterproductive. the sei cmm turned out to be a model not of capability but of incompetence. it's no wonder he spent much of that interview talking about the achievements of people he heckled at a conference one time in 01969 instead of his own
this is not because management and practices are unimportant. we've made enormous strides in the social systems that allow us to write software in the last 50 years. in addition to the kent-beck-popularized practices i listed above, usability testing, source control, decentralized source control, universal internet access, open-source licensing, stack overflow, automated build systems, bug tracking systems, coding interviews, canary deployments, fuzzing, and a/b testing have each individually been revolutionary. boehm invented zero of these and popularized zero of these, possibly because several of them involved software innovation
as for wasting people's time, i think you and i are the only people reading this thread; the only person whose time i'm wasting is my own
I am not doing any backpedaling whatever but unraveling your comments point-by-point and showing up your ignorance of Boehm's work/significance throughout. Also am pointing out your sneaky way of twisting/misrepresenting my words into something which was never said.
You are now throwing everything and the kitchen sink in to a mass of incoherent text with no unifying thread and not related to what we started with. This is merely more useless "Gish Gallop" (https://en.wikipedia.org/wiki/Gish_gallop). If you want a discussion on different topics submit a new thread and have people participate.
As mentioned previously, You have presented no evidence from any source but merely your opinions which amount to nothing in the absence of knowledge of Boehm's work.
You are making up your own laughable stories about what Dijkstra/Others thought about Boehm/his work and vice-versa with no evidence to back up any of it. Your imagination seems to be working overtime to argue some point of your own making none of which are tenable.
I sincerely suggest that you heed the advice in the last para of my previous comment and take a break.
if you take the time to think about what i wrote you'll see that none of that is true. the reason this has been a waste of my time is that you're so stuck in ego-defense mode that you can't even recognize a comprehensive and well-organized rebuttal when it hits you in the face
No it is you who is trying to reflect your faults in this thread on to me. I had already pointed out that you have been engaging in "Arguing for the sake of argument" which is a polite way of saying you are stuck on your "ego-defense" when you had clearly no idea of the original specific topic we started out with. I also hinted at this when i had said "A little humility goes a long way". Again, as mentioned previously, You really need to introspect on how you communicate with others particularly on subjects you are not knowledgeable on. There is much to learn in this world and while it takes a long time and effort to build a good reputation it takes merely an instant to lose it all.
He said that in his youth his colleagues were in awe of him because he was brave enough to give presentations in English. (They were shy and stuck to the local Swiss German dialect.)
My dad's uncle is currently 93, being born in August 1930. When he was 6 and 3/4 years old, he saw the Hindenburg fly over his home in New Brunswick, Canada the day before it caught fire in New Jersey on May 6, 1937.
What do you mean? Why is it weird? Did you mean to imply that you're surprised that he was old or that Pearl Harbor happened around an average lifetime ago ?
I had no literal idea Niklaus Wirth was alive until just now when I learned he died. We've lost a giant of the field already in 2024. This is definitely black bar worthy.
So excuse me for piggy-backing on your post:
https://en.wikipedia.org/wiki/Bucky_bit