  |
はてなキーワード: ディストリビューションとは
もしこれが同じUNIX系OSでも*BSDであれば、Linuxのディストリビューションに当たるものは事実上3つしか存在しないので、それだけでも敷居は大幅に下がる。
言い換えるなら、多様性が各種設定を難しくし、普及を妨げているってこと。
ディストリビューションの違いはもちろん、同じディストリであってもバージョンの違い、更に同じバージョンであってもインストールするパッケージの違いがあるお陰で、Windowsやmacみたく
みたいなハウツーが成立し得ない。
それどころか、あらゆる手順が
「俺んとこではこれでうまく行ったぜ？」
だからLinuxを扱う者はこれを踏まえた上で、トラブルを基本自力解決できる事が、事実上の最低レベルとして求められる。
「俺は別に、OSの勉強がしたくてLinux触ってるんじゃねえ！」
もしこれが同じUNIX系OSでも*BSDであれば、Linuxのディストリビューションに当たるものは事実上3つしか存在しないので、それだけでも敷居は大幅に下がる。
というか*BSDが本気で普及に乗り出してたら、OSの中では新参な上に、大学院生のお遊びがきっかけで作られたLinuxなんて、一瞬で駆逐されただろう。
7年前のクソスペノートに軽いLinuxを入れて、母艦のWin10にリモートしてる
母艦そのものにモニタを接続することができないが、クソスペノートのほうでHDMI出力があるのでデュアルモニタにできる
つまりクソスペPCがそこそこハイスペのPC ＆ 安定インターネット端末として生まれ変わったことになる
あとノートは無線、母艦は押し入れに入れてるので居住スペースがすっきりする
わりといいなこれ
返信：
何がしたいのこれ。母艦だけでいいじゃん。
母艦だと席が移動できない 寝ころびながらPornHubとかみたいじゃん？
Passmark900だからAtomレベルのクソofクソやろな
詳しいね。自作だとDSP版で2000円しか違わないからHome選ぶ理由なし。
リモートって家庭内の狭い環境でも0.3秒ぐらいのタイムラグ避けられなくてイライラしない？ マウスカーソルもキー入力もすべて一瞬遅れてくる。
いい質問だね。結論、宅内なら遅延はゼロ。遠隔地とかならありえるかもしれない。
押し入れの暑さを知ってる経験者やなｗ
ttrrttrr このあとほのぼのしたブコメ欄が突如としてディストリビューション戦争に
Remminaつかればいいのでなんでもいいんだが、
さらに軽量なのがないかなあとも思う アプデとかさせたくないのでロックダウン化させたいんだが情報がない
c_shiikac_shiika 老朽戦艦の朝日を工作艦にするようなものだな。廃物利用に近いので撃沈してもあんまり惜しくない。
それな。エコだよ
LagenariaLagenaria いとこのサンディおじさんに教えてあげなきゃ！
これかｗ
https://dic.nicovideo.jp/a/sandy%E3%81%A7%E5%8D%81%E5%88%86%E3%81%8A%E3%81%98%E3%81%95%E3%82%93
今日Windows Subsystem for Linux 2 (WSL 2)関連の記事を読んで、そういえばWSL 2をまだインストールしていないことを思い出した。数か月前にWSL 2をインストールしようとしたものの、何かの理由で中断したのだ。改めて
https://docs.microsoft.com/ja-jp/windows/wsl/install-win10
を少し読んでその理由を思い出した。手順1でMicrosoft-Windows-Subsystem-Linux 機能を有効にするときに
ここで、手順 2 に進み、WSL 2 に更新することをお勧めしますが、WSL 1 のみをインストールする場合は、マシンを 再起動 して、「手順 6 - 選択した Linux ディストリビューションをインストールする」に進むことができます。 WSL 2 に更新するには、マシンの 再起動を待ってから、次の手順に進みます。
と再起動が必要になるが、次いで手順3でもVirtualMachinePlatform 機能を有効にしてまた再起動が必要だという。2回も再起動が要るのか、と億劫になって後回しにしたのだった。
しかしその時も思ったのだが、どうも手順1の日本語が妙だ。WSL 1をインストールするときにはマシンを再起動。WSL 2に更新するときもマシンの再起動。どちらにしろ再起動が必要なら、こんな書き方をする必要はない。「ここで、再起動します。WSL 1のみインストールする場合は手順6に、WSL 2の場合は手順2に進みます」のようになるはずだ。
そこで英文に当たってみると、
To update to WSL 2, wait to restart your machine and move on to the next step.
となっている。この英文だけからでは私の英語力ではどう解釈すべきか自信がなかったが、そもそも手順1と手順3の機能有効化はWindows + X キー→「アプリと機能」→「プログラムと機能」→「Windows の機能の有効化と無効化」の設定を変更する操作と思われる。このダイアログで2か所変更したいとなったとき、1個変更してマシンを再起動してから、残りの一つを変更してまた再起動する必要があるだろうか？いや、ない。ということから、先の英文でのwait to restart は「マシンの再起動を行い、それが終わるのを待つ」ではなく「マシンの再起動を思い止まる。再起動しない。」の意味と思われる。
※ ひょっとすると「マシンの 再起動を待ってから、次の手順に進みます。」を、私は第一感では再起動すると解釈したが、再起動しないと解釈する人が多いのかもしれない。であれば、私の国語力不足だ。
ウェブ上の辞書でwait to ～ を調べると、大体はcan't wait to ～ で「待ちきれない、すぐにでもやる」という意味を大きく載せていた。また、手元のジーニアス英和辞典第4版を引いたが、「思い止まる、～しない」という意味ははっきりとは載っていなかった。あまりない用例なのかもしれない。
このWSL 2のインストールドキュメントは機械翻訳ではなく人の手によるものと思うのだが(最近の翻訳技術の向上はすごいらしいので断言はできないが)、翻訳する人もなかなか大変だなと思った次第。
そして、この文章を書くのに疲れたので、WSL 2のインストールはまた後回しになりそうだ。CentOS をインストールしようと思っていたが何やらサポートが終わるらしいので、ゆっくり候補を考えようと思う。
マジレスすると元増田みたいに知識と技術が足りない人が使うのにはハードルがあまりに高すぎること
その１ 安定性が悪い
ディストリビューション選択とIDEとカスタマイズ・チューニングによる
Windowsエクスプローラはなんだかんだで万人がそれなりに使えるソフトだし
その２ （正規の終了法を使わず稼働中のPCのコードをいきなり引き抜く）強制的な電源オフに対応していない。Linuxでこれをやると高確率で次回の起動ができなくなる
サーバー用途で入れた奴は停電で切れてもそんな事態に陥ったことが無いから、たぶんシステム構築とかファイルシステムの選択に問題あり
具体的に何で困るかが分からん
初期のパッケージが古くて、何かソフト入れようとするとパッケージアップデート要求されるからネットワーク必須とか？
そもそもLinuxmintとやらは今年7月にもリリースされてるっぽいけど何の話？
その３ デバイスドライバがそろっていない。致命的な弱点
そうだね
トップと営業の方はエンジニアのことを考えていないような環境です。
昨日の求人に書いてあることと違うことをさせる株式会社アイビスを観て私も同じようなことがありました。
私は、女性エンジニアとして入社しましたが、即現場に入りました。しかも、OSはWindowしか知らないのに、Unixディストリビューションで分散型バージョン管理を使った現場です。もちろん1ヶ月で離任しました。
営業の方は、売ることは長けていますが、その後のことは何も考えていないです。
また、株式会社アイビスのトップは自分がやりたい開発だけをしていて、社員に還元できるような仕組みも考えず管理職に丸投げです。
Twitterで自社アプリの使い方をユーザーにリプライなどをしているが、それをするのは広報がするべきです。
連日、Twitterでエゴサーチをしていて、会社として仕組みを変える時間がないみたいです。夜遅くまでエゴサーチで忙しいみたいです。これなら、会社や社員のことなんか考えてられないことに納得。
機種の性能ではないですかね。いつ発売の機種か、また、価格はいくらかによります— かみやん (@kamiyan) December 11, 2018
あ。動いているならDropboxかSDカードでバックアップになります。操作が分かりやすいのでDropboxをお勧めします https://t.co/kB4Ve6q6yv— かみやん (@kamiyan) December 11, 2018
修理に出す端末は電源がらはいらないとか、操作パネルが効かない、ディスプレイが映らない等でアイビス ペイントが起動しない状態ですか？— かみやん (@kamiyan) December 11, 2018
100人も超える組織で、自分がやりたい開発だけしていて組織をまとめるような仕組みを考えない人がトップにいます。
売上/利益/社員数の大半を派遣メンバーは自社開発にまわす予算を稼いでくるものとしてしか捉えてない様子。ただの駒としてしかみていない。社員の人もその背中をみているせいかコミュニケーションをほぼとらず ただただコードをかくだけの人。 また、営業の人はエンジニアのことを考えずお客様に提案しています。つまり、稼げる案件にアサインして、無理だったら次へという感じです。合っていなく業務がままならないことを相談しても待ってくれというだけで何も改善されません。待ってくれというだけで、次はどうにかするからと言うが変わらないです。期待はすべきではないないでしょう。 給与も手取り14万円、中途でも18万ぐらいで本当にエンジニアはいいように使われます。それでもいいというエンジニアは働くべき環境です。
ちなみにですが、資本金は9592万5000円で、4つも事業所や開発センターがあり、別にもう一個会社がありますが、社員に対して特に還元をしないです。上の方々が、お金を搾取しているみたいです。
私も女性エンジニアとして、入社しました。OSのことなんかWindowsぐらいしか知らないのに、プロジェクトはUnixディストリビューション環境で、分散バージョン型を使った案件でした。営業の人は売り込むことは上手いかもれませんが、後のことは何も考えていません。私も1ヶ月で離任しました。株式会社アイビスはエンジニア のことを何も考えていない組織です。
夜遅くまで、自分の開発のエゴサーチにトップは忙しいみたいです。社員のことよりも、自分の開発の方しか考えていない残念さです。
ありがとうございます。画面にフイルムとか貼ってるとなる。とか、画面を拭くと直るというのは聞いたことがあります。ちょっと明日社内でこの動画について検討したいと思います— かみやん (@kamiyan) 2018年12月11日
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
ありがとうございます。症状としてはブラシで描いてるときに別の場所に触れてキャンセルされたのと似た感じですね。同じ質問になってしまうかもですが、機種とApple Pencilの使用有無について教えてもらえますか— かみやん (@kamiyan) 2018年12月11日
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
なるほど。それだと無理ですね、、— かみやん (@kamiyan) 2018年12月11日
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
アイビス でスポイトの起動が邪魔な場合は、設定ウインドウでクイックスポイトをオフにすると良いですよ— かみやん (@kamiyan) 2018年12月11日
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
なんか効率が悪いとかコストパフォーマンスがとか言ってる人が大勢いるけど、そもそもベルマーク集めが効率的であってはマズイでしょうと思う。
だってそうじゃないですか。
効率を求めるなら例えばスポーツなんてエネルギーの無駄だからやらなければ良いし、映画なんて時間の無駄だから行かない方が良いってことになるし、ポケモンを集めている人なんて馬鹿そのものってことになるじゃないですか。これが不当な結論だっていうことは無論ですよね。
ベルマーク集めもそれと一緒なんですよ。当たり前でしょう？
その上でベルマーク集めの良いところを挙げると、
・たくさん集めると、もっと集めたくなる。
・ベルについて考えさせられる。
・たくさん集めたベルマークを見ると心が洗われる。
・おいおい、こんなにたくさんベル集めてどうなってしまうんだろうと爆笑。
・ベルマーク殴りという技を編み出す。
・ベルマークに特化したディストリビューションを開発。
などいくらでもある。
さあ。レッツらベルマーク。
カトラークラスのエンジニアが数十人、数十年かけて磨き上げた Linux カーネルにかなうわけねーだろ。
もはやFreeBSDは人手不足で、Meltdown, Spectre にも満足に対応できない有様。
カーネルがごちゃごちゃしてたのは v3 初期までで、その後、徹底的な抽象化・#ifdefによる機能の分離化、CPU依存の排除をしたおかげで、configでオプションを最小化したら恐ろしいまでに小さいサイズのカーネルになる上に、オレオレCPUへの移植もそれほど大変でなくなった。LLVMのSSAなどの技術をBPFが取り込んだおかげで、カーネル内のモニタリングも perf関係からの置き換えの目処がたったら、そのあたりの余計なコードも削ぎ落とせる夢がある。
おかげでconfigオプションが数千にもなってしまったが、ディストリビューションも多様化してくれたお陰で、自分の用途に合わせたカーネルの選択に困ることもあまりない。WindowsやMacでも Linux システムコールラッパがほぼ完全に動くようになり、「Write Once, Run Anywhere」をVMを介さないで実現する POSIX以来の夢がいま正に実現しようとしている。
その昔、
「Linuxのオススメのディストリビューション教えろください」
と言われたらFreeBSDと答えるのがベストアンサーだった。
それくらい*BSDはLinuxに比べてゴチャゴチャしておらず、シンプルかつ堅牢なOSだったのだ。
同時に、SystemV系のようにrc.*経由でデーモン操作なんてタルいことをせず、プロセスをより直接的に操作できる柔らかさもあった。
ちなみに代表的な*BSDといえばFreeBSD・NetBSD・OpenBSDだが、これがちょうどつぶあん・こしあん・白あんみたいなモンで、まあそういう定番が3つもありゃ十分だろうと。
とにかく*BSDであれば、何かをやる方法のバリエーションは最大でも3パターンにしかならないわけで、上述の通り本当にシンプルで手堅いのである。
一方のLinuxは「誰が食うんだこんなもん」みたいな内容のディストリビューションが乱立しまくっていて、その乱立振りもあってか、/etc以下は壮絶にカオスである。
多様性というが、現実はディストリごとの細かな操作の差異だの方言だの、本当にくだらない事に手を煩わされる、まさしくヒマな大学院生の習作から出発した感が溢れる、頭の悪いOSという感じ。
だからLinuxなんて登場当時はいっときの流行り、或いは時代の徒花くらいに捉えられていた。
それこそ、OSの世界はWindowsと*BSDでほぼ二分される未来のほうが、WindowsとLinuxで寡占された未来よりかは現実性がある…と思ったものだ。
ちなみに今のWindowsのベースは、あのカトラーが人生を賭けて作ったものなので、そうそう色褪せる可能性は低いわけで、軽んじることは出来ない。
しかし、実際のところはそうならなかった。
本当にLinuxがここまで世界に広まったことが不思議でならない。
広まる要素なんて全くもって皆無だったじゃん。
UNIX系の中ではかなりゴチャゴチャしていて、それは今も変わらないわけで。
ディストリビューションについても違いが小さくなるどころか、RedHatとUbuntuでは同じLinuxと思えないくらい違っている。
というかそれぞれの用途に各システムでめちゃくちゃにカスタマイズされまくっていたりで、ある環境でLinuxを触っていたからといって、他のシステムでその経験が通用するとは限らない。
あぁ、これは流行らないなと思った。
ASCII.jp：Twitterのライバル？ 実は、新しい「マストドン」（Mastodon）とは！｜遠藤諭のプログラミング＋日記
記事をまとめると、Mastdonの特徴は次の4つに集約されると思う。
・ほぼTwitter
・サーバーの分散化によるリスク回避（中央集権体制に対するアンチテーゼ）
いうなれば、Windowsに対するLinux郡の構図である。
だが、いまだかつてWindowsより流行ったLinuxなど存在しない。
人類の歴史は、中央集権→革命→群雄割拠→中央集権→革命を繰り返すことで進歩してきた。
Twitterという中央集権に対するアンチテーゼたるMastdon、ないしGNU Socialは「革命→群雄割拠」に当たる。
しかし、Mastdonに「革命→群雄割拠」を起こし、Twitterに取って代わる素晴らしい特徴があるかと言われれば無いだろう。
OSS化されただけのTwitterのクローンである以上、結局Windowsに取っては変わらないLinux同様、Twitterに勝つことは出来ないと思う。
また、群雄割拠の先には新たな中央集権体制があることも忘れてはいけない。
Windowsという中央集権のアンチテーゼであるLinuxは現状どうなったかと言えば、
ほぼUbuntuとAndroidに集約されたと行って過言でない。
UbuntuとAndroidは明確に用途が異なるから交わることはないけども、群雄割拠の末にたどり着いた中央集権の構図である。
同様に鯖とか研究用とか用途ごとにディストリビューションはあれどとりあえず集約されている。
Mastdonも、最終的にはLinux群と同様に集約されるだろう。
おそらく、".cloud"（＋".jp"）しか残らない。だってLinuxのディストリビューション以上に差がないもん。
集約された時点で、「サーバーの分散化によるリスク回避」という特徴が死ぬ。
じゃあどうすればいいのって話だけど、
＝鯖ごとにアカウント作る必要あり、鯖ごとに切り替えて投稿する必要あり
→ .cloudへの集約による中央集権化
→ 特徴が死ぬ
↓
↓
→ 面白そうだけど、なんかアレ感がある
つまり、
・サーバーの分散化によるリスク回避（中央集権体制に対するアンチテーゼ） → 意味がない
・テーマごとにサーバーを変えることも出来る → Google+の二の舞い
うーん…OSS大好きおじさん(老害)しか残らない未来しか見えないなぁ…
とりあえず誰かﾏｽﾀﾞﾄﾞﾝ鯖早く立てればいいんじゃないの
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
ログイン画面とか、機密ファイルを開くときのパスワード画面とか、ファイルコピー中の画面とか。
たまに Windows でも MacOS でもないのあるでしょ。
普通の商社だとか学校、暴力団なんかで Linux を使っているとは思えない。
（そして少なくとも主要なディストリビューションではなさそう）
あのOSは何なんだ？
というのも疑問なんだけど、
撮影に必要なちょっとした画面だけでも、作るの大変だと思うんだよ。
なのに敢えて Win や Mac を使わないのは理由があるの？
以下、自分で考えた説。
コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある（特徴のない言語は廃れていく）。
あまり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。
なお、取り上げるのはある程度広く使われている言語に限りたいと思う。
| 言語名 | 概要 |
|---|---|
| C言語 | 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグ出やすい |
| C++ | マニアック言語、高速、習得大変 |
| Java | サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる |
| C# | 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語 |
| Perl | 広く使われていたが今は若干時代遅れのスプリクト言語。汚い |
| Python | Perlにかわって主流になりつつあるスクリプト言語。綺麗 |
| PHP | Web開発にフォーカスされたスクリプト言語。一世を風靡した。 |
| Ruby | とても綺麗なスクリプト言語 |
| JavaScript | ブラウザで実行出来る唯一の言語。言語自体はいまいちだが、ブラウザの事情で需要あり |
| Go | サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語 |
メモリに直接アクセスして書き換えるといったコンピュータの機械語に近い言語構文を持つため、高速な処理が可能な言語。
コンパイラの歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語。
一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディングの効率が良くなく、多種多様のバグを生みやすい側面も持つ。
ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。
C言語にオブジェクト指向を導入した言語。C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。
C言語の速度を維持したままオブジェクト指向やテンプレートなどの効率的な記述を可能にしようとした意気は真っ当だったのだが、
当時最先端だった色々な技術や思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。
「C++を理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。
速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。
サーバサイドで安全にコードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。
当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリの解放忘れというバグを生まず、
サーバサイドなどで何千時間と動作するソフトウェアに適した言語として受け入れられた。
必然的にエンタープライズ用途で利用されることが多く、各種ツールなども豊富。人海戦術がしやすい言語という側面も出てきた。
一方でブラウザにHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。
ガラケーのアプリや（ちょっと違うが）Androidなど、クライアントサイドでも使われることがある。
プログラミング言語で最初にJavaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。
クライアントサイドで安全にコードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。
元々はWindowsのクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。
マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。
Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。
自作のゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。
ほぼ全てのLinux系ディストリビューションに含まれており、ツールや様々な用途で使われていた。
上に紹介したC、C++、Java、C#のようなコンパイル言語とは違い、（少し語弊はあるが）1行ずつ実行してエラーがあれば止まるスクリプト言語である。
ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインのコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である。
20年近く前にWebでCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。
しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存のコードもどんどん別の言語に置き換えられていることが多い。
日本の大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。
後発のスプリクト言語。こちらもほぼ全てのLinux系ディストリビューションに含まれており、それゆえに広く使われている。
インデントまで言語仕様で規定することで、誰が書いても読みやすいコードになるように考えられている言語である。
Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。
ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。
最近だとマシンラーニング系のライブラリでPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。
Web開発に特化したスクリプト言語。CGIの代わりに使われ始め、一世を風靡した。
以前CGIでWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。
またphp.netの豊富なドキュメント＆スニペットのおかげもあり、開発初期の効率が大変に良い言語である。
残念なことに、言語やAPIの設計がいけていない点が多く、一部の人からは蛇蝎の如く嫌われている。
今でも根強い人気があり、海外でも小規模プロジェクトの最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。
Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。
なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。
綺麗なスクリプト言語。日本発で世界的に普及している数少ないIT技術の一つ。
言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWeb用フレームワークの登場で、Webアプリでの採用例も一気に増えている。
基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである。
スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語。
サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。
一方で、なぜかRubyが採用するWeb側のフレームワーク（具体的にはprototype.jsやCoffeeScript）はいつもクソなので、そちらは深入りしないのが吉。
ブラウザで動くスプリクト言語。ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語。
言語としてはプロトタイプベースのオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。
言語仕様がイマイチで、大変バグを生みやすい言語であり、また関数のスタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが
ブラウザで動く言語が現在これしかないので、大きなシェアを持っている。
一部の物好きがサーバサイドでこの言語を使おうと（主にnode.jsで）四苦八苦している（とはいえ、1つの言語でWebとサーバが完結するのは大きなメリットだ）。
ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。
まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。
Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である。
最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsでサーバサイドもできるしで、意外とオススメだったりする。
C、C++やJavaと同じでコンパイル言語。サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語。
その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。
それ以外の目的ではあまりこの言語を採用するメリットはないが、ニッチな用途をピンポイントで抑えており、これから広く利用されることも期待される。
コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである。
繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。
ここに挙げた言語は何らかの特徴があり、何らかの用途で必要なので生き残っている。
その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。
