Lisp Scheme Part41 (855ﾚｽ)
上下前次1-新
650: 2024/04/12(金)15:01 ID:wZ+y5Ko5(3/3) AAS
>>648
もう80才超えてるし、教鞭執れてるかは怪しいね…
最近プログラム書いてねえなあ、とかウェブで言ってたし
代わりに最近のエッセイ本はマ/CSというより一般人向けっぽいので食指動かず
Understanding the Digital WorldシリーズとかDefending Yourself in a World of Too Many Numbersとかそんな題の書いてる
ソフトウェア作法、プログラミング書法、プログラミング作法の現場で戦うプログラマーの為の三部作は素晴らしい、言語に縛られない(あえて題材は様々な言語)し、lispにも通ずる普遍的な知恵袋だよ
スレチなのでそろそろこの辺で
651: 2024/04/12(金)15:05 ID:dUdcEEpo(1) AAS
>>646
Steele先生はlisperの毛嫌いするC系言語/Algolishな言語も無数にデザインしているという皮肉！
652(3): 645 2024/04/12(金)15:53 ID:OhyEPSVL(1) AAS
lispの話をしよう
onlisp.lispのようなオレオレutil(s).lisp/scmから引用し過ぎるのはあまり宜しくない？
macroはコンパイル順の関係で引く方が問題起きにくいけど
名前がdescriptiveなのは前提として
too generalであれば初見の人に読みにくいのではと思うこの頃
一方でspecificであるかぎり、手続きを分かつ働きすら無い関数抽象も読み易い:
carにget-operator、cdrにget-operandsなど単なるリネームでも重用する
これらはpackage内にレキシカルな意味で近傍に置くべきよね？(使い捨てならflet/labels、共用ならdefun)
より一般的な小物をコーディングを楽にする為だけに引くならば、lisp書きなら定義も大体覚えてるだろう有名な小物util集(alexandria、sfri)に依存した同梱するのも(ライセンスが許しても)憚られる…
このスレやSO等見ても必読書なOn Lispは知名度あるだろうから、onlisp.lisp由来のものは初見で読めてコンパクトでバランス取れた妥協点だと思って使ってるんだけど
(ライセンスや再帰志向で性能難アリなので、手習いがてら書き直したクローン版、念の為)
なおonlisp.lispは手続き名がいにしえのlispかよってくらいヤバいのが欠点
653: 2024/04/12(金)23:54 ID:/A9qFmr2(1) AAS
文章下手糞すぎて読む気も起きない
これって神の言語に慣れすぎて言語障害になった例かよってくらいヤバいのが>>652の欠点
654: 2024/04/13(土)18:14 ID:JilIuOKd(1/2) AAS
ストールマンがガンになったらしい
長髪も髭も落としてしまって別人みたいになってる
655(1): 2024/04/13(土)18:24 ID:OrtqC7Lq(1) AAS
効いてる効いてる
656: 2024/04/13(土)19:21 ID:JilIuOKd(2/2) AAS
何が？
657: 2024/04/13(土)22:51 ID:Vi4F3OXr(1) AAS
昔MSの偉い人がGNUはガンだとか言ってたな
ついに自覚させたか
658: 2024/04/13(土)23:32 ID:c7UXCLXT(1) AAS
>>655
お前は脳にガンを抱えてるなw
659: 2024/04/14(日)12:56 ID:JRHy27WB(1/4) AAS
ゆる学徒ハウス別館
現役Lisperが語る！ Lispはオーパーツで人類には早すぎた【電脳史学】
動画ﾘﾝｸ[YouTube]
660(1): 2024/04/14(日)13:37 ID:JRHy27WB(2/4) AAS
ゆるコンピュータ科学ラジオ
大人の勉強は「夢の中」が主戦場。寝ながらマクロを書くといい【Lisp雑談】
動画ﾘﾝｸ[YouTube]
661: 2024/04/14(日)14:04 ID:JRHy27WB(3/4) AAS
コーシー噴いたｗ
662: 2024/04/14(日)15:00 ID:XsKNoxHh(1) AAS
>>660は娯楽コンテンツとしては面白い
でもLispは良いとして集合論を勉強しようとしてるのにはやれやれだな
Haskellで圏論とかAIで代数幾何に夢見たりするのと似てる
結局広く浅くでウンチク欲を満たすに留めて、実践から逃げたいのだろうな
実践は壁だらけだから
663: 2024/04/14(日)17:27 ID:ezgj98lZ(1) AAS
Lispとは別に2人で集合論やって
Lispは一冊何か挟んでからPAIP読んでほしい
番組のネタ的に
664: 2024/04/14(日)21:34 ID:p4Nf2jzu(1) AAS
その人らはLispに大した拘りはないし
今更検索でまともに引っかからない古代のPAIPなんてやる意味を見出せないだろ
AI関連ならTranslatorからChatGPTブレイクに至るまででも話題にしたらいい
665(2): 2024/04/14(日)21:56 ID:JRHy27WB(4/4) AAS
そうかなあ、論理プログラミングとか自然言語解析とか右側の人大興奮じゃないの
666: 2024/04/15(月)01:53 ID:YG3lrvG/(1/4) AAS
>>649
MLやregexエンジン積んでパターンマッチ機構を言語ビルトインにしても特にアドバンテージなんて無いと思うけどな
50行のコードでcl-ppcre(perl相当)とも機能面では十分戦えるわけで
or/and，named-capture/backref、lookahead/behind-assertion、predication、filter、context-sensitiveなreplace等ね
超古典な"LISP" Winston, Paul Horn, 2nd edのchap.17に載ってるやつ
本を薄くするために徹底的に再帰で書かれてるからまあ性能は察せ()
再帰で分かりやすいコードだから叩き台にもオススメ
667: 2024/04/15(月)02:00 ID:YG3lrvG/(2/4) AAS
あれはsymbolic pattern matchなのでregexと比べるのは良い例出なかったごめん
まあexplodeしてしまえばもうキャラクタベースだ
確かGrahamの>>652にあるシンボルをバラすやつ、まあ3行くらいで書ける小品だけど
explodeってネーミングがクールで覚えてたわ
668(1): 2024/04/15(月)02:27 ID:wPU2Kemh(1) AAS
>>665
そうそう、PCと自分のスキルで実践出来る分野なのに(最低限の真似事すら)やってないのがお察しか
右の人が予めPC音痴だと予防線張ってるのは自走力低めだと自己分析出来てるのかも
まぁ実践(この場合はプログラミング)で玉砕しちゃったら、しょんぼりするか歯切れ悪くて
面白くなくなるタイプだからチャンネル的には今のままで良いのかも
左の人は画面キャプチャしながらライブコーディングするスタイルを何処かで見せないと説得力に乏しい
左右どちらも含蓄なく浅はかに見えてしまうので、その道の専門家をお呼びするスタイルにして欲しい
C#のufcpp的な人が(声とコード画面だけでも)出演したら(最低限の真似事なら)実践する人が増えると思う
669: 2024/04/15(月)02:48 ID:YG3lrvG/(3/4) AAS
>>665,668
うむ、若かりし頃はマルコフやProlog/SQLモドキとかやってた、なるべく決定論的なのが個人的な好み
トレースを分析しても理解の困難なモノは、決して知的探究心を満たしてはくれないのだ
流行りの文章生成もマルコフならトレーサビリティは完全なのが良い
670(1): 2024/04/15(月)03:14 ID:YG3lrvG/(4/4) AAS
古いAIのバイブルPAIPすら恥ずかしながら未読の身ですが…
lispもデータドリブンなNN系はむしろ苦手とは思わない
NN系がマスメディアでもバズり出した頃にウィキペディア見たら、Pythonのサンプルコードが載ってたので
そのままCPython/Numpyとclで書いてみたら、ベンチはsbclぶっちぎりだったよ
もちろん個々の処理がバックのcライブラリより速いなんて言わない
同レベルのコーダが同ロジックで翻訳すればの話
その差はclの無駄に細かいarray/vectorコンストラクタ引数の設計
具体的にはR/W抑えるビュー相当の:displaced-*と:fill-pointer、配列の動的リサイズ指定の:adjustable引数ね
Numpyのndarrayはこの辺が裏で自動でやるのでコーダの裁量がない
まあNumpyでプラグマ/フラグ駆使してその辺のお節介挙動を切れば普通に負けるかも
あくまで並コーダが素直に書く限りの話
671(5): 2024/04/15(月)03:45 ID:KXqIDgH/(1) AAS
Cバックエンドで配列のviewをサポートしてるなら究極的には言語/処理系ではアルゴリズム瑕疵が無い限り有意な差はないよ
ただし最速言語Fortranを半分程度使うNumpyにも優位性はある
gccはじめ同じILにコンパイルされても配列多様コードでにおいてCより数倍は速い
ただしNumpyは書き方に細心の注意をしないとユーザの預かり知らぬ所で勝手にディープコピーする大きな罠も
そうした不透明性が嫌い
明示できるCLのFortran実装を待ち望む
672: 2024/04/15(月)03:58 ID:TPgVCyAO(1) AAS
>>671
clの明示性といえば、:rehash-size :rehash-threshold等で個々のハッシュテーブルまでチューンできるのがいいね
配列なんかよりハッシュテーブルの方がリハッシュコストが遥かに高い
動的言語のリハッシュは知る限り全部処理系任せか、サポートしていてもインタプリタのコマンドラインオプションで一律にしか変えられない
673(1): 2024/04/15(月)06:50 ID:DfbFoW6K(1) AAS
>>671
>ただし最速言語Fortranを半分程度使うNumpyにも優位性はある
>gccはじめ同じILにコンパイルされても配列多様コードでにおいてCより数倍は速い
この部分、Fortranで配列多用したらCより数倍速い的な意見なのかな？
1ミリも分からんので、詳細求む
674(1): 2024/04/15(月)11:04 ID:SeS0dYr5(1) AAS
>>671
言語/処理系で有意な差はないと言ってるのに、Cより数倍も速いって、矛盾してるぞw
675: 2024/04/15(月)11:32 ID:dChAXctC(1) AAS
>>674
何の根拠も無く「数倍は速い」なんて言い出さないから
>>673に対する>>671の回答には期待しているw
676(1): 2024/04/15(月)11:39 ID:L/ePcET8(1/2) AAS
中間言語が同じならコーディングの瑕疵は人間工学的な問題
Cは宣言が貧弱でin/out、純粋関数、エイリアスの有無は推論頼りだから失敗すれば死ぬ
ただ最近はrestrict宣言付けて回るなら重なるか推論不能な配列のエイリアス有無も指定可、難解だけど
一方で参照渡しのFortranはtaraiベンチで推論失敗すればデリファレンス地獄で死ぬわけだけど、これ解消する宣言あったっけ？
むしろ宣言無しのナイーブなコーディングなら数倍どころでは済まんよ
ランタイムの重いclは比類なき宣言の豊富さで静的言語にまで迫ろうと頑張ってるわけで
677: 2024/04/15(月)11:50 ID:L/ePcET8(2/2) AAS
パフォーマンス志向でarrayとdeclareまみれのclはlispっぽさが失われるのがつらい
何でも出来るのだと前向きに考えてゆきたい…
678: 2024/04/15(月)11:53 ID:xx2br7bI(1) AAS
>>671,676
話逸らさんで良いから
Fortranの「配列多様コードでにおいてCより数倍は速い」コードを出してw
679: 2024/04/15(月)13:00 ID:h9iqzVMR(1/2) AAS
ゆる「コンピュータ科学」ラジオなので、集合論でもいいだろｗ
マウントしないと気が済まんのか
上下前次1-新書関写板覧索設栞歴
あと 176 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.021s