ときどきの雑記帖 RE* (新南口)

忘れねばこそ思い出さず候

もやもや

C(や同じ形式)のfor文ならノータイムで手が動くけど Javaやらの拡張for文だとちょっと手が止まることがあるなあなどと思ったり。 どこら辺に境界線があるのかわからないけど 程度の差はあってもまったく何も参照せずに何かを書きあげるのは無理じゃないですかね。

でまあ、以前から何度か(ここ以外の場所、私信)で書いていることなんですが、 サジェストなどのプログラミングサポート機能を見ていると90年代初頭のF1を連想するんですね。 具体的にはこの辺→ ウィリアムズ・FW14 - Wikipedia

LTのネタくらいにはなるかなあと思ってはいるんですが、 きちんとまとめるのは面倒だなあと寝かせ続けて早幾年 😄

ところでF1ネタからの流れでもうちょっと。 いま、「思考のからの逃走」 (思考からの逃走 | 日本経済新聞出版) という本を読んでいるのですが、ちょっと引っかかる記述に遭遇しまして。

たとえば、筆者の好きだったF1では、1990年代に(当時の)ハイテクノロジーによるドラ イバーズアシストが導入され、それに向き合う態度はドライバー間ではっきりと分かれ た。トラクションコントロールを信じて、全速では曲がれないコーナーにフルスロット ルで進入するもの、トラクションコントロールがあってもアクセルを自分で煽ってしま うものなどである。

最初のうちは、ドライバーズアシストを信用しない者のほうが安全に走行できたように思う。 こうしたハイテク装備の信頼性は、登場当初決して高くはなく、誤作動に起因した事故も 多かったからである。しかし、何シーズンかを過ごすうちに、テクノロジーを信じて アクセルコントロールを自動操縦系に任せてしまうドライバーのほうが好成績を残すことになった。

(アクティブサスペンションやトラクションコントロールなどのついたマシンの)ドライビングテクニック云々は マンセルの自伝 にも書かれていて、その辺が自分の書こうと思っているところに関わっているので 興味深く読んだのですが上記の直後にこんな部分があるんですね。

あのアイルトン・セナの1994年の事故も、ローテクだったマクラーレンのマシンでトラ クションコントロールされたマシンを深追いしすぎたことが遠因であるとまことしやか に囁かれた。

セナの事故ってマクラーレンから移籍したウィリアムズ(・ルノー)でだし、 その年のレギュレーションではトラクションコントロール(などのハイテク装備)は 禁止されていたように記憶してるんですが (従って「ローテクマシン」で「ハイテクマシン」を深追いなんてやろうにもできない)、 わたしの勘違い or (この文章の)読み違い?

翻訳本の原著タイトル

これ、オライリージャパンの近刊リスト O’Reilly Japan - Books :: New and Upcoming もそういう問題があったりします。 翻訳本のタイトルのみでその他の情報が皆無に近くて、 原著がO’Reillyのものでなかったりすると調べるに手間がかかるんですよね。 原著者の名前があればそこを足がかりに調べることもできますが それすらなかったりすることも。

実際に翻訳本が出ると O’Reilly Japan - 計算できるもの、計算できないもの のように原著 (What Can Be Computed? - What Can Be Computed?) へのリンクがついたりしますけど。

翻訳関連では、地の文に現れた参考文献(書籍)のタイトルが 原題の直訳で実在する翻訳本のそれと違うとか、 翻訳本は存在していないのに タイトルが翻訳されていたりするケースがままあって これもどうにかして欲しいんですが、面倒なんだろうなあ (せめて原著のタイトルをカタカナ書きなどでなく元の言語で調べられるような 形で記載して欲しい…)

Theoさま

一か月ほどの前の話題ですが

Subject: Re: new: lang/zig From: “Theo de Raadt” Date: 2021-02-28 7:00:27

で

I take no position on what lands in ports, but want to make a public comment. I doubt you wrote the following sentence:

Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

から書いている反論(意見)が「らしい」なあと。

curl

で、Cで書くことの云々と言えば先日23周年を迎えた (curl is 23 years old today | daniel.haxx.se) curlの作者が(23周年の日の少し前に)

という興味深い記事を書いていました。

Lots of people keep referring to the awesome summary put together by a friendly pseudonymous “Tim” which says that “53 out of 95” (55.7%) security flaws in curl could’ve been prevented if curl had been written in Rust. This is usually in regards to discussions around how insecure C is and what to do about it. I’ve blogged about this topic before, but things change, the world changes and my own view on these matters keep getting refined.

I did my own count: how many of the current 98 published security problems in curl are related to it being written in C?

Git のソースコード

さらにC絡みの話で、プログラミングのスキルを向上させる手段の一つとして 他の人の書いたプログラムを読むというものがあるけれども Gitのソースコードを読んでみない? という記事。

Boost Your Programming Skills by Reading Git’s Code

その理由は

Git’s codebase is an incredible resource for intermediate developers to further their programming knowledge and skills.

で、さらに具体的に7つ挙げている。

Here are 7 reasons why it’s worth digging into Git’s code:

  1. Git is probably the most popular software dev tool in use today. In short, if you’re a developer, you probably use Git. Learning how Git’s code works will give you a deeper understanding of an essential tool you work with every day.
  2. Git is interesting! Git is a versatile tool that solves many interesting problems to allow developers to collaborate on code. As a curious human, I thoroughly enjoyed learning more about it.
  3. Git’s code is written in the C programming language, which offers a great opportunity for developers to branch out into an important language they may not have used much before.
  4. Git makes use of many important programming concepts, including content-addressable databases, file compression/inflation, hash functions, caching, and a simple data model. Git’s code illustrates how these concepts can be implemented in a real project.
  5. Git’s code and design are elegant. It is a great example of a functional, minimalist codebase that accomplishes its goal in a clear, effective way.
  6. Git’s initial commit is small in size – it is made up of only 10 files, containing less than 1,000 total lines of code. This is very small compared to most other projects and is very manageable to understand in a reasonable amount of time.
  7. The code in Git’s initial commit can be compiled and executed successfully. This means you can play with and test the original version of Git’s code to see how it works.
≪ prev Ce qui ne passe pas dans ce qui passe
next ≫ 曲がらねば世は渡れず