「プログラミング言語」を含む日記 RSS

はてなキーワード: プログラミング言語とは

2017-04-26

アイマスとpaizaの違いが分からない

自分の中では アイマス→セーフ paiza→アウト なんだけど、この境界線説明できない。

戦艦女性エンジニア

プログラミング言語女性エンジニア

生物なのでセーフ

文豪女性エンジニア

死んでるのでセーフ

アイドル女性エンジニア

アイドル水着をよく着るのでセーフ?

男性エンジニア男性(女性)教職員男性(女性)司書男性(女性)パイロット全部アウトだと思うけどこれとアイドル境界線説明できない。

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2017-04-15

http://anond.hatelabo.jp/20170415104722

Perl は、いろんなプログラミング言語の書き方をごちゃ混ぜに取り込んだ便利言語なので、

非常に特殊存在だと思う。中途半端に学ぶと、その非統一感に悩まされる。

PHPには、Perlのようなごちゃ混ぜ感は無いよ。

WebCGIと言えばPerl時代に、その改良版的な位置づけでPHPが登場したのが

はやった理由だと思う。

PHPより先にサーバサイドJavaScriptが登場していたら、

PHP流行ることは無かったかもね。

http://anond.hatelabo.jp/20170414235405

手足が自在に動かせるからと言って誰もが空手の達人というわけではない、、、、と似たものを感じるが、

だがしかしプログラミング言語単体に道具としてのうまみが少ない

でもアプリを作るにはそれしかないので、

プログラマ友達を作って、おねだりして作ってもらうのが一番簡単確実。

とか考えてんだろとか邪推してたら友達がいなくなりました(超天才プログラマより)

2017-04-12

IT業界全然進歩してなくて笑えてくるw

業界20年目だけど、まるで成長してない(安西先生)って感じる事ばかり

20年もこんなマッチポンプに付き合わされればそりゃ愛想も付きます

なにか目的があって、それを機械解決してほしいだけなのよ

一部のプログラミング大好きサーバー大好きっ子はその手の仕事が好きなのかもしんないけどこっちはそんなことしたくねーよ

だって本質じゃないだろ?

なんでプログラミング言語処理系ケアまでなんでこっちがしなきゃいけないの?アップデートに付き合わされなきゃいけないの?

自分要望目的をしたいことリストアップ言語かなんかに書いておいて、実現する技術はその時々で最適なものを選定してくれませんか?

したい事は変わらないのにプログラミング言語やらOSアップデートされたので開発をやり直します!ってあきれて物も言えないわww

最近流行りのAI技術とやらで、ここら辺解決してくれませんかね?

2017-04-11

http://anond.hatelabo.jp/20170410230648

プログラミングアートからだよ。

もし、プログラム純粋に小さな論理の積み重ねだけで出来上がるとするならば、

つの目的のために書かれたプログラムは誰が書いても同じものになるはずだ。

ところが現実はそうではなく、いろんな書き方が存在する。

これは目的のために、どの論理をどの順番で組み上げたらよいか?という選択余地があるからであり、

その選択は本人のセンスによるところが大きい。

このセンスが全く無いと、頭が良くてもプログラミング言語文法書を片手に途方に暮れてしまうのさ。

2017-04-09

Rubyはもうやめた

もうRubyシステム書くの止めた

日々更新されてコロコロ変わる言語仕様に付き合ってられない

最近互換性を気にしてるようだけど新しい書き方ですとか毎回言われるストレス半端ない

プログラミング言語みたいな土台となる技術がそんな変わって何も違和感覚えないやつらがどうかしてる

(その意味SwiftRuby以上に頭おかしい)

rbenvやらBundlerで完璧ベンダリングできますってそんな誇れることなの?

バージョン依存が激しいのでそうしないとバグますって言ってるようなもんじゃねーかw

まだpython2,perl5で書いた方がまだ良いわ(Perl文法が糞だから書かないけど)

多少言語に粗があっても互換性を維持してくれた方がよっぽど重要なんだけど(少なくとも俺は)

ついでにRailsも止めた

フルスタックフレームワークでなんでもできるぞ!とか言ってるけど理解できない

自分が使わない機能がたくさんコードに入ってて使わない機能脆弱性がありましたアップデートあります

って毎回言われてどう思うの?

モックアップみたいなのをササッと作るには良いかもしんないけど、こんな異常なアップデート地獄に付き合わされて

まだRails生産性が高いとか言えるの?

結局Railsマジックで作ったような気になってるだけで後に来る保守問題先延ばしにしてるだけじゃねーの?

Rubyが変わりRailsが変わりそれに追従して今回のアップデートはあーだーこーだーって茶番すぎんだろw

世の中のレガシーRailsシステムを見て現実を見たらw?

2017-04-04

http://anond.hatelabo.jp/20170403094257

これ、技術 vs マネージメントという単純な話でもなくて。

要はソニーなりの大企業になると大きな仕事をしなくてはならなくて、職人がひとりでできるひとり分の仕事をしていては回らないわけで。

そのときどうスケールさせるか、という話。

日本企業は、昔から製造工場ライン工メタファーで極力プログラミング単純作業に落とし込んで、多くの低スキルプログラマーによりスケールする道を選んだ。

まあ原始的プログラミング言語時代はそれでもよかった。

一方アメリカをはじめ諸外国は、ある時期からプログラミング科学、つまりコンピュータサイエンス数学を持ち込んでスケールさせようとした。

コンピュータ自体最初から科学産物だけど、それをビジネスに展開するときの話ね)

から日本でのプログラマー地位海外に比べて低く、早くマネージメントに上がれといわれ続ける。

日本企業の誤算は、ソフトウェア進化ハードウェア進化よりもずっとずっと誰も予想がつかないほど速く、ドラスティックだったことで。

さらに世の中が急速に進化して、サービス時代になるとフィジカルインタフェース以外は全部ソフトウェアという製品も出てきた。

もはやこうなると多数のライン工プログラマーを抱えたハード屋という構図では圧倒的なアウェイしかない。

もし大企業が本気で変わる気があるなら、製造工場の考えを全部捨ててゲーム制作プロジェクト、それもAAAタイトルの巨大なプロジェクトスタイルを他のビジネスにも取り入れるのが良いと思っている。

(これはハリウッド映画制作メタファーでもある)

ベテランプログラマーがひとり分だけの職人仕事をするのは大企業では難しい。でもその才能を生かしたまま映画監督のように大きなプロジェクトチームを率いることはできるはずで、たぶんソニーはそういうことのできる会社だったはずで。

2017-03-16

数学原理論」


1・空間を前提とした→の体系


空間を前提とした→(動き)を線で表すと数直線になる。点や円で表すと「リンゴが2個、ミカンが3個」のような例のような感じになる。

「+」は数直線での右への移動。「-」は左への移動。「×」はその存在の個数。「÷」は中に存在がいくつあるか。「累乗」は次元

このような数の体系の問題は、フローチャートのような形で書き記すことができる。

問題では前提か答えのどちらかに条件、というか限定がある事が多い。



2・空間を前提とした○の体系


・○の外側の体系

点、線、面、立体、円や球など。

点や線など、それぞれの越境問題になる事が多い。答えは○という事で、面以上である事が多い。


・○の内側の体系

集合論。表の問題も同じく。



3・空間を前提とした○→の体系


ゲーム理論



4・ネットを前提とした体系


空間でなくネットワークを前提とした体系がある。


リストはこのように表す。

(A)→(B)→(C)→(D)

← ← ←


手続きプログラミング言語(C言語など)はこのように表す。

(A)→・(B)→・(C)→・(D)



0・答えの性質


答えの性質にはディープラーニング結節点のようなものと、フローチャートとその中の集合のようなものがある。

2017-03-15

毎朝ぎりぎり出社の運用エンジニアです

今日会社障害対応

最近やっているプロジェクトはつまらない。

今やっている仕事の50%は運用プロジェクト関係

運用なので実装や開発ということもなく、何かシステム修正があればテスト、というような感じ。

障害も頻発するわけではないがそれでもつらい。

先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、

やっぱり運用プロジェクトというせいかモチベーションが上がらない。

最近は毎朝起きるのも遅い。

乗る電車もいつもぎりぎり間に合う電車

以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり

本を読んだり、ランニングをしたり自由に過ごしていた。

会社にはみんなよりも1時間早く来ていた。

きっとその頃は仕事が楽しかったのだろう。

会社に入ったばかりでやることはどれも新鮮。

少し難しい仕事も任されるようになってきてモチベーションもあったと思う。

仕事楽しいだけでなく充実感があった。

それが今では不思議と朝起きたくないのだ。

起きるのがつらいというか億劫

別に疲れが溜まっているわけではない。

目覚めは悪いどころかいつも目はぱっちりしている。

でも起きれない。ぎりぎりまで布団の中。

そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。

まり憂鬱なのだ会社に行くのが。

この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。

今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。

会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。

そういって同僚はフリーランス転職した。

今では職場でも私生活でもいきいきしている。うらやましい限りだ。

自分フリーランスにはなろうとは思わないけども、少なくとも今のプロジェクト半年が限度かなーとは思ってる。

同じ環境にずっと居ても成長できるか不安だし。

それに自分市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。

そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。

運用プロジェクトの残念なところは、仕事の大半が顧客対応コミュニケーションコストでつぶれること。

特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。

障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..

なんてことをつらつら書かなければいけなかったり。

なにより障害が発生したらものによっては休日にも出勤しなければならないこと。

まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。

体力には自身があるけども精神的にはわりときます。人によるのかな?

つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。

運用プロジェクトでは顧客対応必須だ。なので顧客との話し合いは上手くなる。

あと、運用エンジニアには広範な知識が求められる。

例えばフレームワーク脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。

ハードウェアミドルウェア障害が起きればそれに対する知識を駆使して対応を行う必要があるし、

ドメインが変わった、IPアドレスが変わった、となればシステム運用保守作業で影響がないか調査する必要がある。

なのでそのような対応を考える機会があるので勉強にはなる。

他にも必要知識として、プログラミング言語SQLはそこそこかけて、DBクライアントLinux操作、その他ミドルウェア知識必要になる。

なので現時点では自分スキルはそこそこ伸びてはいるのかなーとは感じている。

そんなこんなで運用プロジェクトは色々大変だよってことです。

理想運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。

めんどくさいことが多いけどもつまらなすぎて潰れないようにとりあえずがんばります

明日仕事ですね。みなさん一緒にがんばりましょう。

2017-03-08

SIerは分かってない

SI業界現場をいくつか見て思いました。

SIerヤバい現場は「何をしているのか理解してない」というレベルで分かってない気がします。

大手SIerプロパーは日々Excelと格闘しています

人月計算や協力会社の単金計算に余念がありません。

この方々に

「このシステムはどんな目的に使われているのか?」

「このシステムはどんなプログラミング言語で作られているの?」

「この値はどうやって算出しているの?」

と聞くと

「わからない」「担当者に聞いてくれ」「ユーザーに聞いてくれ」

と言います

確かにプログラミング技術クライアント業務に詳しくない人なのかもしれません。

でもシステムってプログラミングって自分理解していないと作れないものなんですよ。

プログラミングは俺の仕事じゃない」「ユーザー業務ユーザが一番詳しい」

そうかもしれませんが、システムを作るあなた方が理解してないものコントロールもチェックもできないんですよ。当り前じゃないですか。

確認テストも協力会社の方にお願いするんですか?では協力会社仕様を伝えるのは誰ですか?

ユーザーから質問を「担当者確認します」と言って自分からは答えられない状況が続いているのにおかしいとは思いませんか?

プログラミング仕様も分からない、呼ぶ協力会社は単金だけを見て決めるんですか?優秀かどうかはどうやって判断するんですか?

スケジュール管理数字だけを見てできると思っていませんか?その根拠はなんですか?

SIer技術的にレガシー揶揄されます

Git知らないDocker知らないm9(^Д^)プギャーと

でもそんなことは些末なことで、導入してすぐ解決みたいな話ではないように思えます

それに毎日遅くまで働いて、休日は妻子のために家族サービスとなれば自己研鑽時間なんてなかなか取れないでしょう。

でも作ろうとしてるものが何なのか理解する時間会社の中でできると思うんです。

忙しいのは理解しています。稼働調整、スケジュール調整も大事仕事です。

でも1日5分でも良いから興味を持ってもらえませんか?

お客さんと雑談

「ちなみに現場の人ってこのシステムどうやって使ってるんですかねー?」

とか

プログラミングしている方に

「この処理はJavaScriptで書くのが良いのはどうして?」

とかなんでも良いんです。

自分が今作っているもの理解しようとしませんか?

「そんなことをしても仕事が増えるだけで、得にはならない」

「上から命令から黙ってやるだけ」

という意見もわかります。でも自分理解しないといつまで経ってもコントロールできる立場にはなりませんよ。

ラダー効果が云々という話も聞き飽きたかと思いますが、もうちょっと視野が広がると糞な職場がほんの少し変わる気がしませんか?

というわけでお父さんたちお仕事頑張って!

2017-03-06

ハングルプログラミング言語"Aheul"というのを見かけたが

Hacker Newsの上の方にAheui(아희) https://aheui.github.io/specification.en というのが上がってきていて(ろくにコメントがついてないが)、どうも世界初ハングルを使ったプログラミング言語であるらしい。

どんな言語なのかとググってみたらが日本語情報はなく、2014年2015年に同プロジェクトのページをはてブしている人がいた程度だった。

This code printsHello, world!”

밤밣따빠밣밟따뿌

빠맣파빨받밤뚜뭏

돋밬탕빠맣붏두붇

볻뫃박발뚷투뭏붖

뫃도뫃희멓뭏뭏붘

뫃봌토범더벌뿌뚜

뽑뽀멓멓더벓뻐뚠

뽀덩벐멓뻐덕더벅

これがその言語で書いたHello,World!なのだそうだが、短縮しまくったPerlより読める気がしない。本気で使おうとは思っていないのかもしれない。

ハングル文字の中に方向を示すキャラクタがたくさんあり、カーソルを動かすイメージがつかみやすいという売りはあるようだ。

Wikipedia: Non-English-based programming languages

https://en.wikipedia.org/wiki/Non-English-based_programming_languages

これ見ると英語以外で記述できるプログラミング言語は多い。中国BASICPythonC++中国語化したものかあるらしい。C++中国語版は丙正正。名称がそのまんまといえばそのまんま。BASICを見ると一つ一つのコマンド漢字1文字が割り振られているだけのような感じだ。インドヒンディー語もそんな感じ。その程度のレベルならプログラミング言語母国語に置き換えるメリットはないか

日本にもひまわりやMindなど日本語単語を使えるプログラミング言語があるけど、あれらをマスターしてる人は見かけないな。

2017-02-13

http://anond.hatelabo.jp/20170213143611

一歩間違うと無限ループになるようなメソッド結構作るんだけど、そのメソッド無限ループやらかしちまったのかそうでないのかを判定するのが結構めんどいんだよね。

多分この悩みはどのフレームワークでも一緒だぞ。無限ループを検知してくれるようなプログラミング言語(とかフレームワーク)なんてそう無いだろ。

ただ、一点Unity無限ループを描くと問答無用で落ちる(復帰手段が無い)って処は確かにつらいけどな。

2017-02-01

プログラミング言語って業務で使っていたり流行っていたりすると魅力が減る?

価値はあっても魅力は減ってしまう?

プログラミング言語処女性ってあるんですかね。

それとも誰も知らないインディーズ音楽聞いている俺カッコイイみたいな。

2017-01-26

手の指が5本しかなくて辛い

片手の指が5本づつしかない障がい者だが、とても生き辛い。

まれたから指が少なかったわけだが、小学生の頃までは気にならなかった。

確かに周りのみんなと違って、指が少なくて気になってはいたが、いじめとかは特になかった。

算数時間は、なんか苦手だとは思っていた。他のみんなは、なぜあんなに早く数を数えられるのだろうと。


だけど歴史の授業が始まり、5F0年ほど前に人類が5本指から8本指に進化したことで情報技術革新が起きたことを知った時から、生き辛い人生が始まった。

周りからは、旧人類とかイカ野郎とか言われていじめられた。


健常者は両手合わせて指が10本あるから自然プログラミング言語機械言語理解できるらしいけど、

俺は両手合わせてA本しかいから、数字センスというか、感覚が、健常者に比べて劣っている。

日常生活数字に触れるのは問題ないんだけど、主流の機械語コードリーディングに対しては、致命的だ。


プログラミング教育が高度に発達したおかげで、誰もがプログラミングができて、できないと社会に出られない世の中だけど、

機械語直感的な理解ができないので、できる仕事ほとんどない。


昔はA進数だったし、プログラミングができなくても生きていける時代だったらしいが、その時代に生まれたかった。

突然変異で生まれた8本指の人間情報技術革新を起こし続け、結果的に5本指の人類自然淘汰されてしまったが。

一応、発達障害として認定されているので、月にB3万ほど国から支給されているのでなんとか生きていける。


5本指の俺にもできる仕事教えてくれたらマジで嬉しい。

2017-01-18

バッチ書ける?」と聞かれて

バッチ処理のことしか思い浮かばなくて話がかみ合わなかったけど、よく聞いたらWindowsのBATのことだった。

バッチの貧弱な言語機能を補うべく、いろいろテクニックを駆使して分かりにくいコードを書かなければいけなかった。

バッチ以外の普通プログラミング言語で書いたほうが、メンテナンスとか楽だろうと思ったけど、こういう時に言語の変更を提案しても100%却下されるから、黙って仕事をした。

メンテするのは俺じゃないしな。

 

何年か前にも、Windowsサーバーで使うバッチを書かされたことがあったけど、そのときバッチでは実現できない機能実装しなくてはいけなくて、Cで外部コマンドを書いた。

そのサーバーにはperlインストールされていたから、これPerlで書いたほうがいいですよって提案したけど、分かる人がいなくてメンテできないからって却下だったな。

技巧をこらしたバッチ + Cで書かれた外部コマンドの処理も、そこの人たちにはメンテできないだろうからどっちでも同じだろうって内心思ったけど。

 

その現場の人たちもPHPを使ってるんだから、(シンプルな)Perlなら、見れば分かるだろって思うんだけど、まあ、技術に興味ない技術者の未知の技術への恐れはすごいから無理なんだろうな。

2017-01-04

WEB博物館で働いてるけど、もうだめだ

31歳、WEB博物館学芸員大学の専攻はソフトウェア考古学

行ったことのない人のために説明しておくと、WEB博物館WEB150年周年を記念して設立された博物館で、WEB歴史を振り返るとともに

時代サイトデザインインタラクション体験できる日本唯一の博物館。古くは平面ディスプレイでのWEBページから、主流の空間3次元MRの流れを体験できることが売りなんだけど、

まだ2010年~2020年代の展示が用意できていない。暫定的に、展示パネルスクリーンショットを展示している。

この展示の担当者は俺。正直な所、ちゃんとした展示が開始できる見込みは立っていない。というのも、ソースコードはあるけれど、当時の技術背景がはっきりしないため、サイトを動かすことが全くできないためだ。

今時、平面ディスプレイなんて骨董品屋に行かないとお目にかかれないが、なぜか自宅の地下に眠っていた。

りんごマークが描かれた物理キーボード搭載の、所謂ノートパソコンってやつ。金属ボディでかつ核シェルターに入ってたので、核戦争の時のEMPにやられずにかろうじて残っていたみたい。これを高校生の時に見つけて以来、徐々に二次元派になっていった。レトロPCマニアという区分人間だ。

当時のソフトウェアを発掘、解析していくうちに、古い技術ソースコードを集めるのが趣味となり、大学ではソフトウェア考古学を専攻した。

大学時代にやってたことは、未処理地区に入ってストレージを発掘、残っている当時のソフトウェアを解析、当時のものを修復・復元などだ。

その後は技術博物館に勤務し、2年前にWEB博物館に移った。

ここでは研究員がそれぞれの時代WEB技術で作られた製作物を復元するプロジェクトに携わっていた。

で、俺の担当が暗黒の時代と言われた2010年~2020年代だった。

当時のブラウザパソコンに入っていた。

ソースコードは、骨董から譲ってもらった。当時のサーバークラウドサービス核戦争でほぼデータ消失しており、100年以上前ソースコードなんて絶望的だったが、ある企業が当時の中国ハッカー集団に抜かれたソースコードを保存していたストレージがたまたま現存していた。

問題は、それを動かせる環境構築だ。

開発に使われたJavaScriptという言語は、AIの解析によってバージョンが判明し、なんとか仕様が分かった。大学近代プログラミング言語史の授業を取っておいてよかった。

しかソースコード依存するパッケージが手に入らない。

とにかく、この時代フロントエンドの開発環境の移り変わりが激しく、それぞれのパッケージが使われていた期間がとても短く、バージョンも多様に渡ることから、正解のパッケージ現存していない。

この時代は、まだIT教育ほとんどされていなかった時代でもあり、ソフトウェアエンジニアほとんど独学で技術を身につけるのが普通で、そのためソフトウェアに対する価値観が多様であった。どんどん新しいパッケージが開発、公開され、そのため開発環境の移り変わりはとても激しく、特にフロントエンドは1~2年でガラリと変わっていたようだ。

すると、1~2年しか使われなかったパッケージなんて入っているピンポイント生存ストレージなんか見つかるはずもなく、全然開発環境復元が進まない。

バージョンパッケージが見つかることもたまにはあるので、それで代用を試みるけど、エラー文が多すぎてほとんど使えない。

当時の人は、やたら保守性にこだわっていたみたいだけど、こんなバージョン地獄でうまくやっていたのだろうか。

好きで始めた仕事だけど、もうこんな開発環境の構築だけで消耗する仕事は辞めて、普通WEBエンジニアになりたい。

2016-12-26

クラスを適切に抽象化するにはどうすれば良いのだろう?

すでにある一万個の機能について、うまく共通点抽出できたとしても

今後拡張する三万個の機能についても同じことが言えるのだろうか?

エンジニアとしては普遍的テーマだけど、職場帰りに素面でするような話でもなくて。

東証一部企業取締役社長より一時間近く時間をお借りしてしまたからこそできた話は、とても面白かった。

経歴がやばい社長ラリー・ウォールlikeな超々やばい人たちに囲まれて、選択した生存戦略

top1%ではなく10%の山を複数個持つことで、1%スペシャリストになれなくても凄さをわかるところまで追いつけるからと。

正しい方向で正しい努力をすることで、誰でも10%にはなれるけど、正しさの担保物事本質理解しないと得られない。

じゃなその本質とはどのようなことか?抽象化といった、プログラミング言語特性に寄らない普遍的設計思想だと。

程度は違えど、中高と進学校に進んで周りの理三行くような優秀なやつには一生勝てないなという挫折感と劣等感が漫然とあったから、

生煮えエンジニアから脱却する気づきを得られたことに感謝があった。

この歳になって、また頑張りたいと思えた。

でも、ごめんない、御社の下ではキャリアパス漠然しか見えないんです。

2016-12-20

プログラミング言語の本を10冊ほど買ってわかったこと

意識低い系人間にとっては、言語知識だけ身につけようとしてもモチベあがらないし、

身につかないということ

作りたいものができて、かつそれに必要な部分だけをネットで調べる程度で、最初は十分

したがって一番大事なのは自分が何を作りたいかというコンテンツニーズ部分を考えることであること

2016-11-28

http://anond.hatelabo.jp/20161127142031

低脳向けの実践プログラミング言語って言ったらPHPだよなあ。でもプログラマーなんて地獄しかない仕事からプログラミングやってる暇あるならコミュ力鍛えてメーカー品質管理とかそういう仕事を目指したほうが精神衛生上良い気がする

2016-11-27

http://anond.hatelabo.jp/20161127123509

プログラミングやったことのないエセ情報系ってプログラミング言語と言ったら真っ先にCを挙げるあの現象、なんなんだろうな

2016-10-13

英文法で迷ったら、一回プログラミング言語にすると良いよ

なんか知り合いが、↓を読んで、全く判らんが何だこれって言ってたんで解説したのメモっとく

英語が読めるようになるには英語を読むしかないが『日本人の英語』シリーズは読む価値あると思う - しいたげられたしいたけ

制限用法」と「非制限用法」は、「まず制限用法ありき」の用語

日本人英語シリーズは、

「a」と「the」と「何もついてない」名詞が、

全部違う名詞って話から入ってると思うんだけど(うろ覚え

ぶっちゃけ、「the」って言ってんのにそれが自明以外で説明がなかったらキレて良い。

と、英語話者は思ってるってのが、まず大前提にある。

なので、「制限用法」ってのは、

「オレの言ってる姉は、例のアレよアレ、あのアネよ」って制限するって意味がまずある。

で、そのうえで、そうじゃない「非制限用法」がある。

制限用法を、短文で理解するのムリ

そのまんま引用するけど、ここで「older sister(姉)」って言ったあとに、

なんかシカゴとか言ったな、姉の説明ねって、英語話者はボーっと聞いてたら思う。

  • 「こないだ姉ちゃん家行ったんだけどさ、シカゴに住んでる」

これを聞いた日本人は、どう思う?

『そんなん、聞いてる相手によって違うに決まってんじゃねーか』が正解。

  • (息子→父親)「こないだ姉ちゃん家行ってきたんだけど、シカゴの」
    • 父、母、姉、姉、息子の5人家族で、父親は姉が二人居るのを知ってる

この状況だと、父は「ああ、2人の姉のうち、シカゴの方だってのを伝えようと制限したんだな」って考えるわけだ。

まあ、考えないけど。どっちの姉ってああシカゴの方のねって理解するだけで。

これが制限用法ね。

この状況だと、友達は「ほーん、姉ちゃんシカゴに住んでんだ」と素直に思うだろう。

これが非制限用法ね。

おいおい、前提条件で制限用法か非制限用法か違うってナニソレ、とか思うだろ?

それが頻出である文脈によって判断する」ってヤツだよ。

(厳密に言うと、『日本人英語』での説明にも『前提条件無しで短文を読むなら』ってのが常についてると思って読まないといけないハズ)

プログラミングに置き換える

そうすっと、「どういう姉」かを伝えるやり方があって、

  • シカゴに住んでる方の姉貴を訪ねた。

って書いてあったら、日本人は「ほーん、じゃあシカゴに住んでない姉も居るのね」って考えるから

  • 「私には複数の姉があり、そのうち一人がシカゴに住んでいる。私はその姉を訪ねた」

って意味である、ってのが「I visit my older sister who live in Chicago.(コンマなし)」の解説なワケよ。

このまんまだと判り難いだろ?

疑似C言語あたりにすると、こんな感じ。

#define CHICAGO 1

int sister[3] = {45, 43, 41};
int who;

who = CHICAGO;
printf("%d", sister[who]);

まあ結果は43が出てほしいよね。

シスター配列を、CHICAGO指定してんのね。sister指定するのに使う変数who

ならこんな感じ

#define CHICAGO 1

int sister = 43;
int who;

printf("%d", sister);

who = CHICAGO;
printf("%d", who);

カンマで区切られてるから、『一回出力』してんのね。姉だ。

で、その後、どこ住んでるかの番号が出力される感じ。シカゴだ。

英語カンマは、「そこで一回出力してくれ」って命令だと思うのがコツ。

カンマが入っていないwhoは、ワザワザそれを伝えて限定しようとしてると読むべき。

まとめ

英語よりC言語の方が楽。

楽な言語に落とし込んで理解した方が早い。

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