ぶっちゃけ始めるのにいい言語て何 part4
■ このスレッドは過去ログ倉庫に格納されています
>>745
詐欺師が何言っとるかしらんが、高卒レベルとか「文系」の知識では無理。
メリケン式の情報科学の知識を前提とした人事の下では問題無い。 ちなみに、ラムダはラムダ計算、計算可能性理論由来の概念だから、数理論理学、数学基礎論の分野に属する。
普通の数学者、特に日本の数学者は基礎論なんてやらない、興味ないって人が多い。
日本では応用数学は数学屋から嫌われ差別されているが、基礎論は文系の哲学とか応用数学みたいな物との認識あり。
「ラムダ計算なんてね分かるけど興味無い」って数学屋がほとんど。 情報科学? 何それ美味しいの?
phpで糞サイトコーディングするのに
そんな凝った知識要らんとですよ 計算の本質が捉えられてなくてはイノベーションは起こせないよね >>746
ラムダ式は関数表記法の一種であってラムダ式なくても合成関数の概念はなくならない
ラムダ式が言語になくたって合成関数書ける言語はあるし、
関数がファーストクラスでなくてもチューリング完全な言語なら
関数を表すデータ構造を自分で作れる ラムダ計算なんてラムダ式とほとんど関係ないし、実際の計算機の実行と全く関係ない。
(実際はチューリングマシン)
関数適用を一種の計算と捉えるとか、実際の計算でそう捉える必要性はほぼないわ。
バカが自己満足度を高めるために時々持ち出すが無視しても何にも困らん。 そりゃ簡単な課題だけ相手にしていたら高級な知識は要らんよw
電気屋さんレベルのタスクに電磁気学の知識が要らんように。
どのみちIT土方には無用の知識。
使う機会が無い。 じゃあ話すな。
以下のスレタイだってことを理解してから書きこめ。
「ぶっちゃけ始めるのにいい言語て何」 ぶっちゃけ、始めるのに良い言語は実際の計算機が実行するマシン語などではなく高級言語でしょ
ぶっちゃけ、ラムダ計算は数学であり高級言語だよ ぶっちゃけ、実際の計算はどのように実行されているか
なんてことは最初に学ばなくても全然良い
なんとなくわかってればいいだけ 機械は動作原理がわからなければ組み立てられない
簡単なCPU作ってLEDをチカチカさせたりするところから始めたら
原理的にはGoogleだってAmazonだって一人で組み立てられる
けどそれは、時間は有限だと言うことを忘れてる思考だよ
あいつらはそんなこと考えてない アプローチが逆だということを言ってますので
まさか思うけど、一人で作ろうなんて誰も思わないというようなツッコミは無しでお願いしますね
一応念のため こんにちは。
大好きだった初代PSゲームの自作MODをつくってみたい!というわけのわからん夢を持っています。
なんの言語を学べばいいのか御指導いただければとorz たぶんMIPSアセンブラだろ
でもあの頃のゲームってCで書かれるようになってるから、ソース流出してない限り一人ではかなり厳しい戦いになると思う
N64マリオの逆アセンブルされたコードとか見るとめちゃサイズ大きいし PS1はCで書けるけどライブラリとか仕様が分からんと多分何も出来ない気がする 「ネットやろうぜ」みたいな名前のPS1ゲーム開発キットが当時売ってたよね 具体的にはブレスオブファイア3っていうゲームをバランス調整含めていろいろ追加したいんです どっちにしろラムダ計算は関係ない。誤魔化すなバカ。 じゃあSICPとか書いた人も馬鹿なんだな、あなた様の前では >>757
わかったわかった。IT土方とか電気屋さんを馬鹿にしてマウント
取りながら、一方で
「ほんとに優れた人たちから自分はバカにされてるに違いない」
という表裏一体の劣等感を抱いて生きていけ。
頑張って高級なところに行けよ〜。いくらでも上はいるぞw >>761
最初はそこからで良いんですよ。
厨二全開から始めて、気が付いたら業界の第一人者になってる。
それがHaskell道ですから。 >>757
>電気屋さんレベルのタスクに電磁気学の知識が要らん
そうでもないのですよ、最近流行りの「活線メガー」を正確に評価するためには、電磁気学の知識が必要です…… ちゅーか、電気や低レイヤのことをやるのも理系の人だからね
別にラムダ計算理解できないってことないっしょ 萩谷 昌己「関数プログラミング」 (情報数学セミナー)
これが一番やさしいかな HaskellとかLISPはまずやらせたいことがあって、コンピュータでそれを再現している形になるから今のコンピュータアーキテクチャに即した必然性が無いように感じて理解しづらく感じる >>774
バカにされるような電気屋さんってだいたい専門卒じゃね
いわゆる理系とはだいぶ違うかと つまり
簡単なVBAが
覚えるには一番楽ってことだね >>776
そもそもノイマンマシンである必然性に何で付き合わなきゃならないのよ?
と考えたほうが自由になれるんでは 初心者だがここの意見を参考にしてc#を始めることにしたわ
正解ってことでええか? >>782
Windowsに生涯の忠誠を誓うか、もしくはゲーム作りたいならまあ 関数型なら、Elixir の本も出た
Elixir実践ガイド、黒田努、2021/2
Ubuntu 20.04, Docker CE 19.03, Elixir 1.11
結局、普及の溝(キャズム)を越えたのは、Go だけ。
Rust, Elixir は失敗したけど、
スクエアとか大手は、Elixir を使っている。
IoT では、Nerves もある >>782
C#が判るならJavaScriptとかも判りやすいよ。
ブラウザがあればどこでも出来るし、Windowsに縛られることもない。 ラムダ計算というのは人間のプログラミング可能な、モデル化出来る思考にとってのマシン語みたいなもの
人間側の必然性
可読性を高めて具体的なプログラミング可能なものにしたのが関数型
マシン語はノイマンマシンがそうなってるから、という必然性
同じようにして人間よりにし、プログラムしやすくしたものがC
ドライバ、ライブラリを書くのにC、必要ならアセンブリというのはもちろんだけど
大規模な開発に使いたくはないな
神経すり減らすことと引き換えにプログラムをやりたくない 「ポインタは一撃で分かったけどいまの◯×が難い」ってノリが典型的老人。 ポインタは用途が多過ぎるのとCのシンタックスがお行儀良くないのが理解を妨げてるってだいぶ前から言われてる
逆にC++でやっててスキルが十分なら、ラムダ式でもキャプチャのライフタイムを自分で制御する分、アセンブリレベルの挙動も理解できると思うんだよな
ポインタの理解とラムダ式の理解でそれぞれ使ってる言語に一貫性がなくて、例えば後者で抽象度が高くてランタイムに何でもかんでも任せるのがよく分からんみたいな話なら、ラムダ式以前に処理系に対する理解の話じゃないかなとも ポインタどうのの前にラムダ式は
レイトバインディングだから
トレース見るのが面倒くさい インラインアセンブラみたいに
インラインCとかできればいいのにと思う >>792
EXCELの場合にはその気になればシートにSQLが投げられるからね
集約は殆どそれで済ませることができるし
Linqやラムダ式を使いたければVSでEXCELのソリューションC#で作って機能拡張を行えばいいだけ
ラムダ式やポインタなんかに拘ってる間にEXCELやってる人はリアクティブプログラミングを知らない間に身につけてるよ EXCELにpython内蔵させるって計画結局潰れたんか 外部ライブラリ頼みのPythonなんて載せたら混乱しかないからな
そもそもそんな計画なかったんじゃね MSがダメならLibre Officeに載せたら良いじゃない
MS負けるかも(๑˃̵ᴗ˂̵) 他でも言われていたがプログラミング非専門職の素人の使う道具にPython入れるなんて頭おかしい。 普通に考えてVBの方が難しい
Pythonが採用されないのはExcelに求められる互換性レベルを満たそうとするとバージョン塩漬け不可避で結局世間と乖離してしまい意味ないから Pythonを初中級とするならば上級はLispだろう まあ以前誰かが言ってた気がするけど
VBAにもPythonにもRangeが有って
その意味合いが全く違うから
難しいんだろうなぁ Rubyが使えたら一番良いのだが、RubyはWindowsに嫌われてる(尊師談)からなあ。 pythonだろうがVBAだろうがexcelにべったり結合してたら結局一緒だわ。 現時点でPythonのライブラリにVBA連携もできるライブラリがあるので統合する意味もないかもね
ライブラリが多いので便利だけど、言語的にはまだまだ発展の余地が残ってると思う
定数は大文字にして区別するだけで定数自体は存在しないとか
クラスに厳密なprivateやprotectedがない(強引にアクセスは可能)とか
寛容なのかネジが飛んでるのかわからない仕様はあまり好きじゃない
ユーティリティ+データ分析 + 機械学習って感じなのかな
JupyterNotebookが便利なので実行結果を逐一確認しながら学習できるのは初心者にもいいと思う でも実際のところ、クラスにprivateやprotectedがないことが何が悪いんだ?
実際の開発でそれが問題になることってあるのかよ?
命名規約とかで十分解決できそうなもんだけど まあ実際問題、勝手にpublicにすれば簡単に壊れるからな。
変にprivateにこだわるからテストコードがクソ化してる場合もある。
protectedをうまく使う必要があるんだがアホはやらんのよ。 publicなのはstaticにしとけばいい
なにもこわれない 実際にはPublic指定にしてあるものはどこからでも呼び出せるからいいとして、
Private指定の際は委譲を行うときにその効力を発揮する。
インターフェースでPublic指定しておけばクラス側でPrivate指定したとしても値の取得が可能。
インターフェースの介在によってPublicとPrivateを変動的に定義が出来るし
インテリセンスに余計なメソッドやプロパティが出てこなくなるのは大きい。 あわしろ氏はHaskellを学べと強く推奨している。 あわしろさんはElixirを学ぶべきではないかと考え始めてる あわしろさんが普段使ってるのはVBAとCだと聞いている いや、あわしろさんはオールアセンブラで凄いの書いてると聞いた。 意外とみんな知らないようだけど Tcl は隠れた神言語 >>784
に書いたけど、Elixir の本が出た。
Ruby を関数型にした言語(動的言語)だから、割りと簡単
ただ、実装が片方向リストだから、先頭要素だけが速い。
文字列処理で末尾要素をいじくると、計算量がO(N)
Rubyみたいに、両方向リストにすれば良かったのに 静的型検査なしの関数型はもはや人間の扱える範囲を超えている 型検査なしでも大丈夫。
Ruby でも気にするのは、インスタンスがnil の場合ぐらい
Elixir はパターンマッチを使うから、滅多にバグらない Haskell神のあわしろ氏がVBAなんか使うわけないだろ。
そもそも、Microsoft言語は使うなと言ってるのに。 Excelは、いきなりVBAに行くより関数だけでなんとかするのもロマン。
あれも言うなればプログラム言語だよね。 だからあわしろさんは関数型を勧めるんだね
関数型環境のエクセル使えるために まとめると
Haskell→エクセル→VBA→C#→C→アセンブリ
と進んでいけばいいということになるかな? >>831
JavaScript だろ。オブジェクトが入ってんだかプリミティブが入ってんだか
わけわからなくなる。
狙って書いてるソースもあるし。 >>842
それは動的型付け言語全般に言えることだろ。
ただJavaScriptならTypeScriptに移行すればだいぶ改善する。 なるほど
定義時に型付けするしないを選べるVBAが最強か
まぁ型付けしないことはそうそうないけど c#で遊んでるせいか、Typescriptも理解しやすい。
この辺の似たような言語から入るのが良いね。
PythonはインタプリタやらNotebookを使い込むと便利そうだけど、
他とは違うコツが要りそうだから、あんまし身につける暇がない。 Linux板を覗いたら、あわしろ氏のスレが一番上だった
有名人なんだ >>844
動的型付け言語に静的型チェックを後付けするという意味で先駆的だったかもね。
当時はインチキ呼ばわりされたものだが。 日本Ubuntu の総帥・あわしろいくやは、日経Linux に、たまに記事を書いてる ■ このスレッドは過去ログ倉庫に格納されています