It's interesting to imagine what Djikstra would've accomplished if he instead decided to focus on theoretical physics. Conversely, imagine what we would've lost if we didn't have Djikstra as a programmer.
I'd like to point out that Dijkstra's writing might arguably the best writing I've seen from a programmer. English is not my first language and his writing is inspiring; if possible I'd like to request if anyone can point me to a resource (apps, software, etc) so I can learn to write, speak, and converse like Dijkstra in this lecture?
> if possible I'd like to request if anyone can point me to a resource (apps, software, etc) so I can learn to write, speak, and converse like Dijkstra in this lecture?
Practice makes perfect, that's really all there is to it. A good book on writing style can help, but only if you use it. The Sense of Style by Steven Pinker and Revising Prose by Richard Lanham are my two favorites.
For writing, The Elements of Style by Strunk/ White is a classic I still found useful. Plus, as has been said, read a lot of good prose.
Similarly for public speaking, practice makes perfect. Check out Toastmasters International - a nonprofit that is running clubs all over the world where members can improve their public speaking skills in a supportive environment. Worked for me.
I suppose, but unless he felt a true calling to become a theoretical physicist, as is partly outlined in this piece, his decision was clearly right, for the previous golden age of physics was well over by late '50s, and progress since then has been minimal compared to the Thirty Years that Shook Physics (quantum theory: https://www.amazon.com/Thirty-Years-that-Shook-Physics/dp/04...), General Relatively (still our best theory of gravity), and the revelations of the secrets of the nucleus. Maybe also Feynman and company's development of the first quantum field theory.
There were of course a lot of things of smaller scope to be done, and the unification of EM and the weak nuclear force was in the future, as well as the imperfect Standard Model that adds the strong nuclear force, and we still haven't unified gravity and the other three fundamental forces, but programming was wide open, and what you could do was rapidly improving as the machines were rapidly becoming faster and bigger. ADDED: For example, the Electrologica X1 he did his Ph.D. thesis on was solid state, as in completely transistorized (no vacuum tubes) and had magnetic core memory, both major advances in the '50s.
Heck, my calling was science, and I was strongly on that track as of 1968, but computers nonetheless gained a lot of my attention starting in the mid-late '70s, as they did for Feynman starting with the Manhattan Project when "computers" were the operators of 10 digit electromechanical scientific calculators.
Similar to the baseline advice to learn programming: write a lot. Read good writing, read bad writing and learn to tell the difference. Leaving a piece of writing for 24 hours and coming back to it with a fresh pair of eyes to edit helps. Someone else's eyes also helps, similar to how code reviews help.
Reciting your writing out loud helps too. If it isn't in the desired tone and/or it doesn't sound natural, rewrite it. You may find you need less adverbs than you think.
Books on writing style and techniques help in the way books about algorithms, paradigms, design patterns and other facets of programming help. The key is to implement the ideas you learn in your writing.
If you want to write specifically like that, read Bronte, Austen, and other 19th century authors. It's a more verbose, grammatically complex style of prose that's not in vogue anymore. When it's done well, I personally enjoy it, but if your aspiration is to emulate that style you should be warned that to the ear of most modern English speakers it rings overly formal, if not pompous.
Dijkstra writes directly and with and air of authority, but his writing is not great. His style is pretentious and obfuscatory. Even worse, he uses his authoritative style to get away with tons of unsubstantiated assertions. Let's look at a passage from the linked lecture:
Those who want really reliable software will discover [authority!] that they must find means of avoiding the majority of bugs to start with [unsubstantiated!], and as a result the programming process will become cheaper [unsubstantiated!]. If you want more effective programmers, you will discover [authority!] that they should not waste their time debugging [repeated assertion!], they should not introduce the bugs to start with [repeated assertion!].
He could just say:
When creating reliable software debugging takes up much time. If we develop techniques that prevent these bugs from being introduced in the first place then programmers will become much more effective.
Good writing is terse and easy to understand. It should lead the reader from the premises to the conclusions. Good writing shouldn't contain pretentious detours. I don't think you should emulate Dijkstra.
I doubt Djikstra would have been Djikstra is he communicated in such a sterile way. His writing achieved the ends he sought. He's memorable and endlessly quoted which gives life to his ideas beyond what is immediately provable.
You might argue this is improper, but I think that's a bit morose. I dread the day when all people write like that second sentence.
That's not to say someone should emulate him, though. It's not that it's wrong, it's that they're bound to fail and produce something tinny and derivative. That's the thing your revised sentence has going for it: it's as cheap as it is limp.
Not that I dislike your version, but aren't the claims as unsubstantiated there as they are in the original? (And I don't know how they could be anything else when someone is simply sharing their informally gained insights.)
Good writing does what it sets out to do. "terse and easy to understand" is a fantastic style for certain objectives, but there's no one "good writing" style.
And you say you don't like Ayn Rand! Terse is just another word for unimaginative, when it comes to prose.
I think you might be blurring the lines between writing something in a socratic dialogue versus writing technical documentation. Dijkstra, obviously often is writing in the former style and so there's plenty of room for his personality in the text and it doesn't take away from the overall quality and cohesiveness of the text.
I don't think I'm blurring; if anything, I'm sharpening! Not all text is the same, and it's important to know what you're trying to accomplish when you set out to write something.
> Dijkstra writes directly and with and air of authority, but his writing is not great. His style is pretentious and obfuscatory. Even worse, he uses his authoritative style to get away with tons of unsubstantiated assertions.
This bugs me as well. He's obviously made profound and exceptional contributions to the field but I don't like when he writes in the manner you pointed out where he's making bold statements without evidence. Worse is when people quote something Dijkstra wrote that he didn't back up with evidence as if it's true just because Dijkstra wrote it.
> I married and Dutch marriage rites require you to state your profession and I stated that I was a programmer. But the municipal authorities of the town of Amsterdam did not accept it on the grounds that there was no such profession.
There's more to engineering than building bridges. Would you discredit electrical engineers, for example, because PCBs aren't hydroelectric dams? While I generally agree with your rhetoric that software engineering is perhaps not as disciplined, it is still a legitimate engineering discipline, imo.
Right, I wouldn't discredit electrical engineers. I can reasonably expect my house not to burn to the ground due to an electrical fire, and my washing machine/fridge will probably fail safe as well. Hardware engineers mostly get a pass in my book, too (when was the last time your CPU hung?).
Meanwhile, Toyota is allowed to ship buggy, untested, unauditable ECUs[0]. How can SE be considered a legitimate engineering discipline when such examples abound?
The "Software engineer" title ought to be reserved for those doing formal verification or at least aiming for high code coverage and otherwise employing proper design and testing methods. Think programmers of NASA shuttle avionics or airplane autopilots.
It's not for your run-of-the-mill startup coder (which includes me).
Meanwhile, Toyota is allowed to ship buggy, untested, unauditable ECUs[0]. How can SE be considered a legitimate engineering discipline when such examples abound?
In the bad old days, steam boilers would blow up a lot; check your state and maybe local laws and you'll likely see a section to regulate this. Bridges were also prone to failing, and still do due to design errors: https://en.wikipedia.org/wiki/I-35W_Mississippi_River_bridge... (and even then, the bridge was sufficiently over-engineered that it lasted a long time before failure)
As for the EE examples you give, it just so happens I'm about to personally totally rewire a house I just bought that was built in 1910. Relevant things I've noticed include:
The National Electrical Code is drafted and revised in an open fashion, is thoroughly sane, and anyone can buy a copy. My city also makes copies available for free for perusal, and at the counter were you apply for permits and such there was a copy of the combined complete code for residential housing (1-3 stories, 1-2 or 3 families). That version is also online: http://publicecodes.cyberregs.com/icod/irc/2012/index.htm (that's one revision behind the current, many cities like mine prefer to not be at the bleeding edge).
Then there's the permitting and inspection process: while it's obviously ignored a lot, by law you're required to apply for a permit, including plans of what you propose to do. Upon approval, you post the permit at the work site, and call in city inspectors for "rough in" inspection(s), where they will check whatever will eventually be hidden, and they do a single final inspection when all is done. So there's enforcement of the code (at the very least backstopped by insurance companies who will look askance if your unpermitted work results in a loss), in a rather open way, and the city's top dog for this, the Building Official, certainly knew the electrical code when I asked him about the interpretation of one detail.
All car makers, by comparison ... well, there's not even a PE system for this field (https://www.nspe.org/resources/licensure/what-pe), it's too new, and and there's no consensus on even the most fundamental of things. Everything they do is in secret, with no outside oversight mechanisms, and one company we though really had their act together, such that we'd trust their code with our lives, turned out to be utterly unworthy of our trust, that is Toyoda, of course.
My take on this is that this sad state of affairs will continue until a software error kills 4-6 figures of people, and of course there are many domains of software where the rigor that's in theory demanded of embedded systems like cars isn't required. Like, say, this social media site we're using right now.
I find this interesting - I changed degrees halfway through electrical engineering to computer science (which is still under the engineering school at my university). You're right, EE is much more disciplined, however, computer science/SE still requires an extremely logical thought process, and is applying science/maths to solve real problems. For these reasons, I believe it is engineering (even if somewhat softer than other strands).
As it's been said several times on hacker news (sorry for repeating it one more time here):
In some countries calling yourself an engineer without having an appropriate degree issued by an engineering school is a crime (although, seldom enforced in software).
Whether the school should have a software department at all was a big discussion at my school at the time. They decided to keep it.
EDIT: Sorry, to be clear, we agree: it's just adding a bit more information to your point.
I earned a B.S. in an ABET accredited Computer Science program taught by the College of Science and Mathematics at a state University. Before that, I designed electrical control systems and software for industrial machinery, and I still don't consider myself an engineer.
That said, I think 'Software Engineer' is an acceptable title, and is more representative of the work we do in the profession than simply 'Computer Programmer'.
My point is that "Engineer" (software or otherwise) is a legally protected term in many countries (Canada, Switzerland,...)
How much you consider yourself an engineer is irrelevant in this case: you either are one because you have a degree from an engineering school (not a university!), or you don't (it's a civilian title in Switzerland's case at least, "Eng." similarly to "Dr.")
Calling yourself a "software engineer" in Switzerland (and according to wikipedia, in a slew of other countries [1]) if you have a university degree is technically illegal - although of course, seldom enforced.
>>My point is that "Engineer" (software or otherwise) is a legally protected term in many countries (Canada, Switzerland,...)
Actually, you're looking for the term "Professional Engineer" which can only be legally used if you have at least a B.S. or B.Eng. (or local equivalent) in an accredited program, have taken some kind of certifying exam, and may also require a certain number of years working in the field to obtain licensure. In the US, there is a PE certifying exam for ABET accredited Computer Science and Software Engineering program graduates.
Your Wikipedia link had no information about Switzerland, but it did have this interesting bit about the Czech Republic: "In the Czech Republic, the title "engineer" (Ing.) is given to people with a (masters) degree in chemistry, technology or economics for historical and traditional reasons." Every country is different...
> Shocking in his case as he was a true programmer (computer scientist).
How was that shocking? Someone has to be the first to introduce or pioneer a distinct profession to the rest of the world, he was pretty much among that select group. It's like saying you're a 3d printer in the past few years, without anyone having a clue this was an actual profession people spent their days on.
And that's today, in a world where we're more educated and more open to the notion of rapidly changing professions. If you want to know, the people who work those desks at the municipality usually have only a high school degree, the mandatory minimum (not for the job, but as a person raised in the Netherlands). And in the 1950s that minimum was only six years of education, i.e. primary school only. None of this strikes me as shocking in this full context, unless you're shocked by the notion there had to be someone to pioneer a profession for the first time in their municipality and we happen to be talking about him and his anecdote.
You say that you "know because you get paid to code", but that's only half of the picture. To really know you would need to work on the other side, in what you call "real" engineering. An insider is much more likely to see the flaws in their own discipline.
I worked for 3 years in power plants all over the world, including dams, and there were delays, cost overruns, structural defects, flouted safety measures, etc. Not really the civil engineering utopia that HN raves about.
Note that I'm not saying that it's OK for software engineering to suck because civil engineering also sucks. Both should try to improve.
I doubt the local authority was making a blanket statement that there was no such thing as a programmer in the universe. More likely there was no such listing in the official guide to acceptable job titles.
He was not humble towards people, he was humble towards programming. Recognizing that you can never be more than an apprentice at programming is essential to becoming good at it.
My quick summary -- The main limitation in programming complex solutions is the limit of complexity each individual can hold in his/her head. So if we shape our tools, processes and disciplines to acknowledge that, the software development industry can become an order of magnitude.
> I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility.
> Society is getting dissatisfied with the performance of programmers and of their products.
> [Program] testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.
> The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.
> The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
It's fascinating to see what he expected to be the biggest problems in programming. His discussion of more efficient programming techniques focuses on theorem provers, automated checking of loop invariants and the like, whereas today, the biggest problems typically occur during integration of software components with each other.
But maybe he actually did foresee that:
> I now suggest that we confine ourselves to the design and implementation of intellectually manageable programs.
Regarding provably correct programs: I'm torn here. On the one hand, if we required all programs to carry proofs of their correctness, that would exclude a huge number of current programmers who lack the formal education etc. to carry out these proofs. On the other hand, if all programs that we need would have proofs of their correctness (and thus carry a bunch of helpful invariants and formal specifications), it might be easier to combine all these programs, hence obliterating the need for most programming tasks that are just concerned with integrating multiple programs with each other.
I'll close with the most insightful paragraph from this whole piece:
> There may also be political impediments. Even if we know how to educate tomorrow’s professional programmer, it is not certain that the society we are living in will allow us to do so. The first effect of teaching a methodology —rather than disseminating knowledge— is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable.
This is fascinating because right now, a lot of people lament that our students are only being stuffed with facts, but not equipped with the methodological knowledge required for their professions.
45 comments
[ 6.4 ms ] story [ 132 ms ] threadI'd like to point out that Dijkstra's writing might arguably the best writing I've seen from a programmer. English is not my first language and his writing is inspiring; if possible I'd like to request if anyone can point me to a resource (apps, software, etc) so I can learn to write, speak, and converse like Dijkstra in this lecture?
Practice makes perfect, that's really all there is to it. A good book on writing style can help, but only if you use it. The Sense of Style by Steven Pinker and Revising Prose by Richard Lanham are my two favorites.
Similarly for public speaking, practice makes perfect. Check out Toastmasters International - a nonprofit that is running clubs all over the world where members can improve their public speaking skills in a supportive environment. Worked for me.
http://www.toastmasters.org
There were of course a lot of things of smaller scope to be done, and the unification of EM and the weak nuclear force was in the future, as well as the imperfect Standard Model that adds the strong nuclear force, and we still haven't unified gravity and the other three fundamental forces, but programming was wide open, and what you could do was rapidly improving as the machines were rapidly becoming faster and bigger. ADDED: For example, the Electrologica X1 he did his Ph.D. thesis on was solid state, as in completely transistorized (no vacuum tubes) and had magnetic core memory, both major advances in the '50s.
Heck, my calling was science, and I was strongly on that track as of 1968, but computers nonetheless gained a lot of my attention starting in the mid-late '70s, as they did for Feynman starting with the Manhattan Project when "computers" were the operators of 10 digit electromechanical scientific calculators.
Reciting your writing out loud helps too. If it isn't in the desired tone and/or it doesn't sound natural, rewrite it. You may find you need less adverbs than you think.
Books on writing style and techniques help in the way books about algorithms, paradigms, design patterns and other facets of programming help. The key is to implement the ideas you learn in your writing.
Those who want really reliable software will discover [authority!] that they must find means of avoiding the majority of bugs to start with [unsubstantiated!], and as a result the programming process will become cheaper [unsubstantiated!]. If you want more effective programmers, you will discover [authority!] that they should not waste their time debugging [repeated assertion!], they should not introduce the bugs to start with [repeated assertion!].
He could just say:
When creating reliable software debugging takes up much time. If we develop techniques that prevent these bugs from being introduced in the first place then programmers will become much more effective.
Good writing is terse and easy to understand. It should lead the reader from the premises to the conclusions. Good writing shouldn't contain pretentious detours. I don't think you should emulate Dijkstra.
You might argue this is improper, but I think that's a bit morose. I dread the day when all people write like that second sentence.
That's not to say someone should emulate him, though. It's not that it's wrong, it's that they're bound to fail and produce something tinny and derivative. That's the thing your revised sentence has going for it: it's as cheap as it is limp.
If something becomes boring and derivative when stated plainly then there was nothing of substance to start with.
I also don't mind unsubstantiated claims. It's just obnoxious to phrase it like "any person with half a brain knows [controversial claim]".
I think you might be blurring the lines between writing something in a socratic dialogue versus writing technical documentation. Dijkstra, obviously often is writing in the former style and so there's plenty of room for his personality in the text and it doesn't take away from the overall quality and cohesiveness of the text.
This bugs me as well. He's obviously made profound and exceptional contributions to the field but I don't like when he writes in the manner you pointed out where he's making bold statements without evidence. Worse is when people quote something Dijkstra wrote that he didn't back up with evidence as if it's true just because Dijkstra wrote it.
wow
Today, people say they're "software engineers" with a straight face, which is a disservice to real engineers. I know because I get paid to code.
If bridges were built like software is...
Meanwhile, Toyota is allowed to ship buggy, untested, unauditable ECUs[0]. How can SE be considered a legitimate engineering discipline when such examples abound?
The "Software engineer" title ought to be reserved for those doing formal verification or at least aiming for high code coverage and otherwise employing proper design and testing methods. Think programmers of NASA shuttle avionics or airplane autopilots.
It's not for your run-of-the-mill startup coder (which includes me).
[0]: https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_...
In the bad old days, steam boilers would blow up a lot; check your state and maybe local laws and you'll likely see a section to regulate this. Bridges were also prone to failing, and still do due to design errors: https://en.wikipedia.org/wiki/I-35W_Mississippi_River_bridge... (and even then, the bridge was sufficiently over-engineered that it lasted a long time before failure)
As for the EE examples you give, it just so happens I'm about to personally totally rewire a house I just bought that was built in 1910. Relevant things I've noticed include:
The National Electrical Code is drafted and revised in an open fashion, is thoroughly sane, and anyone can buy a copy. My city also makes copies available for free for perusal, and at the counter were you apply for permits and such there was a copy of the combined complete code for residential housing (1-3 stories, 1-2 or 3 families). That version is also online: http://publicecodes.cyberregs.com/icod/irc/2012/index.htm (that's one revision behind the current, many cities like mine prefer to not be at the bleeding edge).
Then there's the permitting and inspection process: while it's obviously ignored a lot, by law you're required to apply for a permit, including plans of what you propose to do. Upon approval, you post the permit at the work site, and call in city inspectors for "rough in" inspection(s), where they will check whatever will eventually be hidden, and they do a single final inspection when all is done. So there's enforcement of the code (at the very least backstopped by insurance companies who will look askance if your unpermitted work results in a loss), in a rather open way, and the city's top dog for this, the Building Official, certainly knew the electrical code when I asked him about the interpretation of one detail.
All car makers, by comparison ... well, there's not even a PE system for this field (https://www.nspe.org/resources/licensure/what-pe), it's too new, and and there's no consensus on even the most fundamental of things. Everything they do is in secret, with no outside oversight mechanisms, and one company we though really had their act together, such that we'd trust their code with our lives, turned out to be utterly unworthy of our trust, that is Toyoda, of course.
My take on this is that this sad state of affairs will continue until a software error kills 4-6 figures of people, and of course there are many domains of software where the rigor that's in theory demanded of embedded systems like cars isn't required. Like, say, this social media site we're using right now.
In some countries calling yourself an engineer without having an appropriate degree issued by an engineering school is a crime (although, seldom enforced in software).
Whether the school should have a software department at all was a big discussion at my school at the time. They decided to keep it.
EDIT: Sorry, to be clear, we agree: it's just adding a bit more information to your point.
That said, I think 'Software Engineer' is an acceptable title, and is more representative of the work we do in the profession than simply 'Computer Programmer'.
How much you consider yourself an engineer is irrelevant in this case: you either are one because you have a degree from an engineering school (not a university!), or you don't (it's a civilian title in Switzerland's case at least, "Eng." similarly to "Dr.")
Calling yourself a "software engineer" in Switzerland (and according to wikipedia, in a slew of other countries [1]) if you have a university degree is technically illegal - although of course, seldom enforced.
[1]: https://en.wikipedia.org/wiki/Engineer
Actually, you're looking for the term "Professional Engineer" which can only be legally used if you have at least a B.S. or B.Eng. (or local equivalent) in an accredited program, have taken some kind of certifying exam, and may also require a certain number of years working in the field to obtain licensure. In the US, there is a PE certifying exam for ABET accredited Computer Science and Software Engineering program graduates.
Your Wikipedia link had no information about Switzerland, but it did have this interesting bit about the Czech Republic: "In the Czech Republic, the title "engineer" (Ing.) is given to people with a (masters) degree in chemistry, technology or economics for historical and traditional reasons." Every country is different...
How was that shocking? Someone has to be the first to introduce or pioneer a distinct profession to the rest of the world, he was pretty much among that select group. It's like saying you're a 3d printer in the past few years, without anyone having a clue this was an actual profession people spent their days on.
And that's today, in a world where we're more educated and more open to the notion of rapidly changing professions. If you want to know, the people who work those desks at the municipality usually have only a high school degree, the mandatory minimum (not for the job, but as a person raised in the Netherlands). And in the 1950s that minimum was only six years of education, i.e. primary school only. None of this strikes me as shocking in this full context, unless you're shocked by the notion there had to be someone to pioneer a profession for the first time in their municipality and we happen to be talking about him and his anecdote.
I worked for 3 years in power plants all over the world, including dams, and there were delays, cost overruns, structural defects, flouted safety measures, etc. Not really the civil engineering utopia that HN raves about.
Note that I'm not saying that it's OK for software engineering to suck because civil engineering also sucks. Both should try to improve.
intrinsic limitations of the human mind and approach the task as Very Humble Programmers.
The ironic thing was he was not very humble. He was pretty mean to a lot of people. He had a pretty massive ego.
- http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EW...
> I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility.
> Society is getting dissatisfied with the performance of programmers and of their products.
> [Program] testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.
> The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.
> The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
It's fascinating to see what he expected to be the biggest problems in programming. His discussion of more efficient programming techniques focuses on theorem provers, automated checking of loop invariants and the like, whereas today, the biggest problems typically occur during integration of software components with each other.
But maybe he actually did foresee that:
> I now suggest that we confine ourselves to the design and implementation of intellectually manageable programs.
Regarding provably correct programs: I'm torn here. On the one hand, if we required all programs to carry proofs of their correctness, that would exclude a huge number of current programmers who lack the formal education etc. to carry out these proofs. On the other hand, if all programs that we need would have proofs of their correctness (and thus carry a bunch of helpful invariants and formal specifications), it might be easier to combine all these programs, hence obliterating the need for most programming tasks that are just concerned with integrating multiple programs with each other.
I'll close with the most insightful paragraph from this whole piece:
> There may also be political impediments. Even if we know how to educate tomorrow’s professional programmer, it is not certain that the society we are living in will allow us to do so. The first effect of teaching a methodology —rather than disseminating knowledge— is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable.
This is fascinating because right now, a lot of people lament that our students are only being stuffed with facts, but not equipped with the methodological knowledge required for their professions.
Reposts are ok unless the story has had major attention in the last year or so (https://news.ycombinator.com/newsfaq.html). In this case there has: https://news.ycombinator.com/item?id=10014530.