次世代言語9[Haskell Rust Kotlin TypeScript Dart]
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語Part8[Haskell Rust Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1512137301/ これ以上は感覚のズレをお互いに調整しないと話が進まないだろうな
そして、その感覚のズレを調整をするつもりは俺にはないし
そっちも多分ないだろうからやはりこれ以上の話は無駄になるだろうな
認識の違いがこれだけもあるということが分かっただけでも良しとしておこう 会社でkotlinの勢力が拡大して飲み込まれるのは目前
やだよぉやだよぉ javaが積極的に言語に手を入れるようになったから
kotlinがcoffeescriptと同じ運命を辿るんじゃ無いかと不安を感じる
androidから放り出されない限り生きていられるとは思うが…… Goに他の言語の機能を追加したいって声はよく聞くけど
逆に他の言語にGoの機能を追加したいって声はあまり聞かないよね var導入するのにval導入しないJavaのおじいさんたちはゲェジなのかな? COM「反射性、推移性、対称性」
次世代「恒等射、合成、共変、反変」
型アサーションと型変換の宗教論争の原因はこれか AppGameKit Mobile Released on Android!
https://www.thegamecreators.com/post/appgamekit-mobile-released
https://play.google.com/store/apps/details?id=com.tgc.agk.mobile
金曜日、2018年3月2日にTGC NewsのAppGameKit News、
今日、Androidプラットフォーム上のAppGameKit Mobileがリリースされました。
今では、AppGameKit Mobileでどこでもどこでもアプリ、デモ、ゲームを作成して、「外出先で」コーディングすることができます。
この完全に無料のAppGameKitのバージョンでは、通常のAppGameKitスクリプト言語を使用してコードを作成してから、プロ
ジェクトをコンパイルしてデバイス上で直接実行することができます。このアプリにはデモとサンプルが付属しているため、新
規ユーザーはプログラミング言語の使いやすさを知ることができます。
カットダウンしたIDE内でアプリケーションをコーディングしてから、超高速コンパイラを使用して、プロジェクトをほぼ即座に実
行することができます。クラウドを追加して保存すると、あなたのプロジェクトをTheGameCreatorsのウェブサイトにアップロー
ドして、プロジェクトを安全に保護したり、Windows、Mac、Linux版のAppGameKitでコーディングを続けることができます。
AppGameKit Mobileは、デスクトップ版の多くのコマンドへのアクセスを提供します。最も重要なのは、ゲーム作成のためのす
べての主要なコマンドです。
・3Dグラフィックスと3D物理
・2Dグラフィックスと2D物理
・レンダリングコントロール
・サウンド&ミュージック
・ユーザー入力
・ファイルI / O
・センサー
カメラと写真のアクセスでは、あなたのデバイスから画像メディアをインポートしてから、これらの画像をアプリケーションのス
プライトまたはテクスチャとして使用できます。
今すぐ無料でダウンロード! >>222
サーバーサイドだとC#/.NET Coreも浮上してきたしな
言語の筋が良かったから期待したけど、結局一過性の流行で終わりそう Kotlinは要するにBabelだろ
JavaがKotlin相当に進化する頃にはJava 1000くらいになってるだろ
それを実行できるAndroidはバージョン100000くらい
じゃあJava 6までダウンコンパイルできるKotlinだよねって話
でもReact Nativeに殺されるんだぜ、嘘みたいだろ? >>219
違いがあるのはいいが
コードの読みやすさで静的動的で比較もいいけど、
テストコードあるかないかで比較したものも載せて欲しい。
型があった方が読みやすいコードもたくさんあるのは事実だけど。 コードリーディングという意味では型情報はありがたい。でも引数に何を入れればいいかLAPACKくらいしっかり書いてあるとなお良い
しかし関数名の直後にドキュメントが長々と書いてあってどこからコードなのかよくわからん奴は嫌い >>234
比較って言ってもこれは独断と偏見に満ちた個人的な印象値だぞ…
参考にして欲しくて書いたわけじゃなくて認識の違いを明らかにするために書いたものだし…
あと、静的動的どちらでもテストは書くんだからテストがない場合と比較することに何の意味が…? なるほど話が噛み合わないわけだ。
俺としては別に動的
本当にテスト書いてんのかなってとこのが重要だと思ってたわけだが、
動的か静的ってとこにそんなに興味があったんだね。
その部分に対してはどっちでもいいわ。
逆にテストするのしないのって話から話題をそらすための抗弁になりやすい印象が強いので
あんまり関わりたい議論ではない。 状況が変わったのにまだ気付いてないんだな
だれも嘘をつかない性善説を前提に読みやすいとか読みにくいとか言う時代は終わった
今は嘘を教える人間を回避することが最重要
正直でありさえすれば読みやすさは不問 嘘うんぬん以前にガイジなせいでウンコードまみれなペチPoorさんはどうすればいいの? 嘘ねえ……そういえば昔知りもしない言語の嘘八百ばらまいてた人いたなあ >>240
phpディスってる人も多いけど、タイプアノテーションついてだいぶ改善されつつあるんじゃないの。結局仕事にはphpも多いからlinterとか環境整備して開発しやすい状況は作っておきたい タイプアノテーションだのlinterだの、PHPerがいらねーって騒いでたものばっかりやん >>237
いまいち話が掴めないんだが、テストを書くのが面倒だからイヤって奴はクソって言いわけ?
俺はできればテストは書きたくないよ。面倒だし。でも書かないわけにはいかない
だったら、テストは書くがテストを書く量を減らしたい
動的型より静的型のほうがテストを書く量を減らせそう…と考えている。
実際に減らせるかどうかはデータを取ってみないと何とも言えないけど
少なくとも動的より静的のほうが減らせるという意見はあってもその逆はない
最低限のテストさえも書こうとしない奴は論外なのでそっちの話はしたくない 静的型派の奴はテストは書きたくないって意見は俺以外にもいると思うけど
動的型派はテスト書くのは面倒だとは思わないの?
それを言うと、静的型派の連中は型を書くのは面倒だとは思わないのか?とか言われそうだが、
静的型派の奴らは型安全は保障してほしいとは思いつつ型を書くのが面倒だとも思ってるよ
だから型推論なんかを導入して型を書かずに済む方法を模索している >>250
動的型の連中の大半は現実にはテストなんか書いてないよw
常識的に考えて、たかが型書く程度のことを面倒臭がる奴がテストなんか書くと思うか?
全くもって机上の空論よ フォローしとくと、そもそも動的型で書かれるシステムって簡単なCRUDだけで構成される単純なものが多いので、いちいちテスト書くのは大袈裟
一般に、静的型での開発では動的型に比べて遥かに多くの工数をテストに費やしてるよ 型すら理解できないやつが、インプット・アウトプット理解してテスト書けるわけないだろ
ペチプァどもが書いたプロダクト見ろよ >>249
誤字訂正
訂正前>テストを書くのが面倒だからイヤって奴はクソって言いわけ?
訂正後>テストを書くのが面倒だからイヤって奴はクソって言いたいわけ? ペチバカの話は他でやれ
新規で採用することはまずありえないし、COBOL並の過去の遺産なんだから
次世代言語スレが穢れるわ Qt使った時、単体テストが簡単にかけたので書いてたんだけど、まあ確かにテストは良いものだよね。
俺が思うに簡単に書けるようになっていないのは、もはや欠陥製品と言っても良いのでは。 Javascriptも少し勉強してみたんだけど、あれはとても難しいものだな。
頭がこんがらかる。
GCがあればメモリーリークしないみたいな考えは間違っているだろうな。
GCがあるからリークする。
そんな風に感じましたよ私は。 >>255
COBOLの開発ってかなり厳密にテストするぞ
PGの頭の品質はともかく、開発プロセスまで含めた品質はPHPと比較するようなものではない PHP案件って負の遺産・ゴミ扱いで、下請けに押しつけられてるイメージしかない
なんていうか、惨め PHPがゴミだとは思いませんね。
ゴミ言語であることは確かですが、ゴミ言語なりに居場所を見つけて素晴らしい成果を挙げています。 次世代言語について話すのであれば、C++2aは欠かせないでしょう。 Boostの逆襲もすでに始まっていると思いますね私は。
C++11以降、Boostは肩身が狭くなってる感がありました。
ところが何ということでしょう。
Boostはさらに先に行ってしまったのです Networking TSがいま人類に必要なもの。 phpで書かれたサーバサイト置き換えるとしたらなに使うの? いまはPHPの代わりはないだろな。
NodeはPHP以上に危険なものだし。
C++でサーバサイドを書くと異常に早くなる。
これはC++が早いからではなく、省メモリーだからじゃないだろか。
でも環境が整備されていないから使うのに苦労が多い。 Javaはあらぬ方向に向かっているからいずれ消えるだろう。 C++があるのにDやGoを使う意義が見いだせない。 日本は国家戦略としてC++に取り組むべきではないだろうか。 俺の感じでは、C++はネットでこそ強みを発揮できるのではないだろうか。 俺もそれが言いたかった。
Go大好き人間に聞くべき。 >>250
>最低限のテストさえも書こうとしない奴は論外なのでそっちの話はしたくない
まあ残念ながらこういう輩が普通に静的、動的がどうのといってるから故の
主張なんだけどね。
型について明示することに関して個人的には別に面倒ともなんとも思ってない。
コードが増えてきて型を分類、整理するのが大変なだけで。
主に c/c++ でアルゴリズムや数値計算の仕事だからかも知れんが、
際どい数値例のテストコードなんかのが百倍くらい役立つわけよ。
>テストを書くのが面倒だからイヤって奴はクソって言いわけ?
まあ端的にいうとこうなる。
プログラマは怠惰なのは悪くないとかバカみたいな格言を持ち出してでも
言い訳してしないからね。
それくらいテスト嫌いってのは根深いと思う。 動的言語でテスト書いてもあまり役に立たないんじゃないか。 c++でサーバサイドを書くのってかなり特殊例だよな。どうゆう用途で使ってんの? たまたま書いてみたら異常に早く安定してるので、これはもしかして?←イマココ。 BoostにHTTPやWebSocketが入ったんだよな。
これは新時代の幕開けでは。 C++でサーバーサイドを書く時代がやってきたのは間違いない。
誰が先頭を走るのか。
それだけだろう。 今あるものをC++に変える必要は全くないが、今から新しい世界を切り開いていくものは、C++で始めたほうが効率よいだろう。 テンプレートエンジンはDOMが遅いから必要になるもので、もしもDOMが早ければ必要性は減るのかもしれない。
そういう観点から設計されたXML/HTMLライブラリがあっても良いのかもしれない。 C++はとにかく早くて省メモリーなので、使わない手はない。 conceptもimportも言い出してからずっと仕様に入らない言語が何だって? >>296
実装したことのない馬鹿が言い出したことはスルーするのが吉 サーバーサイドC++を始めるなら今です!チュドーン。 小資本が大資本と戦う武器としてC++は良い選択になりえる。
時は来た。
今は良いタイミングだ。 C++が速いのではなく早いならこのスレでは時期尚早でもう話すこと無いな オレもNGするか…さようならC++、信者に恵まれなかった言語よ Webサービス開発に絞った話な。
リリースの速さ必要ならRoR
堅さが必要ならJava, Scala, Go
これからはインフラ親和性も必要だから、サーバレスならGo, Python, Node
RoRの劣化コピーのオレオレFWで内ゲバやってるPHPは、もう選択肢にすらあがらんだろ
まともな審美眼と技術力を持ってればね 危険性を理解したうえで使ってるのかと思ったらそうでもないんだな。 私が思うに、決定性を持つアルゴリズムで解析ができないものはすべて危険であり、ネットワークでは避けたほうが良い。
ここに反論するものはいるだろうか? 一方で、決定性を持つアルゴリズムは様々な理由をつけてネットワークから排除されてきた。
これはおそらく大衆の無知につけ込んだ出来事に違いない。
おそらく、決定性と言われても何のことかわからない人は、これを読む者の中にも多いだろう。
とりわけウェブエンジニアには無知が多い。
無知にも務まる時代から、無知でなければ務まらない時代へ。
そんな感じすらある。 現状でウェブ上のすべてのものが危険であり、容易にハックされ得る。
狙われた瞬間降参するしかないのだ。
原理的に防ぐ方法が無いからだ。
SUNとMSはその点を熟知しており、ルールを変えようとするここ試みがあった。
この点に気が付いたものは少ないだろう。
そして試みは打倒された。
なぜそのような事が起こるのか。
それは銃を売るものも必要、そしてほとんどのものは自分は打たれないと考えるからであろう。 まぁ、nodeオンリーだと確かに辛いところは出てくるな。
JSでQRコードの画像作るロジックが言うほど重くないんだけどそれなりに時間かかる処理になってて、そのせいで全然パフォーマンス出ねえって思ったことある。
結局そこはGoで書いたQRコード作るだけのサーバにリクエストすることにした。
タイトなループが書けないは最初から考えとかないと辛い。 >>313
QRコード画像を作る処理ですら重いんかnode.js。 まあ、技術者にありがちな典型的な「やりたかっただけ」だろうな
自分が一番よく分かってると思うが、辛いと思い込もうとしてるだけで、もっとシンプルでメンテや運用コストの低い解決方法は間違いなくあったはず node_modulesの中を見るとゲロを吐きたくなる >>314
重くはないが、シングルスレッドなので詰まる。
cluster使ったところで、ワーカー数使い切る。
npmにモジュールあったから、へぇと思いながら使ったらこうなった感じ。
やりたかったからと言うより要件だったから、かな。
>>316
クライアントは台数凄いけど基本IE8のエンタープライズモードという悲しいイントラネットなのよ。
ブラウザは無力と思わないとどうにもならん。
そいつらがリアルタイム更新したいとかで、万台のlongpollをどう捌こうと言うところで白羽の矢がたった感じ。
それ自体は良かったよ。
node_modulesはせめて圧縮できないかねえと思ってしまう。 >>318
ワーカー数使い切るってどういう事?
基本cpu数で回していくもんじゃないの? ■ このスレッドは過去ログ倉庫に格納されています