Excel VBA 質問スレ Part54

**デフォルトの名無しさん** · 2018/05/26(土) 20:37:37.74

ExcelのVBAに関する質問スレです
コード書き込みや作成依頼もOK

最近プロによる書き込みが多々見うけられますが
彼らに絡むと話がこじれるので質問したい方は適当にスルーしてください

※前スレ
Excel VBA 質問スレ Part53
http://mevius.5ch.net/test/read.cgi/tech/1524823358/

**デフォルトの名無しさん** · 2018/07/22(日) 00:59:08.18

まずC#の方が全てにおいて上だよ。
PowerShellに比べれば。

そしてそれに反論しようとすれば基本的にVBAと同じ論理展開になる。
用途が違うというね。

つまりPowerShellは全てにおいて中途半端とも言える。
VBAを批判する者の論理を進めていくとそういうことになる。

だからPowerShellユーザーのVBA批判は検討に値しない。

**デフォルトの名無しさん** · 2018/07/22(日) 01:26:51.64

>>985
> まずC#の方が全てにおいて上だよ。
なら、C#で作ればいいだけ

**デフォルトの名無しさん** · 2018/07/22(日) 09:07:18.88

事務システムの委託開発業務なんてよく成り立つよなあ、って驚く。
そんなのアウトソースするまでもなく社員がちょちょっと自分で作って完結させればいいんだし、
逆に言うとそんなふうにならなけりゃ米中に競争力で勝てない。
VBAでもPowershellでもなんでもいいよ。
プロの開発者はそんな委託仕事じゃなくて国際市場で勝負できるプロダクト作ってほしいものだ。
と常日頃思ってる自分にとって、ここでの議論は気に食わない部分が多少ある。
だから「プロがこんなとこに来るんじゃねーよ」と言いたくもなる。

**デフォルトの名無しさん** · 2018/07/22(日) 09:23:44.04

>>985
まずPowerShellはC#コードをコンパイルして実行できるためC#の機能の大半を包括しています
その上でPowerShellはC#にない高級なコマンドレット、カジュアルな文法などを持っています
また、もともとシェル系言語ということもありサブプロセスとの連携やリモート処理はC#よりもだいぶ得意です

C#は強力な型システム、業界でも屈指の高い生産性を誇る非同期処理、
Visual Studioとの高い親和性などPowerShellにはない強みも持っています
そしてPowerShell実行環境はマネージドライブラリとして提供されているため、当然ですがC#からPowerShellを実行することも可能です

一方でVBAにはこれといって目を引くような強みはありません

互いに非常に強力な機能を持ちつつ、相手より得意な分野があり、相互に連携可能なC#とPowerShell
これらとVBAを同じ目線で語ることは不可能でしょう

**デフォルトの名無しさん** · 2018/07/22(日) 09:58:22.12

>>988
まず、PowerShellはC#コードをコンパイルして実行出来ません。

あなたがVBAを批判する時に良く出てくる面倒だとかいうフレーズはVBAでも「～すれば出来る」というこちらの回答に対してでした。
ならばPowerShellに対しても「～すれば」という場合は出来ないと判断すべきでしょ。

PowerShellではPowerShell ISE以外で開発することは出来ません。
VisualStudioとの親和性?
そんなものは全く有りません。

あなたのVBA批判を元にすればそういうことになります。
VBAに対しては全ての条件を厳しく、PowerShellに対しては全ての条件を優しくでは困りますね。

VBAでも制約がある中で工夫でそれを乗りきっているわけです。
そういう工夫を否定するならPowerShellにおける工夫も否定して発言してもらわないと困りますね。

**デフォルトの名無しさん** · 2018/07/22(日) 10:02:18.60

>>986
私はPowerShellの適材適所を認めています。
しかしVBE批判者の論理に則ればそういうことになるということです。

**デフォルトの名無しさん** · 2018/07/22(日) 10:35:19.44

VBA は、Excel とか、人間が見て、表に書き込む用途には良い

でも、ボタンを押して、DB・ファイルI/O・テキスト処理などをする場合、
PowerShell, Ruby が適している

これらを、VBA で書くのは地獄だろ。
数行のコードが、数百行になる。
百倍！

Excel エンジニアは、プログラマーじゃないけど、
これらの処理は、プログラマーが求められている業務だから

仕様書・テスト・保守とか、ソフトウェア開発の領域だから、
Excel の領域をはるかに超えている

普通は、目標からツールを選択するけど、
先にツールを決めた場合は、やれる事を限定しないといけない

どこかに、そのツールを使っていくと、非常に不利になってくる分岐点がある。
そこがそのツール・技術・技術者の限界で、
新技術へ以降しなければならないというサイン！

**デフォルトの名無しさん** · 2018/07/22(日) 10:55:23.83

>>991
>DB・ファイルI/O・テキスト処理

ユーザーが手元で作ってきた経緯が長い（下手すると１０年以上）から、そういうのはオレオレ便利ツールが揃っているんだよ。
オレオレであったとしても大抵のことがPowerShellやRubyより少ない行数で書けて、品質が問題なければ十分。
十分てのは「わざわざプロに委託するまでもない」ていう意味。

大企業で異動が頻繁ではないユーザー部門だったら多くはその程度のレベルには行ってる。
もちろんExcel、VBAオンリーじゃないけどね。
逆にIT部門の方が全然ダメだったりする。

**デフォルトの名無しさん** · 2018/07/22(日) 11:00:30.12

>>991
スクリプト言語と汎用言語の違いがわからない痛い人なのかね？

**デフォルトの名無しさん** · 2018/07/22(日) 11:02:15.87

いい加減うぜーからどっかいけよクソアスペ
VBAに文句言ってる人がどこに文句つけてるのかまったく理解できてないから話も通じないしかみ合わない

**デフォルトの名無しさん** · 2018/07/22(日) 11:07:52.11

一見マウント取ってボコボコに叩いているように見えるも彼が何と戦っているかは誰も知らない

**デフォルトの名無しさん** · 2018/07/22(日) 11:08:06.32

やっぱりrubyキチガイのしわざだったか

**デフォルトの名無しさん** · 2018/07/22(日) 11:25:39.83

>>989
PowerShellはC#コードをコンパイルして実行出来ます。
あなたの知っているPowerShell?と本物のPowerShellは別もののようです。
あなたは違う製品をPowerShellと誤認識している可能性があるので、まずは確認をおねがいします。

ただの言葉遊びですね
「〜すれば出来る」という抽象的な文にしてしまえば、まるでVBAもPowerShellも同じであるかのように錯覚させることができます
実際には「〜」のボリュームにて果てしないほどに差がつきます

PowerShellはISEのほかVisualStudioCodeでの開発がMicrosoftによってサポートされてます
VisualStudioにもPowerShell MVPの方が作成したPowerShell Tools for Visual Studioという拡張があります

結果的にVBAに厳しくPowerShellに優しく見えてしまったのかも知れません
ですが評価とは本来そういうものです
成績が悪いのはいじわるされているからだ、などと大人気ないことを言われては困ります

欠陥を補うための工夫と、より良い結果を導き出すための工夫を混同してはいけません
PowerShellはVBAのように足りないものを補うために頭を悩ませることはそう多くはありません
頭を使うなら、どんなものを作ればより高い価値を提供できるのか、について考えるべきです
人間の脳は有限なので、開発基盤由来の困難解決に脳のリソースを使うほど、品質向上のための脳のリソースが減っていきます

**デフォルトの名無しさん** · 2018/07/22(日) 11:31:45.12

1000ぱんてぃ

**デフォルトの名無しさん** · 2018/07/22(日) 11:32:24.57

1000ぱんてぃ

**デフォルトの名無しさん** · 2018/07/22(日) 11:32:57.67

1000ぱんてぃ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 56日 14時間 55分 20秒