アカウント名:
パスワード:
少年が自分で作ってみることのできるプログラムと,物心つく前から当たり前のように触れてきているプログラムとの差が,あまりに大きすぎる気がします。これじゃ,作ってみようという気持ちになれないんじゃないかな……。
VB.netでフォームにメニュー作ったり、適当なダイアログとか作ると、意外と売りモンのソフトと見た目は似たモノが出来て結構楽しいです。
どの、メニューを選んでも「開発中です」っていうダイアログが出るだけだったりしますが。
#そこから先を作るかどうかが人生の分かれ道になるかもしれません。
そんな感じだったなあ結局...その当時に作りたいものは能力上つくれず、まだインターネット普及途上でググることもできず手元の付属リファレンスだけでどうやれば実装できるか考えて考えて、今思えば全然解決ではない方法だけを試して挫折して...ファイルの読み書きもできないまま、オブジェクト指向の本質も理解せぬまま、WindowsAPIの存在も知らず、業務アプリのようなものの存在など一切知らないまま。
いまじゃすっかりコード書く仕事、主にWebとCLIだけのテキスト出力に囲まれて、GUIに惑わされて倒れた当時のジレンマに比べれば幸せで仕方ないと思える日々です。
> 今思えば全然解決ではない方法だけを試して挫折して...
ここで諦めたかそうでないか、が分かれ道な気がします。
人はそれを才能と呼ぶ。
「少年が自分で作ってみることのできる××と、物心つく前から当たり前のように触れてきている××との差が、あまりに大きすぎる」の、「××」に入る言葉が、時代と共に変わってきているだけじゃないかと思います。
いまなら「プログラム」かもしれませんが、以前は「マイコン」だったり「電子回路」だったり「ラジオ」だったりしたんでしょうね。「プログラム」の次には何が来るのでしょうか。
CPUの動作が目で追えた時代があったと聞いたことがありますが、本当なんですかね?
CPUは判りませんが、「300ボーモデム」時代なら、通信で流れてくる文字はそのまま読むことができました。(むしろ、読むスピードよりやや遅いくらい)現在の数十Mbpsくらいで流れてくる速度では、さすがに生データはリアルタイムでは読めません。
ええと、この二つの速度差がピンと来ない若い方は、「送られてくるのがエスケープシーケンス文字アニメか、フルHD動画か」を想像してもらえれば判るかと思います。
# なに、今度はエスケープシーケンス文字アニメが判らない?# うーむ、そりゃ困ったのぅ。
# なに、今度はエスケープシーケンス文字アニメが判らない?
telnet towel.blinkenlights.nl
なに、今度は telnet が判らない?
> 今は組み込みプロセッサでもPLLが入ってたりしてクロック系亜が複雑なので1.は無理,PLLは動かさなければいいだけなのでそれはそれで問題ない気が。むしろセラロック内蔵で外からクロックの入れようがないような石の方が手強い。
>しかも命令コードの自己書換も出来ないものが多く2.も難しい.キャッシュが付いてるような高級な石は組み込みだと「多い」とはいえないのでは?
> CPUの動作が目で追えた時代があったと聞いたことがありますが、本当なんですかね?
昔の大型汎用機のコンソール(机にキーボード、ディスプレイ、操作ボタンなどが埋め込まれたもの)には、8桁程度の7セグメント表示器がついたものがありました。これには常時CPUの実行命令アドレスが表示されていて、上位の桁を見ていれば、現在どのジョブが実行されているか判断できたものです。また、下位数桁だけがちらついて、それより上位の桁にずっと変化がなければ、プログラムが無限ループしていることもわかるわけです。
仕事でZ80や647180のICEを使ってましたが、画面上に表示されるアドレスや割込み信号とかはある程度は目で追えていました。ROMに焼く前にわざと、動作確認用として、サブルーチンのアドレスを判りやすく配置して確認したりとかも。Z80のM1端子をLEDでモニターすれば、LDIRとかで長い時間ループしている最中かとをデューティー比による明るさとかで状況が判ったり、DMAでCPUが止まったままなのかとかも、目視はできましたね。
そりゃICEさえあれば何でもできますがなw問題はICEはクソ高いということです。#いわゆるJTAG-ICEやROMエミュレータはICEじゃありません。
大学の情報工学科でプログラミングを教えています。こういう学科なのでプログラミングに関連する講義や実習はそれなりに充実していますが、GUIを伴うプログラムの作成を教えている科目は一つもありません。現在、学科のカリキュラム委員会で講義のリニューアルを検討しているのですが、他に教えるべきことが沢山あるため、GUIの構成法などについてはいまのところ議題にあがっていません。これはうちにUI関連の研究者が一人もいないためで、もしかすると他の大学ではもっと現代的なプログラム作成をカリキュラムに取り入れているのかも知れませんが。
そういう私もGUIの作成経験なんてSmalltalkやJavaでちょっとしたおもちゃプログラムを書いたくらいしかありません。普段はMacで仕事していますが、30インチディスプレイのほとんどをターミナルエミュレータが占めている状態です。研究関連のプログラムは昔からのコマンドラインで十分ですしね。まあ、オープンキャンパス等で人目を引くデモができないのは何とかしたいところですが。
そのようなわけで、教える側がCUIに過剰適応(?)してしまっているせいか、なかなかGUIまで手が回らないのが現状です。学生の興味を引くという点では改善の余地はあると思います。
GUIの画面を作るだけなら、OSが豊富なAPIを提供してくれるのでたいして難しくないですね。ただ、一般的なデスクトップアプリケーションの作法なんかは勉強しないといけないですね。データの読み書きをどういうタイミングでするかとか、そのデータはどういうフォーマットにするかとか、標準的なメニューの構成と振る舞いとか。あとレイアウトの基本とか。
あるテキストボックスに何らかの文字が入力されていなければボタンを押しても意味がないという場合に、入力されるまでボタンをディスエーブルにしておくなんていうのは、普段GUIのアプリを作っている人には当たり前のことかもしれませんが、はじめは教わらないと分からない人も多いと思います。
GUIプログラミングは、イベントドリブンプログラミングとなり、演習用プログラムの逐次処理とは異なるので、そういう観点では教える価値があるのではないでしょうか。
>GUIプログラミングは、イベントドリブンプログラミングとなり、>演習用プログラムの逐次処理とは異なるので、そういう観点では教える価値があるのではないでしょうか。
イベントドリブンといいつつも、GUIは基本がシングルスレッド且つ同期処理なので、イベントドリブン自体はそんなに難しいとは思わないかな。しかし目的の動作を実現するために、膨大なAPIのどれとどれを組み合わせる必要があるのかとか、その時の落とし穴とかを調べるのがめんどい。
そういう意味では高い丸暗記&コピペ能力が求められるので、一般的なプログラミング能力とは異なる素質が必要だとは言えるかも知れない。
(そしてGUIから入った人の中には、丸暗記&コピペ能力『だけ』は非常に高いけれどそれ以外がまるでダメという人もいたりするから厄介だ。そういう人はなまじ見た目が派手なデモを作るのには高い能力を発揮するので、上司には非常に受けがいい。)
つ [s/GUI/ポインタ/g]
プログラミングを人に教えたことがないし、最新のプログラミングも大昔のプログラミングも知らないので、ずれているかもしれませんが、僕の考えを書きます。
ちょっと違うかも知れませんが、初心者がプログラミングの学習をするにおいて最大の壁はGUIだと感じます。
僕も一時期そう思っていましたが、考えを変えました。
以前は「GUI プログラミング」は高度なプログラミング技術の一つでした。プログラミングを知らない人がまず GUI プログラミングから始めるなんて想像できませんでした。しかし、今ではむしろ普通にプログラムと言えば GUI を使ったものであって、わざわざ「GUI プログラミング」などと呼ぶ方がかえっておかしいくらいです。
一方で、コマンドラインインターフェースが当たり前だった昔に比べて、開発環境も進化しています。今からプログラミングを覚える人は、例えばいきなり HTML 文書中の JavaScript などから入るわけでしょう。それだと GUI を使うこと自体はべつに難しくないのではないでしょうか。
もちろん、実際のプログラミングをする前に基礎 (仕組みの部分) を完璧に理解しようなどと言い出すと、 JavaScript のプロトタイプベースのオブジェクト指向とか、 Document Object Model とか、イベントモデルとか、目に見えないところで使われている高度な技術を理解する必要があってまず不可能でしょう。でも、基礎を理解しないでプログラミングに飛び込むことは十分可能だと思います。昔だって、 ROM-BASIC のインタープリターがどうやって動いているのかとか、 #include <stdio.h> とはどういう意味だとか、知らずにプログラミングを始めて、後から学んでいたわけで。
自分(非プログラマのオッサン)の場合、
と順調に(?)手を広げてきましたが、CUIだGUIだと気張らずに、そのとき必要なことをやっていればなんとなく自分がやっていることはつかめるんじゃないかと思います。
誰かにツール作ってあげて「GUI欲しい」と言われたら、開発環境の標準コンポーネントを組み合わせてやればいいだけだし、HTMLで適当なフォームでっち上げてインターフェースは丸投げしてしまう手もあります。#ruby便利すぎ
本当に「洗練されたGUI」を目指すならデザイナーとしての才能とか人間工学の知識とかも多分必要なので、普通にプログラム書く人がそこまで頑張ることもないかなあと。
フリップフロップのリレーがバシャバシャ動くとこなら目に見えるかなぁ・・・追えるじゃないし、CPUとは言いがたいですが
プログラミングは趣味にしとけば良いと思うよ。
生活基盤が安定してるほうが豊かだっていう別の意見に賛成ですね。この手の仕事は大多数が安定とは無縁なんじゃないかなー
いつまでたってもウィンドウの一枚も出てこない。
それでは書いてみましょう。
(use gtk) (define (main args) [gtk-init args] [[gtk-window initWithType: GTK_WINDOW_TOPLEVEL] show] [gtk-main] 0)
Objective-Cっぽく書いてみました。gauche-gtkが必要です。ネタなので、マクロの部分は省略しています。ウィンドウを閉じてもプログラムが終了しないですし。
CUIなら、PRINT "Hello, world!" とかで済むのに、やっぱり複雑すぎると思います。
#include int main(int argc, char **argv){ printf("Hello world.\n");|
と、Cでhello worldする程度には簡単だと思います。
要は複雑になるかどうかはGUIかCUIかはあまり関係がないということです。
>ところで、CPUの動作が目で追えた時代があったと聞いたことがありますが、本当なんですかね?正直信じられないです(@21歳学生)適当なラベルにトラップ仕掛けてJTAGデバッガ使ってインストラクション単位でステップ動作させるとか、あまつさえそのデバッガのログをリダイレクトして後から追跡するとかやりませんか?# いや、まぁ、そんな真似最近じゃ複雑過ぎて滅多にやりませんが…パソコンが8bitだった時代はJTAGではなく自己書き換えデバッガを使ったステップ動作でのトレースとか普通にあったし組み込みでは32bitであってもそれやらないとダメになる局面と言うのも未だにごくごくわずかながらありますよん。あんましやりたくないけど。
全部独習でアセンブラ, FORTRAN, LISP, HyperCard, C とやってきたが、使ってる Mac のアプリと同じ動作するように試行錯誤で GUI を何度も何度も作り変えるのが楽しいと思えるなら、プログラミングの壁なんてないな。
「Core Memory―ヴィンテージコンピュータの美」がいいですよ。
http://www.amazon.co.jp/dp/4873113571/ [amazon.co.jp]
若松通商でCASIOのポケコンが6千円くらいで投げ売りされてたから、そういうのを触ってみると実感できると思いますよ。
>最近、ボコスカウォーズを動画で見たけど、これなら作れるかもって希望がわいてきた。今時のマシンでなら楽勝でしょうでもこれをファミコンで作るのは結構しんどいと思うよ
というか、(オペレーティング)システムが完成しすぎていて、ソフトウェアを実装する前に理解すべきことが多すぎるように思えます。そのためかどうか、とりあえずゲームを作ってみたい少年たちはOSASKに集う、とのことです。
逆にOSやミドルウェアがそろっているので、それっぽい見かけのものならば簡単に作れるようになったと思います。
そんなものがなかった時代には、最悪ハードウェアのアーキテクチャ調べた上で「$xxxx(アドレス)に$n(データ)を書いて……」(これで点を一つ描画)ってのを延々と繰り返す(ってことやってくれるルーチンを作る)とこから始めなければならなかったんですよ。実際にはBASICなりCのグラフィックライブラリでそこらへんスキップできましたが。
「円」を描くのは「正二十四角形」を描く処理ですませばいい(画面解像度が320*200とか640*400だった頃の話)なんて、今じゃ「はぁ? 何言ってんのこいつ?」って思われるのがオチだろうなぁ。
ま、その代わりあの時代はrawレベルな情報もふんだんに出回っていたので、調べるのは(財布の中身さえあるならば)楽でしたね。 基本情報はパソコン付属のハードウェアマニュアルにあったし。
「$xxxx(アドレス)に$n(データ)を書いて……」(これで点を一つ描画)
ビットマップディスプレイが用意されているなんてすごく最近のマシンですね。#その割にはアドレスが16bitしかないのが...。
>>「$xxxx(アドレス)に$n(データ)を書いて……」(これで点を一つ描画)
>ビットマップディスプレイが用意されているなんてすごく最近のマシンですね。>#その割にはアドレスが16bitしかないのが...。
何を基準に物を言ってるんだろう?元コメは8bitや16bitのパソコンの話をしてるんだろうに。そもそも$xxxxが16bitだというなら$nは4bitなのか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
近ごろの若者はかわいそう (スコア:3, 興味深い)
少年が自分で作ってみることのできるプログラムと,
物心つく前から当たり前のように触れてきているプログラムとの差が,
あまりに大きすぎる気がします。
これじゃ,作ってみようという気持ちになれないんじゃないかな……。
Re:近ごろの若者はかわいそう (スコア:1)
VB.netでフォームにメニュー作ったり、適当なダイアログとか作ると、
意外と売りモンのソフトと見た目は似たモノが出来て結構楽しいです。
どの、メニューを選んでも「開発中です」っていうダイアログが出るだけだったりしますが。
#そこから先を作るかどうかが人生の分かれ道になるかもしれません。
中学生の頃VB4で (スコア:2, 興味深い)
そんな感じだったなあ結局...
その当時に作りたいものは能力上つくれず、まだインターネット普及途上でググることもできず
手元の付属リファレンスだけでどうやれば実装できるか考えて考えて、今思えば全然解決ではない方法だけを試して挫折して...
ファイルの読み書きもできないまま、オブジェクト指向の本質も理解せぬまま、WindowsAPIの存在も知らず、業務アプリのようなものの存在など一切知らないまま。
いまじゃすっかりコード書く仕事、主にWebとCLIだけのテキスト出力に囲まれて、
GUIに惑わされて倒れた当時のジレンマに比べれば幸せで仕方ないと思える日々です。
Re:中学生の頃VB4で (スコア:1, すばらしい洞察)
> 今思えば全然解決ではない方法だけを試して挫折して...
ここで諦めたかそうでないか、が分かれ道な気がします。
人はそれを才能と呼ぶ。
Re:近ごろの若者はかわいそう (スコア:1, すばらしい洞察)
「少年が自分で作ってみることのできる××と、物心つく前から当たり前のように触れてきている××との差が、あまりに大きすぎる」
の、「××」に入る言葉が、時代と共に変わってきているだけじゃないかと思います。
いまなら「プログラム」かもしれませんが、以前は「マイコン」だったり「電子回路」だったり「ラジオ」だったりしたんでしょうね。
「プログラム」の次には何が来るのでしょうか。
Re: (スコア:0)
GUIが当たり前の人がプログラミングを(自発的に)学習しようと思う理由なんてゲームを作りたいとかその辺のGUIゴリゴリ扱うものだと思いますが、実際にプログラミングの勉強を始めてみればやってることはわけのわからないコマンドを打ち込んでるだけ。いつまでたってもウィンドウの一枚も出てこない。それでいつの間にか飽きてしまうなんて人が多いのではないでしょうか?(私の周りに数人います)
CLIが当たり前の時代の人にとってはCLIのプログラミングが普通ですから違和感を感じないのでしょうが。
GUIみたいに「とっても高度なことやってるわりにわからないと実感しづらい」ことが増えている気がします。
ところで、CPUの動作が目で追えた時代があったと聞いたことがありますが、本当なんですかね?正直信じられないです(@21歳学生)
Re:近ごろの若者はかわいそう (スコア:3, 参考になる)
CPUは判りませんが、「300ボーモデム」時代なら、通信で流れてくる文字はそのまま読むことができました。(むしろ、読むスピードよりやや遅いくらい)
現在の数十Mbpsくらいで流れてくる速度では、さすがに生データはリアルタイムでは読めません。
ええと、この二つの速度差がピンと来ない若い方は、「送られてくるのがエスケープシーケンス文字アニメか、フルHD動画か」を想像してもらえれば判るかと思います。
# なに、今度はエスケープシーケンス文字アニメが判らない?
# うーむ、そりゃ困ったのぅ。
Re:近ごろの若者はかわいそう (スコア:2)
telnet towel.blinkenlights.nl
Re:近ごろの若者はかわいそう (スコア:1, おもしろおかしい)
なに、今度は telnet が判らない?
Re:近ごろの若者はかわいそう (スコア:2, 興味深い)
TCP/IPネットワークを構築して遊んでいた時期がありました.
# 知っている人は知っているかも...
そのTNCというデバイスの通信スピードは1200bps.
1200bpsという遅いスピードだったので,TNCをコントロールしているPCのモニター上で
実際にIP Packetが流れていくのをリアルタイムに見ることができました.
通信状況が悪くてリトライしてたり,逆に通信状況が良くなってWindow sizeが
大きくなってACKを待たずにまとめて送っていたり,pingの echo requestを送って
echo replyが帰ってくる様子を「見る」ことができました.
今の仕事をするうえで,そのやり取りをイメージできるのは非常に良かったと思っています.
Re: (スコア:0)
1.プッシュ・スイッチを押すごとにクロックを一発供給(ハード的なシングルステップ実行)
2.モニタ・プログラムで一命令ごとに次の命令をreturnに書き換えてから,call(ソフト的なシングルステップ実行)
昔のシンプルなプロセッサなら簡単に可能.
1.はバスにバッファを介してLEDをつなげば「目で追える」. 2.はモニタプログラムで状態表示.
今は組み込みプロセッサでもPLLが入ってたりしてクロック系亜が複雑なので1.は無理,しかも命令コードの自己書換も出来ないものが多く2.も難しい.(代わりに他の「高級な」デバッグ手段が準備されている)
Re: (スコア:0)
> 今は組み込みプロセッサでもPLLが入ってたりしてクロック系亜が複雑なので1.は無理,
PLLは動かさなければいいだけなのでそれはそれで問題ない気が。
むしろセラロック内蔵で外からクロックの入れようがないような石の方が手強い。
>しかも命令コードの自己書換も出来ないものが多く2.も難しい.
キャッシュが付いてるような高級な石は組み込みだと「多い」とはいえないのでは?
CPUの動作 (スコア:3, 興味深い)
> CPUの動作が目で追えた時代があったと聞いたことがありますが、本当なんですかね?
昔の大型汎用機のコンソール(机にキーボード、ディスプレイ、操作ボタンなどが
埋め込まれたもの)には、8桁程度の7セグメント表示器がついたものがありました。
これには常時CPUの実行命令アドレスが表示されていて、上位の桁を見ていれば、
現在どのジョブが実行されているか判断できたものです。また、下位数桁だけが
ちらついて、それより上位の桁にずっと変化がなければ、プログラムが無限ループ
していることもわかるわけです。
8BitCPUのICEがあれば (スコア:1)
仕事でZ80や647180のICEを使ってましたが、画面上に表示されるアドレスや割込み信号とかはある程度は目で追えていました。
ROMに焼く前にわざと、動作確認用として、サブルーチンのアドレスを判りやすく配置して確認したりとかも。
Z80のM1端子をLEDでモニターすれば、LDIRとかで長い時間ループしている最中かとをデューティー比による明るさとかで状況が判ったり、DMAでCPUが止まったままなのかとかも、目視はできましたね。
/* Kachou Utumi
I'm Not Rich... */
Re: (スコア:0)
そりゃICEさえあれば何でもできますがなw
問題はICEはクソ高いということです。
#いわゆるJTAG-ICEやROMエミュレータはICEじゃありません。
Re:近ごろの若者はかわいそう (スコア:3, 興味深い)
大学の情報工学科でプログラミングを教えています。こういう学科なのでプログラミングに関連する講義や
実習はそれなりに充実していますが、GUIを伴うプログラムの作成を教えている科目は一つもありません。
現在、学科のカリキュラム委員会で講義のリニューアルを検討しているのですが、他に教えるべきことが
沢山あるため、GUIの構成法などについてはいまのところ議題にあがっていません。これはうちにUI関連の
研究者が一人もいないためで、もしかすると他の大学ではもっと現代的なプログラム作成をカリキュラムに
取り入れているのかも知れませんが。
そういう私もGUIの作成経験なんてSmalltalkやJavaでちょっとしたおもちゃプログラムを書いたくらいしか
ありません。普段はMacで仕事していますが、30インチディスプレイのほとんどをターミナルエミュレータが
占めている状態です。研究関連のプログラムは昔からのコマンドラインで十分ですしね。まあ、オープンキャン
パス等で人目を引くデモができないのは何とかしたいところですが。
そのようなわけで、教える側がCUIに過剰適応(?)してしまっているせいか、なかなかGUIまで手が回らないのが
現状です。学生の興味を引くという点では改善の余地はあると思います。
Re:近ごろの若者はかわいそう (スコア:1)
GUIの画面を作るだけなら、OSが豊富なAPIを提供してくれるのでたいして難しくないですね。
ただ、一般的なデスクトップアプリケーションの作法なんかは勉強しないといけないですね。
データの読み書きをどういうタイミングでするかとか、そのデータはどういうフォーマットにするかとか、標準的なメニューの構成と振る舞いとか。あとレイアウトの基本とか。
あるテキストボックスに何らかの文字が入力されていなければボタンを押しても意味がないという場合に、入力されるまでボタンをディスエーブルにしておくなんていうのは、普段GUIのアプリを作っている人には当たり前のことかもしれませんが、はじめは教わらないと分からない人も多いと思います。
Re:近ごろの若者はかわいそう (スコア:1, 参考になる)
GUIプログラミングは、イベントドリブンプログラミングとなり、演習用プログラムの逐次処理とは異なるので、そういう観点では教える価値があるのではないでしょうか。
Re:近ごろの若者はかわいそう (スコア:1)
自分の知らないところで勝手にいろんなイベントが動いている。
どんなイベントが起きているのかを知っていればそれらを捕まえてそれなりの処理をさせることができるのですが、自分の知識では無理でネットで探してそのコードをコピペ。
それでもなんとなくやりたいことはできたからいいか、と。
で、よくわかっていないので意外なところで予想外の動作が起こっていてデバッグに苦労する。
VB.NETが無料で入手可能なので使ってみた。
ケアレスミスをかなり指摘してくれるようになっていてとてもありがたい。
というか、自分の不注意さを実感した。
プログラマーの質の低下をツールで補っているのか、便利ツールが質の低下をまねていてるのか。
私みたいなアマチュアにとってはありがたいツールですが。
Visualなんちゃらならコンポーネントを貼り付ける程度のGUIならなんてことないですが、問題はその先ですね。
Re:近ごろの若者はかわいそう (スコア:1, 興味深い)
>GUIプログラミングは、イベントドリブンプログラミングとなり、
>演習用プログラムの逐次処理とは異なるので、そういう観点では教える価値があるのではないでしょうか。
イベントドリブンといいつつも、GUIは基本がシングルスレッド且つ同期処理なので、
イベントドリブン自体はそんなに難しいとは思わないかな。しかし目的の動作を実現
するために、膨大なAPIのどれとどれを組み合わせる必要があるのかとか、その時の
落とし穴とかを調べるのがめんどい。
そういう意味では高い丸暗記&コピペ能力が求められるので、一般的なプログラミング
能力とは異なる素質が必要だとは言えるかも知れない。
(そしてGUIから入った人の中には、丸暗記&コピペ能力『だけ』は非常に高い
けれどそれ以外がまるでダメという人もいたりするから厄介だ。そういう人は
なまじ見た目が派手なデモを作るのには高い能力を発揮するので、上司には
非常に受けがいい。)
Re:近ごろの若者はかわいそう (スコア:2)
つ [s/GUI/ポインタ/g]
--- Toshiboumi bugbird Ohta
Re:近ごろの若者はかわいそう (スコア:1)
Re:近ごろの若者はかわいそう (スコア:1)
VistaでTelnetクライアントを利用する [atmarkit.co.jp]
Re:近ごろの若者はかわいそう (スコア:2)
プログラミングを人に教えたことがないし、最新のプログラミングも大昔のプログラミングも知らないので、ずれているかもしれませんが、僕の考えを書きます。
僕も一時期そう思っていましたが、考えを変えました。
以前は「GUI プログラミング」は高度なプログラミング技術の一つでした。プログラミングを知らない人がまず GUI プログラミングから始めるなんて想像できませんでした。しかし、今ではむしろ普通にプログラムと言えば GUI を使ったものであって、わざわざ「GUI プログラミング」などと呼ぶ方がかえっておかしいくらいです。
一方で、コマンドラインインターフェースが当たり前だった昔に比べて、開発環境も進化しています。今からプログラミングを覚える人は、例えばいきなり HTML 文書中の JavaScript などから入るわけでしょう。それだと GUI を使うこと自体はべつに難しくないのではないでしょうか。
もちろん、実際のプログラミングをする前に基礎 (仕組みの部分) を完璧に理解しようなどと言い出すと、 JavaScript のプロトタイプベースのオブジェクト指向とか、 Document Object Model とか、イベントモデルとか、目に見えないところで使われている高度な技術を理解する必要があってまず不可能でしょう。でも、基礎を理解しないでプログラミングに飛び込むことは十分可能だと思います。昔だって、 ROM-BASIC のインタープリターがどうやって動いているのかとか、 #include <stdio.h> とはどういう意味だとか、知らずにプログラミングを始めて、後から学んでいたわけで。
そんなに気張らなくても (スコア:1, すばらしい洞察)
自分(非プログラマのオッサン)の場合、
と順調に(?)手を広げてきましたが、
CUIだGUIだと気張らずに、そのとき必要なことをやっていれば
なんとなく自分がやっていることはつかめるんじゃないかと思います。
誰かにツール作ってあげて「GUI欲しい」と言われたら、
開発環境の標準コンポーネントを組み合わせてやればいいだけだし、
HTMLで適当なフォームでっち上げてインターフェースは
丸投げしてしまう手もあります。
#ruby便利すぎ
本当に「洗練されたGUI」を目指すなら
デザイナーとしての才能とか人間工学の知識とかも多分必要なので、
普通にプログラム書く人がそこまで頑張ることもないかなあと。
Re:近ごろの若者はかわいそう (スコア:1)
フリップフロップのリレーがバシャバシャ動くとこなら目に見えるかなぁ・・・
追えるじゃないし、CPUとは言いがたいですが
プログラミングは趣味にしとけば良いと思うよ。
生活基盤が安定してるほうが豊かだっていう別の意見に賛成ですね。
この手の仕事は大多数が安定とは無縁なんじゃないかなー
ウインドウを1枚出すプログラム (スコア:1)
それでは書いてみましょう。
Objective-Cっぽく書いてみました。gauche-gtkが必要です。
ネタなので、マクロの部分は省略しています。ウィンドウを閉じてもプログラムが終了しないですし。
Re: (スコア:0)
CUIなら、PRINT "Hello, world!" とかで済むのに、やっぱり複雑すぎると思います。
Re: (スコア:0)
#include
int main(int argc, char **argv)
{
printf("Hello world.\n");
|
と、Cでhello worldする程度には簡単だと思います。
Re: (スコア:0)
(display "hello, world") (newline))
より複雑だよ(以下エンドレス)。
Re: (スコア:0)
要は複雑になるかどうかはGUIかCUIかはあまり関係がないということです。
Re:近ごろの若者はかわいそう (スコア:1)
各々が付いたり消えたりするのでどんな処理してるのかが目で追えたと何かの本で見た覚えがあります。
#「こんにちはマイコン!」世代なので6001以前のハードはよくわからん
面倒過ぎますが(Re:近ごろの若者はかわいそう (スコア:1)
>ところで、CPUの動作が目で追えた時代があったと聞いたことがありますが、本当なんですかね?正直信じられないです(@21歳学生)
適当なラベルにトラップ仕掛けてJTAGデバッガ使ってインストラクション単位でステップ動作させるとか、あまつさえそのデバッガのログをリダイレクトして後から追跡するとかやりませんか?
# いや、まぁ、そんな真似最近じゃ複雑過ぎて滅多にやりませんが…
パソコンが8bitだった時代はJTAGではなく自己書き換えデバッガを使ったステップ動作でのトレースとか普通にあったし組み込みでは32bitであってもそれやらないとダメになる局面と言うのも未だにごくごくわずかながらありますよん。あんましやりたくないけど。
Re:近ごろの若者はかわいそう (スコア:1)
全部独習でアセンブラ, FORTRAN, LISP, HyperCard, C とやってきたが、使ってる Mac のアプリと同じ動作するように試行錯誤で GUI を何度も何度も作り変えるのが楽しいと思えるなら、プログラミングの壁なんてないな。
the.ACount
Re: (スコア:0)
「Core Memory―ヴィンテージコンピュータの美」がいいですよ。
http://www.amazon.co.jp/dp/4873113571/ [amazon.co.jp]
Re: (スコア:0)
若松通商でCASIOのポケコンが6千円くらいで投げ売りされてたから、そういうのを触ってみると実感できると思いますよ。
Re: (スコア:0)
Re:近ごろの若者はかわいそう (スコア:1, すばらしい洞察)
>最近、ボコスカウォーズを動画で見たけど、これなら作れるかもって希望がわいてきた。
今時のマシンでなら楽勝でしょう
でもこれをファミコンで作るのは結構しんどいと思うよ
Re: (スコア:0)
ソートのロジック1つとっても、ライブラリの充実や
ジェネリックの登場で再実装が不要になっていますし、
アニメーションやビジュアルの分野でも
クラスライブラリ側での実装やデザイナへの分業が進んでいます。
開発ツールやクラスライブラリも進化していますから、
むしろ書くものが無くてかわいそうという気がします。
Re: (スコア:0)
というか、(オペレーティング)システムが完成しすぎていて、ソフトウェアを実装する前に理解すべきことが多すぎるように思えます。
そのためかどうか、とりあえずゲームを作ってみたい少年たちはOSASKに集う、とのことです。
Re:近ごろの若者はかわいそう (スコア:1)
逆にOSやミドルウェアがそろっているので、それっぽい見かけのものならば簡単に作れるようになったと思います。
そんなものがなかった時代には、最悪ハードウェアのアーキテクチャ調べた上で「$xxxx(アドレス)に$n(データ)を書いて……」(これで点を一つ描画)ってのを延々と繰り返す(ってことやってくれるルーチンを作る)とこから始めなければならなかったんですよ。実際にはBASICなりCのグラフィックライブラリでそこらへんスキップできましたが。
「円」を描くのは「正二十四角形」を描く処理ですませばいい(画面解像度が320*200とか640*400だった頃の話)なんて、今じゃ「はぁ? 何言ってんのこいつ?」って思われるのがオチだろうなぁ。
ま、その代わりあの時代はrawレベルな情報もふんだんに出回っていたので、調べるのは(財布の中身さえあるならば)楽でしたね。
基本情報はパソコン付属のハードウェアマニュアルにあったし。
ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより
Re: (スコア:0)
ビットマップディスプレイが用意されているなんてすごく最近のマシンですね。
#その割にはアドレスが16bitしかないのが...。
Re: (スコア:0)
>>「$xxxx(アドレス)に$n(データ)を書いて……」(これで点を一つ描画)
>ビットマップディスプレイが用意されているなんてすごく最近のマシンですね。
>#その割にはアドレスが16bitしかないのが...。
何を基準に物を言ってるんだろう?
元コメは8bitや16bitのパソコンの話をしてるんだろうに。
そもそも$xxxxが16bitだというなら$nは4bitなのか?