この記事は一部(今のところ一人)の方々の主張を取り扱った記事です。 ←天秤は水平ですがニコニコ大百科および大百科ニュース社の見解・主張ではないことにご留意ください。 |
同様の趣旨で検索すればいくらでも類似の記事が見つかるのに今更感があるが、どのような視点でプログラミング言語を選択するべきか記しておく(個人の感想です)。異論は認める。
無駄に長くなったのでまとめを書いておくと、
もちろん異論は認める。
プログラミングは、入門書で文法を一通り覚えればゲームだろうがExcelのような高度なアプリケーションだろうが何でも作れるようになる、というようなものではない(TASレベルの意味で理論上可能かもしれないが、現実的ではない)。
プログラミングをマスターしたと言えるためには以下のようなものを全部とまでは言わないが習得する必要がある。文法よりもそれ以外の習得事項のほうが多いかもしれない。後述するようにアルゴリズムの習得は他の全てを合わせたよりも奥が深いが、そこまで極める必要はない場合も多い。
多くの言語において、「コンソール上でHello Worldする」のと、「Hello Worldと書かれたウィンドウを表示する」との間には大きな隔たりが存在する。前者は知っての通り初心者が最初に書くプログラム(Haskellを除く)、後者は並列処理あたりまで理解した中級者がGUIフレームワークの勉強を始めるときに書くプログラムである。
希望を打ち砕くようで申し訳ないが、入門書を読んだくらいでは「Hello Worldと書かれたウィンドウを表示する」ことすらおぼつかないのが現実である(例外: Javascript, PHP)。
プログラミング言語以前の問題として、あなたは英語力に自信はあるだろうか。多くのプログラミング言語が英語圏出身である以上、プログラミングに関する情報は英語が原文で提供される。
もちろんWeb上には日本語で書かれたリソースも存在する。しかしそれもメジャーな言語に限られ、マイナーな言語は公式ページの英語のチュートリアルが唯一の情報源ということも珍しくない。メジャーな言語でも、マイナーなライブラリやフレームワークになると同じような状態になる。バグなどのように非常にマイナーな話題は、メジャーな言語でも英語の掲示板にしか情報がないことが多い。
とはいえ、日本語の情報である程度勉強すれば、英語は完全に読めなくても(サンプルコードを参考にして)どうすればいいか見当がつくこともあるので、それほど悲観しなくてもいいかもしれない。
コンピューターの計算能力の上昇はすさまじいものがあるが、それでも限界はある。1万件の単純なデータの処理はすぐに終わっても、1万件の個々のデータに1万個ずつ項目が入っていていたら1億の処理をすることになり結構な時間を要する、その1項目にさらに1万ずつの小項目が存在したら、1兆の処理をしなければならなくなり、合理的な時間で終わらないケースも出てくる。
こういった問題を解決するにはアルゴリズムを工夫する必要があるが、アルゴリズムの理解・応用にはかなりの数学力が必要になる。ここでいう数学力は「数学は70点だったけど国語は55点だったから得意科目を強いて言うなら数学かな」と言ったレベルではなく、「証明問題は解けない問題はなかった。可算無限と非可算無限が違う? そんなの当たり前だよね。」といったレベルの数学力である。
あなたが中高生ならともかく、文系大学生や社会人だったりするならば、スーパーハカーになろうと思っても既に越えられない壁が出来てしまっている可能性がある。学校の勉強は将来役立たないって言ってた奴出てこいwwww
もっとも、手作業でやっている定型的パソコン操作を自動化したり、IT土方の仕事をするレベルでは関係のない話だと思われるので、気にしなくていいのかもしれない。
それでも、マニュアルに「以上、以下」を調べる機能だけ記載されていて、「より大きい、より小さい」を調べる機能がないときに「より大きい」=「以下ではない」、「より小さい」=「以上ではない」と脳内変換する程度の機転は求められる。
まずは、あなたがプログラミングで何を実現したいのか思い浮かべよう。
何がしたいか(具体的に)決まっている人は幸いである。目的に一番近い機能を有したライブラリ(あるいはフレームワーク)を探せばよい。そのライブラリが対応している言語が、あなたの使うべき言語である。選択の余地がないという意味では不幸かもしれない。
Excel形式が目的なら、ExcelでVBAマクロしなければと考えてしまいがちだが、Excelを介さずにExcelのファイル形式(.xlsx, .xls)を直接読み書きするライブラリが存在する言語も結構ある。そういったライブラリを用いれば扱いづらいVBAマクロに頼らなくても柔軟なプログラミングが可能になる。
その他 .pdf, .docx, pptxなどのメジャーなファイル形式についても、そういったライブラリが存在することもある。
実際に開発を行う段階になると、ライブラリの細かい使用方法をドキュメントなどを調べながらプログラミングするということは珍しくない。しかし、英語力の項でも述べたように、マイナーなライブラリになると情報源がライブラリの公式サイトのみということも珍しくなく、その公式サイトさえも英文のチュートリアルがあればいい方で、
などといったことは日常茶飯事である。
使用法が書かれていない優れた設計のライブラリよりも、設計はまあまあでもドキュメントが充実しているライブラリの方が実用的であったりすることがある。
使用人口が多い言語・ライブラリは、ドキュメントが充実する傾向にあるし、ドキュメントがない場合でも他の使用者が、ブログなどに使用例を投稿している可能性が高くなる。
言語やライブラリを選択した後に、使い方を調べるにはソースコードを読むしかないと知って絶望することのないように、ライブラリの紹介文を鵜呑みにするのではなく、実際に目的の機能の使い方がしっかり書かれているかまで確認した方がいいかもしれない。
「甲言語で使う乙ライブラリを丙言語から使える丁ライブラリ」のように、ライブラリを本来の言語とは別の言語から利用できるラッパーライブラリ(wrapper: くるむものという意味 cf. ラッピング)というものがある。乙ライブラリと丙言語はメジャーだが丁ライブラリはマイナーであることが多い。
一見、「甲言語を勉強しなくても乙ライブラリが使えるから便利」と思ってしまいがちだが、以下のようなデメリットがあり、最終的には甲言語に回帰せざるを得なくなることもあるのでご利用は計画的に。「言語」を「ハードウェア」や「OS」に置き換えても似たようなことが言えるが、冗長になるので省略する。
丁ライブラリの開発者が有名どころの企業だったりする場合は、上記の一部はかなり改善されるが、ドキュメントが未整備で乙ライブラリを使用したことがないと理解できない点は相変わらずなことも多い。
2010年代以降GAFAMと呼ばれる巨大企業たちでも、鳴り物入りで始めたプロジェクトを「やっぱやーめた」と平気で中止することが珍しくなくなったので、ライブラリの開発中止のリスクは常に織り込んでおいた方が良いだろう。
プログラミング言語の記事でも述べているが、プログラミング言語の良し悪しは、言語仕様以外の要素で逆転してしまうことが珍しくない。ライブラリの有無が言語選択する上で一番大きいことは既に述べたので、ここでは開発環境について述べる。
プログラミングというとソースコードを書くことだけを指すこともあるが、実際にはコンパイラをはじめとするSDK(Software Development Kit)やエディタ、その他もろもろのインストールが必要になる。
その言語に統合開発環境がある場合は、統合開発環境を入れるだけでエディタを含めて一通り揃う。操作もコンパイルから実行までボタン一つで行えて便利だが、有償のものや本格的に使用するとなると有償になるものも多い。
マイナーな言語には(特に無償で使おうとすると)統合開発環境はないことが多く、テキストエディタでソースコードを書いてコマンドラインから実行という手段しかなくて不便極まりない場合もある(玄人になるとこのスタイルの方が好ましいと思えるようになるとか)。
言語仕様が悪い場合でもエディタの機能が欠点をカバーしていて不便を感じさせないという場合もある。
プログラミング用のエディタが提供する機能には以下のようなものがあるが、メジャーな言語でないと提供されていない機能も多いので、選択する際には注意されたい。
エディタも高機能化が進み、エディタから実行やデバッグが可能になるなど統合開発環境との境界は曖昧になりつつある。
その他にもデバッガや、ビルドツール、さらにはUMLからコードを自動生成するツールまで存在する場合もあるが、相当メジャーな言語に限られる。
プログラミングをすると必ずと言っていいほどプログラミングミス(バグ)が発生する。プログラミング言語の進化の歴史は、いかにこのミスの発生を防ぐかの歴史でもある。
プログラミング言語仕様の中には、一見いらないんじゃないかと思えるような機能や、むしろ無い方がいいんじゃないかと思うような制限があったりするが、多くの場合ミスを防止するためのものである。意に沿わない機能や制限を見かけた時に、短絡的に「この言語はダメ」と決めつけてしまうのではなく、どうしてそうしなければならなかったのか、逆にそうしないとどういう問題が発生するのかといったことまで考えると、理解が深まるかもしれない(良くない仕様だが互換性のためにそのままにしているというケースも稀にはある)。
逆に考えると、入門書を選ぶときに「こういう機能があるので、こうできます」ではなくて、「こういうミスを防止するために、こういう機能があります」という説明をしているものを選ぶことが望ましい。もっとも、残念なことにそういう視点の解説がなされることは稀だし、そもそもメジャー言語でない限り入門書を選べないことも少なくない。
決してミスを犯さないプログラマであるならば、どの言語を選ぼうと関係ない。
プログラミング言語の選択方法について検索すると「オブジェクト指向は時代遅れだ。これからは関数型プログラミングだ」という記述を見つけるかもしれない。
関数型プログラミングの項目で私見を述べたが、関数型プログラミングがもてはやされるのは、参照透過性があるという点と、高階関数を駆使した抽象化が可能になるという点が理由になっていると思われる。
参照透過性は、間違いを防ぐために、他の言語を使用する場合でも積極的に心がけると良い。
しかし、参照透過性に完全性を求めると純粋関数型言語に行き着く。2017年の時点で最もメジャーな純粋関数型言語といえばHaskell(それでもかなりマイナーである)だが、これを使いこなすには、モナドを初めとする高階関数を駆使した抽象化の理解を要する。
高階関数を駆使した抽象化というのは、理解するのに数学的素養しかも、単純な数値計算ではなく抽象的なものに関する理解力・応用力が求められる。根性で使っているうちに体得するという考え方もあるが、それは学習が大変ということに他ならない。
関数型プログラミングという言葉に踊らされて言語選択するよりは、関数型プログラミングがどうして有用なのかを理解し、選択した言語でそれを実現するよう心がけた方がいいように思う。関数型プログラミングの重要性も2010年代前半には声高に叫ばれたが、後半には前半ほどは強調されなくなったように思う。
プログラミング言語の大きな分類に静的型付けと動的型付けという分類がある。動的型付けは型を決めなくていいので初心者向けとすることが多いが、(前述のように選択の余地がない場合は別として)少々面倒でも静的型付けの言語を選択することを勧める。
動的型付け言語は、動作内容の詳細が日本語2-3行で表現できてしまうような本当に小さなプログラムを組むときには確かに有利だが、少しでも複雑な動作をさせようとすると静的型付けの言語の型チェックが働いた方が有利になってくる。プログラミングをしようというからには、プログラミングを学んでまでコンピューターにやらせたい面倒な仕事があるのだと思われる。そして面倒な仕事は往々にして複雑であり、単純だと思っていても繰り返す中に例外的な扱いを要するものが混じっていて複雑だったりするものである。
やりたいことがなく、単にプログラミングを勉強したいというだけの場合でも、静的型付けの型安全の考え方は学ぶ価値がある。
「書きにくく読みにくい言語」というのは、どこまでも書きにくく、どこまでも読みにくくすることが可能だが、「書きやすく読みやすい言語」を追求しようとするとどこかで限界にぶち当たる。
書きやすいということは、複雑な処理を短く書ける記法が多数存在するということである。しかし、それを読むときには短い記法からその裏に隠れている複雑な処理を思い出さなければならない(ということは使用頻度の低い記法も含めて多数のことを覚えていなければならない)ということである。つまり書きやすさを追求すると読みにくくなり、読みやすくしようとして文法を単純化し過ぎると書きにくくなる(やりすぎると読みにくくもなる)[1]ということである。
どこかで、書きやすさと読みやすさの折り合いを付けないといけないわけだが、ベストのバランスというのは人によって異なる。すなわち、職業がプログラマだという理由で毎日コードを書くのであれば記法は多いほうが良く、趣味などでたまにしかコードを書かないのであれば記法は少なくていい。
従って万人にとって最良な言語というものはないと思って良いが、「プログラムを書く時間よりも、(バグ探しや仕様確認等のため)にプログラムを読む時間の方が長い」と広く言われており、言語仕様を聞いたときの「書きやすそう」という直感で走るよりも、使用頻度が少なくて忘れてしまいそうな言語仕様はないか、書きやすくても読むときに不利にならないだろうか、など冷静に考えて選んだほうが良いのではないかといえる。
巷に出回っている「その言語が優れている理由」というのは、たいてい「書きやすさ」を基準に評価されており、「読みやすさ」は評価基準に含まれていないか、あっても後付けかおまけ的に書かれていることが多い。
使わない機能は覚えなくていいやと思っても、サンプルプログラムを読む時に知らない言語機能を用いていることがあり、実際に使用していて不便をきたすことは結構ある。
NullPointerException が引き起こすバグを防止するnull安全の考え方が2010年代に入ってからのトレンド。
HaskellにはMaybeモナドがあるが、ScalaのOptionやJavaのOptionalは中身ではなくそれ自身がnullとなりうるのに対し、Maybeモナドはそれ自体がnullになることはないので、上記では区別している。
プログラミング言語は無数にあるが、GUIの製作方法が標準化されている言語は意外と少ない。GUI製作方法がない場合すらある。標準化されていない部分は書籍化もされず情報も手に入りにくいので、GUIアプリを作りたい場合は、闇雲に進んで文法を学んだ後に立ち往生しないためにも、事前にGUIをどうやって作るかまで視野に入れておきたい。
またプログラミング言語のメイン部分はオープンソース化されているが、GUI製作部分はクローズドになっている場合もある。
Webページに用いられている HTML + CSS + Javascript という組み合わせは、E-コマースの発展と共に最も広く用いられているGUIになったとも言える。広く使われると人口に比例して発展するのが常道で、この分野には多数のライブラリやフレームワークが存在するようになった。
また、各種プログラミング言語においてもデスクトップ用GUIフレームワークはない(GUIフレームワークの構築は言語仕様の策定以上に多大な労力がかかる)けれど、(商用サイト用途の需要が多いので)Webサーバーを作るフレームワークはあるということも多くなってきている。
こうなってくると、言語独自のGUIフレームワークを構築するのはあきらめて、GUI部分はWebサーバーから HTML + CSS + Javascript の形式で出力してブラウザで表示させた方がいいんじゃないかなということになってくる[2]。
こういった発想で構成されたフレームワークの一つにElectronというものがあり、実際にメジャーになったエディタであるVisual Studio CodeやAtomはこれで動作している。
なお、Web技術に依存しないクロスプラットフォームなGUIフレームワークとして、Flutterというものがある。
使ってない言語のことも書いているので、大きな偏りはある。異論は認める。
こうして書いてみると、言語が設計された経緯が、特徴として色濃く反映されている気がする。
プログラミングをしたことがある人とない人で感じ方はかなり変わるので、余裕があるならとりあえず適当な言語で少しプログラミングを経験した後、ゆっくり本格的に使う言語を探すといいのかもしれない。プログラミング言語は数学的理論(構造化定理・型理論・カリー=ハワード同型対応・チューリングマシンなど)を背景にしているので、まるで違う言語に見えても本質的には共通している点も多く、2つ目以降のプログラミング言語習得はかなり楽になるからである。一つの言語から次の言語に移ると強く違和感を感じるのは慣れの問題か。
何でもできるが、出来てはいけないことまで出来てしまう。ミスを防ぐという観点からは、あまり良くないと思われる。また、C++は仕様が複雑すぎることで悪名高い。
CやC++の反省を元に作られた言語。静的型付け。使用人口が多く、情報やライブラリも豊富。
APIドキュメントの書き方が言語仕様で規定されている。実際に使ってみるとライブラリの使用方法の調べ方が統一されているというのは大きい。統合開発環境との組み合わせでさらに効果を発揮する。
ソースコード内にコメントを書く機能はほとんどのプログラミング言語に備わっているが、たいていは言語仕様の策定に終始してドキュメントの仕様にまでは手が回っておらず、Javaほど厳密に規定されている言語は少ない。
ソースコードが冗長になるという批判が多いが、ソースコードを読むという観点からは黙示的に定義される部分を補う必要がないので読みやすいという見方もできる。
歴史ある言語のため古い考え方も残っているが、後発の言語に一見無駄に複雑と思える仕様が存在する理由が理解できるので勉強にはなる?
2014年のJava8でラムダ式やOptionalが導入されてから、かなり変化したので、書籍や情報源はそれ以降のものを頼ったほうが良い。
GUIの書き方までオープンソースで標準化されたものがあるが、その使用人口はあまり多くない上に、今後は標準のものはなくなるかもしれない。
進歩が遅いという短所は開発者からすれば言語仕様変更が少ないという長所であったが、2017年後半にOracleが方針を変更したためリリースサイクルが半年になった。同方針変更により長期サポート版にライセンス料が必要になる懸念もあったが、他社が無料で長期サポートのあるJava仮想マシンを提供するようになったので、その点については回避されている。
動的型付け。ブラウザ上でHTMLにインタラクティブな要素を加えるために開発されたという経緯がある。そのため、プログラミング言語としてはややいびつなところがある。
GUI構築に関してはHTMLと組み合わせる方法が標準化されている一方で、ファイルの読み書きが弱い(ブラウザが勝手にファイルを読み書きしたら困るから)。
ブラウザ外の実行環境としてNode.jsがあり、ブラウザを介さずに動作するアプリや、サーバープログラムの製作にも使用できる。
Microsoftが開発した、JavaScriptを静的型付けにした言語。JavaScriptの上位互換でJavaScriptのコードをそのまま持ってきても動作するのが特徴。今から始めるならJavaScriptよりはこちらか。
JavaScriptとの互換性を保つため、プログラミング言語としてはややいびつなところが引き継がれている。
動的型付け。実行結果がHTMLになる。インタラクティブなWebページ製作という観点からは最も手軽に結果を得られる反面、もともとプログラミング言語ではなかったせいか、プログラミング言語としては扱いづらい。
iPhoneアプリ開発向けにAppleが2014年に発表した言語。null安全。
オープンソース化されて他のプラットフォームでも動作するが、GUIを構成するCocoaの部分はオープンになっていない。
iPhoneのイヤホンジャックに限らずAppleは昔から旧環境を切り捨てることに定評があるが、SwiftもObjective-Cを捨てて移行したし、Swift自身もメジャーバージョンアップ時に互換性を保てない変更をしている。2019年にバージョン5になるときには互換性が維持されたようなので、そろそろ落ち着いた頃なのかもしれないが、Appleが開発しているということを考えると油断はできない。
Microsoftが開発した.NET Frameworkのメイン言語。
Javaに対抗して作られた経緯があるので、Javaに似てJavaより書きやすいと言われている。
有志が作ったオープンソース実装Monoが存在するが、2016年に公式からオープンソース化された。
GUI周りに関しては2018年にオープンソースになったが、2020年現在Windows用.NET以外の実装は存在しない。
動的型付け言語。ライブラリやフレームワークの関係でこれらの言語を選択するケースも多いと思われる。
注意点としてはいずれもRuby2.0, Python3.0で互換性のなくなる変更を行っており、区別して検索しないといけない(特にPython)ということがある。
日本人の開発したRubyを推すべきなのかもしれないが、Rubyのキャッチフレーズは「書くのが楽しい」なのに対しPythonは「見やすさ」を目標に掲げているので、この記事では以下省略
静的型付け言語。いずれもJava仮想マシン上で動作するため、Javaで作られた豊富なライブラリが利用可能。Kotlinはnull安全な言語仕様が売り。ScalaもOption型でnull問題に対処しているが、Java8でOptional型が導入されたのでその点ではJavaと差が無くなった。
Javaでの反省を元に作られ、Javaよりも短いコードが書けるという触れ込みだが、コードを読もうとすると黙示的動作を脳内補完する必要があり、いきなりこの言語から入るのは厳しいかもしれない(特にScala)。
コードを書く頻度が高いなら、これくらい機能があった方が便利だと思われる(Scalaはそれでも高機能すぎるという意見もある)。
Oracleが2018年以降についてJava仮想マシンのサポート期間のポリシーを変更したため、これらのJVM言語が影響を受ける可能性は不安要素としてある。
なお、公平のために記しておくとこの記事を書いた編集者は大百科にKotlinのサンプルコード(長文)を投稿してしまう程度のKotlinユーザー(Javaからの移行組)である。
純粋関数型言語。ちまたに出回っている解説はそれなりに数学力のある人が書いていると思われ、数学力に強い自信がないなら平易な情報が手に入らないのでやめておいた方がいい。
他の言語と同じようなことをする分には言われているほど難しい言語ではないのかもしれないが、Haskellならではの使い方をしようとするならかなりの数学力が必要。コンピューターの考え方に近いのが低水準言語、人間の考え方に近いのが高水準言語といわれたりするが、Haskellはコンピューターとも(一般的な)人間とも離れた考え方で、数学者的考え方に近い言語といえるかもしれない。
私の数学力は53万ですという人や、職業プログラマーが時間をかけて長く付き合っていくならありかもしれない。
意識高い系がうっかり手を出すと、挫折した腹いせにこんな毒を吐くことになる。
書きやすく読みにくい言語の代表格。どうしても使いたいライブラリがあるのでなければ、今から始める理由はないように思う。
この記事の読者層にこんなマイナー言語を選択肢に挙げる人は想定されていないのだが、もしかしたら「愛され度No.1」という評価に釣られる人がいるかも知れないので。
Rustの肝である所有権について公式サイトのチュートリアルにわざわざ「難しい」と書かれているくらい(たいていのプログラミング言語は簡単に学習できることを売りにしている)なので、少なくともプログラミング初心者が手を出す言語ではないように思える。
最大の特色は高速な並列処理がメモリ安全に書けること。つまり、やりたいことのメインに多数の複雑な並列処理が含まれていない人は骨折り損になる恐れがある。「愛され度No.1」というのは難所を乗り越えるだけの能力と動機のあった人を対象にしたデータである。
逆に並列処理が目的の人は、どの言語を選択しても並列処理の難所であるメモリ管理の学習に苦しむことは避けられないので、言語仕様がサポートしてくれるRustは検討に値するかもしれない。ただし、現実の並列処理実装にはGPUを用いることも多いが、少なくとも2020年の時点で言語仕様が想定しているのはCPUでのメモリ安全っぽいので、GPGPUが目当ての人はもう少し深く検討した方がいいと思われる。
メモリ安全の思想を持つ言語としては他にV言語というものがあるらしいが、あまりにもマイナー過ぎるためお勧めしない。
やはりこんなマイナー言語を選択肢に挙げる人は読者層に想定されていないのだが、もしかしたら「これからはPythonでなくJuliaだ」という記事を見かける人がいるかもしれないので書いておくと、少なくとも2020年の段階ではあまりお勧めしない。
よくPythonの代替として引き合いに出されるので、その観点を中心に記すと、
数式をほぼそのままの形でコードにできるという利点はあるので、行列やベクトルを多用した数式を自分で立てて計算する人にはメリットがあるかもしれない。
それ以外の人は、物好きは別として手を出すとしてももう少しメジャーになってからでもいいのではなかろうか。
掲示板
63 deadbull
2022/09/03(土) 21:26:31 ID: UtLh3C8RZZ
>>61
では>>44で。2022/9/5 0時〜2022/9/8 0時の任意のタイミングで実施します。
64 ななしのよっしん
2022/09/03(土) 22:18:37 ID: vROllpw8h3
なんでこんなに荒れてんのかと思ったら、編集者の名前見て納得したわ
矢絣模様とか相手にされてなくて完全に言い負かされてんのもあったな
65 ななしのよっしん
2023/06/12(月) 04:16:20 ID: EpAObDZp9G
オタクコンテンツと全く関係ない内容なのにネットスラング満載なのはどうにかならない?
どれも台詞が節の内容と合ってなくて脈絡がないから余計に不自然
急上昇ワード改
最終更新:2024/03/29(金) 19:00
最終更新:2024/03/29(金) 19:00
ウォッチリストに追加しました!
すでにウォッチリストに
入っています。
追加に失敗しました。
ほめた!
ほめるを取消しました。
ほめるに失敗しました。
ほめるの取消しに失敗しました。