YoshikuniJujo's avatar
YoshikuniJujo
YoshikuniJujo@yoshikunijujo.github.io
npub1a7y7...fdm2
Haskell好き
YoshikuniJujo's avatar
YoshikuniJujo 10 hours ago
今のところ、僕のシュー生地遍歴としては 固すぎ→丁度いい→柔らかすぎ→丁度いい→固すぎ(いまここ)
YoshikuniJujo's avatar
YoshikuniJujo 10 hours ago
シュー生地作りの終盤は、「卵を足す、ハンドミキサーで混ぜる、固さを見る」を繰り返すのだけど、はじめは「大丈夫か」ってくらい生地がぼろぼろになる。で卵を入れるうちにまとまってくるのだけど、まだまだざらついた感じ。さらに足していくと表面が滑らかになって、でもまだ粘る段階。ここが狙い目。で、さらに卵を加えるとどろどろって感じで生地が垂れる感じになる。ここまでやると、もう戻れない。
YoshikuniJujo's avatar
YoshikuniJujo 19 hours ago
ファウンダリは初期投資が大きすぎるから、それなりの大きさの国が、相当な予算をつけないと始められない。
YoshikuniJujo's avatar
YoshikuniJujo 19 hours ago
昔はファウンダリなんか泥臭くて、ファブレスこそが新しくてかっこいい企業みたいな雰囲気があったけど、今はもうみんなTSMC様々って感じ。 TSMCの資産として顧客からの信頼や、顧客との協力体制というものがある。 地道にがんばってきた努力が実ったということか。 ただ、TSMCがいかに優れた企業だと言っても、世界を支えるすごく重要な部分が1本柱なのは危険な気がする。 インテル、サムスンあたりが、もうすこしがんばる必要があるし、なんなら、できることならラピダスがその一画を支える企業になったらいいと思う。 「四天王のなかで最弱」くらいの地位までいければ万々歳だと思う。 で、基本的に何の制約もなければ、ファウンダリというビジネスはひとつの企業だけが強くなる「一強」になるわけだけど、顧客や社会、政治側の危機感によって、分散させようという力が働く。 ラピダスの勝機はそこにあると思う。
YoshikuniJujo's avatar
YoshikuniJujo 19 hours ago
昔はAppleはクローズドだから自由のためにGoogleを応援しようっていう話だったと思うのだけど、今はGoogleが強くなりすぎてるので、バランスを取るためにAppleを応援しなきゃって気持ちがある (けど、何もしていない)。 とここまで書いたところで、ちょっと調べてみたところ、GoogleとAppleだと時価総額は同じくらいらしい。 技術の世界を支配しているのはどちらかというとGoogleだと思うのだけど、AppleにはNintendoとかDisneyとかみたいな「ブランド」としての価値をひとつの柱にしている面があるのかもしれない。 あと、ソフトウェアはGoogleのほうが強いけど、ハードウェアはAppleのほうが強いというのもあるかもしれない。 すこし前までは「ソフトウェア」のほうが重視されてたけど、最近だと半導体不足などもあって、ハードウェアの地位が上がっているように思う。
YoshikuniJujo's avatar
YoshikuniJujo 19 hours ago
Stackの機能なのかCabalの機能なのかはわからないけど、ソースコードの拡張子を.xにするとalexに.yにするとhappyに食わせてくれるのって便利。 他にも.hscにするとhsc2hsに食わせてくれる。 あと、.lhsにすると、これはGHC側(というかHaskellに標準的な機能だと思うけど)で文芸的Haskellとして解釈してくれるというのもある。 文芸的Haskellだと、コメント部分と本体部分とが逆みたいになってて、普通に書いた部分はコメントになり、明示的に`>'で始まっている行とか\begin{code}と\end{code}で囲まれた部分だけが本体部分としてあつかわれる。 最近は全然使ってない。まあ英語話者じゃないと、それほどうれしくない機能なんじゃないかな。 もちろん日本語でコメント部分を書いてもいいとは思うけど。
YoshikuniJujo's avatar
YoshikuniJujo 19 hours ago
自作言語をひとつ作っておいて、それ以外のいろいろなアプリケーションを、その自作言語を設定言語として、その自作言語のコード例のようにして構築するってのは「あり」だと思う。
YoshikuniJujo's avatar
YoshikuniJujo 19 hours ago
自作言語を作るという話で、字句解析したり構文解析したりするといったあたりの話なのだけど、 ソースコード -(字句解析)-> -(変換)-> トークン列 -(構文解析)-> -(変換)-> 構文木 みたいな感じでパーサジェネレーターなどによる解析の後に、単純な置き換えレベルの「変換」を置くといい気がする。 つまり、「字句解析器や構文解析器に都合のいい出力」を「次の処理に渡すのにより自然なデータ型」に変換するということ。 字句解析器や構文解析器は、すでに十分に複雑なことをやっているので、できるだけシンプルにしておきたいという話。
ティラミスは一般的にはラム酒だか何かをいれるみたいだけど、もおもとはお酒は入れなかったらしい。
ティラミスを作りたいので、マスカルポーネと板ゼラチンが欲しい
パータ・ボンブというものがあるらしい。 白身に砂糖を加えて泡立てたのがメレンゲなんだけど、それの黄身バージョンみたいなものらしい。 卵黄をあわだてて、煮詰めたシロップを追加してさらに泡立てるみたい。
趣味のプログラミングは「永遠に生きるつもり」でやるのが楽しい。 壮大な目標を立てて、それをすごく細かいところまでこだわってコーディングする。 1ギガくらいの目標を1ナノレベルでこだわって書くのが楽しい。
Rubyってのは「Cでできる無茶」とはちがう無茶ができるのがおもしろい。 高レベルでの「無茶」。モンキーパッチとかだったかな。
Rubyの「なめらかでやわらかい」感じは他で味わえないので、一度やってみてほしい気はする。
Cでオブジェクト指向で書かれたコードを読むのって苦行な気がする。