「関数型言語」を含む日記 RSS

はてなキーワード: 関数型言語とは

2023-09-30

anond:20230930202607

それなー

関数型言語って考え方とか記法全然うから

C系書けたらだいたいの有名なのは方言レベルの違いでそんなに困らなかったけど関数型言語は違いすぎて無理だった

2023-09-27

anond:20230927200327

でもガチCS勉強しようと思ったらアルゴリズムデータ構造必須で、それに適した言語となるとC以下あれやこれやでしょ。

あと、デザインレシピかいう考え方なら OCaml とかの関数型言語が入門に適しているし、オブジェクト指向ならCじゃ無理だし。

2023-08-09

anond:20230809123444

めっちゃ関数型言語意識しとるで。

関数型の人からしたら、あんなもん偽物やって感じかもしれんけど。

anond:20230809120834

メソッドチェーンでコレクション操作するのって、関数型言語から始まって、Javaやらrubyやらjsやら、いろんな言語で使われるようになった奴だな。

2023-07-26

関数型言語を使ってない時点で詰み確定?💩

副作用を分離/管理する仕組み(I/Oモナドなど)を用意してない時点ですでに不利💩

まり書ける人材を集められなかった/育成できなかった、ということ💩

ドンマイ👍

2022-12-21

anond:20221220182332

こういうの見ると豚の映画のベイブ養豚家が見ると毎回ベイブが違う豚で混乱するという話を思い出す

自分の分野だと違和感を強く感じてしまうよね

SEだけどもし物語プログラミングが出てきてJava関数型言語でとか書かれていたらおいおいおいおいとなる自信がある

2022-12-01

コンピューターサイエンスって何だよ?

最近コンピューターサイエンスプログラマー必要か否かみたいな話が上がっているが、そもそもコンピューターサイエンスって何だよ。どこまでの範囲をさしてんの?

って思ってググってみたらちゃん定義されてた。

ググって出てきた情報を整理しただけなので詳しい人、補足・訂正よろしく


情報

CS2013

https://www.acm.org/binaries/content/assets/education/cs2013_web_final.pdf

CS2013はACM/IEEE-CSによるカリキュラム標準。

ACM(計算機協会)はコンピュータ分野全般国際学会、IEEE-CSIEEE(米国電気電子学会)の中にあるテクニカルソサエティ


J07-CS

https://www.ipsj.or.jp/12kyoiku/J07/20090407/J07_Report-200902/4/J07-CS_report-20090120.pdf

J07-CS一般社団法人情報処理学会がCC2001CSベースアレンジを加えたカリキュラム標準。今はCS2013を反映したJ17-CSがあるらしいけどその辺は良く分からん

IPA共通キャリアスキルフレームワークとの対応表もあり。

https://www.ipa.go.jp/files/000024060.pdf


知識体系

J07ーCSから抜粋CS2013と比較するとナレッジエリアがあったり無かったり。

KAナレッジエリアKUナレッジユニットアユニット最低履修時間
DS離散構造DS1関数, 関係, 集合6
DS離散構造DS2論理6
DS離散構造DS3グラフ4
DS離散構造DS4証明技法8
DS離散構造DS5数え上げと離散確率の基礎7
DS離散構造DS6オートマトン正規表現6
DS離散構造DS7計算論概論4
DS離散構造DS8計算
PFプログラミングの基礎PF1プログラミング基本的構成要素9
PFプログラミングの基礎PF2アルゴリズム問題解決6
PFプログラミングの基礎PF3基本データ構造14
PFプログラミングの基礎PF4再起5
PFプログラミングの基礎PF5イベント駆動プログラミング4
ALアルゴリズムの基礎AL1アルゴリズムの解析の基礎4
ALアルゴリズムの基礎AL2アルゴリズム設計手法8
ALアルゴリズムの基礎AL3基本アルゴリズム8
ALアルゴリズムの基礎AL4アルゴリズムの高度な解析
ALアルゴリズムの基礎AL5高度なアルゴリズム設計
ALアルゴリズムの基礎AL6計算クラスPとNP
ALアルゴリズムの基礎AL7暗号アルゴリズム
ALアルゴリズムの基礎AL8幾何アルゴリズム
ALアルゴリズムの基礎AL9データ分析アルゴリズム
ALアルゴリズムの基礎AL10並列・分散アルゴリズム
ARアーキテクチャ構成AR1論理回路と論理システム6
ARアーキテクチャ構成AR2データマシンレベルでの表現2
ARアーキテクチャ構成AR3アセンブリレベルマシン構成7
ARアーキテクチャ構成AR4メモリシステム構成アーキテクチャ5
ARアーキテクチャ構成AR5インタフェース通信3
ARアーキテクチャ構成AR6機能構成7
ARアーキテクチャ構成AR7並列処理と様々なアーキテクチャ2
ARアーキテクチャ構成AR8性能の向上
ARアーキテクチャ構成AR9ネットワーク分散システムのためのアーキテクチャ
OSオペレーティングシステムOS1オペレーティングシステム概要1
OSオペレーティングシステムOS2利用者から見たオペレーティングシステム1
OSオペレーティングシステムOS3オペレーティングシステム原理1
OSオペレーティングシステムOS4プロセス構造スケジューリング3
OSオペレーティングシステムOS5並行性4
OSオペレーティングシステムOS6メモリ管理4
OSオペレーティングシステムOS7入出力デバイス管理と入出力
OSオペレーティングシステムOS8ファイルシステム2
OSオペレーティングシステムOS9認証アクセス制御1
OSオペレーティングシステムOS10セキュリティと高信頼化
OSオペレーティングシステムOS11リアルタイムシステム組込みシステム
OSオペレーティングシステムOS12並列分散処理のためのオペレーティングシステム機能
OSオペレーティングシステムOS13オペレーティングシステム構成
OSオペレーティングシステムOS14システム性能評価
NCネットワークコンピューティングNC1ネットワークコンピューティング入門2
NCネットワークコンピューティングNC2通信ネットワーク接続7
NCネットワークコンピューティングNC3ネットワークセキュリティ2
NCネットワークコンピューティングNC4クライアントサーバコンピューティングの例としてのウェブ3
NCネットワークコンピューティングNC5分散アプリケーションの構築
NCネットワークコンピューティングNC6ネットワーク管理
NCネットワークコンピューティングNC7ワイヤレスおよびモバイルコンピューティング
NCネットワークコンピューティングNC8マルチメディア情報配信システム
PLプログラミング言語PL1プログラミング言語概要2
PLプログラミング言語PL2仮想計算機1
PLプログラミング言語PL3言語翻訳入門2
PLプログラミング言語PL4宣言と型3
PLプログラミング言語PL5抽象化メカニズム3
PLプログラミング言語PL6オブジェクト指向言語6
PLプログラミング言語PL7関数言語
PLプログラミング言語PL8論理言語
PLプログラミング言語PL9スクリプト言語
PLプログラミング言語PL10言語翻訳システム
PLプログラミング言語PL11システム
PLプログラミング言語PL12ブログラミング言語意味論
PLプログラミング言語PL13プログラミング言語設計
HCヒューマンコンピュータインタラクションHC1ヒューマンコンピュータインタラクションの基礎6
HCヒューマンコンピュータインタラクションHC2簡単グラフィカルユーザインタフェースの構築2
HCヒューマンコンピュータインタラクションHC3人間中心のソフトウェア評価
HCヒューマンコンピュータインタラクションHC4人間中心のソフトウェア開発
HCヒューマンコンピュータインタラクションHC5グラフィカルユーザインタフェース設計
HCヒューマンコンピュータインタラクションHC6グラフィカルユーザインタフェースプログラミング
HCヒューマンコンピュータインタラクションHC7マルチメディアシステムのHCI 的側面
HCヒューマンコンピュータインタラクションHC8協同作業コミュニケーションのHCL的側面
MRマルチメディア表現MRI情報ディジタル表現2
MRマルチメディア表現MR2文字コード1
MRマルチメディア表現MR3標本化。 量子化圧縮原理アルゴリズム
MRマルチメディア表現MR4マルチメディア機器
MRマルチメディア表現MR5オーサリング
GVグラフィックスとビジュアルコンピューティングGV1グラフィックスにおける基礎技術2
GVグラフィックスとビジュアルコンピューティングGV2グラフィック・システム1
GVグラフィックスとビジュアルコンピューティングGV32次元画像の生成と加工
GVグラフィックスとビジュアルコンピューティングGV4モデリング
GVグラフィックスとビジュアルコンピューティングGV5レンダリング
GVグラフィックスとビジュアルコンピューティングGV6コンピュータアニメーション
GVグラフィックスとビジュアルコンピューティングGV7視覚
GVグラフィックスとビジュアルコンピューティングGV8仮想現実(VR)
GVグラフィックスとビジュアルコンピューティングGV9コンピュータビジョン
ISインテリジェントシステムIS1インテリジェントシステムの基本的問題3
ISインテリジェントシステムIS2探索および制約充足2
ISインテリジェントシステムIS3知識表現および推論
ISインテリジェントシステムIS4高度な探索
ISインテリジェントシステムIS5高度な知識表現と推論
ISインテリジェントシステムIS6エージェント
ISインテリジェントシステムIS7自然言語処理
ISインテリジェントシステムIS8機械学習ニューラルネット
ISインテリジェントシステムIS9プランニングシステム
ISインテリジェントシステムIS10ロボット工学
IM情報管理IMI情報モデルシステム2
IM情報管理IM2データベースシステム2
IM情報管理IM3データモデリング4
IM情報管理IM4関係データベース3
IM情報管理IM5データベース問合わせ3
IM情報管理IM6関係データベース設計データ操作
IM情報管理IM7トランザクション処理
IM情報管理IM8分散データベース
IM情報管理IM9データベース物理設計
IM情報管理IM10データマイニング
IM情報管理IM11情報格納と情報検索
IM情報管理IM12ハイパーテキストハイパーメディア
IM情報管理IM13マルチメディアデータベース
SP社会的視点情報倫理SP1コンピ

2022-07-25

Pull Requestはプログラミングを嫌いにする

プログラミング能力を向上させるのに必要なのは

難解な解説本だったりドキュメントじゃなく

綺麗なコードスパゲッティコードの解読でもなく

ましてや優れた人から教えて貰うことでもなく

ただただプログラミングを好きになってモノづくりに熱中することだ

小さい子供プログラミングに向いているのはモノづくりが好きだからであって

オブジェクト指向関数型言語設計をしたいからじゃない

これは大人でも当てはまることであって

何かのモノづくりをするという目的の元に手段としてプログラミングが選ばれ

それに熱中することでいつの間にかプログラミング能力は向上していくのだ

新しい仕事としてプログラミングを頑張って覚えるだとか

上司から命令されてプログラミング講座を会社の金で受講するとか

Googleを目指して学生時代プログラミングに打ち込むだとか

そんなのは全然上手く行かないのに定年退職したジジイラズパイ使ってロボ作りとか始めると上手く行くのはそのせいだ

GitHub発明したPull Requestはこの楽しみを徹底的に阻害している

「すげぇやり方思い付いたから本番に実装しようと思う」

というのがPRでは却下される

ちょっとこの辺は微妙だけど他のことやりたいか適当に済ませよう」

というのもPRでは却下される

こうした行為はモノづくりからはほど遠く必要無いものに見えてしま

「早く動いているところを見たい」

という欲求を不満にしてしま

やがて開発者プログラミングのもの従事して嫌いになっていくのだ

以前からプロ現場ではもっと厳しい品質管理がなされていたという人がたまにいる

PRによってアジャイル現場品質管理がもたらされたと主張するのだ

だがソースコード品質とは何なのか結局誰も答えられない

命名規則コメントの書き方などルール化できるもの別にレビューなど必要無くツールで弾くことができる

バグがあるかどうかはテスト担保すべきであってレビューで見るべきではない

PRレビューするのはそうではない「何か」であって

それを勝手品質だと名付けているにすぎない

この手のレビュワーが好んで使う言葉として「技術負債」というものがある

技術負債を残さないためにもPR品質を保つ という主張である

一方で技術進歩は止められるわけが無く10年前に必死クラス設計したJavaシステム

今やJavaのせいで技術負債になっているのだ

このありもしない「技術負債」という幻想のために

またはレビュワーの考える言語化できない「品質」のために今日PRリジェクトされる

そしてコメントで延々とどっち付かずの議論が繰り広げられて

人はプログラミングを嫌いになっていくのだ

2022-05-27

昔話してて思い出したけど。

ネットサービス商売になる感じになって来たのって、00年代後半あたりだったね。

YouTubeツイッターもそれくらいで。

ミクシはもうちょっとからあったか

俺の学生時代は、Windowsゲーム開発みたいなのと、MacWEB開発みたいなのが、ちょうど半々くらい情報系の学生流行ってた。

 

一方俺は関数型言語をやっていた。

2022-05-23

anond:20220522163908

ラテン語古代ギリシャ語・サンスクリット語のうち、最低どれか1つは読めるようになった方が良いとは思う。

少し前に、ギリシア詞華集に出てくる女性詩人ヒロインにしたマンガが一部で流行って、それで古典ギリシャ語に手を出した人が相当数いたみたいだが、何らかのきっかけでこういう古典言語に入ると広い世界が拡がってる。

それはともかく、たとえばHaskell勉強して遅延評価関数型言語妙味を知り、Rustを勉強してメモリ管理の大変さを知り、Go勉強してCSP代数面白さを再認識する、などの知的好奇心を満足させる意味で、各言語の特徴を把握した上で勉強するのはすごく楽しいんじゃないだろうか。

さらバックグラウンドとして、簡単でも良いので半導体ゲートと同期回路がどうCPUメモリを作り出していったか、を知ると、よりこれらの「プログラミング言語」というもの妙味を味わえるだろう。

金を儲けたければ、浅く広く勉強した上で、どれか1つの言語に絞って、深く、深く、ライブラリと同じ機能は自前で用意できる程度まで深められたなら、おそらく食いっぱぐれはない。

2022-04-25

anond:20220425193347

ならないんだよなあ。

そもそも数学プログラミングモチベーションが違うんだよね。数学における証明構成証明と非構成証明があるように、「手続き」というのは数学のごく一部でしかない。それに対して、プログラミングは「手続き」が全てだよね(って言うと関数型とかの人があれこれ言ってくるけど、関数型言語だって結局コンパイラ手続きに落とせる範囲のものしかない)。

機械学習については、論文書いてる奴も含めて大多数はプログラミング脳なので、最初からコードで発想してそれを論文にするために無理矢理数式で書いてるだけというものほとんど。無理矢理書いた後付けに過ぎないか意味不明ものも多いしコードに落とせないもの普通にある。だから数式は無視して著者のリポジトリにあるコードだけ見てればいいよ。実用観点ではコード公開されてない論文は全無視で何も問題ない。

2022-02-02

anond:20220202212250

純粋関数型言語意識高すぎるので、便利なエッセンスだけ普通言語にもってくるのがベターって気がする。

2022-01-23

関数型言語という宗教世界は不変と直観する信者たち。

プログラミング世界に、関数型言語というのがあります

(私は入門書(象の絵のやつ)を読んだことがあるだけで、使ったことはまだありません。)

で、関数型言語の良さをアピールするひとからは、いい意味でのの宗教性というか敬虔さを

私は感じるんですよね。

現実世界は不変だから 関数型プログラミング銀の弾丸であるという主張

本題。「関数型プログラミングが『銀の弾丸である という非常識常識 2022」 と題された長い文章をみつけました。

ここ。https://kentutorialbook.github.io/functionalprogramming2022

まるで熱心な信者による経典なので、ほとんどちゃんと読んでないし読む気も起きませんが、

流し読みをしていて、目に入った 次の一節 がとても私の心に刺さりました。

ーー我々が暮らしている「現実世界」はミュータブル(mutable)なのです。

撤回させていただいて、

現実世界数学物理学的な俯瞰では、immutableです。

( https://kentutorialbook.github.io/functionalprogramming2022/#n0.19337518569281165 )

ちなみに、ミュータブルは「可変」、 イミュータブルは「不変」の意味

私の俗な反応 - 数学物理学がどうあれ、世界は可変

まあ私も世俗的なSEをやってるので、まっさきに、↓くらいのことは、思うわけです。

多分、プログラミング世界での、世間一般の反応も似たようなものかと。

ところがですね。

レトリックによって伝えられようとしている信念

ところがですね。これ、意見戦わせても、たぶん議論でどうにもならず、宗教間の対立みたいなものになる気がするんですね。

というのも。上の文章でとりあげられている数学やら物理やらというのは、おそらくレトリックしかなくて。

そのレトリックで、伝えられようとしているものは何かというと、

そもそも世界決定論的にしか記述できないのだから

 ビジネス世界だろうが何だろうが、本来世界は不変なものとして記述されるべき」

というような 信念(信仰であるような気がするのです。

なぜなら、私が隠し持っている信念が、まさにそれに近しいものからです。

私の本音 - 数学とか物理学か抜きにしても、本当は、世界は不変であるという直観離人症世界観。

私は数学物理学全然からない、文系人間ですが。

物理学法則が成り立たとうが、物理学の通じないアナーキー世界であろうが

世界は不変であり、私自身による世界への介入なぞありえない、と直観的に思っています

から 「やればできる」 「世界は変えられる」 「努力は裏切らない」 みたいな言葉は大嫌いなわけです。

この直観を私は自分勝手に、「離人症世界観」と名付けています

この世界観の持ち主は多分少数派で、社会から見れば異端どころか、害悪とみなされるかも。だから、隠し持っている。

関数型言語好きな人も、おそらく私が似た直観と似たものを隠し持っているのでは、と、

私は思うのですね。

関数型言語が受け入れられる社会

もし、離人症世界観に基づくコミュニケーション社会に浸透し、

自分意志感情」すら、あたかファーストクラスオブジェクトとしての関数のように、

客観的に表明されるようなコミュニケーションが、もしこの世の中に広まれ

関数型言語も当たり前のように、普及するのだろうと思います

そうでもならないと、関数型言語流行らないだろうな。というのが私の予想。

ま、宗教ものは、広まるときは、あっと言う間らしいですから

ひょっとしたら20年後くらいには、手続き型言語が滅びているかも。こればっかりは分かりませんけどね。

以上!

2021-12-11

python布教ってなんで成功してるんだろうな

juliaだの関数型言語だのは大抵「布教者のあいつが嫌い」で失敗してるのに

2021-11-20

anond:20211105092529

Python 使いは、RubyJava勢力からOOP無視しすぎていたし、Haskell のような関数型言語の人たちから失笑されるし、まぁ VBPHP といったたぐいのイージー言語とされていたのよ。少なくとも、人工知能が注目されるまでは。

2021-10-23

anond:20210925214331

関数型言語LISP からし特殊だもんな。もともと、数学ツールだったのが、計算機拡張されたというのが。なんというか、(+ 1 1) が計算量の推定とかはできるかもだけど、OOP を含めた命令形言語のそれよりも計算量とメモリの動きがみえないのがちょっとね。

2021-09-26

触れてはいけないIT用語一覧

Twitterブログで触れても何の得にもならない単語を並べる

2021-09-25

オブジェクト指向はすでに粒度時代にあっていない」を読んで

記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身理解を助けるためにも言わんとしていることを推測しつつ、自分認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分バックグラウンドは以下:

その他の前提:


本文およびブコメを読んで思ったこ

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドプログラムパフォーマンスに影響を与えるので、パフォーマンス要件がをシビア場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスネットワークアクセスレイテンシが大きいので、そうした相対的に細かいオーバーヘッド無視しても(大抵の場合は)問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体モジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます

記事にもありますが、RPC派生実装?)として生まれJava の CORBA や MicrosoftDCOM みたいな振る舞い付きのオブジェクトコンポーネント)を共有しようという世界観は廃れ、REST API のような単一の振る舞い(エンドポイント)とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション通信の潮流と、計算資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。

まり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。

なので、以下のコメントちょっと論点がずれてると思いました。

はあ?「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わりますオブジェクト指向とはほぼ無関係です。

https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin

なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない

https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang

しかに、アプリケーション単位アプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います

ソフトウェア記述をまとめるという視点では主にステートレス関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理やすくするという視点ではオブジェクトというのはライフサイクルリソース管理視点が足りず小さすぎる、ということで、オブジェクト指向粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います

個人的にわからなかったのは以下の部分です。

オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない?」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。

当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの?」って思ってしまますオブジェクト指向定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェア組織化すること」なのであれば)。

おわりに

Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論収束に向かってほしいと個人的には思います(とっくに収束していると感じている方もいらっしゃるでしょうけど)。

https://gist.github.com/posaunehm/4087971

2021-09-14

プログラマーなんていらねーから

プログラミングスクールとか通ってる奴馬鹿じゃねーの

いらねーよプログラマーとか

関数型言語ができます(キリッ)」

じゃねーよアホか

別にいらねーんだよそんな奴

今のDXで一番求められてるのはコンサルなんだよ

「今、こういう業務フローでこれがこうなってて・・・

っていう説明受けたとき

「今の流行はこのツールとかこういう方法で、こういう形で実装すればいいですよ!」

とか言う奴はプログラマー

いらねーんだよ

そうじゃなくて

「その業務本質はこれですよね?」

っていうのとか

「その業務って実はこっちと親和性高いですよね?」

ってちゃんと分かる奴

そんでそれを構造的に落とし込んで関数的に実装出来る奴な

ただの知識としてプログラミングできますとか、つまんねーゲーム作れますとか、しょーもないオープンソースの端っこの方を書きましたとか

そんなの全然いらねーの

ぶっちゃけやろうと思えば誰でも(旧帝大ぐらいなら)できんの

ちゃんと人・部署会社社会それぞれに応じた世界観を感じ取って

それぞれのOSちゃんと作ることが出来る奴がいるわけ

そんじゃそんな能力をどうやったら作れるか、教えてやるよ

とりあえずノート開いてそこにお絵かきしろ

そんだけだ

例えば自動車業界電気自動車っていう観点お絵かきしろ

今の部署10年後っていう観点お絵かきしろ

テーマはなんでもいいか社会のものを具現化して体系化して整理する

これを毎日やるだけ

そういうトレーニングしかない

コンサル出来る奴は話聞きながらそういう絵を頭の中に瞬時に描いている

から立体的に構造的に理解できるし相手を納得させられる

まぁ、とはいえ悪いがこの手のコンサル業界にはそういうのを小学生からずーっとやってきててなおかつ天才ってやつしかいねから

多分今からやっても意味ないと思うけどね

2021-08-25

anond:20210825205300

おう!外部キー制約を語るとは、RDB勉強しているのだな?いい心がけだ。増田は外部キー制約があると「どんなメリットがあるか知りたい」のだな?良し、答えてやろう!外部キー制約があると「変なデータが入らない」ということが開発者が『保証』できるのだ。うん、それで?って増田は思うだろう。それで、実例を挙げるけど、sex というカラムを create で作ったときに、そこに insert into で入る値が「男」「女」「その他」というデータに限りたいとき設計者にあったとする。そうすると、「 insert するのは『チンポ』でしょ?」みたいなアホを防げるだろ?もちろん、limit みたいな副クエリ実装しても構わない場合もある。型を指定して、boolean にしたい場合もある。だが、「入るのはこれだけだと思うが、後に追加で変更できる」としたら、嬉しい場合があるのじゃ。まぁ、究極的に OOP関数型言語、または(古い)命令形言語だと、enum みたいなものなんだよ。いや、だとしたら、enum でよくね?って思うのなら、リプライくれ。答えるから

2021-08-08

プログラミング言語関数型言語ってOOPを含めた命令言語に劣る理由

Scala や Elm と Lisp やら HaskellOCamlSML関数型のプログラミング言語勉強したけど、これらが命令言語に劣る理由解説しよう。

解釈自由関数言語アセンブリレベル最適化ができない

これは、SQL も同じ問題を持っているが、関数言語は「こういうふうに動いてね」という解釈インタープリターやコンパイラが「推測する」必要があるのだ。つまり、書いているときパフォーマンスプログラマー想像できない。

ハイパフォーマンスを出す関数言語コンパイラを作れば良いじゃん?

それが、現実的に厳しいのだよ。マジでコンパイラ関連は金にならない領域になってきたので、関数言語のための独自コンパイラを作る持続可能組織が無い。確かにLLVM を使えば x64arm といった最新のアーキテクチャ対応できるかもしれないけど、フロントエンドレベルすら応対が辛い。よって、関数言語C言語にてチューリング完全な同等なコードだと「いくら最速に書いても」遅いのである

人間は「命令するほうが楽」なので、関数言語は負けます

例えば if と書いたら、関数言語は else が必須ですが、命令言語は else 無しでも動いちゃうのですね。文系の連中が数学的な背景を加味して要件定義できると思うか?違うだろ。毎回、上に else のことについて聞いたら、プログラマー生産性は下がるだろ。関数言語は、上が文系だとますますだが、分岐もきっちりとおさえる必要があるから生産性命令言語に劣るよ。

2021-06-22

関数型言語でバトルしていた頃がなつかしいよ

2021-04-22

anond:20210421172633

この一文だけでも相当高度。

C言語などの関数型言語状態を持つことができません。

C言語関数型言語」という間違った前提から一転して、急に本当の関数型言語の特徴の説明に変わる。

しかも「状態を持たない」のは一般的にいって良い性質なのにも関わらず、悪い性質として紹介する。

……こんなレトリックが凝縮されている。全文を味わう価値のある文章

ログイン ユーザー登録
ようこそ ゲスト さん