borlanco

Amazing, a Nobel Prize in Engineering!. Strange times indeed.

Please, please, please remember to install some fire suppression!

Thank you, Larry!

Federico Tomassetti is also good. Check out his blog: https://tomassetti.me/blog/

We all see the writer in you, wanting to get out!

It's nice to be able to convey your feelings to your audience through writing, but great writers go further.

The world needs great writers, because they are travel guides. They guide us to visit places we couldn't reach alone. Worthwhile places that would go unvisited and unknown without our guides.

That's why "Kitchen Confidential" is such an amazing book. It's a travelogue.

When Gay Talese wrote "Frank Sinatra Has a Cold", he didn't write a profile of Frank. He was inviting us to go see Frank with him, to sign up to the great adventure of finding out who Frank really was.

If you would like to be one of our guides, I thank you.

Study the book "On Writing", by Stephen King, and begin inviting us to your travels!

The "creative" part is all decisions to be made before coding: architecture, design, modularization, algorithms, APIs, etc.

If I am in charge of those decisions, I can use Perl to build a prototype, to validate the solution I am creating.

But if I don't decide anything, my job is to code whatever. No chance for me to be creative.

Most quirks of Perl are there to make the construction of prototypes easier and faster.

To know more about creators and their tools, I recommend:

- "Programming is (should be) fun!", by Gerald Jay Sussman. https://m.youtube.com/watch?v=2MYzvQ1v8Ww

- "On Writing", by Stephen King. Just the chapter "Toolbox".

There are two types of programming, and each has its own definition of "relevant": new programming, with its preference for ready-made components to reduce complexity, and old-time creative programming, which usually was about the creation of new things.

The "creation" part is key. Perl is a tool for "easy creation", for creators that want to be more productive. This is what Larry Wall wanted.

This is why Perl is good for prototyping. You "create" the prototype, and then you "translate" it to something else.

Perl is quite relevant for me, but I say this as a creator.

For tips, commentary and insight about visiting Madrid, and the rest of Spain, this Youtube channel [0] is a gold mine.

James and Yoly really enjoy living here in Madrid, and they explain the good and the bad of our culture and customs. No bullsh*t, warts and all.

[0] https://www.youtube.com/@spainrevealed

This Asianometry video [0] explains why it is so difficult to develop and market new planes.

tl;dr The main obstacles are supply chain inefficiencies and that no one buys planes that aren't cost-effective.

[0] Japan's Commercial Jet Failure https://www.youtube.com/watch?v=XkmtrsE9Jfg

I am glad I was able to help you.

If you like "The Secrets of Consulting", the next one for you should be "Exploring requirements: quality before design", by Gause & Weinberg. What an eye opener it was for me!

Quite difficult to be like you. In any case, much obliged to you, sir!

We can learn from failures if we really want.

For example, see https://www.failory.com

I meant what was shown in this movie [0]. In a nutshell, the ability to remain calm when the unexpected happens, to try to solve the problem, or at least to not make it worse.

[0] https://en.m.wikipedia.org/wiki/The_Right_Stuff_(film)

Exactly this. Either they have the right stuff, or they don't.

I always debug with printf for the clear benefits you mention, and I happen to know another one.

Because I am commited to the Way of Printf, I have seen myself anticipating where printfs might be needed, and limiting the complexity of each segment of code to support printfs that aren't there yet.

In my experience, commitment to printf debugging incentivizes coding for simplicity and observability.

You noticed the conceptual integrity of the systems, as described by Fred Brooks in The Mythical Man-Month.

From Chapter 4:

"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."

"Because ease of use is the purpose, this ratio of function to conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design. This point is widely misunderstood."

"All my own experience convinces me, and I have tried to show, that the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system's basic concepts are best left out. If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts."

There are more anecdotes about Dijkstra in this collection of testimonials written by his friends, colleagues, and students: https://arxiv.org/abs/2104.03392.

These are some of my favorites:

From Tony Hoare:

  They removed recursion from Algol 60, on the grounds of its alleged inefficiency. Edsger's answer was that recursion was a useful programming tool, and every workman should be allowed to fall in love with their tools. 

  He would repeatedly stress the importance of choosing words carefully: "If you have to use your hands, then there is something wrong with your words", he would say, adding "imagine there is a blind man in your audience, how would you speak?" 

  Over time, I came to learn and appreciate that Prof. Dijkstra's class was operating at two different planes. There was the lesson and then, the lesson within the lesson. At one level, the goal was to solve the presented problem. At the second and more richer meta-level was the approach for arriving at the solution. 

  Prof. Dijkstra taught us that in computing science, complexity comes for free; one has to work hard for simplicity. 

  In his technical writing, he used language like a precision tool. For him, precision did not necessarily imply ease of reading, and he stated that the reader also had to make an effort to understand. 

  Professionally, Edsger's impact on me is best summarized by his ATAC Rule 0: "Don't make a mess of it." It made me strive for simplicity in notation and modelling throughout my working life and take unpleasant complexity as an indication of a possible lack of comprehension. 

  I decided against writing with a fountain pen. He never took issue with this, except in a letter that he posted seven weeks before his death: "I hope you will overcome your resistance and learn how to fill a pen without soiling your fingers, or otherwise you are denying yourself one of the joys of life." These were his last written words to me. 

  A famous quote of EWD is the following: 'I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself "Dijkstra would not have liked this", well, that would be enough immortality for me' (EWD1213). I can testify that this actually works. 

  When I write papers, even now, I still see Edsger over my shoulder going "Tsk! Tsk!" [...] I found that being less sloppy not only helped my readers understand what I had written, but most importantly, helped me from confusing myself.

  I have an invisible Edsger inside my head which looks over my shoulder when I am writing and quietly goes "Tut tut" if I write something that is muddled or not accurate. I don't always listen to that voice but know I should. 

  At faculty meetings when Edsger was not present it was common for someone to say "If Edsger were here he'd say such-and-such." 

  He came to work in the summer wearing a big Texas cowboy hat - they are made to keep you cool in the Texas sun. Often he would have on a cowboy's string tie. So from the waist up, he looked more Texan than I did. But he almost always wore shorts and sandals, which ruined the cowboy image completely. 

  Edsger critiqued not the person but only what they said, and later one could drink a beer and laugh as if nothing happened. Technical differences and shortcomings should be treated this way. 

  Douglas Engelbart aroused Dijkstra's ire so much that he needed a whole page of vituperative prose to offload his emotions (EWD387). What has Engelbart done to provoke this outburst? One only has to refer to "Engelbart's Law", see Wikipedia. Its reasoning seems to run as follows: look at what mere printing has done as a tool for thought; the system demonstrated is so much more powerful than printing that it must quickly lead to Intellect Augmentation. This way Engelbart showed no appreciation for the rich culture developed over centuries. What makes printing a powerful tool for thought is mostly due to other things than technology. Much of the power of this culture comes from publishers and editors, who sniff out what is worth printing and hold back what is not. Another important component of this culture is provided by libraries and librarians. Much is due to scholarly societies, which started printing their proceedings and to commercial publishers, which created journals, each with their editorial board and unseen bevy of reviewers. Most of all it is due to the idea of a university.

That parameterization exists, of course, but are you ready to consider the possibility that it might be unknowable?

I am glad you found it useful!

For me, simplicity and reduction of resistance [0] were the most effective improvements. Mark is always kind enough to explain the psychological underpinnings of productivity, or its absence.

[0] http://markforster.squarespace.com/blog/2022/6/13/resistance...

I got this book [0] by Mark Forster [1], tried the techniques and found out what works for me. It is a gold mine.

The author describes in his blog [2] many more of his ideas and experiments about productivity.

[0] https://www.goodreads.com/book/show/26171733-secrets-of-prod...

[1] https://en.m.wikipedia.org/wiki/Mark_Forster_(author)

[2] http://markforster.squarespace.com

I would say yes. They try hard to make cooks laugh.

This is one of their recipes:

  APOCALYPSE RAMEN

  This is basically like regular ramen soup but with three critical differences: 

  - It is intensely chaotic, which is to say that you can pretty much toss anything into it and say you did it on purpose.
  - It's slightly healthier, if your depression has lifted enough that you want to eat something other than delicious, delicious chemicals.
  - It involves a mason jar, so you can feel like you're riding out the end of days in true hipster style.

  Core Ingredients & Supplies: 

  - Mason jar or other heatproof receptacle.
  - Boiling water.
  - The only requirement here is rice noodles. Why? Because they cook fast.

  Preparation: 

  - Put all ingredients in the jar.
  - Boil some water.
  - Pour into jar to cover ingredients.
  - Shake it up a bit (not right away, otherwise you'll burn your hands and get more depressed).
  - Let it sit for a few minutes.
  - Enjoy???

  Variations: 

  - Remember those takeout packets of hot sauce and soy sauce? This is a good time to use them.
  - Frozen or fresh vegetables. Wilted is absolutely fine here. International readers may call them "wilty" vegetables. Reader, you are now bilingual.
  - Any kind of spices. We particularly suggest garlic or ginger powder, but seriously, anything will work.
  - If you have tofu or some other protein to use, go for it.

Pirsig's book is not really about engineering, but about how we engineers relate to the world.

In engineering school I was taught to see the world in a special and unique way, to be able to solve engineering problems as a professional. In the book, this worldwiew is very well laid out.

An example:

  > Precision instruments are designed to achieve an idea, dimensional precision, whose perfection is impossible. There is no perfectly shaped part of the motorcycle and never will be, but when you come as close as these instruments take you, remarkable things happen, and you go flying across the countryside under a power that would be called magic if it were not so completely rational in every way. It's the understanding of this rational intellectual idea that's fundamental. John looks at the motorcycle and he sees steel in various shapes and has negative feelings about these steel shapes and turns off the whole thing. I look at the shapes of the steel now and I see ideas. He thinks I'm working on parts. I'm working on concepts.

This reads like Asimov. Thank you!

You tell them they are special, and definitely not like animals, and you hold them to a higher standard.

And the important part comes right after this. What happens when you hold them to a higher standard? People then choose to accept or reject the standard, and they live according to their (personal) choice.

If some people accept the higher standard and live by it, they prove that they are special, definitely not like animals. That is free will: https://en.m.wikipedia.org/wiki/Free_will

That's easy. After learning the language, study good C code. Try to grok how the masters build higher-level abstractions.

Learn from widely used C code that is not a toy. Examples: sqlite.org, git-scm.org

If you don't understand something, look it up in the C standard doc.

Most of the time, you will want to program for speed, and C will let you. Learn and practice C profiling.

Also, you will need to learn defensive programming. The best source about this is "Learn C The Hard Way" by Zed Shaw: https://github.com/zedshaw/learn-c-the-hard-way-lectures

It's true that engineering principles are not usually applied in the software field, but if quality is the most important requirement, they are indispensable.

Example: https://galois.com/

Example: https://inst.eecs.berkeley.edu/~cs162/sp13/hand-outs/They-Wr...

The best book about the application of engineering principles to software is SICP [0].

Abelson and Sussman wrote SICP to illustrate the principles. Everything else in SICP is some means to that end.

They reveal that SICP is about engineering in the Preface to the First Edition:

  > The techniques we teach and draw upon are common to all of engineering design. We control complexity by building abstractions that hide details when appropriate. We control complexity by establishing conventional interfaces that enable us to construct systems by combining standard, well-understood pieces in a "mix and match" way. We control complexity by establishing new languages for describing a design, each of which emphasizes particular aspects of the design and deemphasizes others.

Programming is still a craft, not engineering, or manufacturing.

Programming can be engineering if you know how to do it. Engineering is, in a nutshell, a set of principles you learn and apply, and never deviate from, in work and life. Engineers always deliver the highest quality.

Craftspersons do not know these engineering principles, or they disregard them. They invariably deliver faster than engineers, and their output is always simpler and of lower quality.

In "The Rise of Worse is Better" [0], an engineer (from MIT) debates with a craftsman (from Berkeley). The Berkeley guy cheerfully admits he is disregarding an engineering principle (correctness), and that's why "the MIT guy did not like this solution because it was not the right thing".

[0] The Rise of Worse is Better https://dreamsongs.com/RiseOfWorseIsBetter.html