【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】

【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】 at TECH

[前50を表示]
150:デフォルトの名無しさん
09/08/11 06:15:54
保守

151:デフォルトの名無しさん
09/08/11 18:56:52
Pythonって何で「普通に」文字列内で変数展開できないの？
3.0でもformat()とlocal()必要だし。どういう方針なんだろ。誰かおしえて。
これさえできればPython使いたいんだけど。

152:デフォルトの名無しさん
09/08/11 20:15:54
文字列内での変数展開なんて一部LLを除いたらおもいっきり邪道だと思うが。
PythonはReconstruct Cを目指した正統派LLというポリシーだからなあ。

153:デフォルトの名無しさん
09/08/11 21:55:00
LLといってもいろいろあるけど、変数展開はスクリプト言語的な機能だよな。
位置づけ的には
Java系カッチリ言語 <- Python ... Ruby . Perl -> シェルスクリプト系テキトー言語

154:デフォルトの名無しさん
09/08/11 22:10:23
変数展開があると、普段から変数に変な記号つくしな。

155:デフォルトの名無しさん
09/08/11 22:20:26
>>154
なにその間違った理解

156:デフォルトの名無しさん
09/08/12 10:04:38
>>151
>Pythonって何で「普通に」文字列内で変数展開できないの？
なんでだろうね。
Rubyのように文字列中に任意の式を埋め込めるようにするには、パーサをおもいっきり書き換える必要があるからめんどくさいけど、
変数展開ぐらいならできてもいいよね。
s = "x=${x}"
とか。
s = "x=%{x}" % locals()
とかかっこわるいわ。

157:デフォルトの名無しさん
09/08/12 11:29:20
>>151
tempita

158:デフォルトの名無しさん
09/08/12 11:33:11
eval

159:デフォルトの名無しさん
09/08/12 15:28:26
「変数展開をしないで文字列を書くときはシングルクォーテーション」とか
文字列書くときのルールを無駄に増やすのはPythonらしくない

それに比べりゃlocals()かっこわるいなんてｗ

160:デフォルトの名無しさん
09/08/12 15:30:47
>>159
> 文字列書くときのルールを無駄に増やすのはPythonらしくない

なんという・・・ｸﾏｰ

161:デフォルトの名無しさん
09/08/12 18:57:24
>>159
r"..." とか u"..." とか """...""" とかあるのに、なにがPythonらしくないだよ
信者乙

162:デフォルトの名無しさん
09/08/12 20:06:05
Python-Devでは5年以上前に議論された話題だよ。
変数展開はいつ評価するの？パース時？それとも実行時？
gettextと組み合わさったときはどういう挙動するの？そのほかの文字列メソッドとは？
セキュリティも怖いよね？

結局、文字列に format() メソッドを追加するのが一番汎用的で強力。
変数展開は str.format() よりも限定した状況にしか対応できず、
そんな限られた状況で「format(vars())」程度のタイプ数を削減するためだけに
言語規則を複雑にするメリットを見いだせなかったので却下された。

163:デフォルトの名無しさん
09/08/12 21:05:52
> gettext…
意味わからん。
変数展開って言語構造レベルの機能だから
メソッドには展開後の文字列が渡るだけでしょ

164:デフォルトの名無しさん
09/08/12 21:16:43
>>163
"$foo value is $bar"
というメッセージを国際化したくなったとき
gettext("$foo value is $bar")
って出来ないでしょ？
str.format() メソッドなら
gettext("{0} value is {1}").format(vars())
できる。 .format() の方が汎用的。

165:デフォルトの名無しさん
09/08/12 21:55:06
>>164
gettext('$foo value is $var');

166:デフォルトの名無しさん
09/08/12 21:58:38
>>165
gettextっていうのは渡された文字列をキーにして、
現在の言語の翻訳文を持ってくる。
それだとgettext()に渡される前に変数展開されてしまうから、
キーとして利用不可能。

167:デフォルトの名無しさん
09/08/12 22:07:08
>>166
リテラルの変数展開は普通、展開・非展開を使い分けるための記法が用意されてる。
PHP なんかだと ' では変数展開されず、" では展開される。

168:デフォルトの名無しさん
09/08/12 22:10:39
ただ結局HTMLみたいなののためなら、
テンプレートエンジン使う→変数展開ｲﾗﾈって話になる。

169:デフォルトの名無しさん
09/08/12 22:35:12
ほー、sprintf()じゃなくて%なのか。
perlにもformat/write有るけど、ほとんど使われてないね。
仕様がアレだからか。

170:デフォルトの名無しさん
09/08/12 22:36:37
で gettext() なんか使わないほうがよい？

171:デフォルトの名無しさん
09/08/12 23:31:05
使うのは構わんけど、そういうのに限って英語も日本語も中途半端なソフトが出来上がるからなあ。

172:デフォルトの名無しさん
09/08/12 23:55:17
>>162
>変数展開はいつ評価するの？パース時？それとも実行時？
解析はパース時、値の評価は実行時。
つまり "foo=${foo}." というリテラルがあればパース時に "".join(("foo=", str(foo), ".")) に変換してくれればそれでいい。
＃いくらなんでも、これくらいのことがわからないPython開発陣ではないだろ。162は分かってないかもしれないけど。

>gettextと組み合わさったときはどういう挙動するの？そのほかの文字列メソッドとは？
>セキュリティも怖いよね？

どれも意味不明。セキュリティって何だよ。変数の埋め込みができたらセキュリティ上問題になるのか。珍説すぎる。
自分ででっちあげた理由を、さもPythonでの公式見解みたいな言い方するのはやめて。自分だけの仮説なら、そうとわかる書き方にしようぜ。

> 結局、文字列に format() メソッドを追加するのが一番汎用的で強力。
> 変数展開は str.format() よりも限定した状況にしか対応できず、
> そんな限られた状況で「format(vars())」程度のタイプ数を削減するためだけに
> 言語規則を複雑にするメリットを見いだせなかったので却下された。

これソースある？実際に却下されたというソースがみたい。
それから変数を埋め込みたいのは、タイプ数削減もあるけど、わかりやすさ・読みやすさのためでもあるんだけどな。たとえば
"{0}: not found (file={1}, line={2})".format(name, file, line) より
"${name}: not found (file=${file}, line=${line})" のほうがわかりやすい。
もちろん短いことも重要。
"{name}: not found (file={file}, line={line})".format(**locals()) ← これ、いけてないよな。実行時にパースしてるから遅いし。

173:デフォルトの名無しさん
09/08/13 00:04:39
>>164
>"$foo value is $bar"
>というメッセージを国際化したくなったとき
>gettext("$foo value is $bar")
>って出来ないでしょ？

gettext()使うときに、だれもこんなことしないって。gettext()の引数はキーなんだから、こんなところで埋め込もうとは誰も考えない。
こじつけもいいところ。
str.format()のほうが汎用的なことと、埋め込み文字列がほしいこととは別の話だよ。
.format()をなくしてかわりに埋め込み文字列を導入しようという話ではない。
.format()もいいけど埋め込み文字列も欲しいよねという話なんだけど、信者にはわかってもらえなさそう。

174:デフォルトの名無しさん
09/08/13 00:05:08
ところで、最近なんでRubyが失速してきたんだ？
RoRバブルの崩壊でJAVA・PHP・Pythonあたりへの対抗力の限界が露呈された、ってところ？

175:151
09/08/13 00:09:36
うおおお、なんかみんな語ってる！
やっぱり言語仕様を複雑にするほど必要としてないって判断なんですかね。

まあ、オライリーのPythonチュートリアルで勉強中ですが、
クラス部分の実装の仕方に惚れたので、Python使ってこうかと思います。

あと、Pythonは正規表現がモジュールってところがいいですね。

176:デフォルトの名無しさん
09/08/13 00:15:16
そもそも、変数展開ってそんなに使う？

177:デフォルトの名無しさん
09/08/13 00:23:00
俺はPerlでもsprintf、RubyでもString#%使うなぁ

178:デフォルトの名無しさん
09/08/13 00:27:33
複雑に変数を埋め込むような場合は普通の文字列連結よりは見やすくなるね。
でも当然文字列のパースが入るからパフォーマンスコストは数倍になる。
最初は変数埋め込みばっかしてたけど最近は極力使わないようにしてる。

179:デフォルトの名無しさん
09/08/13 00:45:17
文字列のパース?そんなんコンパイル時だけだろ
パフォーマンスにほとんど影響しない

180:デフォルトの名無しさん
09/08/13 00:46:48
え？

181:デフォルトの名無しさん
09/08/13 00:48:00
Python的にTemplate/substitute機能ってどうなん？

182:デフォルトの名無しさん
09/08/13 01:32:35
>>167
ああ、そういう意味ね。で、結局gettext()で得られたメッセージに対する
変数展開は行われないんだ。

Perlみたいな変数展開を .format() や % で置き換えることはできるが、
逆は不可だ。言語仕様としても、 .format() や % は通常のメソッドや
演算子オーバーロードの範囲で実現できるのに対して、Perlみたいな
変数展開は言語仕様を汚さないと実現できない。

183:デフォルトの名無しさん
09/08/13 01:37:46
>>182
gettextで得られたメッセージに対する変数展開ってどういう意味？

184:デフォルトの名無しさん
09/08/13 01:53:02
勝手にやられるとうざいから、formatが良い落としどころだと思うけどな。

gettextって
print _("hoge: %s, %s") % (x, y)
ってやるだろうから、こいつに関しては展開要らない。

シェルスクリプトなら変数展開ほしいけど、pythonでほしいと思ったことってあんまり無い。
複雑になるなら"%(name)s" % locals()とかテンプレート使うなりする。
(awkでもprint "hoge" $1 "hoge" でいいし、、ちょっと複雑になってもprintfで事足りる)

185:デフォルトの名無しさん
09/08/13 01:58:30
>>172
URLﾘﾝｸ(www.python.org)
が Reject されて
URLﾘﾝｸ(www.python.org)
になった。詳しい議論はMLの過去ログ参照。
変数展開に能力を与えすぎると複雑だったり危険だったりするし、
能力を限定するとわざわざ言語仕様を汚す価値が無くなるので、
%とtemplateクラスの使い分けで十分と判断された。

186:デフォルトの名無しさん
09/08/13 07:32:13
>>178
>でも当然文字列のパースが入るからパフォーマンスコストは数倍になる。

やっぱりこいつわかってないよ。文字列リテラルが変数埋め込みをサポートしている言語なら、
コンパイル時に一度行なわれるだけだから、パフォーマンスに影響なんかあるわけない。
「パフォーマンスコストは数倍になる」とか無知もいいところ。

実行時に毎回パースして遅くなっているのは format() のほうだろ。
"{foo} is {bar}".format(**locals())
これをformat()が毎回パースしてるんだから、パフォーマンスコストが悪いのはどう考えてもこっちのほう。
Perl の "$foo is $bar" のように文字列リテラルが変数埋め込みをサポートしている言語なら、
コンパイルした時点ですでにパースは完了しているので、毎回パースする必要なんかない。

ところでセキュリティーの解説はまだなの?　なんで変数の埋め込みができるとセキュリティ上問題になるの?　
しっかり解説たのむぜ>>162

187:デフォルトの名無しさん
09/08/13 09:45:18
変数埋め込みだからセキュリティー上問題っていうのは何かあるのかな
意図しない埋め込みが起こるかもしれないぐらい？

188:デフォルトの名無しさん
09/08/13 09:49:21
sprintfやformatではおこらない、何か

189:デフォルトの名無しさん
09/08/13 10:03:34
変数埋め込みがセキュリティ的に危ないのなら、LLに限らずどの言語も危ないことになるな
すばらしい発見なのでさっさと報告してくれ

190:162
09/08/13 10:33:50
>>186
>>178 は俺じゃねーよ。

Python-dev では変数展開がプロポーズされてから、>>162のような議論があった、
というだけの話だよ。別にPerlやRubyや>>186の提案している仕様に脆弱性がある
というわけじゃなない。詳しく知りたかったら2002年の1月と6月のPython-dev過去ログ読め。
以下てきとうに要約。

*どの変数を展開するのかが実行時に決めると、安全じゃない文字列に対して危険
*なので導入するとしたらコンパイル時に $"${foo + bar} is $baz" が
(str(foo + bar) + " is " + str(baz)) に変換されるという仕様はどうだ。
これならセキュリティの問題は無い。
*でも、 % に比べると変数展開時にどの範囲の変数が利用されるのかわかり難いよね
*そんな仕様じゃgettextみたいなケースで使えない
*gettextを、 gettext("$foo is $bar", foo=hoge, bar=hage) みたいな仕様にしたら?
*言語仕様汚してそんな汎用性の無い機能入れるより、汎用的なテンプレートライブラリ
入れたほうがマシだ。

あと、MLでの議論の結果変数展開の代わりに選ばれたのは .format() や % のほうじゃなくて
Templateのほうで、こいつを使うとパースは一回で済むから、繰り返し使う場合は
こっちを使うべきだな。

191:デフォルトの名無しさん
09/08/13 17:46:35
PEP292でPEP215のセキュリティに言及してる部分がさっぱり分からん。
いやみっぽく書かれてるのは分かるけど。

192:デフォルトの名無しさん
09/08/13 17:50:46
いやだから gettext で変数展開は使わんと何度いったら…

193:デフォルトの名無しさん
09/08/13 18:29:14
>>192
だから、gettextでは使わないみたいに使える状況が限定される
変数展開より、広い状況で使える Template の方が良いよねっていう
議論をしてるんだってば。

194:デフォルトの名無しさん
09/08/13 18:37:46
>>193
意味がわからん。

それとも単に歯応えしたいだけ？

195:デフォルトの名無しさん
09/08/13 19:58:25
意味がわからん。

196:デフォルトの名無しさん
09/08/13 20:10:00
いい歯ごたえ！

197:デフォルトの名無しさん
09/08/13 20:13:48
リテラルでしょ？
たとえば、辞書のキーに使うこともあんまり無いだろうし、
特に問題無さそうだけどね。

198:デフォルトの名無しさん
09/08/13 20:21:21
歯応えｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

199:デフォルトの名無しさん
09/08/13 20:49:49
マジレスすると、口答えと歯向かう、がごっちゃになったんだろ
どっちも上から目線ではあるけど、それは敢えてだろうな

200:デフォルトの名無しさん
09/08/13 21:01:13
言いたいことは察せられる
「噛みつく」なら適切かと思う。表現って難しい

201:デフォルトの名無しさん
09/08/13 22:23:24
>186-189
C言語のprintfにはセキュリティホールがあるけど
LLでその書式文字列攻撃がどこまで応用効くか俺は判らんな。
ただ、printf/sprintf/format/% の書式指定文字列に変数埋め込みを使っちゃうと
予想外の挙動を招いてしまう可能性が高いのは間違いないよ。

202:デフォルトの名無しさん
09/08/13 23:37:55
そういや、ここのPythonユーザはみんな3.x使ってるの？
俺は本業Java趣味Pythonってこともあって、今日から移行することにしたんだが。

203:デフォルトの名無しさん
09/08/14 00:01:53
仕事2.5、趣味2.6だよ。
3.1は入れてあるけどほとんど使わない

204:デフォルトの名無しさん
09/08/14 03:39:07
特にprintfとprintで混乱したことは無いな。
予想外の挙動ってのがあるのか。
pythonこえー。

205:デフォルトの名無しさん
09/08/14 05:53:04
>>193
>だから、gettextでは使わないみたいに使える状況が限定される
>変数展開より、広い状況で使える Template の方が良いよねっていう
>議論をしてるんだってば。

gettext使う場合こそすごく限定されるだろ。使わない場合のほうが圧倒的に多い。
特殊な事例をさも一般的なことのように見せて反対するのはバカのすること。

>>201
>ただ、printf/sprintf/format/% の書式指定文字列に変数埋め込みを使っちゃうと
>予想外の挙動を招いてしまう可能性が高いのは間違いないよ。

それ、変数埋め込みに限った話じゃないし、変数埋め込みの欠陥ではない。

結局、なんとかしてPythonの仕様を正当化したいだけの信者にしかみえない。

206:デフォルトの名無しさん
09/08/14 09:58:41
いまのpythonにどういう風に導入したらいいと思う？
uとかrのまねして、e""みたいにすれば、影響範囲は少なそうだけど。

効率を考えなければ、Template("文字列").safe_substitute(vars())とかに置き換えればいいのか?

207:デフォルトの名無しさん
09/08/14 10:10:12
ｽﾚﾘﾝｸ(newsplus板)

208:193
09/08/14 11:06:30
>>205
gettextは目的が明確な専用ツールだし、言語仕様ではなくライブラリ。

それに対して、文字列に対して変数を展開するのは汎用的な要求で、
言語仕様に組み込むとすれば（PerlではなくPythonでは）できるだけ汎用に
いろんな目的に使えることが要求される。gettextと同じレイヤで語れない。

で、Templateならgettextに対応できて、Perl/Ruby方式変数展開では
対応できない。ならば汎用でしかも言語仕様を汚さないで済む方が良い、
というのがPython的な判断。

実際に string interpolation に対して gettext で使えねーと反論しているメールは
こちら。
URLﾘﾝｸ(mail.python.org)

209:193
09/08/14 11:20:41
ちなみに、gettextはリテラル以外の文字列に対する変数展開がほしいという
要求のわかりやすい例であって、gettextのためだけに interpolation が却下された
訳じゃないぞ。

210:デフォルトの名無しさん
09/08/14 11:30:39
>>206
既に str.format(**vars()) で実現できる以上、言語仕様を汚して15タイプを
削減する提案が通る見込みは無いだろうな。
あったらときどき便利な機能を言語仕様に際限なく組み込んでいけばPerlに
なってしまう。

211:デフォルトの名無しさん
09/08/14 16:14:51
俺的にはstr.format()で満足。信者だからかな？ｗ

212:デフォルトの名無しさん
09/08/14 16:20:45
おまえらお盆に何やってんだ

213:デフォルトの名無しさん
09/08/14 20:13:15
センスが悪くて誰もやらないようなことを持ち出して、
それを出来ないように蓋をするのがPython流なんだと理解した。

214:デフォルトの名無しさん
09/08/14 21:25:30
はいはい

215:デフォルトの名無しさん
09/08/14 21:40:14
別に蓋してない気がするけど。元々できないんだし。

216:201
09/08/14 23:05:48
>205
俺自身はRubyがメインだし、Pythonを正当化したワケじゃなく
>186-189の疑問に判る限りで答えただけ。
何がなんでも正当化したいなら「変数展開とeval()組み合わせたら～」とか言ってセキュリティーホールがあるって主張するし
わざわざ「printf/sprintf/format/% の書式指定文字列に変数埋め込みを」という限定を入れたりしないよ。

217:デフォルトの名無しさん
09/08/14 23:07:17
実際、変数展開ある言語だと何かもやもやするから、
Pythonにはいらんな。

218:デフォルトの名無しさん
09/08/14 23:26:36
組み合わせるまでもなく
evalだけでセキュリティホールだな

219:デフォルトの名無しさん
09/08/14 23:32:18
まあ、「何がなんでも正当化」をするなら、って話だからw

220:デフォルトの名無しさん
09/08/15 01:23:28
俺もない方がいいと思う。それこそがPythonの存在理由と思うから。Perlみたいな言語はPerlだけでいい。

221:デフォルトの名無しさん
09/08/15 04:30:09
Perl
my $price = 100;
print "price = $price";

PHP
$price = 100;
echo "price = $price";

Ruby
price = 100
print "price = #{price}"

222:デフォルトの名無しさん
09/08/15 05:32:15
JavaScript
price = 100
print "price = " + price

そろそろJavaScriptに、変数展開もsprintf相当の機能も
ないことに誰か言及してあげてもいいと思うんだ

223:デフォルトの名無しさん
09/08/15 06:58:06
>>222
ExtJS

224:デフォルトの名無しさん
09/08/15 06:59:23
>>210
>言語仕様を汚して

このへんが信者だよな。

225:デフォルトの名無しさん
09/08/15 07:09:19
全然目的が見えない。

226:デフォルトの名無しさん
09/08/15 11:00:20
JavaScriptを使う理由って、ブラウザ上で動くスクリプト言語が事実上JavaScriptしかないってだけだからな。

227:デフォルトの名無しさん
09/08/15 11:17:46
結局そこは、ブラウザの政治力学なのでしょうがない。

228:デフォルトの名無しさん
09/08/15 12:15:26
JavaScriptの近年の過大評価って、不良の善行、落ちこぼれの平均点みたいなところがあるよな。
最初はあんなにダメな子だったのに…という。

229:デフォルトの名無しさん
09/08/15 12:16:24
政治力学がよく解らんが、ブラウザとしてはそんなに多数の言語をサポートしたくないんだろう
HTMLとJSだけサポートするから、あとはサーバ側でやってよっていう
あんまり馬鹿でかいエンジンになられるのも嫌だから、俺はそれで良いと思う

230:デフォルトの名無しさん
09/08/15 12:26:47
>>229
サポートしたくないもなにも、誰も立候補してない

231:デフォルトの名無しさん
09/08/15 12:37:51
JavaScript、結構トリッキーなことが出来て面白いぞ。

232:デフォルトの名無しさん
09/08/15 12:57:46
言語としてはかなり先進的な方
あの普及率で、例えばクロージャが使えるのは珍しい

233:デフォルトの名無しさん
09/08/15 13:01:24
【Javascript,Perl,PHP】LLバトルロワイヤル7【Ruby,Python】

234:デフォルトの名無しさん
09/08/15 13:03:20
ウェブブームに便乗して注目されだした途端に起きた
JavaScriptの言語仕様を讃えれば通っぽいという風潮には飽き飽き。

235:デフォルトの名無しさん
09/08/15 13:13:37
JavaScriptダメな子
JavaScriptやればできる子
JavaScriptでもやっぱりダメな子

236:デフォルトの名無しさん
09/08/15 15:02:15
Firefox上のJSはかんりできる子なんだけど
IEのJSがそこそこだから全体的に評価が引っ張られてる感じ

237:デフォルトの名無しさん
09/08/15 21:40:06
えぇっ？イベントやDOMとかで無く、言語のレベルで違いってあった？
パフォーマンスとかって話？

238:デフォルトの名無しさん
09/08/15 22:19:15
debugger

239:デフォルトの名無しさん
09/08/16 00:33:06
>>237
letとかってIEでも使えるの？

240:デフォルトの名無しさん
09/08/16 01:33:02
getter/setterや分割代入なんかもIEにはまだ無かった気がする
あと、E4X

241:デフォルトの名無しさん
09/08/16 04:08:52
iteratorとかgeneratorとかクロージャ記法とか
要はjs1.7以降の新機能

242:デフォルトの名無しさん
09/08/16 14:22:09
バージョンの違いか。理解しました。

243:デフォルトの名無しさん
09/08/20 18:54:48
まあIE6で動作しないと不可なんだけどね

244:デフォルトの名無しさん
09/08/20 19:03:45
コンマを1つ付けただけで動かなくなるIEに絶望した。

245:デフォルトの名無しさん
09/08/20 19:11:48
CやJavaの流れで付けても動いてよとは思うが、仕様的にはIEが正しいぽいな。

246:デフォルトの名無しさん
09/08/20 20:24:20
やっとIE6を捨てる流れになってきてるね

247:デフォルトの名無しさん
09/08/20 20:41:43
>>246
流れ、ってだけなら、IE8が出た辺りからずっと。
URLﾘﾝｸ(gs.statcounter.com)
ようやく、普通に勧めて反発を食らいにくくなってきた、っていう感じ。

248:デフォルトの名無しさん
09/08/20 22:17:24
ブラウザ依存のサイトなんてうんこだよ。

249:デフォルトの名無しさん
09/08/20 22:21:21
コストや表現力って問題があるんだよ。
ぶっちゃけ、一通りの記述で済めば特定ベンダー以外のみんなが幸せになれるんだ。
それを阻害するブラウザこそがうんこだよ。

250:デフォルトの名無しさん
09/08/21 00:07:09
結論としてはブラウザは全部うんこ

251:デフォルトの名無しさん
09/08/21 08:38:47
全機能を完全な形の完全な見栄えでIE6にも提供する無論追加料金なしとかアホなことが蔓延してるからだ
イマイチ外見に基本機能プラス程度でいいのならやってやるさ
いまさらIE6使ってる一般人向けサイトなんてケータイサイトをCSSで光らせる程度でいいんだよ

252:デフォルトの名無しさん
09/08/21 09:57:40
結論としては http/javascript は全部うんこ

253:デフォルトの名無しさん
09/08/22 02:50:42
そのうんこをこねくりまわして納期までになんとかすんのが俺らの仕事

254:デフォルトの名無しさん
09/08/22 02:56:08
>>251
一応言っておくと、MSが想定する「一般人」は、大抵IE7か8を使ってる。
自動アップデートだし。
微妙すぎる自称玄人もしくは自称マニアのみが、IE6。

あとはまあ、会社でIE6縛りってのもあるっちゃあるが、それは好きで
やってる訳じゃないし、個人批判の対象にはあんまりしたくはない

255:デフォルトの名無しさん
09/08/22 11:06:07
IE6って、Windows98とかMeとかの古いPC使ってる人なのかと思ってたが
マニアが使ってるの？

なんかピンとこないな

256:デフォルトの名無しさん
09/08/22 11:33:35
ネットバンキングとかの主要サービスでも
IE6しか対応していないというところがあるよ。

257:デフォルトの名無しさん
09/08/22 13:42:13
うちの出先は全てにおいて2k/IE6前提

258:デフォルトの名無しさん
09/08/22 13:51:53
IE6ってまだトップシェアじゃないっけ？

259:デフォルトの名無しさん
09/08/22 14:17:00
>>258
韓国の方ですか？

260:デフォルトの名無しさん
09/08/22 14:24:25
あぁ、トップはもうIE7に切り替わってたんだねｗ失礼しました

例えばこの調査だと4人に1人がまだIE6だね
URLﾘﾝｸ(internet.watch.impress.co.jp)

261:デフォルトの名無しさん
09/08/22 14:27:42
勘弁してほしいよね

262:デフォルトの名無しさん
09/08/23 17:54:57
IE6ユーザが減ってきてるのはありがたいが、HTML5の動きを
誰かに止めて欲しい。なんでXHTMLじゃないんだよｗ

263:デフォルトの名無しさん
09/08/23 20:11:25
HTML5でもapplication/xml+xhtmlなxmｌで文章を書けてそれはXHTML5と呼ばれる
XHTML2固有の機能が使いたいというならもっともだけどなんかあったっけ

264:デフォルトの名無しさん
09/08/23 20:12:43
application/xhtml+xmlだった

265:デフォルトの名無しさん
09/08/23 20:45:19
>>264
まあ、IEは8になってもそれを解釈できないんだけどな
これはIEというよりはWindowsも含めた問題かもしれんけど

266:デフォルトの名無しさん
09/08/24 00:10:37
>>262
xは規約がガチガチすぎたわりには
使い勝手がよくなかった。

初心者向きでもなかったし、
ＨＴＭＬというのはもっと気軽に書けるべきもの。

267:デフォルトの名無しさん
09/08/24 00:33:24
xhtmlの存在意義はxmlパーサでパースできることかと
htmlのいいパーサがあればそれでいいんだけどね

268:デフォルトの名無しさん
09/08/24 11:52:05
> 初心者向きでもなかったし、
> ＨＴＭＬというのはもっと気軽に書けるべきもの。

という思想の人が、入れ子が互い違いになってたり、
どうにもパースに困るようなコンテンツの量産を奨励するわけですね。

269:デフォルトの名無しさん
09/08/24 12:24:42
手軽に書きたい人は手書きで書くなよ。

270:デフォルトの名無しさん
09/08/24 12:33:10
そーいやホームページビルダーってまともになったの？

271:デフォルトの名無しさん
09/08/24 12:38:34
むしろ、手軽に書きたいから手書きなんだが

272:デフォルトの名無しさん
09/08/24 12:55:02
HTML5はムダにアグレッシブすぎるよね。
誰得つか、理想論すぎる印象が強い。
成功しないと思うんだが。

273:デフォルトの名無しさん
09/08/24 13:51:30
俺はWYSIWYG嫌いだったし、手書きも面倒だと思ってたから
タグエディタっての使ってたな
基本機能としては普通の色分け付きエディタなんだけど
各種タグ補完やタグの一覧からの選択ができて
各タグごとのオプションがダイアログでも弄れたり、整合性チェックやプレビューのついてるやつ

274:デフォルトの名無しさん
09/08/24 15:09:17
>>266
html5が初心者に優しいかどうかと言ったら全然そんなこと無いと思うけど
そもそもhtmlの仕様上タグを省略してよい箇所を完全に把握できる時点で初心者じゃない
ブラウザ間の解釈の相違もあるし初心者こそタグの省略をすべきではない

>>272
xhtml2と比較したらまだマシだろｗ
それに実装を先行させてるからそれほど仕様と実装が乖離するとも思えない

275:デフォルトの名無しさん
09/08/24 15:53:03
xhtml2は本当に誰得だったな。
5はIE以外ではすぐに実装されるだろうな。

276:デフォルトの名無しさん
09/08/24 23:02:26
HTML5はブラウザベンダー主導で策定していて、
複数のブラウザで実装されたら仕様にするというやり方にしているので、
XHTML2のようなことにはならないかと。

277:デフォルトの名無しさん
09/08/25 09:00:33
そうやってがんばってHTML5がリリース
されても、どうせIE+SLが勝つ気がする。

278:デフォルトの名無しさん
09/08/25 10:20:57
SLって何かと思ったらSilverlightか。

279:名無し学生
09/08/25 10:37:16
Visual Basic の課題で困っております。
誰かお答えください。本当に助けてください。

１．Visual Basicの関数で数値を文字に直すCStr()とStr()の違いについて

２．戻り値の違いが確認できる方法を考え、戻り値の違いについて実際に確認し、
　　その確認方法と違いを具体的に述べよ。
注意：実際にやったことと、確認した違いを簡潔かつ具体的に書くこと。

３．下記の計算結果などから、Visual Basicで計算できる数値の桁数について考察をまとめ、
　　何故そのような制限があるかについて理由を答えよ
　　１）　48 x 100 - 81
　　２）　12 ÷ 9.3 x 247
　　３）　0.2 - 12 ÷ 69
　　４）　-12 ÷ 100 + 100

280:デフォルトの名無しさん
09/08/25 11:22:29
>>279
help読みなよ。
学生なんだから、その位やりさない

281:デフォルトの名無しさん
09/08/25 11:24:59
マルチポスト報告スレ
ｽﾚﾘﾝｸ(tech板)

ｽﾚﾘﾝｸ(tech板:688番)
ｽﾚﾘﾝｸ(tech板:183番)
ｽﾚﾘﾝｸ(tech板:793番)
ｽﾚﾘﾝｸ(tech板:388番)
ｽﾚﾘﾝｸ(tech板:601番)
ｽﾚﾘﾝｸ(tech板:408番)
ｽﾚﾘﾝｸ(tech板:711番)
ｽﾚﾘﾝｸ(tech板:279番)
ｽﾚﾘﾝｸ(tech板:60番)
ｽﾚﾘﾝｸ(tech板:937番)
ｽﾚﾘﾝｸ(tech板:963番)
ｽﾚﾘﾝｸ(tech板:547番)
ｽﾚﾘﾝｸ(tech板:861番)
ｽﾚﾘﾝｸ(tech板:420番)

282:デフォルトの名無しさん
09/08/25 12:10:00
課題でVBはねーよ

283:デフォルトの名無しさん
09/08/25 21:25:39
　　　URLﾘﾝｸ(www.jiji.com)

　　ﾜﾛw

284:デフォルトの名無しさん
09/08/25 21:37:29
今回改修対象でないのに勝手に改修したのか
URLﾘﾝｸ(www.kahoku.co.jp)

285:デフォルトの名無しさん
09/08/29 11:16:25
人イネ～!?
LLTV開催中‼

286:デフォルトの名無しさん
09/08/29 12:09:16
ですねー。そういう国ですからね。
向上心あるプログラマなら飽きちゃうと思う。

287:デフォルトの名無しさん
09/08/29 12:31:46
政治的発表だよ。そういうのはｗ

288:デフォルトの名無しさん
09/08/29 14:07:55
東京だからなー。
新幹線か飛行機になる。

知り合いが居れば別だろうけど、こっち方面では居ないし。

289:名無しさん＠そうだ選挙に行こう
09/08/30 18:08:55
HSPもいちおうLLだよね？

290:名無しさん＠そうだ選挙に行こう
09/08/30 18:10:19
あーうんまあ一応は

291:名無しさん＠そうだ選挙に行こう
09/08/30 18:38:25
特定用途(ミニゲーム)のための言語だし、グラフィックライブラリが重視されてるし、まあ良いんじゃない

292:名無しさん＠そうだ選挙に行こう
09/08/30 19:42:00
DSLとLLって直行する概念？

293:名無しさん＠そうだ選挙に行こう
09/08/30 19:50:22
ぶっちゃけDSLは言語ではない。

294:デフォルトの名無しさん
09/08/30 20:41:00
>>293
Languageと付いている以上「言語」には違いないと思うが。
汎用プログラム言語ではない、というのが適切かと。

295:デフォルトの名無しさん
09/08/30 21:18:26
そもそも、プログラミング言語ってなんで必要なの？って話だよな。
RADが発達すれば将来的には図だけでプログラミングできるんだろうし。
言語ベースってのがいまいち間違った発想な気がして。

296:デフォルトの名無しさん
09/08/30 21:26:08
うん、20年前くらいから同じようなこと言ってる
たぶん、20年先も同じようなこと言ってるはずだ

297:デフォルトの名無しさん
09/08/30 21:26:43
>>295
それはないと思うｗ
未来はＴＶ電話だ！みたいな発想だと思われｗ

298:デフォルトの名無しさん
09/08/30 21:28:52
一応、JavaBeansのような感じで

　・部品を作るプログラマ
　・部品を利用する一般ユーザー

に二極化するだろうとは予想されている
極めて明快視覚的に自由に結合・動作可能なライブラリってことだな

でも、野良ライブラリとか自作ライブラリとか作る人はやっぱ
言語ベースで従来型のプログラミングしてるはずだ

299:デフォルトの名無しさん
09/08/30 21:34:00
我々が相手に何かを伝えたいとき、
口頭にせよ文章にせよ、使うのはもちろん言語だろう
であれば、計算機に対して同じ方法をとるのは自然な発想ではないか

グラフィカルな記述の最大の問題点は、記述密度が低いことだろうなあ
フローチャートぐらいじゃ文字に勝てない
もちろんメリットが生かせる部分では、どんどん採用されていくだろうが

300:デフォルトの名無しさん
09/08/30 21:34:07
アニメとかドラマとか、そういうのでわかりやすく表現されてはいるけど
結局中身を理解しないといけないのは変わらないんだよね

ロボットの行動プログラムとして一部あるぐらいしか有効利用されてるのが思いつかん

301:デフォルトの名無しさん
09/08/30 21:39:51
分岐条件を表現できない時点でゴミ

まあ、天才のブレイクスルーに期待してみよう

302:デフォルトの名無しさん
09/08/30 21:42:50
>>298
低俗な話になるけど、
ニコニコのMADややる夫のAAとかの世界だと（意図しない）二極分業化がかなりすすんでるよな
あのあたりが流行るのって一重に素人でも扱える「部品」がそこらへんに転がってるからだと思うんだ。

今でもライブラリは転がってるけど、
素人が利用できる部品ってどれくらいあるんだろう。

>>299
>>301
つうかフローチャートは再利用を前提としていない時点でゴミ

303:デフォルトの名無しさん
09/08/30 21:44:31
分岐とループぐらいは書けるよ
そういう部品が用意されてるから

304:デフォルトの名無しさん
09/08/30 22:37:00
条件分岐の記述と分岐条件の記述にはウンコとウコンくらいの違いがある

305:デフォルトの名無しさん
09/08/31 06:46:38
現状で図だけでプログラムできる言語はあるけど
全ての分野において使いやすいもににはなっていないしならないと思う

306:デフォルトの名無しさん
09/09/03 01:44:06
低能言語使ってる俺らが部品ってことはないしょ

307:デフォルトの名無しさん
09/09/14 17:30:23
> 730 名前：デフォルトの名無しさん [sage]： 2009/09/14(月) 15:34:52
> Python 3.0 は過去のしがらみを捨てた大掃除なんだから、比べるとしたらRuby 1.9じゃなくてRuby 2.0だろ常考・・・

Python 3.0は順調に出たから、ぜんぜん順調じゃないRuby 2.0なんか全く比較にならんだろ。

308:デフォルトの名無しさん
09/09/14 18:46:17
Python 2.x と Python 3.0 両方で動くプログラムを書くのが難しいのは最初からそう
設計されているからで、この点は Ruby 2.0 に近い。
単に、Pythonの大掃除が決行された時期と Ruby の大掃除が決行される時期が
違うだけの話。

なので、Python 3.x と 2.x 両方で動くプログラムを書くのが Ruby 1.9 と 1.8 両方で
動くプログラムを書くのが難しいというのは、 Python が Ruby よりも互換性を軽視する
根拠にはならない。比較するなら Python 2.7 と Python 2.6 にしておくべき。

309:デフォルトの名無しさん
09/09/14 22:01:52
そういう見方でなんでPythonとRubyを比較せにゃならんのか解らんが。

メジャーバージョン違いとマイナーバージョン違いは全然意味合いが違うだろうに。

そもそもRubyは「その時楽しければいい言語」なんで互換性でPythonと比較するのは
間違っていると思う。

310:308
09/09/14 23:45:57
>>309
バージョン管理スレで、Rubyの方がPythonよりもバージョン間の安定性があるという
ことをPython3を引き合いに出して主張する人がいてね・・・

311:デフォルトの名無しさん
09/09/15 00:42:57
Rubyは脳力消費が低い言語だお

312:デフォルトの名無しさん
09/09/15 05:19:34
Rubyはやたらと重かった記憶しかないんだが
何かと勘違いしてるのかもしれん・・・

313:デフォルトの名無しさん
09/09/15 06:12:23
信者がうざい三大ソフト

Ruby　Sai　メタセコ

314:デフォルトの名無しさん
09/09/15 08:51:41
RubyはWeb2.0のSaaSをクラウドするのに最適な言語

315:デフォルトの名無しさん
09/09/15 08:53:07
ユビキタスしたいときはどれがいいですか？

316:デフォルトの名無しさん
09/09/15 09:36:53
>>312
処理系は重いね。でも書くときは楽だなあ。
やたらメソッドチェーンするお陰で、カーソルを前に戻す頻度が少なめ。
Pythonのやり方も解るんだけどね。あっちのが安全性は高いだろうし。
サクッと書くのはRuby、スクリプトなんだけどカッチリ書くときはPython使ってるわ。

317:デフォルトの名無しさん
09/09/15 18:05:54
>>316
オレは全部Perl。

318:デフォルトの名無しさん
09/09/17 01:08:52
>>316
括弧いらんおかげでメソッドチェーンは本当に書きやすいけど、
その代償に括弧がメソッドコールじゃないし、関数がオブジェクトじゃないから
__send__とか。。。ここらがPythonの方が決定的に好きなところ。
StringクラスがあるのにSimbolはクラスじゃないんかい、みたいな。

319:デフォルトの名無しさん
09/09/17 01:32:32
Rubyは、「こういう場合はこう書きたい」という感覚を重視して、
Pythonは全体の整合性を重視している感じだね。

320:デフォルトの名無しさん
09/09/17 07:59:44
F#も()付けないようだな。

321:デフォルトの名無しさん
09/09/17 08:17:06
そこでまったくパラダイムの違う言語を例に挙げてもだな・・・
OCamlは()無しですごく一貫性が取れてるだろ。

322:デフォルトの名無しさん
09/09/17 08:23:35
Haskellもだよ。

323:デフォルトの名無しさん
09/09/17 08:40:17
問題にしているのは括弧があるかないかではなくて一貫性であって、
括弧が無い代わりにほかの部分にしわ寄せが行っていたら意味が無い。

x = y (言語によってletなどがつく) という構文でyを関数呼び出しとして
扱うのは、例えば y = 3 としたときにすら y が 3 を返す関数になる、
手続き言語的な変数の無い関数型言語だから一貫性が取れている。

Rubyの場合、yが何かによって x = y の意味が変わってしまう。

324:デフォルトの名無しさん
09/09/17 09:01:16
そういうのはPerlから受け継いでるんだろうな。

325:デフォルトの名無しさん
09/09/17 10:42:06
Rubyで関数呼び出しを括弧必須にしたところで、メリットがあまり無いんだよなあ。
Ruby的には関数はオブジェクトでは無く、オブジェクトの機能でしか無いから
括弧無しの動作はエラー以外には取れない。
「関数オブジェクトを取り出す」なんて操作にすると文法自体にメスを入れることになる。

ちなみにPythonの場合、関数呼び出しに括弧が要る、というよりは
オブジェクトに対して呼び出しを試みるのが括弧、というのが正しいと思う。
括弧を付けない場合が関数オブジェクトの取り出しなんじゃなく
普段から関数オブジェクトを取り出していて、そこに括弧を付けて呼び出してる。

でも関数がオブジェクトではないRubyの場合、そうはいかない。
関数はオブジェクトの機能でしか無いので、関数を実装したオブジェクトを取り出すことになると
それこそ文法が崩壊してることになる。

326:デフォルトの名無しさん
09/09/17 11:18:55
つまりRubyにはファンクタしかないってことなのか？

327:デフォルトの名無しさん
09/09/17 11:45:18
真の意味での関数オブジェクトは無いと思うよ。
一応、似たことができるようにProcとかMethodとかUnboundMethodってクラスはあるけど
これらは、単独でオブジェクトとしては存在しえない関数をラップする為のクラスだし。
当然ながら、これらにラップされた関数を呼び出すには
括弧を付けてもダメで、call()などのメソッドを呼ばなきゃならない。

328:デフォルトの名無しさん
09/09/17 12:07:29
真の意味でもなにも、ないよ。

括弧を付けてもダメなのは、文法上の理由もあるけど。
（Javaも同じだけど、関数（手続き）オブジェクトという存在がないことを前提に
言語がデザインされている）

329:デフォルトの名無しさん
09/09/17 14:57:46
>>328
>（Javaも同じだけど、関数（手続き）オブジェクトという存在がないことを前提に
>言語がデザインされている）

Procがあるから、関数オブジェクトが存在しないというのは言い過ぎじゃないかな。
正確には、メソッド名と変数名の名前空間が分けられている、といったほうがいいような。

330:デフォルトの名無しさん
09/09/17 21:53:34
やっぱり、
y　=　f(x)
F　=　f
なら
Y　=　F(x)
だな。

331:デフォルトの名無しさん
09/09/17 23:57:26
>>330
どゆこと？

332:デフォルトの名無しさん
09/09/18 00:00:01
Y = y
ということだろう

333:デフォルトの名無しさん
09/09/18 00:01:50
ひとまわり大きくなるってことかと思った

334:デフォルトの名無しさん
09/09/18 01:22:21
「Rubyは完全性一貫性より自然さを感じる。」
URLﾘﾝｸ(d.hatena.ne.jp)

335:デフォルトの名無しさん
09/09/18 01:50:33
俺が無知だっただけかも知れないけど、$_POSTで受け渡しの文字化けを調べていたんだけど、
「無」という文字（１字文字列）を受け取って正規表現で文字列の前後の空白を除いたら、本当に
「無」（つまりnull）になってしまって、エラー表示されまくりだった。

試しにPHPで構築されている、とあるサイトの入力欄に「無」の１文字だけ入力して送信したら見事に
エラーになったみたいで（画面が真っ白）処理が止まってしまった。

EUC-JPからUTF-8にconvertするときにおかしくなっているような気がするが、原因はよく分らん。
誰か手練の人がいたら解明して欲しい。

336:デフォルトの名無しさん
09/09/18 01:53:38
>>335
1.PHPのMLにでも投げろ
2.WebProg板に適当なスレがあるだろ
3.せめてその正規表現とやらをさらせ

そのあとで、このスレでの有用なレスを期待してくれ。もしかしてマルチ？

337:デフォルトの名無しさん
09/09/18 02:32:30
>>336

メーリングリストでは参加しているPGの数が少なくて、というか初耳という奴が多かったので
こっちに出してみた。正規表現は

$title = preg_replace('/^[　 ]*(.*?)[　 ]*$/', '$1', $title);

$_POST で $title の奴を受け取って正規表現で半角と全角の空白を除去。
その後echoで表示させたら無表示。文字化けだったら？なんだけどnullなのでなんの表示も無し。
mb_convertで色々試しても反応無し。
「無」の文字だけなのよ。「鼻」とか「法」「院」だったら？なんだけど、「無」のときはnullに
なってしまってる。よく分らん。

338:デフォルトの名無しさん
09/09/18 02:40:27
追加

空白除去の正規表現がおかしいと思ってオミットしたら、「無」の受け渡しが
？で表示された。だからたぶん「無」の１文字をPOSTで渡して正規表現で空白除去するところで
おかしくなっているのだと思う。
だって適当に探ったPHPで構築されているサイトで「無」を入力したらおかしくなったもん。

ここなら見てる人が多いかなっと思って聞いてみたの。

339:デフォルトの名無しさん
09/09/18 02:44:21
>>334
平鍋はまともだけど
まつもとは自分勝手で
顧客のこと全然考えてないってことが分かった

340:デフォルトの名無しさん
09/09/18 07:47:03
何を今さら。

341:デフォルトの名無しさん
09/09/18 11:14:11
自分勝手ぶりはGvRも似たようなもんだろ。
どちらもコミット拒否権持ってるし。

342:デフォルトの名無しさん
09/09/18 14:48:15
コミット権は自分勝手とは言い切れないが
平鍋が「顧客の満足」を強調しているのに
Matzは「自分の満足」しか表明していない件

343:デフォルトの名無しさん
09/09/18 16:49:43
>>342
役割分担して答えてるからそうなるよね。
まぁそうでなくても俺言語作者なんてそんなもんだけど。

344:デフォルトの名無しさん
09/09/19 01:03:45
>>295
>RADが発達すれば将来的には図だけでプログラミングできるんだろうし。

それ10年以上前にも言われていた。
結局、図でのプログラミングって特定用途限定なんだよね。

345:デフォルトの名無しさん
09/09/19 05:19:06
そのうち詩でプログラミングできるようになるよ

346:デフォルトの名無しさん
09/09/19 05:31:12
マルチタッチのディスプレイがマウスくらい普及するころには、図によるプログラミングも一派的になるかもね。
そして、文脈によって太矢印の解釈が違う言語とか、楕円を多用するために見た目がスカスカになる言語とかが登場する。

347:デフォルトの名無しさん
09/09/19 08:39:45
0が偽じゃないなんて・・・めんどくさい！

348:デフォルトの名無しさん
09/09/19 09:39:35
"0" が偽なのもめんどくさいけどな。

349:デフォルトの名無しさん
09/09/19 09:45:27
＞結局、図でのプログラミングって特定用途限定なんだよね。

用途限定なんだろうけど、SQLは実現しているんじゃね？
Eclipseでもソレっぽいプラグインとかあるし。

ただ、SQLを直打ちでテキストで適度に整形した方が図よりも理解しやすい場合が多い。

350:デフォルトの名無しさん
09/09/19 09:57:59
>>348
文字列を判定に噛ましてるのがアホなだけじゃん。

351:デフォルトの名無しさん
09/09/19 10:03:19
それは単純なSQLだけだろ。ORMだって、浅いレベルならSQLまったく意識せずに済むし。

352:デフォルトの名無しさん
09/09/19 10:32:53
プロパティにundefinedが代入されていることがあるのもめんどい

353:デフォルトの名無しさん
09/09/19 10:34:21
俺銀行で芸術的なクエリ見た事あるな。
Access+ODBC(OracleやDB2)だったけど。

普通のプログラマには銀行の要求する算術を理解できないので、
行員がクエリを作ってたりするけど、かなり感動を覚えた。

354:デフォルトの名無しさん
09/09/19 10:37:43
Accessのクエリエディタはホントすばらしいと思う

ただ、ブラウザとVBエディタが何とかなって欲しかった

355:デフォルトの名無しさん
09/09/19 10:49:10
SQLをプログラミング言語って言う香具師は
HTMLもプログラミング言語だと思ってそうだな

356:デフォルトの名無しさん
09/09/19 10:53:02
VBには芸術的な「マクロの記録」があるだろ
あれこそ究極のイメージプログラミング

357:デフォルトの名無しさん
09/09/19 10:53:47
ガラクタ箱の中身という意味ではどれも同じ

358:デフォルトの名無しさん
09/09/19 11:01:44
ポカーン？

359:デフォルトの名無しさん
09/09/19 11:10:03
>>355
OracleのSQLなんかはチューリング完全なんだがそれでもプログラミング言語でない？

360:デフォルトの名無しさん
09/09/19 11:18:26
>>359
PL/SOLと勘違いしてない？

361:デフォルトの名無しさん
09/09/19 11:25:17
HSPもチューリング完全です(^o^)

362:デフォルトの名無しさん
09/09/19 11:30:37
URLﾘﾝｸ(www.valuedlessons.com)

ちなみに、共通テーブル式が導入されたのはSQL:1999で、ウィンドウ関数はSQL:2003からね。

363:デフォルトの名無しさん
09/09/19 11:44:26
brainfuckのインタープリタもどこかで見たな

364:デフォルトの名無しさん
09/09/19 13:19:07
>>356
あれは良いよねぇ。
いったんあれで操作して関数名を調べてから，
WIN32Ole で書き直したりしてる。

365:デフォルトの名無しさん
09/09/19 13:58:39
HSPとRubyってどっちがいいの？

366:デフォルトの名無しさん
09/09/19 13:59:50
びっくりするくらい頭の悪い聞き方だな

367:デフォルトの名無しさん
09/09/19 14:29:36
Ruby, Phthonのことを書いてね。

368:デフォルトの名無しさん
09/09/19 14:33:26
友達にHSPかRubyがいいと勧められたので・・Perlもいいかなと思ってます。

369:デフォルトの名無しさん
09/09/19 15:05:30
VBでいいんじゃね？どうせWindowsでしょ？
あえてHSPを選択する意味ってどんなのがあるんだろう。

370:デフォルトの名無しさん
09/09/19 15:14:50
＞SQLをプログラミング言語って言う香具師は

アレは構造化照会言語（ｗ）であってプログラムとはちょっと違うだろ。

手続きを記述すると言う意味においては似てるだろうけど、
集合論でデータを操作する事に特化しているから、
従来のプログラムとかの経験がない人でもそこそこにコード(?)が書けるのがメリット。

個人的にはTrueとFalseとNullの概念がある偉大な言語とは感じるが。

371:デフォルトの名無しさん
09/09/19 15:19:48
速報：グーグルが新言語「Noop」を公開。JavaVMで動作－ Blog on Publickey
URLﾘﾝｸ(www.publickey.jp)

次ページ