いまだにテキストベースでコードを書いているのはなぜ? 205
ストーリー by headless
鉛筆 部門より
鉛筆 部門より
本家/.「Ask Slashdot: Why Are We Still Writing Text-Based Code?」より
私は自分をコードの書ける人間だと思っているが、プログラマーではない。アルゴリズムを考えることや、簡単なスクリプトを書くことは楽しいが、少し複雑なコードになるとお手上げだ。これは我慢強さが足りないだけかもしれないが、実際いつまでテキストベースでコードを書かなくてはいけないのだろう。言語に依存せず、暗号のような専門用語を使わずにアルゴリズムをコンピューターの理解できるものに変換する、より単純で堅牢な方法が必要ではないだろうか。今はまだアセンブリコードの1つ外側の抽象化レイヤーの中にいるように感じる。誰もがコードを書けるようになるグラフィカルなコード生成方法がないのはなぜだろうか。少なくともシンタックスエラーを修正するのにかかる時間をなくすことができればいいと思う。疑問は尽きないが、私の見落としているところがあれば教えてほしい。
いまだに (スコア:5, すばらしい洞察)
テキストベースの数式に依存している数学だの何だのの立場は……?
Re:いまだに (スコア:5, すばらしい洞察)
まさしくこれに尽きるな。
グラフィカルなインターフェースというのは、2次元空間の制約にうまく合う対象にはよいが、それ以外のものについては、必ずしも適しているとは限らない。エクセルとかは2次元を意識するが、それがかえって邪魔なときもよく有る。
少なくとも、2次元や3次元で、再帰構造をテキスト以上にうまく表す方法を知らない。
今のところ、テキストという1次元の列に、シンタックスという構造をいれるのが、構造を扱う汎用的かつ強力な手法。これを超える方法を、人類はまだ発明していない。
Re:いまだに (スコア:1)
んー?それは文法上再帰として解釈されるだけであって字面には再帰構造は表現されてないよ。
ただ名前がそのブロック自体やその「呼び出し元」と同じなだけじゃん。
Re:いまだに (スコア:1)
まさしくそういうことなのだけれど。
その部分は、1次元のテキストだろうと、2次元の図形だろうと、大して差はない、ということで、テキストより優れた表現になっていない。(「以上」と書いたのがまずかったか)
さらに、「名前」というテキスト表現は、一致関係を表現するのには優れているが、それに相当する平面的あるいは立体的表現を知らない。(結局名前というテキスト)
そもそも絵/象形文字から進化して生まれたのが文字/テキストなわけで (スコア:2)
#どこに書くか悩んだが、ここにぶら下げることにする。
絵文字が便利なら今でも絵文字を使っていただろうよ。
しかし不特定多数の様々な抽象概念を記述するには、グラフィカルな絵文字よりも
普通の文字/テキストの方が遙かに洗練され、進歩した技術だってだけの話。
数学や物理やプログラムのような概念を記述する上で、グラフィカルなそれは
テキストのそれより数段劣る。
特定用途に関しては専用の記号が発明されることもあるけどね。
数学におけるインテグラルとかシグマとかのように。
でも、これも特殊な文字の範疇じゃ無いかな。
Re:いまだに (スコア:1)
私は素人なんですが。
どの分野でも先にイメージありきじゃないの?
まあ玄人の世界では納期と予算が決まってるんで最初からゴリゴリとコードを埋めていく事もありますし、
何も考えずに数を上げろ。ってのもありますしねぇ。
#これもなんだけど、元記事が何を言いたいのか良く分からん。
#義務教育の国語の授業で「筆者は何を言いたいのか?|考えているのか?」と言うのが良くあって
#「そんなの勝手だろ」と心の中で思ってた。その呪いか?
Re:国語のやつは出題者の意図のあてっこ (スコア:3)
いやまったく。
忖度する能力とか教養も必要だけど、学校の国語の授業でまず
教えるべきは、物事を正しく伝えるための言い方・書き方だと思うんですよね。
テクニカルライティング的な。
仕事で仕様書読んでても、たまに絶望的な気持ちになることが
あります。
勘違い (スコア:5, すばらしい洞察)
私は自分をコードの書ける人間だと思っているが、
思ってるだけで実際には違うってだけの話だよね?
Re:勘違い (スコア:1)
まず (スコア:5, おもしろおかしい)
質問をテキストで書くなよw
ワタシはLabView使い (スコア:5, 興味深い)
たかが実験の測定のために、テキストベースのプログラミングするのが嫌になって、
HPのVEE使い始め、ここ10年は、LabVIEWでデータ収集や簡単な計算しています。
ブロックを線で結ぶだけなので、立ち上がりは速いです。
立ち上がりだけは。
線の繋がりで、データフローが直感的に掴めるので、
簡単な測定するのに、ダラダラッ と書いて、データを取りっぱなし にするには優れています。
しかし、グラフィカル=直感的=非論理的 なんですよね。
後で見ても分かるようにするには、かなり綿密に「文字で」コメントを入れておく必要があります。
論文や数式が、"文字"という抽象化されたツールを用いて表現されるのは、論理的であるための必然で、
(極論すば)絵画で論理が展開できないのと、根本的には同じことなのでしょう。
Re:ワタシはLabView使い (スコア:1)
うちだと、MATLABで信号シミュレーションする時には、簡単なやつはSimulinkで
ぱぱっとやっちまうので、やっぱりブロックを線で結ぶだけですね。
ただ、性能出しで細かい調整をする場合には最初からMATLABでテキスト表記した方が
速いし楽ですが。特に後でC++とかに落とすのならテキストのが楽。Simulinkだと
アルゴリズム検証くらいにしかならないので。コード自動生成? 速度問われない所なら
それでもいいんだけどねえ。
語学と一緒 (スコア:4, すばらしい洞察)
誰もが外国人と会話ができるようになるグラフィカルなコミュニケーション方法がないのはなぜだろうか。少なくとも母国語以外の言語を習得するための時間をなくすことができればいいと思う。
Re:語学と一緒 (スコア:2)
同意です。
人類は言語以上に素早く簡潔に多彩に表現する手段を発明できていません。
この言語の特性をテキストベースのプログラムも持っており、それを超える表現方法が発明できていません。
Re:語学と一緒 (スコア:1)
わからんでもないがそれも一つの言語だわな。
Re:語学と一緒 (スコア:1)
昔は存在した(というか言語が一つしかなかった)けど、神にバラバラにされたんじゃなかったっけ。
#神「が」バラバラにされたのではなく
Re:語学と一緒 (スコア:1)
☆彡 大和 環
Re:語学と一緒 (スコア:1)
Re:語学と一緒 (スコア:3, 参考になる)
「手話が母語ごとにある」という表現は、「音声言語と手話が1対1で対応する訳ではない」という点(日本手話は日本語とは文法も異なる別言語ですし、アメリカ手話はイギリス手話とは異なる言語であり英語圏以外でも使われています)と、「ろう者にとっては手話こそが母語である場合もある」という2点で、不正確です。
顧客が本当に必要だったもの (スコア:2, 参考になる)
図形プログラミングと自然言語プログラミングは素人さんが夢見る二大巨頭ですねぇ。実際には過去何度も登場しては討ち死にし続けてるわけですが。
まあ、このタレコミ主が本当に必要としているのは、ユーザーから対話的に要件を聞き出してコードを生成してくれる人工知能なんだと思います。
Re:顧客が本当に必要だったもの (スコア:1)
庄司創の漫画にそんな感じのがあったな。
対話型の人工知能と「適切に対話」するお仕事のある世界。
入力効率 (スコア:2)
マウスよりキーボードの方が大量の情報を素早く入力するのに長けているというのが一つの原因でしょう。
出来上がったものを出力して見るには図式的な方が見やすいこともあるが、それはIDEのクラスビューとかで既にある程度実現されています。
電子ブロック→カルネージハートの系譜 (スコア:2)
せっかく築いてきた「パネル/ブロック組み合わせプログラミング」の系譜が途絶えたことが、人類が袋小路に行き着いてしまった原因という仮説を…
#レゴ・マインドストームならやってくれるか!?
私のプログラミング履歴 (スコア:2)
ロボクラッシュ
マルチプライ
がんばれ森川君2号
カルネージハート
パンドラプロジェクト
アーマードコアフォーミュラフロント
ファイナルファンタジー12
C
java
いずれは・・・ (スコア:2, 興味深い)
これまでの流れを見ると
インターフェース的には、
・スイッチとランプ
・キーボードと文字ディスプレイ
・マウスとグラフィックディスプレイ
・タッチパネルとグラフィックディスプレイ
・マイクとヘッドマウントディスプレイ+イヤホン
・ブレイン・マシン・インタフェース
言語的には
・機械語
・アセンブラ
・高級言語
・プログラミングパラダイムの多様化
という流れかと。
それぞれの利用する立場で最適な方法を使うことになるのでしょうが、インターフェース技術と人工知能が進歩すれば要求する概念を考えただけでシステムが実現してくれるという形になるような気がします。
ハリウッド映画とかよくある (スコア:2)
ハッキングツール作ったりするときの画面みたいな感じで実際に作れたらいいんじゃね?
ってことだと思うが、攻殻機動隊くらいのSFまで技術が進歩すれば出来るんじゃないかと思ってる。
そんなふうに考えていた時期が俺にもありました (スコア:1)
20年ぐらい前の学生の頃、GUIを使って部品を組み立てるタイプのなんかの特集を見て、これからのプログラミングはこうなるんだ、じゃあもうプログラム言語なんて覚えなくていいんだなー、と思っていた頃がありました。
それから数年して、一向に巷でそんなのを見かけないことに気づいて、あれアカン奴だったんや、と気づきましたが・・・。
ビジュアルな奴って発想は判りやすいのかもしれませんが(使ったことない)、出来ることが制限されたり、細かいことをしようとすると結局テキスト書かなくちゃいけないんでしょ?という印象があります。
# ステルヴィアの謎のプログラミング環境はよ!
Re:そんなふうに考えていた時期が俺にもありました (スコア:2)
むかし dbMagic という環境を使ったアプリケーションを
保守する仕事をしたことがありますが、違和感ありまくりでした。
アプリ側の仕様書が従来のやり方で書かれていたのに対し、
プログラミングはいきなりグラフィカルになっちゃうので、
「この処理はどこでやってる?」的な、一覧性に欠けるシステムだと
感じました。新規開発の案件なら効率良いのかもしれないですけどね。
Re:そんなふうに考えていた時期が俺にもありました (スコア:1)
ビジュアルプログラミングはピクセル面積あたりの情報密度が低くてなー。
うまいこと階層化と抽象化を強制するようにでもなってなければ実用には耐えまい。
でも仮にそのようなものができたとしてもこの記事が主張するような「わかりやすさ」はないだろうし。
既存言語でも記述の抽象レベルは高められるんだから、抽象レベルが低い云々ってのは単に酷いコードを扱っているというだけだろう。
# ジーンシャフトのアレ...はダメダメな結果が見えてるかw
無茶振り (スコア:1)
要するにプログラム言語を覚えずにプログラムを作りたいと言ってるわけで、
それは電気を使わずにPCを使いたいと言ってるのと同じで、無茶にもほどがある
#その手の開発ツールは複雑なロジックの実装が通常よりも高コストになるからプロユースに向いてないんだよ
どんな方法でも (スコア:1)
並列な論理思考が出来ない人間には無理。
the.ACount
そういやExcelとかのVBAはそろそろグラフィカルな環境にしてもいいような… (スコア:1)
ほかの方も言っているとおり、用途を限定すれば案外使いやすいモノはすでに
あったり、作れたりするかもしれないですね。
と思ってふと周りを見ると、ExcelなどのOffice製品用VBAが未だにアレ。
Office 2013になってもアレなのは正直どうなのよマイクロソフト、とか思う。
おかげで「若いけどVBAでVB6.0ライクな実装しか覚えていない」とかって変な
人種が登場したりする温床に。
テキスト以外ではバージョン管理が難しい (スコア:1)
テキスト以外ではバージョン管理が難しい
ってのが大きいのではないかな。
特にマージが難しいのでロック型ならざるを得ない。
Re:テキスト以外ではバージョン管理が難しい (スコア:3, 興味深い)
私もこれに賛成です。テキストベースで組んでおけば、バージョン管理ツールの恩恵を受けやすいです。継続的ビルドの書籍でも、開発環境の構成情報すらバージョン管理に含めろと書いてあります。
テキストベースでのメリットを生かせるようにいろんなツールが既にできているわけで、グラフィカルなものだとどうしてもこれらの仕組みを生かせません。
グラフィカル中心でやるということは、diff/merge に当たるものからその他もろもろ用意しないといけないわけで、それらの開発コストもそうなんですが、利用者側にもツールの使い方を覚えてもらわないといけないわけです。かえってコストがかかります。
ただ、向き不向きはありますので web サービスを強化して、BPM で連携とか、そういったところはグラフィカルなものが主流になっていくんでないかと思います。
人間が言語で思考する以上、言語以外の表現でプログラムを作ることはできない (スコア:1)
ただそれだけのことだとおもうんだが。
Re:UML (スコア:2)
Re:UML (スコア:1)
シーケンサ(PLC)ならラダー自体がグラフィカルだ。
論理演算も算術演算もできるけど、アセンブラを簡易的に視覚化して組んでるのと変わらんが
#ST言語を使おう
Re:UML (スコア:2)
それこそ、Visual Studio Ultimate [microsoft.com]とか。
後はVS [sparxsystems.jp]とかEclipseの開発環境に統合できる [sparxsystems.jp] Enterprise Architect [sparxsystems.jp]とか、生成位だと旧名JUDE、現astah* [change-vision.com]とかですかね?
結構対応してるけど、結局それ+の部分を手作業で書くことは必要になりますので完全にコーディングしなくてよいとはなりませんが。
Re:UML (スコア:2)
無償で使えるのにJUDEってのがあったハズ……と思ってググったら公開終了になってた。
後継にastah* community [change-vision.com]ってのがあるのね。
後、名前を知ってるレベルだとEnterpise Architect [sparxsystems.jp]ってのがあるけど、使用感は知らず。
ある所にはあるし、使ってる所は使ってるんでしょうね。
Re:UML (スコア:1)
> UML で絵を描いて、コードに落とすのってないでしたっけ?
Rational Rose [ibm.com]とか?使った事が無いので、どの程度使えるのかは不明ですが。
# お勉強、してみるかね。
Re:UML (スコア:1)
RationalのRoseとかが、すでに15年ほど前にその辺のことはやってると
思います。ただ、やはりそれなりの規則や成約に基づいて記述する必要が
あるのと、規則や成約があればとりあえず反発するという中学生みたいな
老害エンジニアが多いという現実があったので、たぶん普及しませんでした。
#理由については個人的な偏りに基づく偏見と憶測です
Re:UML (スコア:1)
15年前の老害エンジニアが死んでいなくなったのに、まだ普及しないのは単に不便だからです
Re:UML (スコア:2)
「UMLを導入しました」と言いつつアクティビティ図と称したフローチャートしか使っていない現場を見たような覚えが。
Re:日本では実現済み (スコア:1)
エクセル方眼紙の方眼1セルに1文字という域にまだ人類は到達できていないので、
エクセル方眼紙の真の力を人類は引き出せていない。
あれは偽方眼紙。
#こんな方眼紙は食べられないよ。
#10人月くれ。ボクが本物のエクセル方眼設計を見せてあげよう
Re:日本では実現済み (スコア:1)
新人の時、VBA で COPY 句を出力するヤツ作ったなぁ。
Tak.Miyoshi
Re:楽譜も1つの言語というかソースコードと考えると・・・ (スコア:1)
作曲するときのことを考えてみるといい。
主題のパートを思いついて、そこが楽譜なりになる。
で、それを元に肉付けして展開させていく。
まあ例外はもちろんあるだろうが、普通に考えれば作曲の過程はこんなもんだ。
で、この「肉付け」する過程で、パート間の関連性がわかりづらいMMLは不便なんだよ。
別に特殊でもなんでもなく、必要とされる機能が既存のものより劣ってるから選ばれない。
ただそれだけの話。
Re:楽譜も1つの言語というかソースコードと考えると・・・ (スコア:1)
あれは、
横軸を時間にして、変化を記したグラフの1種。
というような印象です。
時間に沿って音を鳴らす、という実行側の絶対的な仕様のおかげで、
繰り返しや分岐が基本的に存在しないため、
そのほうが見やすくて都合がいいのでしょう。
Re:シンタックスエラーの修正に時間がかかる? (スコア:1)
# コミット前フックにmakeを登録するんだ。
Re:無知なスラド民は知らないと思うが (スコア:2)
「ビュッと来たところをグッとしてバーンと打つ」、というのはテクスチャルに入るんでしょうかね。
Re:プログラムに必要とされている事 (スコア:2)
厳密な論理は言語ぬきでは構築できない。
その「言語」が、文字をベースにする一次元的なものではなく、図形をベースにする二次元(or多次元)的なものにすることはできないか、って話ですよね。
例えば、電気回路は、厳密な論理で設計されるわけですが、その設計結果である回路図は、二次元的だったりしますね。
以上の考察から、
真に言語なしで論理を構築する事の出来る人間はほとんどいないし、いたとして、そのアウトプットを検証する事はできないから。
は、正しいとは言えないと思います。