次世代言語Part7[Go Rust Swift Kotlin TypeScript]

**デフォルトの名無しさん** · 2017/10/19(木) 17:51:38.66

文字数制限きついので改題
スレタイ以外の言語もok

前スレ
次世代言語議論スレ[Rust Kotlin Haskell]第6世代
http://mevius.5ch.net/test/read.cgi/tech/1503924817/

**デフォルトの名無しさん** · 2017/10/27(金) 23:45:39.75

>>211
ちゃんと具体的にコードを書いてくれて議論しやすくしてくれたのはありがたい。
tree を rust で実装しろって言われたら 10 人中 9 人は Box と Option を
使ったそういう構造体作ると思う。

**デフォルトの名無しさん** · 2017/10/27(金) 23:47:59.22

>>214
Pointの例に限って言えば同意できないな
大量の小さなベクトルを扱うような場合、構造体を使うより各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
C++系の言語で行持ちの方が好まれるのは、一番の理由は言語の性質上そのほうが扱いやすいからに過ぎない
最近は列指向DBなんかも普通に使われるようになって、データの列持ちが見直されつつある今、
列持ちのデータ構造をスマートに扱える言語があってもいいと思うわ

**デフォルトの名無しさん** · 2017/10/28(土) 00:01:16.09

>>229
Fortran, Juliaのことか？

**デフォルトの名無しさん** · 2017/10/28(土) 00:03:34.74

>>227
>無様なHaskellのコード

908 ：あ：2017/05/31(水) 09:15:21.09 ID:dc+IbjjD
>>905
具体的に上げろと言われてもなぁ。
<T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。

これのことじゃないの？（適当）

**デフォルトの名無しさん** · 2017/10/28(土) 00:24:09.93

てか
>>229
> 各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
これってどういう演算の時にそうなるんです？

**デフォルトの名無しさん** · 2017/10/28(土) 00:46:39.85

Rustアンチくんはペチパー

はっきりわかんだね

あ · 2017/10/28(土) 00:51:22.50

>>219
許せないんじゃなくて、健全ではないよね、と。
なんせ改善せずとも、自分があたかもまともであるかのように思える一番楽な方法だし、進歩もない。

>>222
ホントに。好きなら好きで良いんだよ。
バカで比べる事ができないなら素直に信者してりゃ良いの。
狂信者が戦争起こすような真似をネットでまでやらんでもよろしい。

>>227
>>231
しかも、結局すごくひねり倒してグダグダ言った割に、最後まで動くコードが出てこなかったんだけっけ。

**デフォルトの名無しさん** · 2017/10/28(土) 00:58:11.14

>>232
分かりやすいのはパディングが入るケース
ループのベクトル化もスカラー配列の方が効きやすいらしい

**デフォルトの名無しさん** · 2017/10/28(土) 01:07:07.63

>>235
うーむ……
もしかしてPoint3Dのベクトルに一括して行列を掛けたりする状況を想定しているのか？

**デフォルトの名無しさん** · 2017/10/28(土) 01:09:54.95

そういう状況でもない限りそもそもボトルネックにならないからな

**デフォルトの名無しさん** · 2017/10/28(土) 01:16:42.42

>>211
試行錯誤の過程でアルゴリズムぶっこわれるってのはよくあるが、そうならないためにテストコードがあるっちゃそうだから、
明確な欠点とは言えないかもな

まさかスレに貼るサンプルコードにまでテストコードつけろなんて言えねえし。

**デフォルトの名無しさん** · 2017/10/28(土) 04:09:54.80

>>234
ドアの奴なかな？
あれならHaskellのコード出てただろ
いつまで言ってるんだ

**デフォルトの名無しさん** · 2017/10/28(土) 09:04:44.68

コード出すという行動ではなく
コードが正義っていう知見への承認とか共感が欲しかったんじゃないか
だから行動だけでは駄目

あ · 2017/10/28(土) 09:19:59.46

>>239
じゃ、いつまで、スレタイにはHaskellが、って言ってんだよ(笑)

**デフォルトの名無しさん** · 2017/10/28(土) 10:25:15.53

なぜ私達は Python から Go に移行したのか
https://frasco.io/why-we-switched-from-python-to-go-19581e27de7c

**デフォルトの名無しさん** · 2017/10/28(土) 10:45:03.08

よくあんな無様な知ったかぶりしといて人のこと無様とか言えるな

**デフォルトの名無しさん** · 2017/10/28(土) 11:06:53.69

これだからペチプァは

あ · 2017/10/28(土) 11:20:03.53

>>243
自分が無様だと思ってる奴に無様だと言われるのはさぞ辛かろうが、
俺が無様なのとHaskell書いたやつが無様なのは別の事象で、

同時に無様でありえるんだから、その指摘はナンセンスだろ。
その理解力でHaskell最高！と思ってるのも面白いな。Maybeの真髄だろ。事象を整理するのは。

**デフォルトの名無しさん** · 2017/10/28(土) 11:28:14.87

なんだこいつなんで俺がHaskell 信者みたいな前提で煽って来てんだ

**デフォルトの名無しさん** · 2017/10/28(土) 11:36:54.21

もう最新規格のFortranで良いよ

**デフォルトの名無しさん** · 2017/10/28(土) 12:01:24.16

Fortranに第一級関数がついてimplicit noneがデフォルトになってinterface文をもうちょっと短く書けるようになって引数の型指定をCみたいに書けるようになって
配列の大きさ指定の関数に組み込みでない関数を使えるようになってgfortranのbind(C)周りのバグを解消してくれたらFortranでいいよ

**デフォルトの名無しさん** · 2017/10/28(土) 12:13:39.86

西京言語PHPを使えばいいじゃん（いいじゃん）

**デフォルトの名無しさん** · 2017/10/28(土) 12:20:24.44

PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい

**デフォルトの名無しさん** · 2017/10/28(土) 12:31:15.99

mod_perlとだったら大して変わらん気がする

**デフォルトの名無しさん** · 2017/10/28(土) 12:33:46.88

＞PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい

キリッ

ｗｗｗ

**デフォルトの名無しさん** · 2017/10/28(土) 17:09:33.99

皆がCGIという共通ルールを守る中
汎用性のない独自実装をしたphp

**デフォルトの名無しさん** · 2017/10/28(土) 17:24:26.31

まあ今更Perlとかって選択肢はないからね

**デフォルトの名無しさん** · 2017/10/28(土) 17:31:59.24

FacebookはなんでPHP推しなの？

**デフォルトの名無しさん** · 2017/10/28(土) 18:04:40.73

PHPをC++に変換するんだっけ
むしろJavaをC++に変換するのを誰もやらない理由を知りたい

**デフォルトの名無しさん** · 2017/10/28(土) 18:12:54.21

>>256
Javaは事実上サーバーでしか使われていないので、
全くメリットがないから

**デフォルトの名無しさん** · 2017/10/28(土) 18:27:47.92

phpのがサーバでしか使われてない印象
どっかで使ってる?

**デフォルトの名無しさん** · 2017/10/28(土) 18:32:36.63

>>254
別にCGIはperlでなくてもいいだろ
プロセスを起動するインタフェースのお約束だよな
perlは文字列処理が得意だっただけで

**デフォルトの名無しさん** · 2017/10/28(土) 19:01:45.06

PHPの特徴ってインスタンスの生存時間が極端に短い。ってこと。
request受けてからresponse返すまで。
だからGCが貧弱でも何の問題もないし。糞汚いコードでもメモリリークが問題にならない。

**デフォルトの名無しさん** · 2017/10/28(土) 19:13:14.28

>>256
GCC
http://news.mynavi.jp/news/2016/09/08/290/

あと、AndroidはJavaじゃないからノーカンなのかもしれないが、
以前はネイティブに全部変換していたのをやめた

**デフォルトの名無しさん** · 2017/10/28(土) 19:51:46.92

>>255
むしろPHPを積極的に潰そうとしてる印象なんだが
クソ挙動しかしないウンコ製造機PHPを潰すためにHHVMは作られたんだぞ

**デフォルトの名無しさん** · 2017/10/28(土) 20:44:53.33

>>255
最初は何も考えずにお手軽に作れたからPHPだった
大きくなりすぎてから管理コストを考えてノロノロと移行を企てている
そんなとこだろ

**デフォルトの名無しさん** · 2017/10/28(土) 21:07:01.93

それ以上ペチパーの心のより所を叩くのはやめてやれｗ
彼ら、憤死してしまうでｗｗｗ

**デフォルトの名無しさん** · 2017/10/28(土) 21:37:38.45

>>260
言ってること滅茶苦茶だな

**デフォルトの名無しさん** · 2017/10/28(土) 21:57:38.28

伝えようとすれば滅茶苦茶
隠そうとすればバレバレ
だから型情報とか一生懸命伝えようとする言語が報われない

**デフォルトの名無しさん** · 2017/10/29(日) 03:03:23.28

>>242
go 好きな人ってまともすぎてつまらんな。

**デフォルトの名無しさん** · 2017/10/29(日) 05:05:09.88

>>261
ARTは全部変換なんてしてない
元からJITとAOTの複合

**デフォルトの名無しさん** · 2017/10/29(日) 05:05:25.10

>>267
きんも

**デフォルトの名無しさん** · 2017/10/29(日) 17:16:13.61

>>268
http://gihyo.jp/lifestyle/clip/01/awt/201603/24
＞しかし，AOT方式をいざ導入してみると，サイズの大きなアプリのインストールや，
＞一度に複数のアプリをアップデートするような場合にコンパイルに時間がかかり，
＞場合によっては20分程度かかるケースが存在していたようです。
＞このインストール時間を問題と捉えて，Android NのARTでは，JIT方式をもう一度使うことになりました。

**デフォルトの名無しさん** · 2017/10/30(月) 08:01:20.39

>>242
GOいいな

**デフォルトの名無しさん** · 2017/10/30(月) 10:22:57.04

>>271
Goは色々足りないところも多いが、生産性にステガン振りしてるって点で評価できる
Rubyみたいに前借りではない

**デフォルトの名無しさん** · 2017/10/30(月) 11:06:54.77

Rubyの教訓は、「Perlよりマシ」に全振りしたけどPythonと比べると大したことなかった

**デフォルトの名無しさん** · 2017/10/30(月) 17:27:48.73

Goのどこに生産性があるんだよ

あ · 2017/10/30(月) 18:12:26.17

>>274
そりゃ、ひたすら書ける部分だろ。
迷わんぞ。書く量が多いだけで。

生産性と言うと表現力ばっかり取り上げられるが、単位時間あたりのアウトプットも見ないといかん。
その点、信じられないレベルで楽。

**デフォルトの名無しさん** · 2017/10/30(月) 19:01:45.29

>>275
行数多くなるから生産性が高いように見えるだけだろ

**デフォルトの名無しさん** · 2017/10/30(月) 19:15:05.61

そいつは関数型しったか野郎なので話すだけ無駄
無知が無知なりの常識で頑張って答えてくれるかも知れないけど参考にはならないだろう

**デフォルトの名無しさん** · 2017/10/30(月) 20:23:14.16

迷わずひたすらに書かれたF77のコード読みづらすぎ

**デフォルトの名無しさん** · 2017/10/30(月) 20:45:20.95

Goは構造体へのタグ埋め込みや、codegenまわりのツールが充実してるお陰で
ボイラープレートコードを書かんでいいのがでかい
それだけならLLでもできるが、テスト作ってから設置して実行するまでの作法が簡潔に固まってるのが更に強い

少なくとも時間当たりのテスト含めた成果物は他の言語と比べ物にならん

**デフォルトの名無しさん** · 2017/10/30(月) 21:31:16.17

逆に、汎用ライブラリ書こうとするととたんにinterface地獄になってボイラープレート増えるんだがな
だから、目の前の仕事の案件片付けるのに特化した言語だと思ってる

**デフォルトの名無しさん** · 2017/10/30(月) 22:18:12.05

>>221
ちょっといまさらだがRust版平衡木(AA木)をリファクタリングしたぞ。
まあ、だれも書いてくれそうになかったし、数日たったらまたやる気も出たから自分でやり直したわけだが。

基本的には②だが、すべて当てはまるな。
RustはNull安全なのでOption型のチェックが必須、コンパイラに所有権を伝えるためas_ref等が必要、
デフォルトはイミュターブルのためミュータブルを扱うためにmutキーワードが必要などが主な理由。
そこら辺の安全性と引き換えに多少は目をつぶってくれという感じはある。
③に関しては副作用もあるが、それよりもどちらかというと木構造の回転操作みたいな
変数の所有者が次々に代わるようなコードはRustでは所有権システムがあるため書きづらい。

とはいえ、前のコードに比べれば大分マシにはなったかと。
まあコードが綺麗か汚いかなんて個人の主観によるところが大きいから、まだ文句を言うやつもいると思うけど。。。
特に>>217なんかには「どんなアルゴリズムだろうが言語によって最適な書き方は違う」
ということをきちんと理解してもらいたい。

あと、コードのリンクを貼るという手段があることを知った。
比較できるように全て載せておく。
C版
https://wandbox.org/permlink/fc1xI7dDCdOMgysC
Rust版 before
https://wandbox.org/permlink/cbzzpLw97K2Tydk1
Rust版 after
https://wandbox.org/permlink/ppQOQREnDlpccpJV

**デフォルトの名無しさん** · 2017/10/30(月) 22:28:38.00

ほう

あ · 2017/10/31(火) 00:08:53.17

>>276
そーでもないぞ。

>>277
関数型以外シッタカの意識だけ高い系に言われてもな。
人をディスるんじゃなくて、自分を高めれば？
無理なんだろうけど(笑)

**デフォルトの名無しさん** · 2017/10/31(火) 00:13:46.41

関数型以外シッタカ←根拠なしのただのディス
からの
人をディスるんじゃなくて自分を高めれば？

自戒かな？

**デフォルトの名無しさん** · 2017/10/31(火) 00:16:52.10

そいつの相手しても得るもん無いってことくらいはそろそろ分かって欲しい

あ · 2017/10/31(火) 00:17:14.17

言い返されてそれはみっともないリアクションだな。
よほど、関数型言語が好きなんだね(笑)

専スレ立ててやれよ。次世代言語でもないわ。

あ · 2017/10/31(火) 00:19:38.37

好きなら好きで良いのに、なぜ固執するかわからん。
ナイフで整備できるようにネジを全部マイナスネジにしたロシア(？)の戦車みたいな間抜けな話と同じように、目的に対して使う道具なんか考えりゃ良いのに。

**デフォルトの名無しさん** · 2017/10/31(火) 00:26:46.01

よほど関数型言語が好きなんだね←誰もそんなことは言っていない

なぜ固執するかわからん←固執していない

誰と闘っているんだコイツは。少なくとも俺じゃねえな

**デフォルトの名無しさん** · 2017/10/31(火) 00:39:43.26

おまえら旧世代猿人類どもはウンコブラシのプェチピィのゲリクソピィでもプリプリしてろ

**デフォルトの名無しさん** · 2017/10/31(火) 01:21:58.60

>>281
コンパイル通らんのを試行錯誤してる間に答えが出てしまった悲しみ
まとめてもらって感謝。勉強してみるわ

**デフォルトの名無しさん** · 2017/10/31(火) 07:32:43.21

>>281
比較を載せてくれてありがたい。
やっぱり
C -> rust before -> rust after
となっていくごとに読みづらくなってるんだけれど。。

**デフォルトの名無しさん** · 2017/10/31(火) 07:35:28.96

>>270
それの何が反論になってると？
元から速度云々関係なしにネイティブ変換できない部分があったんだよ

**デフォルトの名無しさん** · 2017/10/31(火) 09:37:19.94

>>291
root.as_ref().unwrap().level
を
root->level
と書いて良いというシンタックスシュガーを導入すれば良い気がする

**デフォルトの名無しさん** · 2017/10/31(火) 09:56:03.51

unwrapはNoneだった場合にランタイムクラッシュする関数だから本来使ったらアカン関数
この辺はnil安全うたってる言語はおおむねそう

**デフォルトの名無しさん** · 2017/10/31(火) 10:23:24.56

Goは最初期Javaかっていう後退レベルだし、Rustは木構造すら数日かかりで必要な難解言語だしでどっちもクソ言語
はいこれで仲直り

**デフォルトの名無しさん** · 2017/10/31(火) 10:43:17.86

パラダイムシフトを強いる言語は地雷が多いな。
俺はリアクティブプログラミングで懲りた。

**デフォルトの名無しさん** · 2017/10/31(火) 10:44:19.94

数日がかりというが兎と亀みたいにRust以外の言語は寝てたから
Rustが一番早い

**デフォルトの名無しさん** · 2017/10/31(火) 11:07:20.83

その理屈だとCが一番じゃん？

**デフォルトの名無しさん** · 2017/10/31(火) 11:21:14.97

結局当面はC#系(TypeScript/Kotlin)の天下ということでよろしいか

**デフォルトの名無しさん** · 2017/10/31(火) 11:40:23.38

>>294
そういうこと。だからRust版 afterではunwrapはほとんど使用していない。
通常、Optionの中身を取り出すときはunwrap_or, unwrap_or_else, unwrap_or_default
のどれかを使用してNoneだったときはどうするのか指定する。
unwrapを使用するときはアルゴリズム的に中身が存在しないこと自体がありえなくて、
Noneならバグと判断してむしろそのタイミングで落ちてバグを知らせてほしい時のみ使用する。
この仕組みによってNullが存在しない(いわゆるNull安全な)言語を実現している。
多少書くのは面倒だが「10億ドルの損失」に比べればこのくらいカワイイもんだろってこと。

ちなみにC#なんかでも導入が検討されているらしいが、既存コードとの互換性が保てないので難儀しているようだ。
Type scriptみたいにコンパイルオプション付ければいいのにとか俺は思うんだが、なんか理由があるのかな？

**デフォルトの名無しさん** · 2017/10/31(火) 11:47:33.10

コンパイルオプションだと既存コードを一緒にビルドできなくなるだろ
互換性を絶対神とするC#に導入するなら、#pragmaでソースファイルごとにオプトインするか、
asyncみたいに修飾子で特定のスコープだけ解釈を変えるか、
デフォルトをnull非許容にするのは諦めてstring!にするかのいずれかだよ

**デフォルトの名無しさん** · 2017/10/31(火) 12:45:40.51

Goが優れてる点はcode生成に最適化されてる点だと思う。

Goはメソッド定義が同じディレクトリ内なら何処でもできる。
つまりコード生成によってメソッドを追加できる。
ファイルでコード生成の箇所と自作の箇所をわけれる。

**デフォルトの名無しさん** · 2017/10/31(火) 12:48:35.27

>>296
Rxはもっとシンプルな定義にできないのかなーって思う。
「全てはストリーム」という考え方はシンプルなのにいざ使おうとすると
ライブラリは複雑すぎる。

もしかしたら言語まるごとRxの考え方で作ったら簡単になるんかな。
Rubyの作者がStreamって言語をつくってるけど、、、、完成しそうもないし

**デフォルトの名無しさん** · 2017/10/31(火) 15:40:47.27

rust で
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level
を
match root {
Some(node) => node.level,
None => 0
}
と書かないのは何故？所有権とかの問題？

**デフォルトの名無しさん** · 2017/10/31(火) 16:19:26.73

>>304
え？どっちでもいいよ？
リファクタリング後のコードでは使用してないはずだけど。。。
それでもいいし
root.as_ref()
.map(|node| node.level)
.unwrap_or_default()
でもいいし
if let Some(ref node) = *root {
node.level
} else {
0
}
でもいい。どれを使うかは好みの問題。
ただし、>>304のmatch文は正確にはこうなると思う。
match *root {
Some(ref node) => node.level,
None => 0,
}
rootはたぶん型が &T (借用) だから*で参照外しないといけないし、
ref は所有権を「移動」じゃなくて「借用」するために必要。

**デフォルトの名無しさん** · 2017/10/31(火) 17:24:30.09

>>304
>> リファクタリング後のコードでは使用してないはずだけど。。。
誤解を招くかもだな。すまぬ。
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level
のほうはリファクタリング後のコードでは使用してないはずだけど。。。だな

**デフォルトの名無しさん** · 2017/11/01(水) 08:38:18.68

なるほど。ありがとう。

**デフォルトの名無しさん** · 2017/11/02(木) 00:38:25.36

いいってことよ

**デフォルトの名無しさん** · 2017/11/02(木) 08:54:18.64

if not is_none 判定時に実行される、
コンパイラさんにも非noneと分かるコードパスでは
unwrap省略できれば読み書きする際にもPanic起こさないと分かりやすいしシンプルになるな。

実際にも最適化でチェックのコードも吐かれてないだろうし。

**デフォルトの名無しさん** · 2017/11/02(木) 12:08:13.82

>>308
んん？ちょっと待て。良くないぞ
誰だぁ？俺の手柄を取ったヤツは？

**デフォルトの名無しさん** · 2017/11/02(木) 12:58:12.12

>>309
そのやり方は所有権システムの関係で難しいかもしれないな。
非noneが分かっていたとしても中身を取り出す時に所有権を移動する借用するのか決める必要がある。
そして、移動するにせよ借用するにせよ、取り出した時点から所有権システムの制約により
その親にあたるOption型の変数がスコープを抜けるまでは参照不可になる。
移動する場合は、スコープが抜ければOption変数ごと一緒に消費されるはずなので問題ないと思うが、
借用の場合は、スコープを抜けるまでOption変数が参照不可のままじゃ困る場合も多いだろう。
結局は、if let や match 等のスコープを使って借用が終わるタイミングを
コンパイラに知らせるための表現が必要になるんじゃないかと思う。

自分も所有権システムを完全に把握してるわけではないので、間違ってたら指摘してくれ。

**デフォルトの名無しさん** · 2017/11/02(木) 16:01:49.17

panic の代わりに未定義動作を行うことで、最適化時にNone時の経路が取り除かれる unchecked_unwrap() とかある。
外部クレートだけど。

**デフォルトの名無しさん** · 2017/11/02(木) 18:20:00.53

FFIと静的型は相性悪いなあ

**デフォルトの名無しさん** · 2017/11/02(木) 21:04:39.70

嫌われているプログラミング言語ランキング - Stack Overflow
http://news.mynavi.jp/news/2017/11/02/073/

**デフォルトの名無しさん** · 2017/11/02(木) 21:06:15.09

最も嫌われているプログラミング言語は？--Stack Overflowが調査結果を発表
https://japan.zdnet.com/article/35109803/

**デフォルトの名無しさん** · 2017/11/03(金) 01:51:06.45

だから何度も言ってるだろ
型なし能なし未来なしの糞言語が
使ってる連中は今すぐ首吊ってなるべく苦しんで無様に血糞尿にまみれて死ねよ

**デフォルトの名無しさん** · 2017/11/03(金) 01:55:11.36

>>316
死ぬだけじゃダメだな
来世でも来来世でも苦しみ抜いてもらわないと

**デフォルトの名無しさん** · 2017/11/03(金) 09:09:40.17

>>317
せやな
一族郎党末代まで呪われて地獄の業火で焼かれるべきだ

**デフォルトの名無しさん** · 2017/11/03(金) 09:10:55.64

その政策の予算をいくらまでなら払えるか考えよう
予算なしは能なし未来なし

**デフォルトの名無しさん** · 2017/11/03(金) 10:56:17.26

すまんが型なし言語って何ンゴ？

**デフォルトの名無しさん** · 2017/11/03(金) 11:18:42.35

機械語のことかな？

**デフォルトの名無しさん** · 2017/11/03(金) 11:44:21.79

変数に型の無い言語か

**デフォルトの名無しさん** · 2017/11/03(金) 14:34:55.34

Go言語で
var 変数名 = 値

の表記の時は型を省略できるそうですが
値が数値で、値から型が確定できない場合はどうなるのでしょうか？
値から型を確定できるのは文字列型と真偽値くらいだと思いますが

**デフォルトの名無しさん** · 2017/11/03(金) 14:43:12.88

>>323
値に応じたデフォルトの型か決まっている

**デフォルトの名無しさん** · 2017/11/03(金) 14:58:26.87

>>324
なるほど
たしかにだいたい推測できますね
ありがとうございました

**デフォルトの名無しさん** · 2017/11/03(金) 15:00:00.55

>>319
予算がないからクソゴミクズ汚物言語を使い続ける？
地獄に落ちろビチグソ野郎

**デフォルトの名無しさん** · 2017/11/03(金) 15:50:26.42

VBA は explicit 付ければ堅く書くこともできるんやで～。
そんな書き方するやつあんまいないけど。。