ときどきの雑記帖 RE* (新南口)
たった一兆
前回に引き続きタイトルはアシモフの科学エッセイから。
debug
pythonでwhile queue
がうまく行かなかった話 - Qiita
キューの実装は複数あるが、queue.Queueとcollections.dequeでの差が問題になった。 もともとdequeを使って書いていたものをQueueを使って書き直した
この状態で下のコードを実行すると無限ループとなった。
引っかかるものを感じつつも(伏線) 二つ目のスクリプトを実行すると、 確かに止まらない。
from queue import Queue
queue = Queue()
queue.put("hogehoge")
while queue:
item = queue.get()
if n := len(item) == 1:
print(item)
else:
queue.put(item[:n//2])
queue.put(item[n//2:])
しばしスクリプトを眺めていると、
if n := len(item) == 1:
の部分が気になった。
これって n に入るのは len(item)
の値ではなく
len(item) == 1
の結果ではなかろうか?
通常の代入であればそう解釈されるし、
walrus operator だからってその辺の解釈が大きく変わらないとは思うんだけど。
そこで、
from queue import Queue
queue = Queue()
queue.put("hogehoge")
import pdb
pdb.set_trace()
while queue:
item = queue.get()
if n := len(item) == 1:
print(item)
else:
queue.put(item[:n//2])
queue.put(item[n//2:])
とデバッガを起動するようにして実行。
>python qiita.py
> qiita.py(7)<module>()
-> while queue:
(Pdb) n
> qiita.py(8)<module>()
-> item = queue.get()
(Pdb) n
> qiita.py(9)<module>()
-> if n := len(item) == 1:
(Pdb) p item
'hogehoge'
(Pdb) n
> qiita.py(12)<module>()
-> queue.put(item[:n//2])
(Pdb) p n
False
(Pdb) p len(item)
8
(Pdb)
ですよねー。
ということで
from queue import Queue
queue = Queue()
queue.put("hogehoge")
while not queue.empty():
item = queue.get()
if (n := len(item)) == 1:
print(item)
else:
queue.put(item[:n//2])
queue.put(item[n//2:])
と、代入を優先するようカッコをつけてやると
>python qiita2.py
h
o
g
e
h
o
g
e
(たぶん)正常終了。
さて、walrus operator の使い方が原因なら、最初のスクリプトが「正常に」動くのは変じゃね? と思いつつ実行すると…
from collections import deque
queue = deque()
queue.append("hogehoge")
while queue:
item = queue.popleft()
if n := len(item) == 1:
print(item)
else:
queue.append(item[:n//2])
queue.append(item[n//2:])
止まらない(笑)
こっちも walrus operator の行を書き直すと
from collections import deque
queue = deque()
queue.append("hogehoge")
while queue:
item = queue.popleft()
if (n := len(item)) == 1:
print(item)
else:
queue.append(item[:n//2])
queue.append(item[n//2:])
無限ループにはならずに終了する。 ということでなんか勘違いが入ってんじゃないすかね。
辞書をひこう
文中に知らない言い回しが出てきたときは、「誤字(脱字)だ!」と騒ぐ前に、まずは落ち着き、辞書を引いてみることだと思っています。辞書は自分の語彙の貧しさを知らしめてくれる。誤字だと決めつけた表現が、在った。そのとき、己とはいかに、思い込みで凝り固まって生きていることか、と実感する。
— 伊皿子りり子|編集Lily (@lilico_i) January 9, 2021
というのを見かけて、そういや昔(前世紀)シグネチャーに 「辞書をひこう桃を食べよう」とか書いていた人がいたよなあ と思い出しつつググってみると 逆だったらしい(笑)
桃を食べよう 辞書を引こう | ふらっと、もとい、こ~ひ~てん、もとい、いちれんたくしょう
タイトルは、JUNET時代(←同世代でも誰もついてこれないだろう?ニヤリ)の某氏のシグネチャに記載されていた一文。
正しい順番で再度検索すると古い fj の記事がひっかかり、そこにはあのシグネチャーが (メールアドレスの部分は除きました)。
old fj.beginners post 2021/2188
--
加藤洋太郎 --- 桃を食べよう、辞書を引こう ---
- –桃を食べよう、辞書を引こう–/加藤洋太郎 - Florian’s NewestDiary
- okkyの銀河制圧奇譚: 桃を食べよう・辞書を引こう
- Re:itojunさんを失ったこと (#1274440) | 2007年スラドの重大ニュースは? | スラド
それはそれとして、記事を読んでいて「あれ? これって間違ってないか?」と思ったときは できるだけ辞書をひくようには自分もしていたつもり。 ほかにもpodcastを聞いていて「今○○という言葉を間違って使ってないか?」 と思ったときも調べるようにしている(停止したり遡ったりが面倒だけど)。 こっちは自分の方が間違っていたことも結構あって、 「げ、そうだったのか」となったり。
fundamentals / lock-in
いつもの。
IT業界で「半世紀」近くのキャリアを積んで得られた教訓とは? - GIGAZINE
◆2:基礎を大切にすること
IT業界では技術が日進月歩で変化していくため、いつまでも基本的な事柄にこだわっていられないようにも思えます。 しかし、ゴールドバーグ氏は「ソフトウェア開発の基本的な考え方の中には、流行とは無縁なものがあります」と述べて、 いくら時間がたっても変わらない大切な「基礎」を6点挙げました。
BTI360 | What I’ve Learned in 45 Years in the Software Industry
- Focus on the Fundamentals
Technology constantly changes, but some fundamental approaches to software development transcend these trends. Here are six fundamentals that will continue to be relevant for a long time.
fundamental approaches to software development を「ソフトウェア開発の基本的な考え方」 としたのだろうけど、「考え方」は違うんじゃないかなあ。
英語「approach」の意味・使い方・読み方 | Weblio英和辞書
それと翻訳の方1行目の後半は翻訳記事の書き手の意見なのね。最初読み取り損ねてびっくりしてしまった。
◆5:目新しさに目を取られて落とし穴にはまらないこと
ゴールドバーグ氏によると、「新時代のソフトウェア開発」や「革命的な生産性」をうたうような製品やサービスには、 しばしば多額の先行投資や制約といった落とし穴があるとのこと。こうした問題のせいで袋小路に入り込むことを防ぐため、 ゴールドバーグ氏は「新しいものが常にいいものだとは限りません」と指摘しました。
- Beware of Lock-In
There will always be the next hot productivity product that will promise to revolutionize how software is built. Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now it can happen with frameworks too. Either way, lock-in means significant cost to change. Choose wisely. New is not always better!
Beware of Lock-In がどうして「目新しさに目を取られて落とし穴にはまらないこと」に? ロックインされることが落とし穴にはまるということだとして、 それ言い換える必要があるだろうか?
確かに New is not always better! (「新しいものが常にいいものだとは限りません」)とは あるけど、その前の Choose wisely を無視するのはねえ。
Perl
ちょっと流し読み的に読んだけど面白かった。 Perl 6(Raku)がああいう方向に行ったのはなんでだったんでしょうねえ。
2021
連休中も(ほとんど外出してない(できない))のでつらつら考えていたのだけどまだ結論に至らず。
PostScript
世界のプログラミング言語(31) PostScriptは印刷業界を支えたスタック指向型言語 | マイナビニュース
に
PostScriptは1984年にアドビによって開発されたページ記述言語です。1985年にAppleのレーザープリンターに採用されて普及しました。 なぜ印刷とプログラミング言語が関係するのか不思議に思うかもしれません。PostScriptが登場した時代、 電子印刷はそれほど普及していませんでした。というのも、コンピューターとプリンターの通信速度は遅く、 高品質な印刷データをプリンタに転送するのに膨大な時間がかかっていました。
それで、PostScriptでは印刷データを転送時間を短縮する目的のため、プリンター自身に計算能力を持たせることで転送時間の短縮を行ったのです。 PostScriptデータをプリンターに送信すると、プリンター側でプログラムが実行されて、描画データを生成し印刷するという仕組みです。
(最初のパラグラフにももやもやするものがあるけどそれはさてき) 「転送時間を短縮するため」って初めて聞いたと思うけどそんな話あったっけ? そのために当時のPC(Macintosh含む)と同等かそれ以上のCPUやRAMをプリンターに搭載するってのは 信じがたいものがあるなあ。
と思ったら
日本語版のうぃきぺに同様な記述があるのね。
PostScriptは1985年にアップルコンピュータのレーザープリンター、LaserWriterに採用された[1]。 モトローラ68000プロセッサと1.5メガバイトのRAMを搭載したこのプリンターは、 プリンターでありながら当時のパーソナルコンピュータと同等の計算能力を持ち、 それ自身が PostScript インタプリタを実行してページを生成した。 同じ年、ライノタイプによりPostScriptを採用したイメージセッタが発表された。
当時はコンピュータとプリンター間の通信速度の遅さが、印刷物の品質向上のネックになっていた。 しかし、プリンター自身に高い計算能力を持たせて、プログラミング言語を実行するという大胆な発想により、 一気に問題は解決された。PostScript以前は、伝統的な手法より品質が劣るとされてきた電子印刷が、 一気に商業印刷のレベルでも使われるようになり、今日では当たり前になっているDTPが普及するきっかけとなった。
英語版 PostScript - Wikipedia にはそれっぽい記述はないみたいだけどなあ (過去の履歴までは見てないけど)。
PostScriptのメリットというかアドバンテージは The history of Adobe PostScript にある
PostScript is device-independent. This means that a PostScript file can run on any PostScript device. On a laser printer, you get 300 dpi output, while the same file gives you beautiful and crisp 2400 or 2540 dpi output on an imagesetter. For users, this meant that they were no longer tied to one manufacturer and could choose the devices that best fit their purpose.
の方が大きいと思う。