He was a proponent of a style of programming that was reasonable... you could reason about it and prove / demonstrate that it is doing what it should within that block of code as being correct.
Imagine teaching someone BASIC or FORTRAN...
IF (IA .GT. 0 .AND. IB .GT. 0 .AND. IC .GT. 0) GOTO 10
WRITE (6, 602)
602 FORMAT (42H IA, IB, AND IC MUST BE GREATER THAN ZERO.)
STOP 1
10 CONTINUE
Dijkstra's approach to programming help take software development from a craft where each woodworker did things their own way and going from one shop to another meant relearning everything to something were one could more easily reason about how an application worked by removing some of the ability to write unstructured code. You can still write it... and I'm sure you can find some code that is convoluted ("... the determined Real Programmer can write FORTRAN programs in any language." https://www.ee.torontomu.ca/~elf/hack/real-programmers.html ).
Structured programming is also easier to teach. Yes, you can teach people how to write line numbered BASIC but the challenge is also teaching them discipline to not cut off their fingers when doing it. The structured programming approach it becomes easier to enforce that discipline as part of teaching ... and if they go and do dangerous things after they graduate from college, that's up to them.
That is one of his least important contributions, though it was important, because at the time when it was written, even if better programming languages existed, most of the programs were written either in COBOL or in FORTRAN and using ad hoc program structures implemented with a lot of GOTO instructions.
Several years later, there was a series of articles as a reaction to the misguided extreme interpretation of the title put by an editor to the article written by Dijkstra, i.e. the interpretation that GOTO should be avoided completely. Such articles were written by people like Zahn and Knuth and they demonstrated that while unrestricted GOTO is dangerous and unnecessary and it should not be allowed, a restricted form of GOTO (i.e. jumping only forwards and without entering nested blocks) is absolutely necessary if maximally efficient program structures must be implemented. Those conclusions from the early seventies have become even more relevant today, because when essential GOTOs are removed from a program structure, that is possible only by adding extra Boolean variables and extra conditional branches (i.e. "if" or "while" statements), which can be mispredicted, so their cost is many times higher in modern computers than it was in the computers from a half of century ago.
The language Xerox Mesa was designed according to the conclusions of those articles, so it included a restricted GOTO. Unfortunately, being a proprietary language of Xerox, Mesa has not seen widespread use, even if it was superior to most of the languages designed later than it.
Far more important contributions of Dijkstra are that in 1960 he taught everybody how to implement recursive functions and procedures and also how to allocate the parameters and local variables of the ALGOL 60 blocks, using stacks, stack pointers and stack frames, and then in the following years he taught everybody how to implement mutual exclusion when concurrent processes access shared resources.
In computing science it is hard to say with certainty who invented first some technique, because many of the early uses of some programming techniques have never been published.
Nonetheless, if someone had discovered earlier some programming trick and they kept it to themselves, that does not really count, what matters is only who published first the technique, teaching everybody how to use it.
Dijkstra is certainly the one who popularized during the sixties and early seventies many of the programming techniques that are now among the most fundamental and which are now implemented in any operating system, in any compiler and in any executable program.
Other examples of people with similarly important contributions to programming are John McCarthy and C.A.R. Hoare. As a coincidence (or not), all 3 were supporters of allowing the procedures and functions of ALGOL 60 to be recursive, as there was a camp who wanted to prohibit recursion, fearing that allowing recursion may lead to complex and inefficient compilers and executable programs.
The website author's thesis is on ALGOL60 Recursive Procedures;
Dijkstra's Rallying Cry for Generalization: the Advent of the Recursive Procedure, late 1950s - early 1960s - https://www.dijkstrascry.com/node/4
This paper describes some early contributions of E.W. Dijkstra by elaborating on his involvement in putting forward and implementing the recursive procedure as an ALGOL60 language construct. Particular attention is paid to Dijkstra's generalizing style of solving problems.
Two messages lie at the heart of this paper: (i) the early history of programming languages, and the ALGOL60 effort in particular, can be perceived as a dichotomy between specialization and generalization, and (ii) Dijkstra's continual appeal for generalization led to practical breakthroughs in compiler technology. Specialization, as promoted by Bauer, Samelson, Strachey, and Wilkes, refers to language restrictions, static solutions, and the exploitation of machine-specific facilities --in the interest of efficiency. Generalization, as promoted by Van Wijngaarden and Dijkstra, refers to general language constructs, dynamic solutions, and machine-independent language design --in the interest of correctness and reliability.
idk how old you are, but there there was a style in the 70s where goto was the only control flow operator used in a lot of codebases, and it was absolutely horrible.
I'm in my 40s, wasn't coding in the 70s. Horrible use of code is a different thing from removing something entirely, though. Just that almost every language removed goto as a response is kind of amazing to me.
There is a lot of misconceptions with people's understanding of Dijkstra's views on goto; simply because few read his original writings.
Read David Tribble's Go To Statement Considered Harmful: A Retrospective which annotates the original paper with historical details for better understanding - http://david.tribble.com/text/goto.html
This is a discussion and analysis of the letter sent to Communications of the Association for Computing Machinery (CACM) in 1968 by Edsger W. Dijkstra, in which he calls for abolishing the goto statement in programming languages.
The letter has become quite famous (or infamous, depending on your feelings about goto statements) in the 40 years since it was first published, and is probably the most often cited document about any topic of programming. It is also probably the least read document in all of programming lore.
Most programmers have heard the adage "Never use goto statements", but few of today's computer science students have the benefit of the historical context in which Dijkstra made his declaration against them. Modern programming dogma has embraced the myth that the goto statement is evil, but it is enlightening to read the original tract and realize that this dogmatic belief entirely misses the point.
This paper was written at a time when the accepted way of programming was to code iterative loops, if-thens, and other control structures by hand using goto statements. Most programming languages of the time did not support the basic control flow statements that we take for granted today, or only provided very limited forms of them. Dijkstra did not mean that all uses of goto were bad, but rather that superior control structures should exist that, when used properly, would eliminate most of the uses of goto popular at the time. Dijkstra still allowed for the use of goto for more complicated programming control structures.
> Maybe it's also brain damage of using too much Windows (with wsl). But there I have a different problem: It's easy to install and configure stuff, but it's everything else than minimal.
You could make your own tiny Windows 'distro' building on Tiny 11.
That's what I have in my setup, six titlebar buttons: send to other screen, sticky among workspaces and always on top in addition to the base 3. Can't imagine ever using something that gives me less control again.
Agreed. It beats Arch and Void hands down IMO when I was looking for a no fuss simple and minimalist yet up to date and secure system after Slackware lost its way.
> But then you run into the problem of apps assuming the tray icon exists or is visible, but isn't, leading to problems such as the program just disappearing when you close it's window with no way to reopen it (some do reopen when you try re-executing it, others do nothing or just spawn a whole new instance...) or even having no access to some function that is exclusive to the tray icon menu.
Can you name some that act like this? In 30 years I don't think I've ever seen that behavior...
This is bad news, and exactly the type of viral problem criticics of systemd warned about. Systemd advocates always downplay the issue, but here we are.
I love using Alpine, and for the few packages that don't have a musl version available (e.g. Steam), flatpak has been a great way to run them.
I think Apple became much better at security in recent years. One example which I think is indicative of their approach to security - they bothered to add a hardware microphone disconnect when a macbook is closed. Source: https://support.apple.com/en-gb/guide/security/secbbd20b00b/...
What's your thinking on this? From my perspective Apple security go pretty hard. They have a strong track record of being able to ship architectural mitigations like PACs / MIE / Exclaves first. I guess because Apple control the stack from silicon to userspace.
My thinking was in a historical context, and for their desktop OS's. I know they've been pretty on top of things with iPhones, and MacOS has become a lot better, but for the longest time MacOS was pretty lacking, coasting very much on promoting how much PCs have viruses and macs didn't, which was a marketshare thing more than a security thing. I don't think they got ASLR until later than pretty much everyone else, for example.
They've improved a lot, especially their phones, but I'd still never consider them a company that has a really strong focus on security.
They were not "coasting" on anything. Everything about OS X has always been designed to protect users from the stuff Apple hasn't caught yet, because they know they can't always catch it first - and Apple has led the pack in nearly every major OS security feature of the last 25 years.
That includes "don't give the user root, and ask the user for their password before doing dangerous things" - four years before Linux distros started moving to a similar model.
Didn’t Microsoft pioneer the privilege escalation prompts in Vista in 2007? It was a joke at the time how little things would hijack the entire screen to allow seemingly mundane things. I didn’t ever use Vista personally or professionally, but macOS has become pretty bad with basically the same model.
IMHO, both are a mode of progressively penalizing developers as a mode of API obsoletion. It doesn't feel like the opportunity to fix a degradation of user experience really motivated app developers in either case.
The difference is Apple is much more likely to progressively make these legacy feature compatibility more difficult for users to configure over time, and to remove them eventually.
Microsoft's Secure Desktop feature is actually incredibly well designed, and provides strong protect against fraudulent prompts or prompt interception attacks.
It is the default (unless they changed it in the last 2 years or so). I know for a fact that my PC and Laptop don't ask for my password and I know for a fact that I reinstalled Windows on my laptop less than 2 years ago and changed nothing regarding the UAC prompt (the closest that is even remotely close is enabling sudo in the settings).
Yeah, they were. Virus writers were not targeting them as a platform because why develop for 10% marketshare when you can target 90% for free. It just wasn't worth it to target as a platform. So there was some level of protection due to lack of interest in distributed attacks, but the OS had very little protection against targeted attacks.
> Apple has led the pack in nearly every major OS security feature of the last 25 years.
What an absurd claim. Apple trails behind, it never leads in this space. Windows 7 had numerous protections that had become standards that Apple still lacked when Windows 10 came out.
Recently there was an Anki vulnerability that gave any website access to any local files. On Windows or Linux this would be deadly. On macOS, Anki can't access my desktop or documents or Chrome storage or password manager storage. I think Apple's been smart about which security features it prioritizes.
> That includes "don't give the user root, and ask the user for their password before doing dangerous things" - four years before Linux distros started moving to a similar model.
Linux distros have always required sudo for "dangerous" things. What distros made users root by default?
That's a really strange claim given AS was a refinement of a technology other manufacturers have yet to surpass in the ten years since the T1 chip came out.
To this day nobody else ties their SMC, biometric auth, and HSM together as tightly and well as the T1 did. AS was further advancement of that.
Furthermore, Apple protects users against the legal changes that have allowed law enforcement to physically force someone to provide biometric credentials. By default MS just provides biometric auth to make it easier to log in to your system.
iOS always had a strong focus on security but if you take the time period say 2005 - 2015 it did not seem like there was much investment in macOS security at Apple. I am talking about stuff like exploit mitigations and relatively low hanging LPEs. Features like (full) ASLR / SIP / kext controls were added well after competitors.
> I guess because Apple control the stack from silicon to userspace.
People always say this but there is no real relationship there. When hardware vendors add security technologies to the hardware, the major third party operating systems add support to use it pretty much immediately, and in many cases before the hardware even ships because the hardware vendor publishes the documentation ahead of time.
Try to name something where Apple was the first to support something (by a non-trivial amount of time) not because they were the first to add hardware support but because they released the combination of hardware and software in the time between when e.g. Intel or Qualcomm added hardware support and when Linux or Windows added software support to use it.
reply