  |
はてなキーワード: Pythonとは
そりゃ今でこそ、python でウェブ？と言われるときょとんとするかもしれんが、
perl php ruby と渡り歩いてきたウェブスクリプト屋からみると
早くPerlとRubyを滅ぼしてPythonが使えない人間が何もできない無能としてライン工でぶざまに一生を終える世の中がさっさと来て欲しい
分かったのは言語の多機能さというのは、一点水準さえ満たしていれば、それ以上足しても生産性に寄与しないという事
自分しか使わない、最初書くときに限れば書きやすいと思うこともあるが、それ以上に保守性を落とす
ライブラリを利用したり他人のコードを読む機会の方が多い昨今マイナス要素でしかない
perlのスローガンだかに "There's More Than One Way To Do It." というのがあるらしいが、読む側からするとたまったもんじゃない
演算子がオーバーロードされてるかも？モンキーパッチされてないかな？等々あれこれ想定しなきゃいけないのが苦痛でしかない
パスの選択肢を見せた事で沢北が集中できなくなってしまったから
DSL(笑)が良いと思ってるのは最初だけで、最終的に負債にしかならない糞コード
統計・機械学習系のライブラリが皆無で先細りのイメージしかないからRailsと一緒に心中ください
リスト評価、スカラー評価とか意味わかんねーくくりもtie変数もアイディアは糞中の糞
Perl6にいたってはわけわかんねー演算子のオンパレードで悪いところをさらに悪くした感じ
オーバーロードされまくりのコードなんてどっから読んでいいかわかんねーよ
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。
○画面に表示する時
フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。
最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。
最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける
次に他の人の英語化したのを見る時。
その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。
そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。
相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラスや関数によって呼び方違うと辛い。
かといって全員に日本語と英語の対応を先に渡しておいて統一しようというのは大変すぎる。
（日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず）
----
次にデメリット
軽く調べた感じ主にこの2つな感じ。
○IME
と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。
ほぼ無意識でやってて意外と苦じゃない。
短いとF10変換で半角にすることもあるけど、キーボードのタイプ数カウンタとか入れてみると半角全角キーはけっこう上位にいた。
それに、なんだかんだコメントは日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。
そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。
最近じゃIDEやエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。
githubで公開したりとかライブラリで再利用してもらうときに日本語じゃ使ってもらえない。ってことみたい。
私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーションの固有名詞みたいなところ。
「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的な英単語でいいと思う。
具体例がいいづらいけど、業務システムで表示する金額の名前とか、日本語独特なものとか、一般的な単語じゃなさそうなの。
こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いからgithubで公開する範囲も英語のものでいいと思う。
ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体をgithubで公開する場合はできない気がする。
でも、海外も対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語でいいんじゃないかな。
----
長くなったけど、まとめると、
業務システムの固有名詞とか日本語特有なものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな
ということ。
まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由。
帰ってきたらすごいブクマついてた。
絶対「自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間に日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。
まず、思いの外日本語プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。
具体例上げずにサッと書いたらからかな。
あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。
これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。
---
最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。
JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift
rust と Lua は無理だった。
rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。
実際に今どんな状態かは知らない。
その記事のコメントとかでみたけど、日本語以外は割りと自国の言葉を使ってたりするっぽいね。
VBA を上げてる人がいたけど、私はそこまでのはみたことない。（幸せ者っぽいな）
稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。
パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。
---
○使ってみて
大規模案件に使ってみてこその問題もあるだろうけど、簡単なスクリプト程度のを日本語にしてみて気づいたこと。
割といける。
PHPて言語は変数は全部$からはじめないといけない欠陥言語。
まあ変数のみのgrepのしやすさや予約語キーワードを変数名に使えるからメリットもある。
だが、$って打ちづらい。
Shift+4ってすごいつらい。
に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。
GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。
IDE重いから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語の変数名で書くより速度は早いと思う。
---
少し前に知人から言われた日本語のデメリットを思い出したのでそれも触れとく。
「仕様変更で言葉変わったときに日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」
英語わからない人が、英語を言葉とみなさずただの記号として考えてるから、っていうような発言。
仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。
英語と日本語の対応をコメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。
こういう考えの人がいたら本当にやめてほしい。
---
あとは気になったコメントについて書いてく。
表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。
年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。
こういうのを日本語にしたい。
なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。
特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。
---
見た目について。
見た目が残念とか見づらいというのは同意。
見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語のコード見ればなれるんじゃない？って思う。
---
へとヘ
これはありそうな問題。
ただ、IDEを使う前提なら未使用変数のエラーとか、選択したときに色が変わってないとか、割と気づけると思う。
lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。
---
私が日本語にしたいような固有名詞をローマ字化してるプロジェクトにであったことはある。
それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
結果
Java https://ideone.com/V7rEZP
Javascript https://ideone.com/pUmDJI
Python https://ideone.com/aF48Dm
Ruby https://ideone.com/oyknMD
Perl https://ideone.com/RHz3lF
http://anond.hatelabo.jp/20170414012241
（人文、文学、新書、文庫、経済、経営、ビジネス、ITエンジニア）
| 名前 | 2016年のベスト | リンク | 所感等 |
|---|---|---|---|
| 紀伊國屋じんぶん大賞 | [『戦争まで―歴史を決めた交渉と日本の失敗』加藤陽子 | 発表！！紀伊國屋じんぶん大賞2017──読者と選ぶ人文書ベスト30 | 高くて長くて購入を躊躇しがちな人文書を適切にセレクトしてくれてありがたい。 |
| Twitter文学賞 | 国内 『吸血鬼』佐藤亜紀 国外 『すべての見えない光』アンソニー・ドーア | Twitter文学賞投票結果上位一覧1-7回｜文学賞の世界 | 発起人は豊崎由美。売れ線から距離を置く感じ。 |
| 新書大賞 | 『言ってはいけない(新潮新書)』橘玲 | 新書大賞｜特設ページ｜中央公論新社 | 中央公論新社が主催。 |
| おすすめ文庫王国 | 『雪の鉄樹』遠田潤子 | ― | 埋もれていた良書を発掘してくれる。 |
| ベスト経済書（週刊ダイヤモンド） | 『人口と日本経済 - 長寿、イノベーション、経済成長(中公新書)』吉川洋 | ― | 2016年は学者ほか107人が選考。真面目。 |
| ベスト経営書（ハーバード・ビジネス・レビュー） | 『ビジネススクールでは学べない 世界最先端の経営学』入山章栄 | ハーバード・ビジネス・レビュー読者が選ぶベスト経営書2016の結果発表 | ベスト経営書｜DIAMOND ハーバード・ビジネス・レビュー | 意識高い。 |
| ビジネス書大賞 | 『HARD THINGS』ベン・ホロウィッツ （2015年発行が対象） | ビジネス書大賞 | 2010年～ |
| ビジネス書グランプリ | 『LIFE SHIFT』リンダ・グラットン | 「ビジネス書グランプリ2017」結果発表ーービジネスマンの来し方、行く末を考える（1/2） - HONZ | 5分野（イノベーション・マネジメント・政治経済・ビジネススキル・リベラルアーツ）が対象。 |
| ITエンジニア本大賞 | 技術書 『ゼロから作るDeep Learning Pythonで学ぶディープラーニングの理論と実装』斎藤康毅 ビジネス書 『最強の働き方』ムーギー・キム | ITエンジニアに読んでほしい！技術書・ビジネス書 大賞 2017 | 翔泳社が主催。 |
意識低い企業内研究者です。プログラミングはサブウエポン。だけど趣味でも勉強してる。
働き方改革のせいで早く帰れって言われて、酒のみながら今これを書いてる。
C言語とかC++は・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、
WindowsのAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。
組み込みプログラミングではC言語はいまだに現役。お金も普通に稼げると思うよ！次代のCOBOLと化しそうで怖いとこはあるけど。
Javaは・・・使える人が多いからあえて今から学習しなくてもいいような気がする。
文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有のセオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。
セオリーとかあるかもしんないけど速度とか気に揉むまえに書いて測れ。たいていは杞憂か、あるいはCPUパワーで殴れるから。
Goは・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。
ライブラリの選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。
GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。
Goでデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。
GoでGUIつくるの？あんまり普通じゃない気がする。軽量プロセスのうまみがそんなない（詳しい人に否定されそうだけど）
普通にC#(mono/.net)かwebアプリにするかで良くないか？
ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。
広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。
twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。
一応著名なプログラマーをTwitterでフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。
twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いから自分からリプは送ったりはしない。
ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。
アルゴリズムは使うものだ書くものではない！高階関数とかテンプレートプログラミングとかその辺勉強するといい。
あと計算が制限時間内に終わるなら総当たりが最速で品質も高いぞ。
どうしてVimかというとプラグインが多いしIDEっぽくできるから。
Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。
NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。
Vim知らない。Linux使うならVimかemacs使えるだろみたいな雰囲気あるけど、GUIならgedit, CUIならnanoでいいよね。
パソコンのスペックもどのくらいのものを用意したらいいのかわからない。
10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートだからプログラミングに向いてないのかもしれない。
VirtualBox上のubuntuでMySQLをコンパイルすると2時間20分ぐらいかかった記憶がある。
CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。
スペックにお金をかけることで時間の節約ツールの選択肢が増える
EclipseなどのIDEが支障なく使えるレベルのスペックってどのくらいするんだろう。
3年前のCore i7, SSD, 8GB。最近はもっぱらJupyter。
Pythonは・・・・機械学習する上で避けて通れないけど、今のPCだと無理。
Pythonはいいぞ、機械学習だけじゃなく計算系はエクセルじゃなくてJupyter使う。でも周りはエクセルつかってる、勿体ない。
使ってないけど最先端の研究では機械学習使って当たり前感があってそろそろヤバい。
僕は中学生の頃、いじめにより心の余裕なんてなかったから勉強どころではなかったけどもっと英語の勉強しておけばよかったと後悔している。
迷宮にいる感じ。
なんとなく、プログラミングじゃないほうがいい気がするなあ。
C言語とかC++は・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、
WindowsのAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。
Javaは・・・使える人が多いからあえて今から学習しなくてもいいような気がする。
文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有のセオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。
Goは・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。
ライブラリの選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。
GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。
Goでデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。
ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。
20の言語でHello World出来るより、1つの言語でいろんなアルゴリズムを知っている方がすごいと思う。
コミュ症がフランス語や英語やドイツ語覚えても、使う機会がないとまったく価値がないと思う。
広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。
twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。
一応著名なプログラマーをTwitterでフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。
twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いから自分からリプは送ったりはしない。
ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。
コードを写経しても覚えられないし、仕組みは理解したけど自力でコードが書けない。
どうしてVimかというとプラグインが多いしIDEっぽくできるから。
Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。
NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。
パソコンのスペックもどのくらいのものを用意したらいいのかわからない。
10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートだからプログラミングに向いてないのかもしれない。
VirtualBox上のubuntuでMySQLをコンパイルすると2時間20分ぐらいかかった記憶がある。
CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。
スペックにお金をかけることで時間の節約ツールの選択肢が増える
EclipseなどのIDEが支障なく使えるレベルのスペックってどのくらいするんだろう。
ノートでCore i3、メモリ4GBにランクアップしたらいけるのかな。
他人がどんなスペックのPCで何のツール使ってプログラミングしているか知りたい。
Pythonは・・・・機械学習する上で避けて通れないけど、今のPCだと無理。
あと、クレジットカード持てないのでAWS上で機械学習するのだけは遠慮したい。
過大請求されるの怖いし、トラブルが起きた時に英語でコミュニケーション出来ないから。
僕は中学生の頃、いじめにより心の余裕なんてなかったから勉強どころではなかったけどもっと英語の勉強しておけばよかったと後悔している。
迷宮にいる感じ。
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
