*Reflections on the Craft of Programming* # 2023 Reading Goals Following my [[Current Interests]]. I was re-reading *Coders at Work* for the following: * Change of the tech culture over the years. * Notion of the [[Titles and Staff Engineer]]. Did this exist back then? If not, why? * Role of the [[Programming Languages]]. # Summary ## State of the [[Programming Languages]] ecosystem - many weren’t happy with it Between [[C|C++]] and [[Java]] (and C#), many weren’t happy / limited by the choice. Since 2009: * [[Go]] and [[Rust]] are meaningful new players in the industrial [[Programming Languages]]. * [[JavaScript]] is no longer a toy language ("Ajax" apps existed then too, but there was a widespread belief that JavaScript is not a good language and it needs to be abstracted away). Subsequent rise of [[TypeScript]]. * Similarly, Swift and [[Kotlin]] evolved iOS and Android programming from Objective-C and [[Java]]. * Rise and rise of [[Python]], both as an backend application language and scientific computing language. * Other players, such as Julia and Elixir. Interviewees' view on the status quo: * [[#Joshua Bloch]] considered Java the best, with C++ and C# as meaningful competition. * [[#Ken Thomson]] unhappy with C++, but left with no alternative. * [[#Brad Fitzpatrick]] wanted a [[#Partially Typed Language]]. [[#Joe Armstrong]] has a similar “permanently inconsistent vs temporarily inconsistent” idea. * [[#L Peter Deutsch]] is unhappy with C - "Every language is qualitatively the same; it has the concept of pointer." - This highlights the problem that [[Rust]] solves. * [[#Fran Allen]] is also unhappy with C and languages following it - "We have seriously regressed, since C developed ... we over-specify the location of data". * [[#Simon Peyton Jones]] is perhaps the only optimistic one; He's excited by the advancement - both from the technological (STMs, Monads) and cultural (no longer need to explain what functional programming or [[Haskell]] is). Almost everyone is disdainful towards the [[OOP]]: * [[#Jamie Zawinski]] and [[#Brendan Eich]] hated the [[Design Patterns (GoF)]] worshipping crowd, blaming them for the demise of Netscape. [[#Fran Allen]] had a similar experience. * [[#Douglas Crockford]] and his famous disdain towards the *classical* OOP. * [[#Joe Armstrong]]'s criticism of the [[#On OOP]] - around unnecessary bundling of the *contexts* - is quite an an apt one. (The irony is, OOP paradigm saw this as a feature) >[!quote] Criticism of the implicit context >...\[the problem is the \] implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle" ## Moore's Law, concurrency, and efficiency The end of the Moore's law and its consequences is a big topic amongst interviewees: * Living with the end of the [[Moore's Law]]. This was the boogyman everyone feared. * Living in the multi-core world - this is when the multi-core PCs were becoming mainstream. * Concurrency and the role of programming language. Many believed that a new programming model / language was needed to harness the multi-core computing. * Tangentially, peoples' idea of *efficient* code was quite naive. For them, this was "rolling up ones' sleeves, abandoning high level languages, and writing a subroutine in assembly". Even though this is the case for some abstractions - Numpy being written in C - but [[Moore's Law#Rise of Hardware Acceleration|hardware acceleration]] was a bigger game changer of 2010s. This boogyman around the Moore's Law turned out very boring. Moore's law is still ongoing, albeit slowly. In 2023, we're excited about the upcoming 3nm TSMC chips that Apple is rumored to use on their M3 processors. Multi-core CPUs are mainstream - though no 1,000 core CPUs. Finally, the programming model is the most *boring* of it all - we're programming the same way as before (at least, more or less; we're not all coding in distributed Haskell or Prolog) but we don't feel hindered by it. The nail in the coffin is that we no longer talk about it anymore. It feels eerily similar to the *peak oil*. We are even closer to the end of the Moore's law, but the industry don't perceive it as an existential threat. There are other things to worry about and we're even optimistic about the near-term hardware improvements. Side note - there's a lot of snark when it comes to the multi-core world. **Examples:** > [!quote] Joe Armstrong > The other source of real concurrency in the chip are multicores. There’ll be 32 cores by the end of the decade *(2010)* and a million cores by 2019 or whatever. > [!quote] Peter Seibel > Yet by 2019, or whatever, we’re supposed to have 1,000 cores in a notebook computer. >[!jee] >Perhaps we're not far off given that Nvidia GPUs have 1,000s of CUDA cores. Other comments from the interviewees: * [[#Joe Armstrong]] - Skeptical about implicit parallelism. * [[#Guy Steele]] - [[Fortress]] programming language with implicit parallelism. ## Disdain for the modern programming This is universal as almost all practitioners were known for building the literal foundation of this industry. * [[#Ken Thomson]] - “Too many layers” * [[#Joe Armstrong]] - “Today we are overburdened by choice” * [[#Donald Knuth]] - "There’s this overemphasis on reusable software" However, some like [[#Peter Norvig]] and [[#Bernie Cosell]] are more accepting of the modern programming. Similarly, for the question of *what makes a great programmer*, almost everyone emphasized curiosity and having initiatives to open up black boxes. Another related topic is [[Reusability]]. Many believe that we have too strong emphasis on reuse, and we're not quite right with how we tackle reuse. ## On [[#Donald Knuth]] and [[Dijkstra]] Both Knuth and Dijkstra are held highly. Interviewees took them seriously. Every interviewee's asked with: * Have you read Knuth's *the Art of Computer Programming*? * What are your thoughts on [[Literate Programming]]? Do you practice it? [[Dijkstra]]'s * One should learn how to program thoroughly *before* they ever touch a computer. * Importance of writing and communication. ## Nobody has a fancy setup Many interviewees has a very rudimentary setup. Seibel asks questions around *debugging* and *programming environment* and many of them shyly admits that `printf` debugging is their most natural method of debugging. - `printf` debugging. - `Emacs`, without many customizations. ## On Good Programmer > [!todo] summarize this section. * Curiosity * Enthusiasm * Communication * The code-maximalism * "Empathy Gene" * [[#Joshua Bloch]] - You aren’t going to be a good API designer or language designer if you can’t put yourself in the shoes of an ordinary programmer trying to use your API or language to get something done. * Impact * [[#Joshua Bloch]] - "solve real problems for real customers... The moment you lose sight of that and who your customers are, you're dead meat." >[!jee] 💭 2023 thoughts >The term *programmer* is actively harmful, as this implies that *programming* is the primary activity. > > Many mention [[Titles and Staff Engineer]]-esque ideas here and there, but that is still seen as something secondary. "Do you still code" is asked to everyone, and everyone shyly answers "not as much as I used to". With *Software Engineer*, the role is to participate in the end-to-end software engineering lifecycle, including but not limited to *programming*. > > **💡Ideas**: > - Importance of communication and writing > - Thinking in terms of impact / ramifications > - Influence and leadership - [[#Brendan Eich]] - "enough leadership or influence to cause other programmers to write code like they would write without them having to do it" ## Archetype Peter Seibel asked "Do you see yourself as a *scientist, an engineer, an artist, a craftsman, or a mathematician*" to everyone. > [!quote] [[#Jamie Zawinski]]'s archetype > Definitely not a scientist or engineer because those have very formal connotations... > [!quote] [[#Douglas Crockford]]'s archetype > I think of myself as a writer. Sometimes I write in English and sometimes I write in JavaScript. > [!quote] [[#Fran Allen]]'s archetype > I think of myself as a ==computer scientist==. I was involved in my corner of the field in helping it develop. And those were interesting times—the emergence of computer science—because there was a lot of question about, “Is this a science? ==Anything that has to have science in its name isn’t a science.==” Others: * [[#Ken Thomson]] - Craftsman * [[#Dan Ingalls]] - Engineer < Craftsman < Artist ~ Scientist ## On Burnout Many people are old and thus retired but burnt out from tech. [[#Jamie Zawinski]] is the prime example (he was 40 in 2008). [[#Dan Ingalls]] lives in a ranch and [[#L Peter Deutsch]] is a composer. > [!quote] [[#Jamie Zawinski]]'s burnout > "I got completely burned out on the software industry. That part of it I just couldn't take anymore - the politics of it both in the corporate world and in the free-software world." --- *The following are the reading notes on all 15 interviewees* # [[Jamie Zawinski]] # Brad Fitzpatrick > [!jee] 💭 2023 Thoughts > Fitzpatrick's journey of scaling [LiveJournal](https://en.wikipedia.org/wiki/LiveJournal) is quite illuminating. Back then, [[Scalability]] was a fun problem. CGI, FastCGI, adding more servers, database sharding ... this was un uncharted territory and the practitioners had to figure out on their own. This sequence of paragraphs explained the journey of scaling LiveJournal. > [!quote] On Scaling LiveJournal > > Then I converted to FastGCI. Then I tuned Apache and turned off reverse DNS lookups. All these steps you go through. > ... > I think that raised maybe six or seven thousand dollars or something to buy these two big Dells and put them in Speakeasy in downtown Seattle. > ... > The next thing to fall over was the database, and that’s when I was like, “Oh, shit.” ... “Well, I can optimize queries for a while,” but that only gives you another week until it’s loaded again. > ... > That’s when—I thought I was the first person in the world to think of this— I was like, we’ll shard it out—partition it. So I wrote up design doc with pictures saying how our code would work. “We’ll have our master database just for metadata about global things that are low traffic and all the per-blog and per-comment stuff will be partitioned onto a per-user database cluster. These user IDs are on this database partition.” Obvious in retrospect—it’s what everyone does. Then there was a big effort to port the code while the service was still running. ## [[Programming Languages]] Fitzpatrick complains that [[Java]] engineers are obsessed with *pure java* and has an unhealthy aversion towards JNI. > [!jee] 💭 [[Go]] makes using CGO really easy, but Go also has that aversion. Fitzpatrick displayed a small optimism that App Engine would be this generation's [[BASIC]]. > [!jee] 💭 Heroku of the `$current_year` is still an illusive goal as of 2023. ## Partially Typed Language > [!quote] On Programming Language of the Future > **Fitzpatrick:** I want something that lets me have static types and checks all that stuff at compile time. \[...\] > **Seibel:** \[...\] so the compiler can optimize better? > **Fitzpatrick:** No. I also want it to blow up at compile time to tell me like, "You're doing something stupid." Good insight. This raises a question around the role of types: 1. Allow efficient compilation (for a compiled language). 2. Safeguarding and enforcing structure. In the year 2008, we had the insight over (2). This is before [[TypeScript]] Funny how we're living in the world where "efficiency doesn't matter" yet we still want (some) types because this allows us to move [[Velocity|faster]]. Historically dynamic languages' lack of static types were seen as their *benefit*. However, [[TypeScript]] has proven that this is not the case. (And typescript doesn't use types for *performance*, for sure). # Douglas Crockford Father of the modern [[JavaScript]]. Doug's criticism of the [[OOP#Classical OOP|Classical OOP]] is valid. The class hierarchy is too static to meet the need of the needs of the programming. Focus on communication, reading, and writing. Crockford highlights it multiple times at the end on "what makes a good programmer". > [!quote] On communication > The other thing I wanted was that they be really literate in whatever language they write to other humans. I want people who can write, because we spend a lot of time writing to each other. We’re writing email or documentation. We’re writing plans. We’re writing specifications. I want to know that the people on my team are capable of doing that, and that turns out to be a really difficult skill. > [!quote] on software architecture > What we really need to be doing is getting better at predicting what we’re really going to need in the future. # Brendan Eich > [!jee] 💭 2023 Thoughts > Most of the interview is on [[JavaScript]] - how Eich only had a week to design JavaScript and he had an upper management directive to "make it look like Java". He's not apologetic about JavaScript's deficiencies as his decisions shaped the next decades of the tech industry, but he shares what was on his mind during the ten days he was designing and developing JavaScript. ## On JavaScript and other programming languages **Influences and constraints to JavaScript:** * prototype-based delegation was from [[SmallTalk]]. * [[Dynamic Scoping]] was from Perl and Lisp. This was trendy in 1990s. JavaScript's `this` has a dynamic scoping behavior. > [!note] > However dynamic scoping (and JavaScript's `this`) is an anti-feature. We avoid it via `Function.prototype.bind()` or `=>` operator. * Eich wanted to reduce the total number of objects - thus the `window` object was conflated with the global object. > [!note] 🪦 - this caused so much error in the future. **On Lisp:** On the whole *everything is lambda* approach, Eich is skeptical - "It's very reductionistic and it's not for everybody" > [!quote] > That’s the sort of impoverished approach that tries to make everybody into an expert and it will not work on the large number of programmers out there who have been mistrained in these Java schools. **On Other Languages:** > [!quote] Dissatisfaction against the academic PL research > But the academics are out there convinced static type systems are the ultimate end and they’re researching particular kinds of static type systems like the ML, Hindley- Milner type inferences and it’s completely divorced from industry. >[!jee] [[Paul Graham]] made the same comment about academic PL research too. > [!quote] Dissatisfaction on C++ > We’re able to use most of its features—there are too many of them. It’s probably got a better type system than Java. But we’re still screwing around with ’70s debuggers and linkers, and it’s stupid. I don’t know why we put up with it. > > [!jee] The market for [[Rust]] so ripe back then. ## Other Topics Similar to [[#Jamie Zawinski]], he criticizes the [[Design Patterns (GoF)]] worshipping engineers. They saw this as a Netscape-ending mistake. > [!quote] > I never bought the *\[[[Design Patterns (GoF)|Design Patterns by Eric Gamma]]\]*. Some people at Netscape did, some of Jamie Zawinski’s and my nemeses from another acquisition, they waved it around like the Bible and they were kind of insufferable because they weren’t the best programmers. He expresses his criticism of Design Pattern throughout the interview. > [!quote] I do agree with Peter Norvig: those patterns show some kind of defect in the language. Finally, Eich presents a role criterion that is closest to the modern notion of [[Titles and Staff Engineer]] - exerting technical leadership and influence. **This is the closest we get to such a notion in this book**. > [!quote] On [[Titles and Staff Engineer|Principal Engineer]]: > at Netscape when we talked about their track for principal engineer—is somebody who isn’t management but still has ==enough leadership or influence to cause other programmers to write code like they would write without them having to do it==, because you don’t have enough hours in the day or fingers. # Joshua Bloch > [!jee] 💭 2023 Thoughts > Along with [[#Peter Norvig]], Joshua Bloch foreshadows (and built) the modern software engineering principles. His methodologies are understandably cautious as foundational building blocks he built - Java Collections Library, Java Generics, Google's foundational Java libraries ... all are widely used. Prior design decisions have heavy ramifications and they cannot be easily corrected. > > I personally have fond memories of Joshua Bloch, given how invested I was to [[Java]]. His books, such as *Effective Java* and *Java Concurrency in Practice* were formative reads in my early days of computing. ## [[Programming Languages]] > [!quote] > when you choose a language - you're choosing a community. > ... > I also think that the inertia of a platform is so much higher now than it used to be. A modern platform isn't just a language and a few libraries; On keeping language not complex, and "quadratic explosion of complexity". Power versus complexity trade off. > [!quote] On Java Generics > \[Graham Hamilton; of Java Generics\] fought against it for years, trying to keep generics out of the language. The above is a similar situation as [[Go]] as the Go authors fought against generics for the longest time. ## On [[Concurrency]] This is an interesting one. Bloch believes that [[Java]] is the best language. The argument is very ... pragmatic? Realist? First, the only real competitions he sees are [[C|C++]] and C#. Second, he is skeptical about constructs such as the [[Concurrency#Software Transaction Memories|STM]] (Software Transactional Memory). It was his research area and he doesn't believe that this is a silver bullet. Third, he believes that a concurrency programming model, if dominant, can be adopted to Java. On Erlang's [[Concurrency#Actor Model|Actor Model]] he replies "if they prove to be a big win, they can also be implemented in many languages" > [!jee] 💭 2023 Thoughts > This is a strange prediction. Bloch is right in many ways - STM is still experimental and Erlang/Actor Model didn't "take over the world" - However, even though Bloch was correct within the known universe, he missed large trends that he didn't mention. > > Nonexistent or non-mainstream technologies back then are: > * [[Go]] which did not exist in 2008. > * [[JavaScript]] wasn't a "serious" programming language yet. AJAX applications were created, but [[Node.JS]] didn't exist yet and no substantial backend JavaScript programming occurred. > > These two languages were used as examples, but they represent two different paradigms - [[Green Threads]] and Async event-based programming - that weren't mainstream yet. Green Threads allowed to have effectively unrestricted number of threads. Async programming removed certain problems (no concurrent race conditions) but introduced different problems (race conditions still exist, callback hell, cannot exploit multi-core, ...). > > I'm surprised that the [[Asynchronous Programming#C10k Problem|C10k Problem]] or some variant of it (focusing on asynchronous IO) is not mentioned at all. # Joe Armstrong > [!TODO] organize and summarize. Love of Prolog; Erlang is heavily influenced by Prolog, even though very little of it is visible now. > [!quote] On good programmers > The really good programmers spend a lot of time programming. Heavy emphasis on curiosity & opening up the black boxes. Many examples of this. ## On [[Concurrency]] * Functional Programming Language is about immutable state * "less is more" - "copying data can make things more efficient as it reduces lock contention" * "I'm also very skeptical about implicit parallelism" permanently inconsistent vs temporarily inconsistent. "As I change the code in a system, it's not atomic" ## On Communication Syntax vs semantic - > The code shows me what it *does*. It doesn't show me what it's supposed to do. Once again, focus on writing. Quoting [[Dijkstra]] - "if you're no good at English you'll never be a very good programmer." --- Armstrong is totally fine with Erlang not being the most popular language. > [!quote] On Erlang's popularity > "It might need Microsoft to take some of its ideas and put ==some curly braces here and there== and shove it out in the CLR to hit a mass market." # Simon Peyton Jones > [!TODO] organize and summarize. [Wikipedia](https://en.wikipedia.org/wiki/Simon_Peyton_Jones), Creator of Glasgow [[Haskell]] Compiler. * Programming Language is UI/UX * However, the academia is engaged in more theoretical activities; "soundness and correctness". * [[Concurrency#Software Transaction Memories]] * Very big supporter of this. * Locks and critical sections are too low level, one needs to get it right; * Optimistic concurrency. STM doesn't need to be optimistic. Skepticism around formal specification * better to prove "property" than the whole program. > I think much more productive for real life is to write down some properties that you’d like the program to have. > types are like a very compact specification language. "set of correct programs" and "set of correctly typed program within a system" > which can’t be typed by a particular type system but which nevertheless don’t “go wrong” at runtime, Nuanced view of the Functional Programming * "I haven't coded large OOP systems; thus I don't know much about it; so I'm careful with what I say" * Glad that FP is now having mainstream usage; we at least don't need to explain *what* [[Haskell]] is. "analogies" * "building bridge" analogies * "banking system" analogy # Peter Norvig > [!jee] 💭 2023 Thoughts > Out of all the people in the book, Peter Norvig's views are most aligned with the back-then future (and now present) views of the tech industry. Understandable given that Norvig was a Director of Research at Google. In that sense, he didn't just predict the culture, but shaped it too. [[Hackers; Heroes of the Computer Revolution#Conway's Game of Life|Conway's Game of Life]] is the first large non-trivial program that he wrote. ## On Modern Software Engineering Norvig's views are the most modern. He highlighted that it is "important to get a *quick understanding* than the *total understanding*" and we only need to understand the low level at the abstract level. This extends to his criticism of [[Literate Programming]] too. > [!quote] > \[Knuth asked\] What’s the best order for writing a book" - However, nowadays "\[programmers\] don’t want to read a book. > > \[Knuth\] wanted to put it in a linear order rather than in a web-like or a searchable order Above highlights the [[Growth Engineering]] mentality. Before, knowledge is organized either for exhaustive learning or exhaustive referential material. However, this is now how we interact with knowledge anymore (prescriptively, one can lament on "lack of deep understanding". Descriptively, this is fact of life, and perhaps it always was). Programmers are trying to get stuff done and we don't have time to exhaustively study a subject. Thus, Knuth's writing style (both for books and programs) that exploits the linear order is out of fashion. > [!quote] On Agile; "Agile Sudoku" > ...then there’s this other guy, whose name I’ve forgotten, one of these test-driven design gurus. He starts off and he says, “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bunch of tests.” But then he never got anywhere. He had five different blog posts and in each one he wrote a little bit more and wrote lots of tests but he never got anything working because he didn’t know how to solve the problem. > [!quote] On UML > If you can’t do it in the language itself that’s a weakness of the language. This comment is consistent with his presentation on [[Design Patterns]]. # Continuous view of Programming Norvig discusses two related topics: * [[Computer Science - Discrete or Continuous?|Is Programming continuous or discrete]]? * Software decisions live on the spectrum of Return on Investments. Norvig used the example of *search quality* with the concept of precision/recall to communicate that binary correctness doesn't exist. Given the rise of AI/ML in the 2010s software engineering, this insight is apt. In that sense, everyone else is living in the past era as they highlighted the importance of discrete mathematics in programming. RoI of software engineering is another topic. Again, Norvig displayed his pragmatic / industrial view. He believes that all software problems, including NASA missions, should be judged from the RoI perspective (though he admits why it can't be done this way, as the political backlash of losing a rocket would be too strong). Norvig thinks that NASA's cost per LoC is prohibitively high. His caricature of the NASA engineers is quite hilarious: > [!quote] On NASA scientists > At NASA they’re rocket scientists! They aren’t software guys. They say, “Software is this necessary evil. Straight line code, I can sort of understand; if it’s got a loop in it, that’s kind of iffy. Then if there’s a branch statement inside the loop, ooooh, that’s getting away from what I can solve with a differential equation in control theory.” Norvig then discusses programmers' tendencies to desire for a *closure* with a problem. However, it may not be worth it and we need to move on. This idea is surfaced on his *Sometimes I delete everything and rewrite, instead of isolating and fixing the bug*. This approach does not yield closure but it may be the most efficient thing for us to be doing. ## On Good Programmer Seibel and Norvig briefly talked about [[Teach Yourself Programming in Ten Years]] and the concept of master-apprenticeship. Supposedly IBM tried this (IBM master-programmer; hard to find references to it). One insight that Norvig had was that in the olden days of apprenticeship, *materials were rarer* thus must tread carefully: **I found this analogy very apt**. > [!quote] > When you were doing goldsmithing, there's only so much gold. Or when the surgeon's operating, there's only one heart, ... **Characteristics** >[!TODO] organize this * Talking about different type of *programmers*; some are good at coding, some are good at understanding the codebase. * Getting along with people; programmer is more social than before. * make progress and improve upon * being able to keep everything in your head at once. * "go backwards \[from the end state \]"; (Norvig's referring to the top-down design). If necessary, Being able to dig in (good example of investigating network filesystem API). # Guy Steele > [!quote] Switching from *Math* to *Computers* > I had no intuition whatsoever for infinite dimensional Banach spaces. > [!jee] Totally empathize with this, as the *Functional Analysis* class was the time I realized that I wasn't good at math. MIT Hacker culture; History of [[vim vs emacs|emacs]]. It started off as a macro processor for TECO; he needed to "standardize the macros" > [!jee] it's strange to think that Emacs once was "bleeding edge". Praising mathematical ideas (using integer algebra as an example); but one doesn't need to be accustomed to math to do this. "It's not possible to understand everything anymore" - said this multiple times. "non-linear reading of code" "no example of good code to read now that most software are commercial" "learning programming before [[Structured Programming]] era" ## [[Programming Languages]] Guy Steele used *a lot* of languages and he has a well-rounded view of all of them. They all have something to offer. ### On Language Evolution Before, Programming Languages were once designed once and people move on. Now they're too complicated to design once; they evolve over time. This means that languages need to be designed with growth and evolution in mind. > [!jee] Example of [[Software Engineering at Google|Software Engineering is programming integrated over time]] in action. > > Many older used to have `$LANG-$YEAR` format to describe it - `C99`, `Smalltalk-80`, ... However, most languages now have "living version". > [!quote] Language trade-offs at the syntactic level > On the other hand, it’s really hard to make a language that’s great at everything, in part just because ==there are only so many concise notations to go around. There’s this Huffman encoding problem==. If you make something concise, something is going to have to be more verbose as a consequence. The comparison to the *Huffman encoding problem* is apt. Even independent of the paradigm mismatch (static vs dynamically typed), one cannot appease all use cases from the syntactical level. ### Other Language Thoughts > [!quote] criticism of [[Haskell#Monad|Haskell Monad]] that I agree with. > monads strike me as that fan (White Knight; Through the Looking Glass), where you’re dragging in the I/O and trying to hide it again—are the side effects really there, or are they really not? Discussion of [[Fortress]], Guy Steele's project. Language focused on implicit parallelism. Obviously he's bullish on this topic. # Dan Ingalls > [!quote] [[Inconvenience is a Feature|Ignorance is Bliss]] > > **Ingalls:** If I had been as comfortable in a system like Lisp, I never would have bothered \[with inventing Smalltalk\]. > > **Seibel**: Alan Kay has said that ==both Lisp and Smalltalk have the problem that they’re so good they eat their children==. If you had known Lisp, then Smalltalk would have been the first eaten child. * Obsession with interactive programming * [Squeak](https://en.wikipedia.org/wiki/Squeak) / [Etoys](https://en.wikipedia.org/wiki/Etoys_%28programming_language%29), *Lively* * Constructionism * but not computer maximalist; doesn't think that everyone *should* learn to program (*should* is a strong word and Ingalls avoids from saying this) * How Do I program? "I always set it up for the most immediate gratification." * System should be as dynamic as possible; (ex: HTML) * note: I disagree with this take; I think the core system should be as simple as possible. HTML to JavaScript is the right path of evolution. We should've not started with dynamic rendering (`<canvas>`). > [!quote] On dynamic foundation > But it’s easier for someone to put a layer, like HTML, on top of that. I think it’s better to have the underlying systems be as dynamic as possible. Then you can put on ==syntax or type restrictions==, or this, that, and the other that make it into a fixed thing. * HyperCard * [[SmallTalk]] * The idea of *kernels*. * Microcode & Virtual machine * Simulating keyword arguments in [[JavaScript]] via Object notation. * "terribly inefficient, but it works" > [!jee] > This obsession (or subconscious guilt) of inefficiency is unfortunately; indeed it took a generation (who didn't grow up with this imperative) to surpass this and see this only from structural merit. > [!quote] On Types > Types are essentially assertions about a program. This is similar to [[#Partially Typed Language|Brad Fitzpatrick]]'s view. # L Peter Deutsch > [!jee] 💭 2023 Thoughts > Deutsch is also the main character of the [[Hackers; Heroes of the Computer Revolution]], Part 1. It was interesting to have a different portrayal of the same person. His rejection of [[LISP]] is especially insightful. ## Why Programming is Hard Deutsch makes [[Dijkstra#On the cruelty of really teaching computer science]] style argument on why programming is hard. 1. Programming is math adjacent, and math is hard. 2. Programming has diverged so much from the physical world. Some memorable quotes around these are: * *"The physical properties of matter are such that 99.9 percent of the time you can understand it in aggregate" * *"Software is a discipline of detail, and that is a deep, horrendous fundamental problem with software."* ## On Good Programmers > [!quote] On *(not)* good programmer > Not only were they not used to thinking in terms of the impact or ramifications of changes; they to some extent didn’t even realize that that was an essential question to ask. This has similar notion to the modern [[Titles and Staff Engineer]]. > [!quote] On word *coder* versus *software developer* > there are a lot of different roles and a lot of different processes and skills that go into achieving that end. > ... > It doesn’t cover the process of understanding the problem domain and eliciting and understanding the requirements. It doesn’t cover the process—at least not all of the process—of the kind of feedback loops from testing to what happens after the software has been released. Basically “software developer” refers to the world within the boundaries of the organization that’s developing the software. ## Criticism of [[LISP]] This is pretty good one as both Deutsch and Seibel (the interviewer) are both proficient and passionate with Lisp. Deutsch's criticism are: * Lack of informationally density * Syntactically monotonous ## On [[Programming Languages]] > [!quote] On Ownership and why pointers are bad > "Every language is qualitatively the same; it has the concept of pointer." > > The essence of the problem is that there is no linguistic mechanism for understanding or stating or controlling or reasoning about patterns of information sharing and information access in the system. This is before [[Rust]]; I wonder what he thinks (well; he only does music now). The problem Deutsch is describing - unpredictable mutability - is real. [[#Joshua Bloch]] argued against it via immutability but that provides only so much (from the bottom-up perspective). Deutsch is frank at admitting not knowing how to proceed forward. > [!quote] On a potential alternative > I don’t think I have enough insight to know how to describe patterns of sharing and patterns of communication at a high enough level and in a composable enough way to pull it off. > [!quote] On [[Haskell]] Monads > You know, I have never understood Haskell monads. > [!quote] Criticism of the [[OOP]] and [[Reusability]] > The things that I see getting reused theses days are ==either very large or very small==. The scale of reuse that we were talking about when we were promoting objects was classes and groups of classes. ## Techno-Utopia Talking about the techno-utopian (or disillusionment) from it. > [!quote] > a lot of my motivation for going into software in the first place was that I thought you could actually make the world a better place by doing it. I don’t believe that anymore. Not really. Not in the same way. [[Techno Utopia|constructionist]] mentality - computer power into the hands of a lot of people... > [!quote] [[Techno Utopia#China|On Internet]] > I never would’ve predicted the degree to which corporate influence over the Internet has changed its character over time. I would’ve thought that the Internet was inherently uncontrollable, and I no longer think that. China shows that you can do it pretty effectively. ☹️ This was only 2008 and things only got worse. # Ken Thomson > [!jee] 💭 2023 Thoughts > This was an interesting one. Ken Thomson is indeed *the* original Unix hacker. Yet, he's working at [[Google]] (at the time of the interview) with its own culture. Agree that Google had many interesting problems for him, but the cultural clash - "They take a subroutine call, package it as an RPC". "I don't have C [[Software Engineering at Google#Readability|Readability]]" > > Ken Thomson's apology for [[C]] boils down to "write better code" and "bugs of different form can exist in every programming language" - which is not the most honest position, as the industry have converged that the class of bugs possible in C, such as [[C#Buffer Overflow|Buffer Overflow]], is too dangerous. **How he got started** - Started with the electrical engineering / analog computers. Exciting time for Computer Science. Discussion of the new sorting algorithms (Shell Sort) being discovered. **Career** - not much plan; "Basically I planned nothing and I just took the next step. And if I had to do it over again, I’d just have taken the next step again." ## Apologist for [[C]] Thomson's defense of C is twofolds: 1. You can write bad code (and thus bugs) in any language. 2. *Buffer overflow* is a bug, but the alternative - using `strcpy` versus `strncpy` - which limits the number of characters - also introduces a change in behavior (silently truncating data). Thomson identifies this as a bug too. I find this to be a false equivalence. Bad code and bugs exist in every language, but that doesn't mean that all languages are identical. Second, consequences of security vulnerabilities and application bugs are drastically different (though, in the early days of computing, security vulnerabilities weren't treated seriously as the industry had more cooperative view of the world). On C++, Ken calls it "too complex, there's almost no replacement for it". It's quite telling that everyone hated C++, but there was no replacement for it. [[Rust]] and [[Go]] really tackled this market. > [!quote] Skepticism towards compiler optimization; > No. I think it’s mostly because the machines have gotten a lot better. Compilers stink. > [!quote] Skepticism towards the [[LISP]] machines; > ==I didn’t think that Lisp was a unique enough language to warrant a machine==. And I think I was proved right. All along I said, “You’re crazy.” The PDP-11’s a great Lisp machine. The PDP-10’s a great Lisp machine. There’s no need to build a Lisp machine that’s not faster. ==There was just no reason to ever build a Lisp machine==. It was kind of stupid. ## Materialism Ken Thomson had very pragmatic, almost materialistic perspective on programming. Examples: * **Code needs to run** - Optimizing the code that isn't running is pointless. * criticism of [[Literate Programming]]; two versions of code; you'll end up reading the "real & correct" version - I found this to be the best criticism of the literate programming amongst the interviewees. > [!quote] On [[Literate Programming]] > It’s two representations of the same program that are often out of phase and conflict with each other. > [!quote] On Style > I prefer much denser books that just give me the syntax and semantics rather than chatting me up and telling me what’s good style and what’s bad style. ## On Good Programmer Good programmer? Team? > Enthusiasm; > Just working with good, compatible people. I don't think the above belief can fly in the modern [[Meritocracy]]. anti-reductionism is the name of the game. ## On Modern Programming > [!quote] Too many layers > you *must* read top-down > ... > All the software here has layers and layers and layers of what happens if this doesn’t work, what happens if that doesn’t work. What happens if I don’t work. > ... > The operating system is not only given; it’s mandatory. > ... > you’re just building another layer on top of another layer on top of another layer ## As a [[Google]] employee > [!quote] On [[Software Engineering at Google#Readability|Google Readability]] > **Seibel**: I know Google has a policy where every new employee has to get checked out on languages before they’re allowed to check code in. Which means you had to get checked out on C. > > **Thompson**: Yeah, I haven’t been. > > **Seibel**: You haven’t been! You’re not allowed to check in code? > > **Thompson**: I’m not allowed to check in code, no. > [!quote] On Google > ==The programming style here at Google is so bizarre. They take a subroutine call, package it as an [[GRPC|RPC]], and store it somewhere static.== Which means anybody can call it at any time for any reason. And then they call generic listening kind of code and somebody somewhere gets a message, goes off and finds that, and makes that subroutine call. # Fran Allen [wikipedia](https://en.wikipedia.org/wiki/Frances_Allen) - IBM, [Stretch](https://en.wikipedia.org/wiki/IBM_7030_Stretch) > [!quote] What makes a program beautiful: > ... some intrinsic structure and obviousness about it that isn’t obvious from the problem itself. ## On Career > [!quote] On [[Dual Career Ladder|Manager versus Individual Contributor]] > Everyone were RSMs (Research Staff Members)... So one moved in and out of management without any stigma attached. > [!quote] Fallacy of becoming a manager too fast > Get a reputation for technical work. ## [[Programming Languages]] > [!quote] Disdain for the [[OOP]] > But one of the people working for the subcontractor had just discovered object-oriented programming and decided that he would apply it to the extreme. > [!quote] Disdain for [[C]] > We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. > > But they still overspecify. The core thing is that it specifies location of data. ## On [[DEIB]] Early programming had a lot of women, but Computer Science that emerged between 1960s and 1970s rooted from engineering schools; which were very male-centric. Discussion on funnel; OLPC [[DEIB#Anita Borg|Anita Borg]]'s 50/50 by 2020; # Bernie Cosell Bernie Cosell started his career in the [[Hackers; Heroes of the Computer Revolution]] generation. Many familiar names - The Model Railway Club, Richard Greenblatt, and Bill Gosper, were mentioned as part of his MIT career. ## On Debugging Large part of his career is known for debugging. Some crazy debugging stories, such as reading memory octal values of memory over payphone. > [!quote] > Really what I was was a very careful programmer with the arrogance to believe that very few computer programs are inherently difficult. Cosell also confessed how in many cases, he re-wrote code instead of debugging them, thus he couldn't explain what the bug was. Something that [[#Peter Norvig]] confessed too. Even though Cosell presents his story in terms of *debugging*, he talks about the software development lifecycle in its entirety. There are many concepts (testability, fast development cycle, refactoring) that Cosell practiced while these words didn't exist. ## On Refactoring His explanation of refactoring, without using the term, was fascinating. He describes a case where the code is structured wrong and it needs to be refactored. However, this is difficult to justify for a lack of the business case: > "It’s not going to improve anything but it’ll make the program better for next week." - Not going to get permission to do that. Afterwards, Cosell describes his strategy of planning and accounting for refactoring work along with the bug fix. > ... Now when you go to fix a bug and you have a choice on how to fix it, fix it moving toward the better model. Don’t just fix it in the shortest way. Later on, Seibel introduces Cosell to the modern terminology. > **Seibel**: Have you heard of refactoring? > **Cosell**: No, what is that? > **Seibel**: What you just described. I think now there's perhaps a bit more acceptance ... ## On Comments > The only place I tend to put comments in my code is when my instinct says, “This particular piece of code, even though it works, doesn’t clearly state what I’m trying to accomplish.” And so I put a comment in the code to say, “This code sorts the table,” if it may not look like your standard table- sorting code because, as it turns out, I can take advantage of something. ## On [[#Donald Knuth]] > The second problem *\[of learning Knuth's [[The Art of Computer Programming]]\]* is once students get sensitive to that, they get too clever. This is a good point. It is ironic that Knuth argued against [[Performance#Premature Optimization|Premature Optimization]] yet being well versed in algorithms may make one *compulsive* about optimization and performance. One may feel "wasteful" for doing certain things, whereas if one is ignorant then one wouldn't even notice. > Programmers are the worst optimizers in the world. They always optimize the part of the code that’s most interesting to optimize, This describes *Snacking*. ## On [[C]] Cosell's criticism and endorsement of C is interesting. Cosell believes that C was too powerful and too expressive; and it ended up eating the whole software world. He admits that it is used in too many places, but compared to the competition back then - Ada, Fortran, Pascal - C was just so powerful at controlling the machine. > \[C\] was designed to be a systems-programming language and it was such a comfortable systems-programming language that all the hotshots used it. We built operating systems out of it. We built real-time systems out of it. > > I remember the wars in the days of Pascal. The argument was that computers should help you; that C was too dangerous a language. The two big voices I remember were Wirth and [[Dijkstra]]. On the other side was every systems programmer I know, including me. I wrote everything in C. So C sort of steamrolled the zillions of languages back then. > > The government tried mandate Ada and they wouldn’t let contracts unless they were in Ada. C steamrolled over those. It was just amazing. Cosell feels regret with C's popularity, as common C security vulnerabilities - buffer overflow, dangling pointers - are too common and too dangerous. However, he shivers at the alternate history where Pascal was used as a systems language to write systems. ## On [[Java]] > Java didn’t feel right. My old reflexes hit me. Java struck me as too authoritarian. > > "Oh, this is just another one of those languages to help ==not- so-good programmers go down the straight and narrow by restricting what they can do==." This is the same criticism that [[Go]] attracts today. ## On Modern Software > [!quote] > Each generation of programmers gets farther and farther away from the low-level stuff and has fancier and fancier tools for doing things. > ... > So I don’t envy modern programmers, and it’s going to get worse. > ... > I’m glad I can have a little bit of repute as having once been a good programmer without having to actually demonstrate it anymore, because I don’t think I could. Cosell also has the common observation of *too many layers*. However, Cosell's views are more neutral. He doesn't just lament about the good old days, but praises the difficulty of modern software engineering. Cosell presents his conceptual understanding of Google Maps - frontend, backend, communication via AJAX, real time routing - and marvel at its complexity and sophistication. **I really like this take**. Cosell admits that he won't be a good programmer today (independent of his age) and doesn't dismiss the software engineering as it stands. # [[Donald Knuth]] > [!quote] His job was not “to be on top of things” but ”to be on the bottom of things”. ## [[The Art of Computer Programming]] * Every five pages of my book is somebody’s career. * balancing between “this is too complicated” and “this is too trivial” ## Literate Programming Discussion on [[Literate Programming]] and [[Structured Programming]] ## On Modern Programming > [!quote] > “People have this Strange idea that we want to write our programs as worlds unto themselves so that everyone else can just set up a few parameters and our program will do it for them.” … “If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then ==who’d want to go into that as a career==?” * Disdain towards [[Reusability]]. * “There’s this overemphasis on reusable software” * “A lot of programming goes today isn’t any fun because it’s just plugging in magic incantations” Similarly, Knuth has disdains towards the modern Computer Science - i.e. data structures that has better asymptotic behavior for unpractically large *N* - "they have lots of data structures that are just .. *baroque* is the only word I can think of." --- * “programming is a lot like religion; people have their beliefs.” On explaining * stereo view instead of one dimensional view. * “A good explanation somehow combines different viewpoints” Skeptical about formalism > [!quote] On language > I resent having every language be universal because they’ll be universal in a different way. This has very similar read as [[#Guy Steele]]’s reflection. “Get inside somebody else’s way of thinking, to decode their vocabulary, their notation…” “don’t only read the people who code like you” # Other Observations Almost everyone are skeptical about **Formal Methods**. * [[#L Peter Deutsch]], as a person with a PhD on formal methods, is skeptical about it - "development system should strive to giving you confidence that the code does what you intend to do (paraphrased)". * [[#Donald Knuth]] - “I can't prove lots of intangible things” The "puzzle questions" - *how many golf balls fit in a school bus* - was very popular, especially around [[Google]] and [[Microsoft]]. Many interviewees were criticizing them. >[!note] Find & Learn more about this. Change in programmer interview