「Javascript」を含む日記 RSS

はてなキーワード: Javascriptとは

2017-05-28

敬愛する最高指導者キム・ジョンウン同志

国防科学院で組織した新型半航空迎撃誘導兵器システム試験射撃をご覧だった

 

朝鮮労働党書記であり、朝鮮民主主義人民共和国国務委員委員長であり、朝鮮人民軍最高司令官であるわが党と国家軍隊最高指導者金正恩同志が国防科学院で組織した新型半航空迎撃誘導兵器システム試験射撃をご覧あった。

黄兵書同志、李ヨウンギル同志、膝鉄同志、ギムグァンヒョク同志、李ビョンチョル同志、キム・ジョンシク同志、ジョンスンイル同志が同行した。

敬愛する最高指導者同志を現地で槍し同志、ジョンイルホ同志をはじめとする国防科学院と軍需工場幹部科学者技術者たちが迎えた。

朝鮮労働党の新しい並進路線の旗のもとに、世界を驚か泣くの奇跡で、より大きな奇跡を抱いてきて万里氏の速度で力強く前進する国防科学幹部科学者技術者は、わが党の軍事戦略思想に合わせて作戦配置された新型半航空迎撃誘導兵器システム戦闘的性能と信頼度検証し、より近代化、精密化するためのために目的を置いて半航空迎撃誘導兵器システムテスト射撃を再び行った。試験射撃は火に私たちの国の領空侵犯する敵公衆目標を打撃消滅するもの仮想して状況を造成して、任意の方向から飛んでくる各がした空中の目標を検出し、迎撃する方法で行われた。

敬愛する最高指導者同志は監視所で試験射撃進行計画の報告を受け射撃命令を下し時であった。各がした高度と速度でレスプする敵空中目標に、仮想無人機ロケットターゲットが出現しよう天地を震撼する爆音サウンドと雷のようなブルジュルギが空を切って、連邦飛ん目標を単にドクた。

敬愛する最高指導者同志は成功新型半航空迎撃誘導兵器システム試験射撃を見ながらあの完成された半航空迎撃誘導兵器システムをみると、私たち将軍考えがさらに切実になると、低武器システムは、開発の最初足跡から将軍様一つ一つ品かけ導いオシドンユボクジャ武器システムと、生涯の最後の時期まで国の半分の航空防御能力の強化のためにあらゆるロゴと心血を捧げ来ら偉大な将軍様が完全に成功今日をご覧だったらどのよう良かっだろうと熱く言わ希望であった。

敬愛する最高指導者同志は人民軍指揮メンバー国防科学院の幹部に昨年より迎撃誘導兵器システム目標発見チュバ能力が大幅に向上し、衝突の精度も高まった、昨年に現れた一連の欠陥も完全に克服されたし、合格評価する、作戦能力が徹底的に検討された私の武器体系をヒイラギ生産持ち出してきた国の森林をなすようにすることにより、公衆優勢論、武器万能論を提唱する敵の制空権妄想を完全に制圧粉砕して捨てなければならないとおっしゃった。

敬愛する最高指導者同志は、そのいくつかの敵空中匪賊神聖私たち領空をあえて侵犯しないように国の半分の航空防御能力を飛躍的に強化と次の世代の半分の航空迎撃誘導兵器システム研究開発事業も早急に並行していかなければならないと強調しながら、私たちの式の近代的な半航空迎撃誘導兵器システムの発展戦略と関連した綱領課題を明らかにしてくださるであった。

本社政治報道の半分

http://www.rodong.rep.kp/ko/

javascript:article_open('index.php?strPageID=SF01_02_01&newsID=2017-05-28-0001')

2017-05-25

何でjavascriptとして処理できない拡張書式のコードを「.js」で保存する

コンパイル前はjavascriptとしては動かないコード

コンパイル後はコンパイル前と同じ「.js拡張子

合理的理由って、なんかあるの?

2017-05-24

C#連想配列がショボい

なんでこんなにショボいのに使われてるんだ?

PHPとかjavascriptみたいな多元連想配列が使えなくて意味分からん

2017-05-23

会社JavaScriptのことJavaって略したりスプリクトと言うやつがいて、何度言っても是正しない。

うそういう人だと諦めたが、こんなITリテラシー低くてもこの業界で食っていけるって、やっぱITって魔境だなと再認識

2017-05-22

はてなのみなさんって

JavaJavaScript混同したら怒るくせに

痴漢痴漢冤罪を同一の問題だと考えている節があるよね。

2017-05-18

痴漢冤罪問題痴漢魔のせいだと言っているバカどもへ

結論から言うと別問題だ。

痴漢魔と痴漢冤罪魔を同列に語って問題の筋を逸らそうとするんじゃない。

痴漢が居るから痴漢冤罪が起こるんだ、痴漢そもそも全て悪いんだ」と言っているバカどもへ言いたいことがある。

まず痴漢痴漢冤罪は以下の通り分けられる。

また、罪を犯す目的が違う。


お前らJavaJavascript を 同列に語ったらブチ切れる癖に、目的が270度ぐらい違う痴漢痴漢冤罪という全然別物の問題を同列に語るんじゃないよ。

いか痴漢冤罪っていうのは行政司法に対するハッキングだ。

痴漢案件なら女側に肩入れするゴミ司法起訴されたら拉致監禁拷問で何がなんでも有罪にするクソ行政のあわせ技ってだけなんだ。

これは別に痴漢じゃなくても良い、他の罪状でも似たような構造なら冤罪は量産されるはずだ。

痴漢はただ単に女側に強すぎるから下衆共が痴漢冤罪を利用しているだけなんだ。

痴漢がなくなり痴漢冤罪を生み出す仕組みが無くなったら下衆共は次のやり方を探すだけだ

痴漢がいようがいまいが人様を出しにして金を盗る下衆は消えないんだ。

からこそ、少しでも手段を封じて新たな手段を得られない雑魚から減らしていくしかないんだ。

もう一度言う、痴漢冤罪痴漢が生まれ犯罪じゃない。

法の抜け穴を使い、人様から金と名誉を奪いたがるカスが居るからまれ犯罪なんだ。

2017-05-14

http://anond.hatelabo.jp/20170514134817

「。」は";"のかわりだろ?C++, Java, JavaScript、全部、;いるけど、モダンプログラミング言語ではないのか?

http://anond.hatelabo.jp/20170513175715

JavaScriptフロントエンドか、JavaAndroidあたりが需要が多くて潜り込むチャンスが多いんでない?

ただ、無職のままでってのは厳しいな。そんなにすぐには習得できないしな。

中途である以上、ある程度の実力は期待されるだろ。

2017-05-12

製造業新卒で入って数年経過したけどもうダメかもしれない

新卒製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分能力絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミング経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドVBAから、Rやら自社製品の解析用環境の割と珍しいタイプスクリプト言語など(特定されそうだからぼかすけど。)

とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手作ってみたりして提案していた。

物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。

この辺で気付いたことだが、製造業ITリテラシーは驚くほど低い。製造業一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。

なんせまともにプログラムを書いたことが無い新人半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。

ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。

(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)

2年目に気付いたのは、弊社エンジニアITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。

製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。

無骨だが使いやすイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。

から逆に言えば下々の人間コピペでなんとか恰好を整えられるのだった。

彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。

私はそれに感動した。なんせWebスクレイピングみたいな方法他人が社内プラットフォーム社内WIKIに上げた報告をまとめたり、製造データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。

それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。

何にせよそういったもの一気通貫自動化できるポテンシャルがあると感じられた。

SQLjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しか管理IT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータプロジェクト人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)

自分ドメイン知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果確認の為に数十億行のデータ活用された。彼らの力が無ければ常識的時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般エンジニアスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。

そういう時に起ることは不要冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署相手側にも存在するということだ。

まりどちらにもある部署統合するか一方を無くすかという戦争が始まるのだ。IT例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)

一方で製造業の本懐である製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存顧客への説明必要からだ。

そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか

(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)

今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である

旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフ簡単に表示され、A社側のお偉いさんからも好評を得ていた。

だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。

そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉

増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」

もちろんhtmljavascriptphpRoRも一行も書いたことが無いのが当時の私である

果たして旧A社のプラットフォームはB社のプラットフォームデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。

そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。

クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベル筆舌に尽くしがたいものがあるが、

反面教師だと思って耐える日々だ。

最近分かったことは旧B社のバックエンドスクリプトデータを引っ張るついでに意図的に旧A社のプラットフォーム攻撃しているということだ。DDoSとまでは言わないが、悪意100%である

いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォーム不安定かつ重くなることを意図しているらしい)

旧A社から継続されてる業務はまだそこ使ってるんですけど・・・

それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。

旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングレベルが二回りぐらい違うように見える)

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

2017-05-09

JavaScript簡単SPAフレームワークってありますか?

勉強が不得意な職業プログラマですが、WindowsアプリSPAに作り替えることになりそう。

プロジェクトメンバー積極的技術習得するような人はいないので、簡単フレームワークを探しています

↑に近いようなフレームワークありませんか?

2017-05-08

mizchiとかerukitiとかはまだまだ小物

現状最強の天上人id:megumin1

http://b.hatena.ne.jp/megumin1/

phpJavascriptJavadisするくらいの人間ならよく居るが同時にRubyGoDisるところまでくると常人離れ感がいやでも目に付く

彼 / 彼女は一体どんな言語を至上とするのか、初心者に何をすすめるのか気になって夜も眠れないほどである

http://anond.hatelabo.jp/20170507200847

2017-05-07

Atomエディタ日本語入力確定前のカーソル移動が見えない

持ってる人はやってみよう。文節区切りを変え隊とかひらがなにゅうりょくしてryときのにゅうりょくみすけしたいときとかのどうさだ
なんでこんなことになってるのかと思ったら「AtomはChrome+JacaScript+CSSなのでブラウザ上のJavaScriptから読めないものはできん」ということらしかった。
Atom絶妙に重いのは中身Chrome(正しくはChromimum)だからか!なるほど!畜生
日本語利用を片隅に置いて作られたものじゃないから仕方ないのかねコレも

フレームワークFWって略すのやめろ

主にJavaScript使いどもがフレームワークの乱立の為にいつしか略すようになったこの言葉

他の言語国民は大困惑よ。

お前ら無法地帯国家の悪しき慣習を持ち込むな。

2017-05-01

http://anond.hatelabo.jp/20170501085956

JavaScriptDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔建設に耐えうる言語でもない。」

ほんとこれなんだよなあ。TypeScriptへ徐々に移行するしかないと思うけど、TypeScript廃れて来てるの?つい最近Googleが社内で公式採用したって読んだばかりだけど。

フロントエンドが嫌い

ウェブフロントエンド技術進歩と興亡の速度には目を見張るものがある。

browserifyが生まれGruntが生まれ、Gulpが生まれた。

そしてその全てが死んだ。

Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。

一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。

そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプター自称し最新技術のケツを追いかQiitaにクソを垂れ流す彼らこそ我らがイケイウェブフロントエンジニアである

最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれたて技術知名度は彼らにより上げられる。

それはやがて大きな同調圧力空気となって流行った技術を押し流す。

さて、少し話は変わる。

かつては栄えた技術が滅び、消え去れども残るものはある。

書いてしまったソースコードと拭いきれない遺物と化したクソの塊だ。

ウェブサービスはただ作って終わりではない。その先にあるのは長く続くメンテナンスだ。

少し例を挙げたい。あるところにイケイウェブエンジニアあなたがいたとする。

ある日あなた上司からあるウェブサービスを作ってほしいと頼まれ、それを引き受けた。

さて、サービスを作るにあたりあなた使用する技術を選定する。イケイウェブエンジニアあなたはとても流行に敏感だ。勿論jQueryを使い泥臭くDOMを弄くり回すことなどあってはならない。

あなたESの最新規格に準拠したコードを書き、Flowtypeで静的型検査を行い、Angular4を使うことにした。

勿論そのままでブラウザ動作しないためWebpackとBabelを駆使してトランスパイルする。

数週間後、めでたくサービスは完成した。

さて、問題はここからである

一年後のある日、あなた上司に呼び出された。

曰く、そのサービスに新たな機能を追加して欲しいのだという。

あなた脳内で試算する。時間と手間は掛かるが可能だと判断したところで、はい、と答え一年ぶりにプロジェクトソースコードを開いた。

ここであなたはあるものを目撃、頭を抱えることになるだろう。

それは何か。陳腐化した一年前のトレンド技術の塊である

一年後の未来世界では Webpack2 など既に新しく現れた技術に叩き潰され醜く断末魔の鳴き声を上げる死に瀕した哀れなヒキガエルの如き存在だった。もちろんAngular4はもう誰も使おうとはしない。

もちろんあなたもそれらを過去存在へと葬り去った新技術に首ったけだ。

さて、ここであなたがとれる戦略は次の2つだ。

一方は、クソだクソだと悪態を付きながらもはやメンテナンスもされていないクソプラグインの体系化されていないクソドキュメントとにらめっこをしながら古臭いクソの塊と付き合っていくこと。

もう一方は、新たに聳え立った最新のクソの塊に無限移植を続けることだ。

前者を選んだあなた時間が経つごとにまともな情報を得られなくなり、やがては身動きが取れなくなった段階でようやく最新技術への移植を考えはじめる。しかし、その頃には膨れ上がった旧時代のクソはそんなことを容易に許してはくれやしない。

さて、後者を選んだあなたを待っているのは無間地獄の如き最新技術の濁流だ。それに揉まれながら一年ごとに、古臭きは悪だと声高に叫びながら無限移植作業を行うことになるだろう。

どちらにせよ待っているのはクソの如き地獄である

しかし、どれほど技術が移り変われど変わらないものもある。

あなたがクソと罵り選択肢からも除外されたjQueryである一年後の未来であってもjQueryはそこにあった。もちろんクソと野次られながら。

クソレガシーこと枯れた技術の利点はそこにある。

勿論jQueryを使った品質の低いクソコードはクソだ。

けれども一年前のあなたjQueryを使ったコードが読めるし、今のあなたももちろん読める。一年後のあなたは疎か、三年後のあなたの後継ですらも (泥臭くDOMを弄るコード閉口しながらではあるが) やはりあなたの書いたコードを読めるだろう。

そもそもからしてウェブフロント倒錯している。

JavaScriptDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔建設に耐えうる言語でもない。

前提からして倒錯したクソウェブフロントは一度無に還るべきだし、私はそんなクソウェブフロント界隈が大嫌いだ。

この意味不明なクソポエムも憎むべきクソの一端である

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

結局C#でやるか・・

JavaScript ローカルファイルの読み込みはセキュリティがどうの

なでしこ しこしこ

HSP

 

WindowsちんまいGUI作りたいとき選択肢があるようでないのがうざい

http://anond.hatelabo.jp/20170415113018

ネットで動的型派に静的型のよさを説明して理解されたためしがないんで説明はしないけど、

Python宣言が入る

Ruby 将来のバージョンで型チェックを入れると表明

PHP宣言が入る(型チェックは実行時だけど、ツールは静的チェックも可能)

Javascript googletypescript公式言語指定FBflowを公開

Go、Rustなどの新興言語はたいてい静的型を採用

などなど、世の中の趨勢は静的型言語

世の中の人は静的型がよいと思ってる。

http://anond.hatelabo.jp/20170415105513

javascriptがまともになったのってES2015からじゃん。

ES2015も素の状態だと型チェックとかないしさ。

型チェックっぽいのがついたPHP7のほうがちょっとましな感じ。

http://anond.hatelabo.jp/20170415104722

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

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

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

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

はやった理由だと思う。

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

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

PHPってなんで流行るの?

よく知らんけどあれってPerlだよね

Perlってめちゃくちゃ書きにくくない?

C言語から始めていろいろ言語は触ったけど、JavaScriptが一番書きやす

サーバでもJavaScriptクライアントでもJavaScriptにしてるからもうJavaScriptしか書けなくなった

VBエクセルに付いてるからたまに使うくらい

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん