2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2009/07/25(土) 11:03:24
最強のLL=軽量プログラム言語は、どれよ?

エントリーは、Perl、PHP、Python、Ruby、JavaScript・・・
さあ、死ぬまで語りやがれ!!!

■LLとは?
軽量プログラミング言語(Lightweight Language,LL)とは、取り回しに優れ、
コードの作成や修正が容易と見なされるプログラミング言語のことを指す。

ここでいう「軽さ」はプログラマの負担の軽重を指し、
実行速度に優れているという意味ではない。

現在の水準では
・インタプリタ
・動的型
・正規表現
・関数オブジェクト
などを利用できるものがLLと呼ばれることが多い。(Wikipediaより)

■過去スレ
【Perl,PHP】LLバトルロワイヤル6【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1244166510/
【Perl,PHP】LLバトルロワイヤル5【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1238720336/
【Perl,PHP】LLバトルロワイヤル4【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1234635513/
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1215319832/
【Perl,PHP】LLバトルロワイヤル2【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1209289408/
【Perl,PHP】LLバトルロワイヤル【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1188997302/

2 :デフォルトの名無しさん:2009/07/25(土) 11:48:28
>>1
Lispも入れろっちゅうことですよ アホー!


3 :デフォルトの名無しさん:2009/07/25(土) 12:49:38
Lispは"Perl、PHP、Python、Ruby、JavaScript・・・"のなかの "・"です。
信者とアンチがうざいから名前を出さないわけではありませんのでご了解をお願いします。

4 :デフォルトの名無しさん:2009/07/25(土) 12:59:52
これはハスケルを締め出そうという陰謀のスレね…こわい

5 :デフォルトの名無しさん:2009/07/25(土) 13:30:52
>>4
>>3のLispのところをハスケルに置き換えてください。他の言語も同様です。
マイナーな言語を使う人は劣等感から妄想を抱きがちですが決してそういう意図は
ありませんのでご了解をお願いします。


では、死ぬまで語りやがるよう お願いします。
なお私は1ではありません。でしゃばってすみません。

6 :デフォルトの名無しさん:2009/07/25(土) 14:50:02
D言語はLLですか?

7 :デフォルトの名無しさん:2009/07/25(土) 15:03:28
いえ、ダメ言語です

8 :デフォルトの名無しさん:2009/07/25(土) 15:07:58
LLは lua & Lisp の事です D言語は入る余地無しです


9 :デフォルトの名無しさん:2009/07/25(土) 16:19:24
え、Lispに一番近いとまで言われたPythonってなんだったの

10 :デフォルトの名無しさん:2009/07/25(土) 17:09:12
Lispに近いって、どういう事?
おままごとか、せいぜいCADのマクロぐらいにしか使えないって事?

11 :デフォルトの名無しさん:2009/07/25(土) 17:28:25
関数に関数を渡したり、関数の中で関数を定義したり、関数が関数を返したりする事。
大雑把に言えばLispに近いほどJavaから遠くなる傾向がある。

12 :デフォルトの名無しさん:2009/07/25(土) 17:35:16
他にLispっぽいとか言われるのは、JavaScriptとかRubyとか
基本的には褒め言葉
強力なリストであったり、高階関数であったり、GCであったり
パワーのある言語だねって

13 :デフォルトの名無しさん:2009/07/25(土) 17:37:47
関数系は遅延評価が(どういう風に使えばいいのかが)よくわからない。

14 :デフォルトの名無しさん:2009/07/25(土) 17:59:07
Javaだってインナークラス使えば同じことができるぞ。

15 :デフォルトの名無しさん:2009/07/25(土) 18:01:05
高階関数は使い出すとクセになるな
Lisp使うとjavaは要らんとつくづく思うよ


16 :デフォルトの名無しさん:2009/07/25(土) 19:13:09
pythonやrubyで√2の小数点以下100桁を求めるとしたらお前らどうよ?


17 :デフォルトの名無しさん:2009/07/25(土) 19:14:14
いい感じだよ。

18 :デフォルトの名無しさん:2009/07/25(土) 19:32:42
Python
>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 101
>>> Decimal(2).sqrt()
Decimal('1.414213562373095048801688724209698078569671875376948073176679737990732
4784621070388503875343276415727')

19 :デフォルトの名無しさん:2009/07/25(土) 19:57:38
まだやんの?
最強は機械言語でいいじゃん

20 :デフォルトの名無しさん:2009/07/25(土) 20:01:42
import使われるとなんかズルされた気がするよ。


21 :デフォルトの名無しさん:2009/07/25(土) 20:41:18
√2 = r と置いてみる

(r * 10^100)^2 = r^2 * 10^200 ≒ 2 * 10^200 となる整数 (r * 10^100) を探してみる

(r * 10^100) / 10^100 がたぶん求める答え

ひょっとすると 10^101 かもしれないがそれは後で検証

22 :デフォルトの名無しさん:2009/07/25(土) 21:22:55
>>> def r2(m):
...  p = 2*10**m
...  for i in xrange(p):
...   if (p-3)*10**m <= i*i and i*i <= (p+3)*10**m:
...    print i
...
>>> r2(4)
14142
14143
>>> r2(5)
141421
141422
>>> r2(6)
1414213
1414214
>>> r2(7)
14142135
14142136
遅いわwww

23 :デフォルトの名無しさん:2009/07/25(土) 21:32:40
>>> r2(100)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in r2
OverflowError: long int too large to convert to int


24 :デフォルトの名無しさん:2009/07/25(土) 21:36:15
このスレもレベル下がったな
糞スレ決定だろ

25 :デフォルトの名無しさん:2009/07/25(土) 22:44:23
みんな!民主党が大変な事になってるよ。
http://www.nicovideo.jp/watch/sm7737318

26 :デフォルトの名無しさん:2009/07/25(土) 23:14:45
平方根を数値計算するアルゴリズムは意外と簡単だ。
筆算でも算盤でもできる。
http://ja.wikipedia.org/wiki/%E9%96%8B%E5%B9%B3%E6%B3%95

27 :デフォルトの名無しさん:2009/07/25(土) 23:16:08
http://www.jma-net.go.jp/sat/data/web/suneclipse_img/mtsat2_20090722_0900-1400_enhanced.gif

28 :デフォルトの名無しさん:2009/07/25(土) 23:38:56
√(10+3√(97+56√3))

29 :デフォルトの名無しさん:2009/07/26(日) 01:53:07
遅延評価って
if( hoge() or hogehoge() )

って時に、hoge()がtrueならhogehogeが実行されないってことだしょ?
短絡的に考えれば、hogehoge()を実行しなくていい時ってことでいいんじゃない。
どっちも確実に実行したいなら、ifに掛ける前に代入しておけばいいだけだし

30 :デフォルトの名無しさん:2009/07/26(日) 01:54:34
は?

31 :デフォルトの名無しさん:2009/07/26(日) 01:57:10
ははは

32 :デフォルトの名無しさん:2009/07/26(日) 02:02:22
あっ、ごめん
俺おもいっきし間違ってる?

33 :デフォルトの名無しさん:2009/07/26(日) 02:16:56
それは短絡評価。

34 :デフォルトの名無しさん:2009/07/26(日) 06:37:03
foo( bar() + baz() )
って時に、普通の言語ならbar()+baz()をそれぞれ呼んで計算してから
その結果をfoo()に渡すのに対して、遅延評価のある言語だと
いきなりfoo()に「bar()+baz()」っていう「式」を渡す
んで、bar()+baz()の値が実際に必要になるまでは式のままで評価されない

あと、無限リストなんかも扱えたりする
(1〜∞)の中から、条件に合致する値を抽出し、さらのその2番目から10番目を抽出する
なんて処理がマジで言葉通りに書ける

35 :デフォルトの名無しさん:2009/07/26(日) 06:37:40
>>22-23
せめてニュートン法くらい使えよw

>>> def r2(m):
...  p0 = 2*10**m
...  p = p0
...  while(not ((p0-3)*10**m <= p*p and p*p <= (p0+3)*10**m)):
...   p = (p*p + p0*10**m) / (2*p)
...  print p
...
>>> r2(4)
14142
>>> r2(10)
14142135623
>>> r2(100)
14142135623730950488016887242096980785696718753769480731766797379907324784621070388503875343276415727


36 :デフォルトの名無しさん:2009/07/26(日) 06:54:49
前置記法って何でLispしか無いんかね?

37 :デフォルトの名無しさん:2009/07/26(日) 07:01:42
>>34
>あと、無限リストなんかも扱えたりする
>(1〜∞)の中から、条件に合致する値を抽出し、さらのその2番目から10番目を抽出する
>なんて処理がマジで言葉通りに書ける

整数nについて,各桁の数の階乗の和S(n)を考える.たとえば,n = 145 とすると,

S(145) = 1! + 4! + 5! = 1 + 24 + 120 = 145
となる.このように,S(n) = n となるn(n≧0)のうち3番目と4番目を抽出せよ.

これを遅延評価でおながいします.

38 :デフォルトの名無しさん:2009/07/26(日) 07:19:34
ああ、Lispスレの929か。

39 :デフォルトの名無しさん:2009/07/26(日) 08:08:24
>>37
それ2つしか答えないよ


40 :デフォルトの名無しさん:2009/07/26(日) 08:13:40
だいたい、「遅延評価でおながい」って、何をおながいするんだ?

41 :デフォルトの名無しさん:2009/07/26(日) 08:40:47
平方根はこんな感じ ↓

(labels ((nxt (x v) (/ (+ x (/ v x)) 2)))
(defun sqp (n e)
(do* ((x1 n x2) (x2 (nxt x1 n) (nxt x1 n)) (err (expt 10 (- 0 e))))
((< (abs (- x1 x2)) err)
(truncate (* (expt 10 e) x2))))))

> (sqp 2 100)

14142135623730950488016887242096980785696718753769480731766797379907324784621070388503875343276415727



42 :デフォルトの名無しさん:2009/07/26(日) 08:46:33
>>40
ハスケルでお願いっていう意味じゃないの?


43 :デフォルトの名無しさん:2009/07/26(日) 08:51:30
>>39
では50番目から100番目まで。


というのはおいといて”マジで言葉通りに書ける”とあるから1−2番目を計算せずに
いきなり3番目を取り出せるのだろうな。処理系内部では一所懸命計算やるだろうけど。
>>35の説明で遅延評価をはじめて知ったんだけど処理系にバグを仕込むために考え出さ
れた仕様ではないだろうか。

44 :デフォルトの名無しさん:2009/07/26(日) 09:07:44
>>39
4っつだ
ぼけ

45 :デフォルトの名無しさん:2009/07/26(日) 09:08:40
「4っつ」って珍しい書き方だな。

46 :デフォルトの名無しさん:2009/07/26(日) 09:11:32
>>43
え、もしかして、なんか言質とってツッコミ入れて恥かかせたがってる?
「言葉通りに」というところを取り上げて何か言いたかったら、元の「言葉」を正しく読み取らなきゃダメよ。

47 :デフォルトの名無しさん:2009/07/26(日) 09:26:02
よく2chの情報はいい加減とか、正しくない情報が多いとか言われるけど、
僕にとっては大事な情報源です。
たまにはボロクソ言われることもあるけど、みんな親切に教えてくれる。
いつもありがたいと思ってる。

48 :デフォルトの名無しさん:2009/07/26(日) 09:29:47
>>46
そんな気はまったくない。>>35には感謝してるよ。よそで”遅延評価というのはだな・・・”
とか言ってみたいほうだから。元の「言葉」を正しく読み取ったらどえなるのだ。

49 :デフォルトの名無しさん:2009/07/26(日) 09:38:28
うわ。アンカー間違えた>>34だ。最後”どえなるのだ” じゃねえ ”どうなるのだ” だった。

50 :デフォルトの名無しさん:2009/07/26(日) 10:09:38
tail $ take 10 $ filter func [1..]

とかそんな感じのことじゃねーの?

51 :デフォルトの名無しさん:2009/07/26(日) 10:31:33
>>48
> 元の「言葉」を正しく読み取ったらどえなるのだ。
「(1〜∞)の中から、条件に合致する値を抽出し、さらのその2番目から10番目を抽出する」
これが元の言葉だよね。
「”マジで言葉通りに書ける”とあるから1−2番目を計算せずに」って、それは元の言葉にある
「条件に合致する値を抽出」する途中の段階を、そっと見て見ぬフリしてない?

52 :デフォルトの名無しさん:2009/07/26(日) 10:56:53
遅延評価って、例えば現在の時間を内部でパラメータとして使うような関数だと、
いつ評価されるん?

53 :デフォルトの名無しさん:2009/07/26(日) 11:00:43
現在時間を使うなら「時間を得る」部分だけはその時点で評価されて
それ以外の処理は後回しじゃね?

54 :デフォルトの名無しさん:2009/07/26(日) 11:06:17
>>51
見て見ぬフリはしてない。「条件に合致する値を抽出」するところは処理系が
3番目が必要になったときに1−3番目を計算して3番目を返すと解釈している。
だからプログラマはいきなり3番目を取り出せると想像したんだけどこれで
合ってるんじゃないか。

55 :デフォルトの名無しさん:2009/07/26(日) 11:09:07
遅延評価と、クロージャとかカリー化を統一できそうだな。

56 :デフォルトの名無しさん:2009/07/26(日) 11:38:45
>>52
Haskell では IO モナドでそのへんをうまくやってる

57 :デフォルトの名無しさん:2009/07/26(日) 17:48:30
とんだすれ違いスレだな

58 :デフォルトの名無しさん:2009/07/26(日) 18:52:22
すれちがい通信か

59 :デフォルトの名無しさん:2009/07/26(日) 19:52:52
>>16>>26のアルゴリズムで書いてみたわ。
泥臭い方法だけど、桁が増えても計算量が線形増加だからいいかも。
30行くらいだけどソースいる?

60 :デフォルトの名無しさん:2009/07/26(日) 21:05:47
plz

61 :デフォルトの名無しさん:2009/07/26(日) 21:06:28
2/2 http://www.youtube.com/watch?v=nVDq-s3r5Ys
1/2 http://www.youtube.com/watch?v=9UU4Hx76Zg0

62 :59:2009/07/26(日) 21:16:15
def kaihei(n, k):
    stack = []
    keta = 1
    while n >= 100:
        stack.append(n % 100)
        n = int(n / 100)
        keta = keta + 1
    else:
        stack.append(n)
    dlist = list(range(10))
    dlist.reverse()
    baikon = 0
    rem = 0
    result = ""
    while (keta > 0 or (keta <= 0 and -keta <= k)):
        if keta == 0:
            result += "."
            keta = keta - 1
        if(len(stack) > 0):
            rem = rem + stack.pop()
        for i in dlist:
            if(rem >= i * (baikon + i)):
                result += str(i)
                rem = (rem - i * (baikon + i)) * 100
                baikon = baikon * 10 + i * 20
                keta = keta - 1
                break
    print(result)

63 :59:2009/07/26(日) 21:24:32
>>> kaihei(2, 100)
1.4142135623730950488016887242096980785696718753769480731766797379907324784621070388503875343276415727

ちなみに、整数しか対応してない。
一部の名前が、開平とか桁とか倍根とかそのままローマ字になってるけど、そのあたりは勘弁してくれ。
かわりに桁合わせをちゃんとしたから。

64 :デフォルトの名無しさん:2009/07/26(日) 23:32:27
クスクス

65 :デフォルトの名無しさん:2009/07/26(日) 23:35:23
>>43
横レスだが

drop 49 $ take 100 $ filter (\x -> (foldr ((+) . product . enumFromTo 1 . read . (flip (:) [])) 0 . show) x == x) [1..]

直感的に書くとこんな感じかな?
49と100の部分を変えればどうとでも書けるよ。

66 :デフォルトの名無しさん:2009/07/27(月) 07:40:37
>>65
サンクス!
haskell知らないから間違っているかもしれないが49までの計算結果を捨てる
のを明示しなきゃいけないということですね。
>>34を読んだら 2..10 という感じで書けると思っていた。

67 :デフォルトの名無しさん:2009/07/27(月) 08:51:59
>>62-63
GJ!!!

68 :デフォルトの名無しさん:2009/07/27(月) 11:28:26
memo
ttp://www.youtube.com/watch?v=xJ93ESdCJgI

69 :デフォルトの名無しさん:2009/07/27(月) 12:08:35
>>66
そうですね。
でもたとえば「それが50番目である」ことを示すには前の49個の計算が
必要なわけで、それを省略することは遅延評価といえどできない。
遅延評価なのは100以降を計算しないこと。

自分で2,10を引数にとる関数を作ればもちろん2..10みたいに書けるよ。



70 :デフォルトの名無しさん:2009/07/27(月) 15:02:19
PHPで無料レンタル鯖のいいとこ&有名なとこあります?

71 :デフォルトの名無しさん:2009/07/27(月) 15:12:24
俺んち

72 :デフォルトの名無しさん:2009/07/27(月) 15:25:28
養殖ならノルウェー辺りが有名だな

73 :デフォルトの名無しさん:2009/07/27(月) 23:44:17
http://www.atmarkit.co.jp/news/200907/24/ruby01.jpg

なにポーズつけてるんだよ(w

74 :デフォルトの名無しさん:2009/07/27(月) 23:50:13
It has already been out.

75 :デフォルトの名無しさん:2009/07/28(火) 01:14:48
「ポーズとってください」って言われたんだろうなw
『まつもとゆきひろ コードの世界』でも「私だって恥ずかしい」とか書いてた

76 :デフォルトの名無しさん:2009/07/28(火) 03:13:45
その記事おもしろかったねー。いろんな話が凝縮されてて。

77 :デフォルトの名無しさん:2009/07/28(火) 05:55:15
プログラマーって見栄え悪いのばっかだな。

78 :デフォルトの名無しさん:2009/07/28(火) 06:00:38
見栄えで稼ぐ商売以外は似たり寄ったりだよ。

79 :デフォルトの名無しさん:2009/07/28(火) 12:14:20
>77
運動不足が職業病だからな。

80 :デフォルトの名無しさん:2009/07/28(火) 12:46:29
まっつんはちょっと痩せればそれなりにダンディになるとは思うが。

81 :デフォルトの名無しさん:2009/07/28(火) 13:31:14
全員、顎髭を伸ばせば、かっこがつくよ。

82 :デフォルトの名無しさん:2009/07/28(火) 13:50:10
They should be skin head.

83 :デフォルトの名無しさん:2009/07/29(水) 19:12:58
Python 3.1からifとかforとかけっこう変わるんだね。
修正がめんどい orz



84 :デフォルトの名無しさん:2009/07/29(水) 20:59:40
http://coreblog.org/ats/statements-to-expressions-python-31
このエープリルフールを真に受けちゃった人ですか

85 :83:2009/07/30(木) 01:26:38
>>84
変わらないの?良かったぁ (;´Д`)

86 :デフォルトの名無しさん:2009/07/30(木) 01:31:23
しかし、3がリリースされた直後に3.1を四月馬鹿ネタにするってのもなんかセンスが微妙だな
Python 4とかなら微笑ましいんだが。
Pythonってそんなにバージョンアップしないもんなの?
Perl6がリリースされた後でPerl 6.2の話題とか、多分普通に信じるぞ。

87 :デフォルトの名無しさん:2009/07/30(木) 03:32:19
Pythonのメジャーバージョンは1、2、3、3.1、3.11、3.12、3.13、3.14、3.141と増えていくからな

88 :デフォルトの名無しさん:2009/07/30(木) 03:34:48
クヌース先生の美学だよなあ……

89 :デフォルトの名無しさん:2009/07/30(木) 13:13:54
>>87
最近の小学生は3と聞いたけど

90 :デフォルトの名無しさん:2009/07/30(木) 13:39:23
>>89
それ聞きまちがい


91 :デフォルトの名無しさん:2009/07/30(木) 15:00:19
ttp://ja.wikipedia.org/wiki/円周率は3

92 :デフォルトの名無しさん:2009/07/31(金) 00:01:38
エイプリルフールネタを一見それとはわからない状態で
いつまでもWeb上に残しておくなんて、はっきり言って悪だろ。
それでwebなんちゃらなんて会社の代取とか笑えねーって。

93 :デフォルトの名無しさん:2009/07/31(金) 00:39:36
日付みればわかるだろ。アホか

94 :デフォルトの名無しさん:2009/07/31(金) 01:03:21
実際、真に受けてるやつがいるだろ。アホか

95 :デフォルトの名無しさん:2009/07/31(金) 01:08:02
ひとりのアホの面倒をみるためにみんなが犠牲にならなければならないのかよ

96 :デフォルトの名無しさん:2009/07/31(金) 08:58:40
>>95
犠牲て。

ネットにデマを流すときはそれなりの
配慮があってしかるべき。jk



97 :デフォルトの名無しさん:2009/07/31(金) 11:54:13
4/1のエントリって時点で、それなりの配慮はしてるわな。

98 :デフォルトの名無しさん:2009/07/31(金) 18:47:55
4/1に書かれた記事は全て疑わないといけないのかよ

99 :デフォルトの名無しさん:2009/07/31(金) 19:00:29
とうぜんだろ

100 :デフォルトの名無しさん:2009/07/31(金) 21:20:58
どっかのバカがやってるならともかく、
プロフィールにそれなりの肩書き書いておいて
あんな感じじゃ、いろいろ神経疑われるわなw

101 :デフォルトの名無しさん:2009/07/31(金) 22:03:28
Pythonian: モンティパイソン精神なのでそんなの余裕で笑ってスルー
Rubist: エープリルフールネタなんだからあーたらこーたら
Perler: ネタを見逃して話題に乗れない

102 :デフォルトの名無しさん:2009/07/31(金) 22:13:16
>>101
あ、それいいえてミョー

103 :デフォルトの名無しさん:2009/07/31(金) 23:20:35
>>101
いや、きっとdankogaiなら、
dankogaiならネタを見逃すはずがない。

104 :デフォルトの名無しさん:2009/07/31(金) 23:34:11
>>103
断固GUYって誰?

105 :デフォルトの名無しさん:2009/07/31(金) 23:34:33
LLTVまで残り1ヶ月を切りました。

盛り上がって参りましょう!

106 :デフォルトの名無しさん:2009/08/01(土) 06:20:40
すみません。

ところで僕は中学生のころ、いじめられっこでした。
一番ひどくいじめられた放課後、先生が見るに見かねてとめてくれて
家の帰りもずっといっしょでした。そのとき、川原で先生と一休みしたんですが
先生がこんなことをいっていました。

「人間ってのはひどいもんだ。
こんな鼻くそより汚い。」

私はいまだに鼻くそより汚いという比喩がうまく理解できませんが、
そんな比喩にまで使われた鼻くそをいまだに食べています。私はRubyプログラマーです。

107 :デフォルトの名無しさん:2009/08/01(土) 15:45:52
そのコピペなんかいみあんの?


108 :デフォルトの名無しさん:2009/08/01(土) 18:49:14
例えばこれを実行すると結果が何になるか、すぐにわかる?
@int i=0;if(i=1){puts("1");}else{puts("2");}
Aint j=0;for(;j>0;++j){}


109 :デフォルトの名無しさん:2009/08/02(日) 02:02:48
分かるよ。
1,1 が表示される。
2,for文は実行されない。

110 :デフォルトの名無しさん:2009/08/02(日) 07:04:04
俺は後者はとっさに判らないな
単項++演算子の戻り値はアテにすべきじゃないと思ってる
自分じゃそういうコードは書きたくないね

111 :デフォルトの名無しさん:2009/08/02(日) 07:06:57
単項++の戻り値は使われていないわけだが…

112 :デフォルトの名無しさん:2009/08/02(日) 07:13:43
ごめんなさい間違えました

113 :デフォルトの名無しさん:2009/08/02(日) 07:15:59
i=1が(文脈によっても)何を返すかは、言語によってブレがあるな。

114 :デフォルトの名無しさん:2009/08/02(日) 08:16:52
BASIC系は文脈で比較か代入かが決まることが多いね
本家はLET省略不可だからLET文以外代入だけど

Javaは代入文自体の戻り値はCと変わらんが
if文がbooleanしか受け付けないからエラーだな

115 :デフォルトの名無しさん:2009/08/02(日) 12:42:53
>>107
底辺Rubyプログラマーってことだろ

116 :デフォルトの名無しさん:2009/08/03(月) 09:39:57
所謂覆面算で
英字一文字がそれぞれ異なる一桁の数字(0-9)で表されるとき
one
+ nine
+ twenty
+ fifty
= eighty
となる組み合わせを検索してください
各行の先頭の文字は0以外です

117 :デフォルトの名無しさん:2009/08/03(月) 11:52:03
それって正解は「そんな組み合わせは無い」で合ってる?

118 :デフォルトの名無しさん:2009/08/03(月) 11:55:11
pythonスレで答え出てなかったっけ?

119 :デフォルトの名無しさん:2009/08/03(月) 12:26:48
ごめんあった、何故かone+nine+twenty+fifty+eighty=eightyで計算してた俺の馬鹿〜
selects([], _).
selects([X|XL],YL) :- select(X,YL,L), selects(XL,L).
check(O,N,E,I,T,W,Y,F,G,H,ONE,NINE,TWENTY,FIFTY,EIGHTY) :-
ONE is O * 100 + N * 10 + E,
NINE is N * 1000 + I * 100 + N * 10 + E,
TWENTY is T * 100000 + W * 10000 + E * 1000 + N * 100 + T * 10 + Y,
FIFTY is F * 10000 + I * 1000 + F * 100 + T * 10 + Y,
EIGHTY is E * 100000 + I * 10000 + G * 1000 + H * 100 + T * 10 + Y,
ONE >= 100, NINE >= 1000, TWENTY >= 100000, FIFTY >= 10000, EIGHTY >= 100000,
EIGHTY =:= ONE + NINE + TWENTY + FIFTY.
solve(ONE,NINE,TWENTY,FIFTY,EIGHTY) :-
selects([O,N,E,I,T,W,Y,F,G,H],[0,1,2,3,4,5,6,7,8,9]),
check(O,N,E,I,T,W,Y,F,G,H,ONE,NINE,TWENTY,FIFTY,EIGHTY).
?- solve(ONE,NINE,TWENTY,FIFTY,EIGHTY).
ONE = 984,
NINE = 8584,
TWENTY = 364832,
FIFTY = 75732,
EIGHTY = 450132 ;
false.

120 :デフォルトの名無しさん:2009/08/03(月) 13:24:34
prologだっけ?


121 :デフォルトの名無しさん:2009/08/03(月) 14:54:47
Prologだよ
手続き書くのは面倒いが
覆面算とかはむしろこの言語の十八番だと思う

122 :デフォルトの名無しさん:2009/08/03(月) 15:29:28
>>121
おすすめのProlog実装を教えてください。
あとおすすめの教科書もあれば。

123 :デフォルトの名無しさん:2009/08/03(月) 15:48:44
とりあえずはSWI-Prologで良いんじゃないかと
教科書は…Prologスレのテンプレに載ってるやつ片っ端読むのが良いんじゃない?
日本語で書かれてるやつだけ読んでもそれなりには解るかと

ちなみに今回のコードは「Prolog 覆面算」でググって出てきた
SEND+MORE=MONEYのコードを元にして改変したものだったりする
自分で書いたコードは遅すぎて話にならんかったw

124 :デフォルトの名無しさん:2009/08/03(月) 15:51:51
metafontとかでも解けそうな気がするな。
くりあがりの処理がミソかしら。


125 :デフォルトの名無しさん:2009/08/03(月) 20:24:40
>>123
a+b+...+c=x の形になる任意の式を与えて
解いてもらうようにするにはどうすれば良いですか?

126 :デフォルトの名無しさん:2009/08/03(月) 22:34:53
>119 みたく答えになりうる値を全部列挙するワケにはいかないだろうから
モジュール使うほうが良いんじゃないかな

?- use_module(library('clp/bounds')).
?- 3 + X + 4 #= 19.
X = 12.

っていうか、Prologってこのスレで扱って良いものなのかな

127 :デフォルトの名無しさん:2009/08/04(火) 07:35:13
>>123
さんくすです。swi-prologをインストールして勉強することにします。

128 :デフォルトの名無しさん:2009/08/04(火) 15:00:08
>>126
他の言語よりも分かりやすく短く書けるのならそれはLL

129 :デフォルトの名無しさん:2009/08/04(火) 15:04:26
この手の問題だと、論理型が得意だったって事

130 :デフォルトの名無しさん:2009/08/04(火) 16:16:06
読めないからよく解らんのだが、119のコードって他言語に直訳できないの?

131 :デフォルトの名無しさん:2009/08/04(火) 16:20:03
アセンブリ

132 :デフォルトの名無しさん:2009/08/04(火) 16:24:23
119って式が変わったら毎回書き換えるしかないんかな

133 :デフォルトの名無しさん:2009/08/04(火) 16:35:08
>>130
つ ttp://miko.org/~naruto/Artifact/MASKSQL.html

134 :デフォルトの名無しさん:2009/08/04(火) 17:31:52
汎用性は無いだろうね
ただコード自体が式を列挙してるようなコード…つまり入力データみたいなコードだから
Prolog的には下手なことするより最適な方法かも知れん

135 :デフォルトの名無しさん:2009/08/04(火) 19:06:45
>>130
論理型言語を、そうでない言語に直訳
するのは基本的に無理。

論理型言語には、処理順序とかまったく
ないし、根拠となる条件式に基づいて
解を求めることしかできない。


136 :デフォルトの名無しさん:2009/08/04(火) 19:09:31
>>132
式を他の言語で解釈して、
ソースを機械生成すれば。


137 :デフォルトの名無しさん:2009/08/04(火) 19:16:27
>>135
じゃあロンリー型言語は?

138 :デフォルトの名無しさん:2009/08/04(火) 20:37:13
ロンリーロンリーロンリーロリー

139 :デフォルトの名無しさん:2009/08/04(火) 20:51:06
TOMOちゃんじゃないか!

140 :デフォルトの名無しさん:2009/08/04(火) 23:09:17
どっちにしろマシン語になるんだから、無理なわけないだろ。

141 :デフォルトの名無しさん:2009/08/04(火) 23:14:19
>>140
誰がそんな話をしたんだろうか
ある言語を使うってことは、その言語の制約内のことしかできないってことだと単純にわかるだろ

ここで話題に上がるような言語は、大概昔ラリーさんだかが言った、
「簡単な事は簡単に、難しいことは可能に」
って作られてるから、とりあえず何でも可能な気がするだけだ。

142 :デフォルトの名無しさん:2009/08/05(水) 00:59:56
どっちかっつーと、Prologは制御可能なフレームワークって感じ。

普通の言語は流れそのものを書くが、Prologの場合は
基本的な流れはProlog処理系が既に持ってて、ちょいと書くだけである程度勝手に動くものを
コードで制御してやると流れが変わって、複雑な動作ができる。

だから元々Prologが持ってる流れに近い動作は簡単に、遠い動作は面倒になるし
流れそのものが明快なものに対しては、それをそのまま書けば良い手続き型言語に対して
「既にある流れをどう変えればその流れになるか」と考えなくちゃいけないからしんどい。

143 :デフォルトの名無しさん:2009/08/05(水) 02:45:30
>>142
PrologはDSLの一種と使った方が良いと思う。
正規表現とかSQLとかの仲間。

144 :デフォルトの名無しさん:2009/08/06(木) 09:19:46
とはいってもPythonにprologモジュールが入ったりすることはないよね
広めたかったら他のプログラミング言語用のライブラリだ、って割りきっちゃったほうがいいのかな

145 :デフォルトの名無しさん:2009/08/06(木) 09:42:30
On LispにLispで書かれたprologが載ってたな。
結構すくないコードで書かれてたよ


146 :デフォルトの名無しさん:2009/08/06(木) 10:31:24
何気に欲しいな、Prologモジュール

147 :デフォルトの名無しさん:2009/08/06(木) 17:31:14
何気に欲しいな、Prologモジュール

148 :デフォルトの名無しさん:2009/08/06(木) 19:11:44
>>147
インストール済みのPrologを利用する
薄いラッパーだったら、自分ですぐ
作れんじゃね?


149 :デフォルトの名無しさん:2009/08/06(木) 23:29:52
>>147
Python で作る Prolog 処理系;;http://www.okisoft.co.jp/esc/prolog/in-python.html


150 :デフォルトの名無しさん:2009/08/11(火) 06:15:54
保守

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

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

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

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

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

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

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

158 :デフォルトの名無しさん:2009/08/12(水) 11:33:11
eval

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

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

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

なんという・・・クマー

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

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

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

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

164 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/08/12(水) 21:55:06
>>164
gettext('$foo value is $var');

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

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

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

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

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


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

172 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/08/13(木) 00:04:39
>>164
>"$foo value is $bar"
>というメッセージを国際化したくなったとき
>gettext("$foo value is $bar")
>って出来ないでしょ?

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



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

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

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

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

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

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

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

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

180 :デフォルトの名無しさん:2009/08/13(木) 00:46:48
え?

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

190 :162:2009/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 :デフォルトの名無しさん:2009/08/13(木) 17:46:35
PEP292でPEP215のセキュリティに言及してる部分がさっぱり分からん。
いやみっぽく書かれてるのは分かるけど。

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

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

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

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

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

196 :デフォルトの名無しさん:2009/08/13(木) 20:10:00
いい歯ごたえ!

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

198 :デフォルトの名無しさん:2009/08/13(木) 20:21:21
歯応えwwwwwwwwwwwwwwwwwwwwww

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

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

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

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

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

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

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

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


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

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

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


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

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

207 :デフォルトの名無しさん:2009/08/14(金) 10:10:12
http://tsushima.2ch.net/test/read.cgi/newsplus/1250174574/

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

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

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

実際に string interpolation に対して gettext で使えねーと反論しているメールは
こちら。
ttp://mail.python.org/pipermail/python-dev/2002-January/019523.html

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

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

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

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

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

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

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

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

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

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

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

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

221 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/08/15(土) 05:32:15
JavaScript
price = 100
print "price = " + price

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

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


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

このへんが信者だよな。

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

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

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

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

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

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

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

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

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

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

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

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

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

238 :デフォルトの名無しさん:2009/08/15(土) 22:19:15
debugger

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


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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

なんかピンとこないな

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


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

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

259 :デフォルトの名無しさん:2009/08/22(土) 14:17:00
>>258
韓国の方ですか?

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

例えばこの調査だと4人に1人がまだIE6だね
http://internet.watch.impress.co.jp/docs/news/20090707_300476.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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


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

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

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

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

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

281 :デフォルトの名無しさん:2009/08/25(火) 11:24:59
マルチポスト報告スレ
http://pc12.2ch.net/test/read.cgi/tech/1251165265/

ttp://pc12.2ch.net/test/read.cgi/tech/1225268851/688
ttp://pc12.2ch.net/test/read.cgi/tech/1158410544/183
ttp://pc12.2ch.net/test/read.cgi/tech/1245309571/793
ttp://pc12.2ch.net/test/read.cgi/tech/1136788500/388
ttp://pc12.2ch.net/test/read.cgi/tech/1200175247/601
ttp://pc12.2ch.net/test/read.cgi/tech/1249687283/408
ttp://pc12.2ch.net/test/read.cgi/tech/1239996587/711
ttp://pc12.2ch.net/test/read.cgi/tech/1248487404/279
ttp://pc12.2ch.net/test/read.cgi/tech/1193667819/60
ttp://pc12.2ch.net/test/read.cgi/tech/1164783092/937
ttp://pc12.2ch.net/test/read.cgi/tech/1206835319/963
ttp://pc12.2ch.net/test/read.cgi/tech/1247937958/547
ttp://pc12.2ch.net/test/read.cgi/tech/1247636661/861
ttp://pc12.2ch.net/test/read.cgi/tech/1249140049/420

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

283 :デフォルトの名無しさん:2009/08/25(火) 21:25:39
     ttp://www.jiji.com/jc/c?g=soc&k=2009082500836

    ワロw



284 :デフォルトの名無しさん:2009/08/25(火) 21:37:29
今回改修対象でないのに勝手に改修したのか
ttp://www.kahoku.co.jp/news/2009/08/2009082501000971.htm

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

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

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

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

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

289 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 18:08:55
HSPもいちおうLLだよね?

290 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 18:10:19
あーうんまあ一応は

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

292 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 19:42:00
DSLとLLって直行する概念?

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

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

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

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

297 :デフォルトの名無しさん:2009/08/30(日) 21:26:43
>>295
それはないと思うw
未来はTV電話だ!みたいな発想だと思われw

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

307 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/09/14(月) 22:01:52
そういう見方でなんでPythonとRubyを比較せにゃならんのか解らんが。

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


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

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

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

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

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

Ruby Sai メタセコ

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

358 :デフォルトの名無しさん:2009/09/19(土) 11:01:44
ポカーン?

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

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

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

362 :デフォルトの名無しさん:2009/09/19(土) 11:30:37
http://www.valuedlessons.com/2009/08/sql-is-now-turing-complete.html

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

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

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


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

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

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

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

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

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

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

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

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

371 :デフォルトの名無しさん:2009/09/19(土) 15:19:48
速報:グーグルが新言語「Noop」を公開。JavaVMで動作 − Blog on Publickey
http://www.publickey.jp/blog/09/noopjavavm.html

372 :デフォルトの名無しさん:2009/09/19(土) 15:36:40
今にはじまったことじゃないが、相変らずGoogleのプロダクトはいまいち感かもしだすなあ。

373 :デフォルトの名無しさん:2009/09/19(土) 16:33:39
>>365
今すぐ自分の役にたつもの作りたいならHSP
時間がかかってもいいから人の役に立つもの作りたいならRuby

374 :デフォルトの名無しさん:2009/09/19(土) 21:48:24
おまえらそんな糞なものすすめんなw

375 :デフォルトの名無しさん:2009/09/19(土) 21:52:52
まぁ一生そこから出てこないってんならHSPやRubyもありかもな
でも他の言語もやるかもしれないならその2つは止めとけ
害にしかならん

376 :デフォルトの名無しさん:2009/09/19(土) 22:01:15
>>362
論理演算はまだ?

377 :デフォルトの名無しさん:2009/09/19(土) 22:02:05
>>362
bit演算はまだ?

間違えた
アホだorz

378 :デフォルトの名無しさん:2009/09/19(土) 22:07:03
>>355 >>370
SQLで覆面算を解いてるケースがあるからあなどれんよ

379 :デフォルトの名無しさん:2009/09/19(土) 22:20:27
Noop
Yeah, perhaps.. I personally find it more readable and I think there is good precedence for it in python
and ruby, but totally understand the other view... As far as xor, nand, etc, if we were to have "and"
and "or" and if we aren't afraid to add keywords, why not? :)

if foo and bar:
if not foo:

On an sort of related note, I always liked being able to give the conditional at the end:

foo = 2 if bar; // Ruby style
foo = 2 if bar else 0; // Python style where else is required, which I find super annoying sometimes
bar = 1 unless foo; // Ruby style unless, though I find if not easier to deal with than unless in my brain
bar = 1 if not foo;

This gets to ternary expressions, which can be more readable this way as well...

foo = 1 if bar else 2;
foo = 2 unless bar else 1; // Probably unnecessary

Otherwise I guess we would use (a ? b : c) ?


380 :デフォルトの名無しさん:2009/09/19(土) 22:21:52
I like the gabrielh's vote to put the conditional at the end:

foo = 1 if bar;

I'd also like to suggest my favorite looping construct from Pick Basic (yes Basic):

loop {
   x = doSomething();
} while (!x) {
   doSomethingElse();
}

putting the test in the middle of the loop allows you to dispense with any setup code for the loop
that has to be repeated within the loop -- it all goes before the test and will be executed again
for each iteration.


381 :デフォルトの名無しさん:2009/09/19(土) 22:23:31
An array is essentially a function that takes a numeric parameter and returns a value.
A Map can also be viewed as a function that takes an object (usually a String) argument
and returns an object. They are essentially parametrized objects. Why can't we unify the syntax?
A template (Generics) takes a parameter and behaves like a function also. Can we then move
toward a syntax similar to the following?

Array(Int) factorial = {1, 1, 2, 6, 24, 120};
Int fourth = factorial(3); // fourth == 6
Object myObj = myMap("myKey");

We can standardize this feature for all classes by using a special method:

class TableRow() {
  String get(String name) { /* Return field name as a String */ }
  String get(Int    i   ) { /* Return field i    as a String */ }
}

TableRow row = getNextTableRow();
String city    = row(5);         // city == "Alexandria"
String country = row("Country"); // country == "Egypt"

This is especially useful if we can extend the syntax to set values and not only retrieve them.
The syntax might then look like this:

class TableRow() {
  String get(Int i) {                 /* Return field i as a String */ }
  void   set(String value, Int key) { /* The  first parameter is the new value */ }
}
TableRow row = getNextTableRow();
String city = row(5);      // city == "Alexandria"
row(5)      = "Ankara";    // row(5) is mutable of course
String town = row(5);      // town == "Ankara"

382 :デフォルトの名無しさん:2009/09/19(土) 23:33:52
>>380
これはPythonに欲しい。

>>381
array[index] と map[key] を関数のようにみせるために
array(index) と map(key) のように書くのか。
そのせいで代入が array(index) = value とか、きもいわ。

383 :デフォルトの名無しさん:2009/09/19(土) 23:45:22
オブジェクトの参照を返す関数で
hoge(fuga) = hage
っていうのは他の言語でも有な気がする

pythonの
codecs.getreader('utf-8')(file('test.txt')).read()
みたいなのも当初はきもいと思ったけど慣れたらそうでもないし
Javaでも結構こんな書き方しなくね?

384 :デフォルトの名無しさん:2009/09/19(土) 23:47:02
array(index)は今のPythonでも可能だろうけど(callの挙動を弄るだけ)
array(index) = value はかなり無茶なことになるな
BASICみたく配列の添字が括弧なのか、それ?

385 :デフォルトの名無しさん:2009/09/19(土) 23:49:53
>>378
kwsk

386 :デフォルトの名無しさん:2009/09/19(土) 23:50:08
>オブジェクトの参照を返す関数
この辺がキモなのかな
言語仕様によっては無理筋過ぎそうだけど
よくわからん

387 :デフォルトの名無しさん:2009/09/19(土) 23:57:34
VBでも
hoge.item(n) = x
の場合
itemが配列なのか関数なのか
区別出来ないっていうか意識しなくて良いようになってるのでは

388 :デフォルトの名無しさん:2009/09/20(日) 00:12:24
そのうちmutableかimutableかが判らなくなる気がする


389 :デフォルトの名無しさん:2009/09/20(日) 00:24:01
>>383
やっぱ普通に hoge(fuga).Value = hage とかじゃないとキモく感じるわー

390 :デフォルトの名無しさん:2009/09/20(日) 00:25:34
NoopはGAE/bigtable専用言語なのかと思った

391 :デフォルトの名無しさん:2009/09/20(日) 00:51:57
Noop専用スレ立ってるからこっちで
http://pc12.2ch.net/test/read.cgi/tech/1253286429/

392 :デフォルトの名無しさん:2009/09/20(日) 03:24:54
またおまえら新しいものに手出すのか。他にやることがあるだろうw

393 :デフォルトの名無しさん:2009/09/20(日) 05:40:17
新しい言語がでてきて既存の言語と競争することで、既存の言語も改良されるのだったら歓迎だよな。
新しい言語万歳。

394 :デフォルトの名無しさん:2009/09/20(日) 09:44:52
プログラマー的発想だな。。作業員の覚える作業内容が増えるだけ。
経営者的にも、今の開発環境は各種技術が乱立してて、設計も人員リソースも
計画がたてづらい。
プログラマーにしてもスキルセットとかキャリアプランをたてづらいし、
転職の際の壁になることが多いし。
なんでも言語できますって奴は、器用貧乏な奴が多いよ。数理処理とかレンダリング
とかネットワークとか専門的なことできなくって、結局WebとかDBとか誰でもできるとこ
やることになる。

395 :デフォルトの名無しさん:2009/09/20(日) 10:06:14
>>394
しむら、スレタイ!スレタイ!

396 :デフォルトの名無しさん:2009/09/20(日) 10:11:21
だな。
393みたいに他の言語を迎合してたらバトルロワイヤルになってないな。
けしからん。

397 :デフォルトの名無しさん:2009/09/20(日) 11:36:25
>>394
ウチの会社のメインは汎用機で金融系なトコなんだけど、そういう考えが強く、
結果オープン系の技術力が他の会社に比べて著しく劣っている。
で、世の流れで営業がオープン系をねじ込んできて、導入したら障害が大量発生。
エンジニアは老害と偽装派遣ばっか。
地獄だよ。

まあ研究職と人身売買業種とは別に考えろよ。

それにここはプログラム板でプログラマーが多いのは当たり前。

398 :デフォルトの名無しさん:2009/09/20(日) 12:34:30
>>347
俺は真偽と0、nil系は別もの派だからオケー


399 :デフォルトの名無しさん:2009/09/20(日) 12:48:02
Webは新しいこととか、他より見劣りしないようとか営業的圧力が強いからなあ。
なんとかしようと開発は、流行りのその辺に転がってるOSS使って、
はりぼてにノリを塗りたくってる感じ。


400 :デフォルトの名無しさん:2009/09/20(日) 19:48:00
問題はその営業が顧客の押しに弱かったりすることだな
Perlで案件取りにいったのに帰ってきたらJavaになってたときは怒鳴り散らした

401 :デフォルトの名無しさん:2009/09/20(日) 19:51:45
Javaがいいなんて言う顧客なんているんだ
PHPがどうしても嫌だという顧客は多いが

402 :デフォルトの名無しさん:2009/09/20(日) 19:57:50
ディスプレイタッチパネルでやる予定が、いつの間にか別の小型端末からの入力まで入ってたからな
その頃はJavaやってなかったから、最初の見積もりから3倍ぐらになるかな、といっただけで青ざめてた

403 :デフォルトの名無しさん:2009/09/20(日) 21:23:23
>とかネットワークとか専門的なことできなくって、結局WebとかDBとか誰でもできるとこ
>やることになる。

Webはドカタな現場が多いとは思うが、案件の規模がでかい(億を越えるケース)
とかだとDB部分は相当なエンジニアでないと参加できないけど。

DBが誰でもって発言が出てくる辺り相当に底辺しか知らん印象があるが。

404 :デフォルトの名無しさん:2009/09/20(日) 21:29:17
誰でも最低のことは出来るが、最高のことが出来るまでには相応のスキルが必要ってのと
誰でも要件を満せて、天井もすぐ、っていうのとの区別がつかない奴って絶対いるよな。
「ウェブなんて小学生でも出来るんでしょ?」とかほざく頭の悪いおっさんとか。

405 :デフォルトの名無しさん:2009/09/20(日) 22:19:40
そもそも、全く新しいアルゴリズムの開発なんて仕事はめったにないしな。
五十歩百歩だよ。

406 :デフォルトの名無しさん:2009/09/20(日) 22:43:18
>>403
前に流体とか応力計算とかやったけど、理系で大卒のそれなりの人じゃないと無理。
DBとかは短大文系でもやらせりゃ1年でできるようになるからね。

407 :デフォルトの名無しさん:2009/09/20(日) 22:55:25
>>406
>DBとかは短大文系でもやらせりゃ1年でできるようになるからね。
この発言が>>404のほんといい実例だよな

408 :デフォルトの名無しさん:2009/09/20(日) 23:12:06
※ExcelDBを含む

409 :デフォルトの名無しさん:2009/09/20(日) 23:21:34
DBを「使ったことある人」と「使いこなせてる人」の差は広すぎる。

410 :デフォルトの名無しさん:2009/09/20(日) 23:41:47
DB設計のためにはモデルを作り上げる能力が必要だが、
流体にしろ応力計算にしろ、先人の作り上げたモデルを利用できれば十分だからな。

411 :デフォルトの名無しさん:2009/09/21(月) 00:06:14
>DBとかは短大文系でもやらせりゃ1年でできるようになるからね。

Accessの話でもしているのか?
このニートは。

412 :デフォルトの名無しさん:2009/09/21(月) 01:20:39
410は406へのカウンターなんだろうと思いつつ
そんなことはないと言ってみる

413 :デフォルトの名無しさん:2009/09/21(月) 01:43:48
1年はかかり過ぎだろどうみても

414 :デフォルトの名無しさん:2009/09/21(月) 06:49:41
ExcelとかAccessなら1年で出来なきゃアフォだろうな。

415 :デフォルトの名無しさん:2009/09/21(月) 09:52:55
DBってもともとデータ処理を簡単に扱えるようにしたアプリだからな。
誰でも使えないとそれはそれでおかしい。

416 :デフォルトの名無しさん:2009/09/21(月) 11:05:25
ExcelやAccessはマクロ言語を内蔵していて、GUIパーツも使えるわけで、ウェブアプリより応用範囲が広い。

417 :デフォルトの名無しさん:2009/09/21(月) 12:10:41
サクサク作れるのは良いけど
いまだにソースやオブジェクトの管理が改善されないので大規模化するとカオスになるよ

418 :デフォルトの名無しさん:2009/09/21(月) 13:52:09
ソース埋め込みだからね

419 :デフォルトの名無しさん:2009/09/21(月) 13:53:03
どのくらいの規模からカオスになる?
大規模っていうのは人によって全然違うから、いちおう聞いてみる。

420 :デフォルトの名無しさん:2009/09/21(月) 14:16:03
カオスになるのは規模関係ない。

421 :デフォルトの名無しさん:2009/09/21(月) 14:38:16
機能が増えて、メンテナンス性を上げようとクエリやら関数を共通化しようとしたあたりからカオスだな


422 :デフォルトの名無しさん:2009/09/21(月) 15:10:39
自分で作ったフォームと良く似た機能のフォームを
ソースをちょっとだけ変えて2つ目を作るとき
それなりのプロジェクトでは共通部分を親クラスにして
それぞれが継承したりするもんなんだが
Access/Excelでは良く似たフォームを
もう一度最初から作るしかないのか

423 :デフォルトの名無しさん:2009/09/21(月) 16:14:34
いや、コピペするからそんなことないよ

424 :デフォルトの名無しさん:2009/09/21(月) 16:27:48
そして後日修正漏れが発生するのですね、わかります。

425 :デフォルトの名無しさん:2009/09/21(月) 16:50:42
最近はdiffを使いこなしてるから修正漏れはなくなったよ。
diff -rbw
これの意味分かるかい?へへへ

426 :デフォルトの名無しさん:2009/09/21(月) 17:09:02
-uは付けないの?


427 :デフォルトの名無しさん:2009/09/21(月) 18:40:59
<>の方が好きだからつけないよ
patchとか使わないし

428 :デフォルトの名無しさん:2009/09/21(月) 20:55:09
フォームの継承はマジで出来ませんか?

429 :デフォルトの名無しさん:2009/09/21(月) 21:07:28
Excel VBAとかって使ったことあるけど、バージョン管理ソフトで差分管理できなくて大変だった。
ソースをdiffれねえw

430 :デフォルトの名無しさん:2009/09/21(月) 21:22:38
俺もDB定義書をSQLにするようなのを書いて使ってるんだが、その辺が不満
コピペで無理矢理SVNに突っ込むって以外に、何か方法はないのかな

431 :デフォルトの名無しさん:2009/09/21(月) 21:25:56
Flashもソース管理できないから大変。プロジェクトファイルのバイナリ1個しかはかねえし
Flex?だとファイルがバラになるからいいんだけど

432 :デフォルトの名無しさん:2009/09/21(月) 21:34:03
Office2007でxml形式で保存したらsvn/diffに合いますかね

433 :デフォルトの名無しさん:2009/09/21(月) 21:35:58
>>431
Flashはソースをテキストからincludeする方法があるからまだましかと
ちょっとめんどいけど

434 :デフォルトの名無しさん:2009/09/21(月) 21:43:53
>>432
ODFにしてもそうだけど、最終的にはzipでまとめてるから
既存のバージョン管理システムとは相性悪いんじゃないかな

435 :デフォルトの名無しさん:2009/09/21(月) 22:50:18
>>432 >>434
圧縮されてるんだよな。

しかもデータがでかいとロードが時間掛かりすぎるから、バイナリ形式で保存したりするし。

436 :デフォルトの名無しさん:2009/09/22(火) 00:51:37
RubyをVisualBasicの代わりとして使えないかなと考えている。
VisualBasicは進化の方向性を致命的に誤ったと思うのだよね。
旧VB6のポジションが空いている。
VB.NETに代替に成りきれていないでしょ?
そこにRubyが入れないかと、そう思った次第。

437 :デフォルトの名無しさん:2009/09/22(火) 02:13:07
Pythonでもいいや

438 :デフォルトの名無しさん:2009/09/22(火) 02:33:48
>>436
Rubyはよいのだが、GUI付くんのどうする?オススメライブラリ教えて欲しい。
web系ならRailsでも使ってwebインターフェスにすればいいかもしれんが。
GUIなら、VB.net、というかC#でいいしな・・・

439 :デフォルトの名無しさん:2009/09/22(火) 02:58:46
>>438
大抵の人の言う「GUI」は「(見慣れたWindowsの)GUI」なんで
とりあえずVisualuRubyじゃない?

440 :デフォルトの名無しさん:2009/09/22(火) 05:16:14
VisualuRuby昔使ったけど
イベントやらなんやら色々書き足さなきゃいけなくて
結局自分でAPIゴリゴリ読んだ方が速いってことで
VisualuRuby使うのやめちゃったな

WIN32API/WIN32OLEだけで殆ど問題ないし

ところでRubyから.NET呼べたっけ?

441 :デフォルトの名無しさん:2009/09/22(火) 08:45:24
IronPythonを思い出してあげてください…。

442 :デフォルトの名無しさん:2009/09/22(火) 10:07:01
VisualuRubyかサンクス、試してみるワー

>>441
俺はIronRubyに期待

443 :デフォルトの名無しさん:2009/09/22(火) 13:29:04
言語の機能もあるけど、GUIアプリ作るなら、VisualStudioを超えないとな。まあ、C#は凄くいいと思うけど。

444 :デフォルトの名無しさん:2009/09/22(火) 13:41:35
そうすると最終的にTcl/Tkが候補に挙がってくるわけだ

445 :デフォルトの名無しさん:2009/09/22(火) 13:43:21
そういえば動的VBというかVBxの話はどうなったんだろね

446 :デフォルトの名無しさん:2009/09/22(火) 13:54:56
Win/UNIX問わずGUIが充実したスクリプト作ったらそうとううけるね。

447 :デフォルトの名無しさん:2009/09/22(火) 14:38:49
つPython

実際、海外だとそういう用途に使われてるしな・・・

448 :デフォルトの名無しさん:2009/09/22(火) 14:38:52
現状で GUI アプリを作りやすい LL は何なの?

449 :デフォルトの名無しさん:2009/09/22(火) 14:42:48
>>447
いや、やっぱ結局Win32呼ばんとできんこといっぱいあんのよ

450 :デフォルトの名無しさん:2009/09/22(火) 14:47:45
つTcl

451 :デフォルトの名無しさん:2009/09/22(火) 15:21:05
>>449
例えばどんな事?
今wxPythonをやってるんで気になる

452 :デフォルトの名無しさん:2009/09/22(火) 17:14:47
>>451
今Dockableウィンドウとか使ってるけどたぶん無理でしょ。
つかオーナードローもできないのがほとんどじゃない?
あとIEコンポーネントもイベントシンクとか上手く使えなさそう。
まあ膨大なWindowsの機能をすべてラップするってのも無理な
話だと思うから、CとかDllを簡単に呼べるスクリプトがあったら
使いたい。

453 :デフォルトの名無しさん:2009/09/22(火) 18:03:30
ctypes

454 :デフォルトの名無しさん:2009/09/22(火) 19:52:45
Pythonは標準ライブラリにctypesがあるのが強いよね。
if sys.platform == 'win32' とかして WinAPI 呼ぶコードを混ぜた
クロスプラットフォームアプリが書ける。

455 :デフォルトの名無しさん:2009/09/23(水) 02:23:40
wxPython 使いやすいね
GUI を XRCed で作って
ほぼ完全にコード部分と切り離せるのが素敵

456 :デフォルトの名無しさん:2009/09/23(水) 02:27:58
>>451
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/8861.txt

457 :デフォルトの名無しさん:2009/09/23(水) 09:11:14
>>456
昔VBで書いてたら、結局こんな感じのAPI呼び出しばっかになって
C++で書けばいいじゃんってなったよ。defineとか自分で書くのばからしいし。

458 :デフォルトの名無しさん:2009/09/23(水) 17:54:31
Python3の普及度はどんなもんかね。

459 :デフォルトの名無しさん:2009/09/29(火) 00:07:15
この間落としたWindows版はなんか2.5だった
何故だったんだろ

460 :デフォルトの名無しさん:2009/09/29(火) 20:00:07
Snow Leopard にしたら 2.6.1 だ

461 :デフォルトの名無しさん:2009/09/30(水) 22:34:19
sed,awkってLLにはいるん?

462 :デフォルトの名無しさん:2009/10/01(木) 03:28:29
sedはプログラミング言語とは言えず微妙な気がする
awkは初期のLLと言えるんじゃね

463 :デフォルトの名無しさん:2009/10/01(木) 10:35:37
awkはいまだにワンライナーで使うなあ。

464 :デフォルトの名無しさん:2009/10/01(木) 10:50:19
俺はハードなCUI使いじゃないので、
ipythonをshellにしてipipeとか使うよ

465 :デフォルトの名無しさん:2009/10/01(木) 13:06:37
で、LLってなにwに戻ると

466 :デフォルトの名無しさん:2009/10/06(火) 22:19:28
最近思う。
「やっぱ、perlでいいや」

467 :デフォルトの名無しさん:2009/10/06(火) 22:59:04
perlはなんか昔は良かったみたいな気分になるなw

468 :デフォルトの名無しさん:2009/10/06(火) 23:04:08
perlはなんか昔は酷かったみたいな気分になるなw



469 :デフォルトの名無しさん:2009/10/07(水) 00:11:53
LLでがっつりしたもの書く気しないし、汎用作業はperlでいいや
ガワが必要になったらtcl/tkでいいや

470 :デフォルトの名無しさん:2009/10/07(水) 02:07:50
WEBプログラミングでの利用を前提に考えた場合Pythonってどうだろう。

471 :デフォルトの名無しさん:2009/10/07(水) 03:30:29
標準で
cgi
wsgi
フレームワークでは
django
TurboGears
pylons
plone
zope
テンプレも
ORも
いっぱいある

472 :デフォルトの名無しさん:2009/10/07(水) 04:20:53
なせかPではじまるのが3つ
Rではじまる天の邪鬼がひとつ

473 :デフォルトの名無しさん:2009/10/07(水) 04:37:14
>なせかPではじまるのが3つ
Prolog、Pascal、PL/Iですね、わかります。

474 :デフォルトの名無しさん:2009/10/07(水) 07:21:24
スレタイ1000000回読んで出直せ



475 :デフォルトの名無しさん:2009/10/07(水) 07:51:06
>>470
Webアプリに関して言えば、PHPやRubyの方がいい気が

476 :デフォルトの名無しさん:2009/10/07(水) 07:54:59
根拠を述べろよ禿

477 :デフォルトの名無しさん:2009/10/07(水) 08:36:51
サンプル多いもん
土台からして、PHPはサーバ屋さん任せにできるところは多いしもともとフレームワークみたいなもんだし、
Rubyなら、Railsの情報の豊富さも、CGIとしての利用例もそれなりに。チュートリアルもあるし。

間違いなくPythonの取っつきにくさは一段階上だよ
Windowsサーバでならちょっとは状況は違うのかな?

478 :デフォルトの名無しさん:2009/10/07(水) 09:08:35
cgiとしての利用例ならPythonにでもいくらでもある。
あとは、Railsに情報が集中しているRuby vs Django/Pylons/TurboGears/etc... に
情報が分散しているPythonの違いになるけど、ぶっちゃけたいした差じゃないな。

479 :デフォルトの名無しさん:2009/10/07(水) 09:19:37
CGIとフレームワークって、viとEmacsみたいなものなの?

480 :デフォルトの名無しさん:2009/10/07(水) 10:33:21
違う。
なぜならCGIとframeworkでは聖戦にならない。

481 :デフォルトの名無しさん:2009/10/07(水) 10:42:43
>間違いなくPythonの取っつきにくさは一段階上だよ
W

482 :デフォルトの名無しさん:2009/10/07(水) 12:05:34
俺はPerlが一番取っ付きにくかったなあ

483 :デフォルトの名無しさん:2009/10/07(水) 12:30:52
WEB業界ではPython浸透してると思うよ。
今日本でPythonが注目されてるのはGoogleAppEngineの成果も大きいし。

484 :デフォルトの名無しさん:2009/10/07(水) 12:32:50
プログラミングはCGIの改造から入ったから、Perlが一番できるなー
その後、Rubyを勉強したけど、Rubyのほうがよさそうな感じ。

485 :デフォルトの名無しさん:2009/10/07(水) 13:13:38
CGI ≒ perl

486 :デフォルトの名無しさん:2009/10/07(水) 13:44:09
PerlやらPHPでWEBアプリが作りやすいってのは、みんな最初そこから入るからだろ?
パーミッションの設定やらなんだかんだ、フリーのアプリをなんとか動くように頑張って、
その後いろいろ改造して・・・ってな段階を踏んでるから。
大抵、基礎の筈のHTTPプロトコルの詳細やApache等Webサーバの仕事・設定を知るのは
それなりになんか書ける様になってから。そういう人がかなり多いという。

だから、全くの一からの取っつきやすさの議論ってのは、あんまり意味が無いと思う。
取っつきやすさって要は、どれくらいそれを触り、動かそうとする動機があるかってだけじゃん。

何がいいたいかというとPerl難いよめんどいよってことだ。なんだあのデリファレンスって。

487 :デフォルトの名無しさん:2009/10/07(水) 14:05:16
>>485
そう認識してる馬鹿が多いという点は同意

488 :デフォルトの名無しさん:2009/10/07(水) 14:09:11
webアプリしか書いたことのない人
あるいはwebアプリからプログラミングに入ったひとに
質問なんだけどデスクトップアプリって書ける?
or書きたいと思う?
or書けるようになるまでに違和感なかった?

489 :デフォルトの名無しさん:2009/10/07(水) 14:40:34
>>488
画面を作るのが楽(簡単、ではなく)なら書けるだろうし書きたいだろうな。
JavaのSwing使って掲示板もどきなら書けた。
デスクトップアプリってのが何を指すのかよくわからんが、CUIで例えばncursesで
オセロとかなら、入力やら表示やらの段階で簡単に挫折出来る自身がある。

あと、やたら数を数えたり足し算引き算しまくるような記述が必要ないなら。
とにかく数を数える、数を指定する、数を覚える、という作業が面倒くさいイメージ。

って、隣の隣の兄ちゃんが言ってた。俺だけど。

490 :デフォルトの名無しさん:2009/10/07(水) 15:06:06
>>488
>>484だけど、C#で挫折したわ。
趣味でPerlやRubyでCGIプログラミングするのがやっと。

491 :デフォルトの名無しさん:2009/10/07(水) 15:06:13
>>485
やってた頃はcronでたたくscriptが多かったな
後は mail受信->DB登録を書いたりとか
#PerlでCGI書くのはあまり好きじゃなかったよ

>>488
今どんなOS/言語使っているか、どのOS/言語を対象に考えているかが
無いと、なんとも言えないと思う
Postでパラメータ拾ってくるのとは違うけど、それ以降は同じだよ
#画面出力は色々はコンポーネント使うことになると思うけどね

492 :デフォルトの名無しさん:2009/10/07(水) 15:47:07
>>486
@{$hash->{key}} …つまり $hash->{key} (もしくは $list->[idx] )と @{array_ref} の2つさえ判れば
デリファレンスは意外と何とかなる…気がする、逆に $$hash{key} とか考えると混乱する

493 :デフォルトの名無しさん:2009/10/07(水) 16:55:21
>>490
簡単な本を1冊こなして、オライリーのプログラミングC#やれば
そこそこ、いけると思うのだが
#後者のみでも可。ある程度の大枠つかまないと、使えないと思うよ
c#の構文そのものと.Net Framework 使いこなすのとは違うから

494 :デフォルトの名無しさん:2009/10/07(水) 17:40:45
>>493
アドバイス、d
また挑戦してみるわ。

495 :デフォルトの名無しさん:2009/10/07(水) 19:21:40
メインがウェブで、たまに頼まれてWindowsフォームのアプリ作るけど、HTMLに慣れてるとGUIを組み立てるのが面倒だな。その分、操作性が高いもの作れるけど。
後はウェブの場合、RDBMSに頼りすぎるっていうか。

496 :デフォルトの名無しさん:2009/10/07(水) 19:25:55
っXAML


497 :デフォルトの名無しさん:2009/10/08(木) 22:06:39
また、perl本 買っちゃったよ。。

498 :デフォルトの名無しさん:2009/10/08(木) 22:09:32
>>497
何買ったの?

499 :デフォルトの名無しさん:2009/10/08(木) 22:12:46
続・はじめてのperl
ずっと 初心者卒業できないんだ

500 :デフォルトの名無しさん:2009/10/09(金) 00:21:21
お前らもっと異宗教どもを口汚くののしらないとだめなんだぜ。じゃないとバトルでロワイヤルじゃないんだぜ。

501 :デフォルトの名無しさん:2009/10/09(金) 00:42:02
>>500
この豚野郎!

502 :デフォルトの名無しさん:2009/10/09(金) 00:45:33
ケンカはやめて(><)

503 :デフォルトの名無しさん:2009/10/09(金) 01:19:40
バトルロワイヤルと言うよりは、暖を囲んで愚痴を吐いて励ましあってるよな。。。

504 :デフォルトの名無しさん:2009/10/09(金) 02:00:05
う、うん……

505 :デフォルトの名無しさん:2009/10/09(金) 05:10:30
>>501
お前、俺に・・そんな・・ハア・・・言葉浴びせる・・ハアハア・・ないで;ください、お願いします。

506 :デフォルトの名無しさん:2009/10/09(金) 17:28:49
RubyとPythonを足して2で割ったような言語を教えてほしいな…っと

507 :デフォルトの名無しさん:2009/10/09(金) 17:45:44
>>499
RubyとかPythonのほうがいいんじゃない?

508 :デフォルトの名無しさん:2009/10/09(金) 18:18:42
Schemeだろjk

509 :デフォルトの名無しさん:2009/10/09(金) 18:41:32
とりあえずPythonやっとけば仕事でも趣味でも困らない。

510 :デフォルトの名無しさん:2009/10/09(金) 19:23:11
PythonとSchemeとJavaScriptをやってる。LL界隈では無敵だじぇ

511 :デフォルトの名無しさん:2009/10/09(金) 20:18:53
>>506
perl

512 :デフォルトの名無しさん:2009/10/09(金) 22:29:54
pythonが使われてるところってあるの?
少なくとも日本ではほとんどないんじゃないかな。

513 :デフォルトの名無しさん:2009/10/09(金) 23:08:39
>>512
Windows では DropboxやBitTorrent が有名だけど、いろんなゲームで
組み込まれててたり、縁の下で力持ってる。
LinuxはもうPython無しが苦行なレベル。

514 :デフォルトの名無しさん:2009/10/09(金) 23:28:19
LinuxはPerlとPythonがほぼ標準で入ってるよね

515 :デフォルトの名無しさん:2009/10/09(金) 23:47:27
Perlなら大分前から商用含めてUnix系OSにはデフォで入ってる気がする
Pythonはさすがにそこまででもない

516 :デフォルトの名無しさん:2009/10/10(土) 00:33:09
>>506
tcl

517 :デフォルトの名無しさん:2009/10/10(土) 01:10:38
メジャーなディストリで、Python無しでもインストールできるのってDebianくらいじゃね?

518 :デフォルトの名無しさん:2009/10/10(土) 01:13:22
う、うん……(´・ω・`)

519 :デフォルトの名無しさん:2009/10/10(土) 02:42:36
windowsに標準搭載されれば爆発的にヒットする?

520 :デフォルトの名無しさん:2009/10/10(土) 03:12:15
WSHが爆発的ヒットしてないのを考慮するとおそらくヒットしないだろうな。。

521 :デフォルトの名無しさん:2009/10/10(土) 03:19:20
PowerShell!!

522 :デフォルトの名無しさん:2009/10/10(土) 03:45:06
会社で買ったHPのWindows PCにこっそり入ってた>Python
なにに使ってるんだ?

523 :デフォルトの名無しさん:2009/10/10(土) 03:49:10
Thinkpad X200 にも入ってるぞ
C:\Program Files\Common Files\Lenovo\Python24

ほんと、OSに標準搭載にしたらいいのにな。
でも、WinXPみたいに長寿命なWindowsが出ると、ずっと古いPythonに対応しないと
いけないのが面倒そうだ。

524 :デフォルトの名無しさん:2009/10/10(土) 03:59:08
MSが搭載したらIronPython

525 :デフォルトの名無しさん:2009/10/10(土) 16:40:53
Macが標準でインストールされているのはRubyだっけか?確か

526 :デフォルトの名無しさん:2009/10/10(土) 17:08:34
>>525
日本語大丈夫か・・・?
Macにも標準でPython入ってるよ。wxPythonとかまで入ってたはず。

527 :デフォルトの名無しさん:2009/10/10(土) 17:57:15
すのうれぱーどにて

$ /usr/bin/python --version
Python 2.6.1
$ /usr/bin/php -v
PHP 5.3.0 (cli) (built: Jul 19 2009 00:34:29)
<略>
$ /usr/bin/ruby -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]
$ /usr/bin/perl -v

This is perl, v5.10.0 built for darwin-thread-multi-2level
<略>

$ which wxPerl wxPython wxRuby
/usr/bin/wxPerl
wxPython not found
wxRuby not found


528 :デフォルトの名無しさん:2009/10/10(土) 18:38:41
>>514-515
うに系でPython使うのはGUIの小物ツールに多い気がする
設定ファイル弄るツールとかに多くね?
んだから玄人向けの環境ほど見ないが、簡単に使える系の環境だと多そうだ

529 :デフォルトの名無しさん:2009/10/10(土) 18:41:10
>>528
yumとか、iotopとか、コマンドラインツールもPython系大量

530 :デフォルトの名無しさん:2009/10/10(土) 19:39:14
  | ̄ ̄ ̄ ̄ ̄ ̄ ̄|
  | 次でボケて! |
  |_______|
 ..  . ハ,,ハ ||    .       .
   ( ゚ω゚)||      .
   / づΦ

531 :デフォルトの名無しさん:2009/10/10(土) 20:26:11
>>1
> 最強のLL=軽量プログラム言語は、どれよ?
>
> エントリーは、Perl、PHP、Python、Ruby、JavaScript・・・
> さあ、死ぬまで語りやがれ!!!

コンパイルして EXE ファイル作れるのは、どれですか?

532 :デフォルトの名無しさん:2009/10/10(土) 20:28:49
>>531
貴方がコンパイラさえ書いてしまえばどの言語でも可能です。

533 :デフォルトの名無しさん:2009/10/10(土) 20:34:37
>>532
スミマセン
いまからどれ学ぼうか考えてる初心者なんですが、直ぐにEXEファイル作れるのは、どれですか?

534 :デフォルトの名無しさん:2009/10/10(土) 20:43:56
>>533
exeファイルを作るのにコンパイラが必要だと思っているようだが、
hspみたいにインタープリタとスクリプトをセットにしてexeを生成できるパターンもある。
pythonとか。

535 :デフォルトの名無しさん:2009/10/10(土) 20:47:10
hspって何だか意味もわからない厨房ですが、pythonならオケってことですね

536 :デフォルトの名無しさん:2009/10/10(土) 20:52:39
perlでもrubyでもできるよ

537 :デフォルトの名無しさん:2009/10/10(土) 20:54:29
なんか気になってググってたらどの言語でもexeに変換できそうな気がしてきたw

538 :デフォルトの名無しさん:2009/10/10(土) 20:56:39
>>537
Perlで昔からできてたんだから、後発の言語のコミュニティが似たようなものを作らないはずがない

539 :デフォルトの名無しさん:2009/10/10(土) 20:59:37
目的はパスワード含んだソースの隠匿です
ダンプしたら中身が見えちゃうニセモノのEXEじゃダメです

540 :デフォルトの名無しさん:2009/10/10(土) 21:04:06
EXEにしても中身が見えるモノなんだが。

541 :デフォルトの名無しさん:2009/10/10(土) 21:06:42
>>539
実際にEXEの中身見たことないだろ?


542 :デフォルトの名無しさん:2009/10/10(土) 21:13:08
Zend Guard でも買え。

543 :デフォルトの名無しさん:2009/10/10(土) 21:14:33
なでしこ のEXEは、中身見るとそのままスクリプト見えます!
始めはVBSでスクリプトをエンコードしたら、簡単にデコード出来てしまいました、容易に見られちゃう

いま色々と調べてみたら、アイロンpythonでEXE作れそうなので、それを試してみます

544 :デフォルトの名無しさん:2009/10/10(土) 21:19:41
なんかちょっと勉強になったわ

545 :デフォルトの名無しさん:2009/10/10(土) 21:53:51
ソースの隠蔽が可能な言語ってC/C++以前の年代の言語だけなのかな。

546 :デフォルトの名無しさん:2009/10/10(土) 22:21:09
パスワード含んだソース
というのを何とかしたほうがいいかも

547 :デフォルトの名無しさん:2009/10/10(土) 22:23:49
インタプリタ言語から実行可能ファイルを作り出す簡単な方法として
対象スクリプトを起動するためのインタプリタと一体化したファイル
にする、という方法を選んだだけで、VMコードやネイティブコードを
吐くようになってればCと同程度の隠蔽は可能。単にそういう方法を
採用しなかったというだけ。

実行時に決まる部分が多い言語だとなかなか難しいところもあるがな。



548 :デフォルトの名無しさん:2009/10/10(土) 22:32:29
C/C++の年代ってまだ終わってないぜ

549 :デフォルトの名無しさん:2009/10/10(土) 22:33:25
Access で作ったパスワード掛けた業務データベースのフォーム入力を従業員にさせたいのですが
パスワード解ると、DAOで接続してテーブルデータ全て見られちゃいますので
パスワード知らせずに、パスワード掛かったAccessアプリをスクリプトで起動させたいのです

始めはVBSで起動スクリプト組んでエンコードしましたが、簡単にデコードされちゃう事が解りました
次にVBでEXE作って一応解決しました

今風なスクリプト言語を新たに学ぼうと思い、どうせなら同じ用途にも使えるもの選ぼうと考えました
先日RCがリリースされたPowerShell2.0を色々と弄って見ましたが、ソースの隠匿は無理のようでした

550 :デフォルトの名無しさん:2009/10/10(土) 22:49:10
悪い事は言わんから素人がそういうヘンテコな実装をするのはヤめといた方がいい。

マトモなエンジニアにそういうシステム全体から設計してもらえ。

551 :デフォルトの名無しさん:2009/10/10(土) 23:07:57
Accessねえ…

552 :デフォルトの名無しさん:2009/10/11(日) 09:18:28
Access自体が隠蔽を前提にしてないからなあ…

553 :デフォルトの名無しさん:2009/10/11(日) 11:31:12
>>549
パスワードによる情報保護や複数人でのデータアクセスの場合、普通はRDBMSを用いて実装する。

Accessはフロントエンドしては優秀なツールだと思うが>>549の利用方法はヘンテコと言うか
パスワードをアプリに埋め込んだ場合、パスワードがデコードされる可能性は常に0ではない。

バカにするワケではないが、Accessで済む程度の業務データなんざ、ゴミみたいなモノだろうから
妙な小技使わない方がマシだな。


つか、そういうのはOSのアクセス権でやっとけば済む話じゃないのか?
根本的な物事の解決方法がイカれている印象。

554 :デフォルトの名無しさん:2009/10/11(日) 11:54:19
つか、んなもん使ってる業務あるんだw

555 :デフォルトの名無しさん:2009/10/11(日) 12:34:03
AccessのVBA部分にパスワード掛けるってのはダメなの?

556 :デフォルトの名無しさん:2009/10/11(日) 12:34:31
Accessでももう少しマシなアクセス権管理できなかったか

557 :デフォルトの名無しさん:2009/10/11(日) 12:40:40
アクセスできるからAccessなのにアクセスできないAccessなんかNon-Accessだろ。

558 :デフォルトの名無しさん:2009/10/11(日) 12:57:28
いやそういうのはいい。

559 :デフォルトの名無しさん:2009/10/11(日) 14:02:26
mde

560 :デフォルトの名無しさん:2009/10/11(日) 16:34:35
どうしてこうなった

561 :デフォルトの名無しさん:2009/10/11(日) 19:38:20
>>557
俺は評価する

562 :デフォルトの名無しさん:2009/10/11(日) 22:10:49
>>527

wxPython は独立したコマンドじゃくてスクリプトに取り込むモジュールだ。今のOSXには最初から入ってる。
wxRuby も似たような感じだろう。
Perlの場合は wxPerlっていう別コマンドでないと実行できないんだな。

563 :デフォルトの名無しさん:2009/10/12(月) 20:11:45
だからperlで十分だっての

564 :デフォルトの名無しさん:2009/10/12(月) 21:39:29
PHP、割りと嫌いじゃない

565 :デフォルトの名無しさん:2009/10/12(月) 23:09:59
俺も。

というかC使いとかの人は一番慣れやすい。
PHP使いはウェブPHPで、他はC/C++でとか両刀的な人が多いけど
Ruby/Python使いは割となんでもこれ一つでやる、って人が多いな。

566 :デフォルトの名無しさん:2009/10/12(月) 23:26:20
Ruby、Python、どっちが日本語対応が良いの?

567 :デフォルトの名無しさん:2009/10/12(月) 23:36:16
>>565
それはPHPがWeb以外にむいていないから。
まあ真のPHP厨はなんでもPHPでやろうとするけど。

568 :デフォルトの名無しさん:2009/10/12(月) 23:37:17
>>563
十分って言い方だと、Perlは劣っている前提みたいにならないか?

569 :デフォルトの名無しさん:2009/10/12(月) 23:38:18
>>566
Python

570 :デフォルトの名無しさん:2009/10/12(月) 23:39:17
Perlは劣ってるっての

571 :デフォルトの名無しさん:2009/10/12(月) 23:43:06
そういうことにしたいのですね。

572 :デフォルトの名無しさん:2009/10/12(月) 23:59:44
そういうこと

573 :デフォルトの名無しさん:2009/10/13(火) 08:00:41
>>566
Ruby

Pythonのソフトはいつもマルチバイトがらみでトラブル起こす。

574 :デフォルトの名無しさん:2009/10/13(火) 08:05:21
そうでもない。
Pythonでトラブルが起きるのはプログラマが正しい使い方を分かってないから。
(日本では少ないが欧米だとそれなりに経験のあるプログラマでもバイト列と文字列の区別のついていない人が結構いる)

少し前だったが、俺が各言語でのファイルシステム関連の多言語対応状況を調べたときはPyhtonが一番よくできていたと思う。
次点でrubyだったがUnicodeのファイル名の扱いに若干難があった。PHPとPerlはもはや論外。

575 :デフォルトの名無しさん:2009/10/13(火) 08:11:34
欧米というか特にアメリカ人な。
本当にZの後に文字がないと思ってるんじゃないかって連中が存在する

576 :デフォルトの名無しさん:2009/10/13(火) 08:17:21
Pythonの「暗黙に失敗するよりも明示的にエラーになるほうがいい」というルールが
結果的に >>573 みたいな印象を受けている。
UnicodeEncodeError, UnicodeDecodeError はPythonで頻繁に見る
ことになるエラーだけど、文字コードに関する設計ポリシーを持ったときにこのエラーは
ポリシー違反している箇所を報告してくれる頼もしい見方になる。

中途半端にうまく動いていくれる代わりに、ShiftJISのファイルの中にUTF-8が混じる
ことがあるのに比べるとPythonの方が安心できる。

577 :デフォルトの名無しさん:2009/10/13(火) 09:18:33
>>574
なんでPerl論外なん?

578 :デフォルトの名無しさん:2009/10/13(火) 10:30:26
>>577
(少なくとも)ActivePerlがファイルを開く際にCreateFileAをうちぎめで使ってるので移植性を考えると避けたい。
ファイル名として与える文字列にUTF-8フラグ立てても変わらない。カスすぎる

ちなみに、PHPはファイル名を文字列と見なしていないので、
自分でファイル名をShifit_JISとかにエンコードする必要がある。
もはやウンコのレベル

579 :デフォルトの名無しさん:2009/10/13(火) 12:33:10
>>566
Rubyい一票

580 :デフォルトの名無しさん:2009/10/13(火) 13:21:09
>>578
Windows限定で、日本語ファイル名限定かよ。

581 :デフォルトの名無しさん:2009/10/13(火) 14:04:04
>>579
RubyはPythonみたいにCreateFileWを使ってくれるん?
>>580
日本語というか、Unicodeファイル名だな。
W系APIを使っている=Windowsでの動作がきちんと考えられていると
判断されても仕方ない。

582 :デフォルトの名無しさん:2009/10/13(火) 15:41:36
>>573
>Pythonのソフトはいつもマルチバイトがらみでトラブル起こす。

それは誤解

漏れもpython初心者の頃はなんだこりゃと思っていたが
理由がわかるとちゃんと使えるしよくできてる


583 :デフォルトの名無しさん:2009/10/13(火) 15:45:37
windows のコマンドプロンプト
はやく UTF-8 に対応してくれないかなぁ


584 :デフォルトの名無しさん:2009/10/13(火) 15:47:55
>>583
一応 chcp 65001 したら utf-8 になるけど、問題が多すぎて使い物にならないね。
WriteConsoleW を使って utf-16 を出力できるようにするのが一番いいんだろうけど、
あまりにも標準入出力の概念からずれるから、sys.stdout.write()を置き換えるのは
難しい。結局、 pywin32 の console を使うのが正解だと思う。

585 :デフォルトの名無しさん:2009/10/13(火) 18:48:59
>>584
標準入出力にUTF16はよくないのでは。
ASCII互換じゃないし、表現できない
文字があるでしょ。


586 :デフォルトの名無しさん:2009/10/13(火) 19:08:47
>>585
WindowsのW系APIが受け取る文字列がUTF-16だから、UTF-16で表現できない
文字列はそもそもWindowsが表示したりファイル名に使ったりできない文字列だよ?

587 :デフォルトの名無しさん:2009/10/13(火) 21:10:08
perlは、windowsで使わない!!
それでよし!

588 :デフォルトの名無しさん:2009/10/13(火) 21:43:11
そーだ。perl以外は、いらん!
マルチバイト処理もEncode覚えれば不自由ないし。


589 :デフォルトの名無しさん:2009/10/13(火) 22:24:16
>>583
PowerShell標準で付くんだから、必要ないだろ
ISEもあるんだし

590 :デフォルトの名無しさん:2009/10/13(火) 22:24:43
使いたいの使えばいいじゃないか

じゃ話が終わるので、

負荷を心配しないである程度大きめなものを、急いで作りたいなら、Railsが使えるRuby
負荷を気にしたり、高速に作りたいなら、Perl
「俺Python使い」と、かっこつけたいなら、Python
外注に安く作らせたいなら、PHP

591 :デフォルトの名無しさん:2009/10/13(火) 22:26:47
外注に安く作らせるならPHP。
それ以外は全部PythonとC。

592 :デフォルトの名無しさん:2009/10/13(火) 22:48:33
>>582
誤解じゃねーよw

俺がいいたいのは問題起こすPython製アプリの話と、それが原因となっている言語の問題。
プログラマの心遣いとかの話じゃない。

逆に、.NETアプリはマルチバイトで問題起こすの見たことない。
UNICODE前提のせいかしらんが・・・(.NETの仕様はあまり知らんので俺に突っ込みされても困るけど)

>>584
あー、そういや、>>573でRubyって書いたけど、コマンドプロンプトと文字コードの相性最悪なの忘れてたわw
UTF-8でRSpecとautotest(autospec)でまともにテストもできないwww
俺は出力時にSJISに変換してるw

>>589
PowerShellだと文字コード周り解決するのか?ちょっと入れてみるか

593 :デフォルトの名無しさん:2009/10/13(火) 22:59:21
>>592
> プログラマの心遣いとかの話じゃない。
プログラマの心遣いの問題ですね
CでUnicode対応アプリも書ければ、いわゆる「駄目文字」で問題を起こすアプリも書けるのと同じ
ただ、Javaや.NETのようにテキスト=Unicodeと割り切ったほうが
心がけの悪いプログラマでも問題を起こしにくいのは確かで
Pythonも3.xからはそうなりました

594 :デフォルトの名無しさん:2009/10/14(水) 01:11:57
Java/C#
  内部エンコーディングUTF16で固定。入出力時に外部エンコーディング指定して必ず変換。
Python
  uを付けた文字列はUTF16固定。付けないと任意?設定だっけ?内部的に混在するので扱い注意。
Perl
  Cと同じで任意だっけ?wideはなしだっけ?

こんなんだっけ?もう面倒だし、Java/C#式の内部固定がぐちゃぐちゃにならなくて一番いい気がするけどどうなん?

595 :デフォルトの名無しさん:2009/10/14(水) 02:03:55
>Python
>  uを付けた文字列はUTF16固定。付けないと任意?設定だっけ?内部的に混在するので扱い注意。


>付けないと任意?設定だっけ?
ソースの先頭2行目に
# -*- coding: utf-8 -*-
などと書くと
そのコードでエンコードされたバイト列になる

>内部的に混在するので扱い注意
混在っつっても明示的にuが付いてる訳でそこは平気
どっちかというとprintでuの付いている文字列を出力すると
暗黙にデフォルトのエンコードに変換されてコンソールに出力されるが
pythonに慣れずに(perlとかと同じ感覚で)ごっちゃにしたバイト列の方をprintすると
よくここでエンコードエラー/デコードエラーになる
つまり文字列とバイト列の違いは意識する必要がある

あとpython3で改善されてるはず

596 :デフォルトの名無しさん:2009/10/14(水) 02:07:00
>>595
>あとpython3で改善されてるはず

だからといって 2.4.x - 2.6.x が劣ってる訳じゃないけどね

2.3.x 以下は糞

597 :デフォルトの名無しさん:2009/10/14(水) 03:58:10
>>593
もしかして、プログラマ性善説主義者か?お前w

そんなのは言語仕様のレベルで都合のいい方向に傾けておくべきこと。

プログラマーなんて信用しちゃいけないよ。
あのリーナス・トーバルズすら、エンコーディングに無関心なのか git がマルチバイトを考慮しない仕様(バイナリとして扱う)

心遣いの問題とか言いいながら、永遠にマルチバイト対応がクソなC言語製やPythonアプリでも使ってろや

598 :デフォルトの名無しさん:2009/10/14(水) 04:01:39
>永遠にマルチバイト対応がクソな

kwsk

599 :デフォルトの名無しさん:2009/10/14(水) 08:45:26
597は言語がサポートしてないとなにもできない厨。

600 :デフォルトの名無しさん:2009/10/14(水) 09:19:42
いや、gitは確かにウンコ。
これはリーナスのおっさんが新しい方式について行けない老害だったから。

hgもウニコードの扱いが糞で、これもプログラマのセンスがなさ過ぎる。
Python3の文字列にバイナリとしてアクセスする方法をよこせなどと言っていた。

一方bzrは同じPythonだが上二つと比べて格段にエンコーディング周りのポリシーが優れてる。

601 :デフォルトの名無しさん:2009/10/14(水) 09:29:19
>>594
uがついたのが文字列で、ついてないのはバイト列。
世の中には、どうしてかこれを区別できない連中が多すぎる。

602 :デフォルトの名無しさん:2009/10/14(水) 09:38:09
uがついてるのはリテラルのときじゃね?
str = u"ahoaho"
ってしたらstrがなにかわかんなくね?

603 :デフォルトの名無しさん:2009/10/14(水) 09:41:41
正直スクリプトはこの辺がごちゃごちゃしすぎてて全然LLじゃねー
Javaのがはるかに楽

604 :デフォルトの名無しさん:2009/10/14(水) 09:47:00
>>602
その場合strの値はunicode型で、uをつけなかったときはstr型になる。
型が違うと当然、相互の演算に制約を受ける。

605 :デフォルトの名無しさん:2009/10/14(水) 09:50:15
Pythonの型付けは強い方だから、perlやPHPに慣れてる人だと引っかかるのかもしれないね

606 :デフォルトの名無しさん:2009/10/14(水) 10:09:01
JavaはcharがUCS2だと割り切っただけだろ。
サロゲートペアで泣きを入れることになっても知らんぞ。

607 :デフォルトの名無しさん:2009/10/14(水) 10:11:23
>>606
ユニコード操作するときってサロゲートペアはあんまり気にならないものだよ。
UTF32でも結局のところ合成文字を考えないといけなくてコード単位ごとに処理できない

608 :デフォルトの名無しさん:2009/10/14(水) 10:17:29
Pythonは2.6でも from __future__ import unicode_literals したら、
"foo" が unicode になって、代わりにバイト列は b"foo" しないといけないようになるよ。

609 :デフォルトの名無しさん:2009/10/14(水) 16:23:55
WindowsでPerlは確かにCreateFileAなのがダメだ。
Win32API::FileのCreateFileWを使えば簡単に呼べるんだが
Windows用のコードが増えちゃう。
decodeされてる文字列がそのまま、ファイルテスト演算子やPath::Class, IO::All等で使えるといい。
現状そうなっていないので、B::Hooks等を使って作ろうと考えたが時間がとれん。
PerlIO::fseは今一歩だ。
でも、だれかがやってるれるんじゃなかろうか。

現状はencode("cp932", "...")渡してる。

610 :デフォルトの名無しさん:2009/10/14(水) 18:17:53
>>566
1.9ならRuby圧勝だが、1.8ならPython勝利。

611 :デフォルトの名無しさん:2009/10/14(水) 19:14:12
pythonのバージョンは?

612 :デフォルトの名無しさん:2009/10/14(水) 19:29:37
具体的にRuby 1.9はPython2/3に比べて何がいいの?

613 :デフォルトの名無しさん:2009/10/14(水) 19:33:36
全然使ってる人がいなくてかっこいい

614 :デフォルトの名無しさん:2009/10/14(水) 19:50:52
後発組だけあって、いいとこ取りが可能

615 :デフォルトの名無しさん:2009/10/14(水) 19:55:25
そんな抽象的な発言はいいから、具体的に何がPythonよりも優れているの?
Python/Java/.NET の文字列=Unicode方式は十分ベターな解として
受け入れられていると思うんだけど、それよりも良い物なんだよね?

616 :デフォルトの名無しさん:2009/10/14(水) 20:05:13
文字列のインスタンス毎にコードセット情報が付いていて、
言語やライブラリはコードセットについて暗黙の前提を一切持ってない。

プログラム本体が基本的に使う文字コードはUTF-8だけど、2ちゃんねるの
datファイルを扱うクラスの中だけはShift-JISに、とかそういう設計が普通に
できる。

コードセットインディペンデントと言って、一昔前に文字コードに興味のある
Unix屋が集まれば必ず、理想の処理方式として話題になった方式なんだが。

617 :デフォルトの名無しさん:2009/10/14(水) 20:08:49
結局、標準ライブラリ内に文字エンコーディングに関する情報をばらまかないといけない不便な方式。

618 :デフォルトの名無しさん:2009/10/14(水) 20:13:11
perl以外の言語の必要性が分からん!

619 :デフォルトの名無しさん:2009/10/14(水) 22:02:28
JavaはBOMをゴミ扱いするのが嫌


620 :デフォルトの名無しさん:2009/10/14(水) 22:04:35
javaってLLか?

621 :デフォルトの名無しさん:2009/10/15(木) 00:07:08
objectです

622 :デフォルトの名無しさん:2009/10/15(木) 00:13:54
primitiveもあるから

623 :デフォルトの名無しさん:2009/10/15(木) 01:14:20
Python3 > Ruby1.9 = Python2.6 > Python2.5 > Python2.4 > Ruby1.8 > Python2.3

624 :デフォルトの名無しさん:2009/10/15(木) 10:47:26
Curl

625 :597:2009/10/15(木) 13:50:49
>>599
「俺が」じゃなくて、海外のアフォどもがなw

626 :デフォルトの名無しさん:2009/10/16(金) 12:25:40
求人でRUBYとPHPで検索かけたらPHPの圧勝。

627 :デフォルトの名無しさん:2009/10/16(金) 12:42:41
そりゃ求人ページが.phpなだけ。

628 :デフォルトの名無しさん:2009/10/16(金) 15:02:25
それだけ需要が有るって事じゃね?
RUBYよか。

629 :デフォルトの名無しさん:2009/10/16(金) 18:31:21
COBOLみたいな人気だよな。どう見ても

630 :デフォルトの名無しさん:2009/10/16(金) 22:24:06
COBOL W

631 :デフォルトの名無しさん:2009/10/16(金) 23:27:19
php きらいだが、php + netbeans 便利だな。

632 :デフォルトの名無しさん:2009/10/17(土) 03:08:14
どの辺が?

633 :デフォルトの名無しさん:2009/10/17(土) 09:24:43

リモートデバッグっていうやつ
perl cgiでできんのかな

634 :デフォルトの名無しさん:2009/10/17(土) 09:32:21
printデバグ + tail -f でそれほど困らないと思うのだが
サーバで動くアプリでデバッガって、どうやったって面倒くささが先に立つような

635 :デフォルトの名無しさん:2009/10/17(土) 10:11:30
php 大きらいだが、php + netbeans は、わりと面倒ではなかったよ。
しかし、printデバグ + tail -fで十分だな

636 :デフォルトの名無しさん:2009/10/17(土) 15:13:07
mixi Engineers’ Blog ≫ Lua on Tyrant: DBサーバにLLを組み込む
http://alpha.mixi.co.jp/blog/?p=236


LL?Python?Rubyと思ったら

Luaでした

Python、Ruby組み込みにくいってよwww死亡確認ww

637 :デフォルトの名無しさん:2009/10/17(土) 15:15:50
VisualStudioとかに慣れてて、php仕事に移行して何がつらかったってprintfデバッグだったわw
DOS時代から入ったけど、その時すでにIDEだったからprintfデバッグなんて、perlでCGI(笑)作ったときくらいしかやったことなかたからひどかった

しかも、phpの挙動不審さが輪をかけてた

今なら、NetBeansでデバッグできるのか・・・
今度試すか

638 :デフォルトの名無しさん:2009/10/17(土) 15:23:23
俺はそもそもあんまりバグ無いからなあ・・・

639 :デフォルトの名無しさん:2009/10/17(土) 15:40:53
ttp://hellopython.wordpress.com/2009/10/08/interview-with-python-3

Python△


640 :デフォルトの名無しさん:2009/10/17(土) 18:34:41
>>636
そもそもが組み込み向けのLuaやスクワールと比べたらなあ…

641 :デフォルトの名無しさん:2009/10/17(土) 19:05:53
>>638
そういう問題じゃないだろ

あろうがなかろうが、やらなきゃならん。普通は。

642 :デフォルトの名無しさん:2009/10/17(土) 23:22:11
GUIのあるアプリケーションだとIDEがあった方がいいけど、ウェブならテキストエディタとprintデバッグで十分だろ。

643 :デフォルトの名無しさん:2009/10/17(土) 23:31:11
う、うん……(´・ω・`)

644 :デフォルトの名無しさん:2009/10/17(土) 23:38:39
>>641
バグがないのになにをデバッグすんだよ

645 :デフォルトの名無しさん:2009/10/17(土) 23:41:37
>>644
デバグは、バグを探すことも含んでるよ

646 :デフォルトの名無しさん:2009/10/18(日) 02:16:10
デハゲしたいわ

647 :デフォルトの名無しさん:2009/10/18(日) 10:36:26
GUIもCUIも関係無いだろ。

648 :デフォルトの名無しさん:2009/10/18(日) 13:26:25
ああ、でもJavaScriptの場合、IDEがあった方がいいな。IDEというか、Firebugみたいなツール。サーバサイドの場合、高度な仕組み用意するまでもないからな。

649 :デフォルトの名無しさん:2009/10/18(日) 15:06:29
eclipse + EPIC は、使い物になるのか?

650 :デフォルトの名無しさん:2009/10/18(日) 15:26:45
とりあえず、本当にデバッガがないと困るって人はこれくらいやってるんだろうか
ttp://0xcc.net/blog/archives/000162.html

Eclipseのプラグインとかで使いやすくなってそうな気もするが、そういうのは無いのかな

651 :デフォルトの名無しさん:2009/10/18(日) 15:56:22
あたし学生だけど、仕事現場ってxUnitつかわないの?

652 :デフォルトの名無しさん:2009/10/18(日) 15:56:50
>>649
GUIでデバッグができるので重宝してるよ

653 :デフォルトの名無しさん:2009/10/18(日) 17:18:23
>>651
千差万別。このスレの話題でも出てたように、コンソールでtail -fしかデバッグ環境が無いものもある。

654 :デフォルトの名無しさん:2009/10/18(日) 18:30:04
デバッグの話が出てるけど、
バグ潰しって普通テスト書くもんじゃないの?

655 :デフォルトの名無しさん:2009/10/18(日) 20:07:31
初心者だから、普通がわからん!!

656 :デフォルトの名無しさん:2009/10/18(日) 20:13:41
テストって言っても、ウェブの場合、結局ブラウザ通さないとダメでしょう。処理が複雑な場合は、セレニウム使ってる。簡単なのは目視。

657 :デフォルトの名無しさん:2009/10/18(日) 20:17:00
>>655
意味が分かる前にやめておけw 全然すすめられない。

知ってはいたけどブラウザー依存はかなり多いのね。特にjavascript。
Firefoxだけ解釈が違うものがいくつかあって、対応しなくてもいいことになったが、今後の事を考えると怖い。

658 :デフォルトの名無しさん:2009/10/18(日) 20:40:36
テストをすすめない?なぜ?

659 :デフォルトの名無しさん:2009/10/18(日) 21:35:45
いや、仕事として薦めないってだけ。
テストはやらなあかん。

660 :デフォルトの名無しさん:2009/10/18(日) 21:39:40
友愛とUIを掛けてるのか

661 :デフォルトの名無しさん:2009/10/19(月) 00:47:19
つーか、テストってそういう環境依存テストばっかりだからなw
LL使うような仕事はw

662 :わかんないんです(><) ◆WAkan9Ey1g :2009/10/19(月) 02:08:31
わかんないんです(><)

663 :デフォルトの名無しさん:2009/10/19(月) 14:19:20
そもそもマトモな仕様書がない状態で開発させられるからな。
多分こんな感じで動けば自然な動作だし使いやすいだろうって作って、クライアントに検収出すと、それで通るからな。
そんな実態でユニットテストなんて意味持たない。

664 :デフォルトの名無しさん:2009/10/19(月) 18:15:21
ブラウザのUIをテストするのに、
xUnitとかをどう使えばいいのか。


665 :デフォルトの名無しさん:2009/10/21(水) 21:26:02
>>664
>わたしは無能で土方作業をしています。
まで読んだ。

666 :デフォルトの名無しさん:2009/10/21(水) 22:03:33
666

667 :デフォルトの名無しさん:2009/10/21(水) 23:07:09
>>665
自分の心を読んだんですね。

668 :デフォルトの名無しさん:2009/10/21(水) 23:11:24
さくら鯖使ってsend_mailで送信元のアドレスを変えたいんですが
変わりません。

php.iniをこんな感じにしたのですがどうすればいいでしょうか?

[mail function]
; For Win32 only.
SMTP = smtp.xxxx.sakura.ne.jp
; For Win32 only.
sendmail_from = info@xxxx.sakura.ne.jp

669 :デフォルトの名無しさん:2009/10/21(水) 23:14:58
さくらサーバって、Windowsサーバだったのか。知らんかった。

670 :デフォルトの名無しさん:2009/10/22(木) 00:38:26
>>668
require 'net/smtp'

671 :デフォルトの名無しさん:2009/10/22(木) 00:40:36
>>669
www

672 :デフォルトの名無しさん:2009/10/22(木) 00:43:01
http://pc11.2ch.net/test/read.cgi/hosting/1249413826/
http://pc11.2ch.net/test/read.cgi/hosting/1227200815/
http://pc11.2ch.net/test/read.cgi/hosting/1245735246/

673 :デフォルトの名無しさん:2009/10/22(木) 03:23:01
gtkチュートリアルのサンプルコードを見比べてみて、rubyが一番まともに見えた


674 :デフォルトの名無しさん:2009/10/22(木) 13:52:48
よし、そのまま仕事の案件として昇華するんだ

675 :デフォルトの名無しさん:2009/10/22(木) 20:19:48
なんとなく phpって嫌いだ
好きにになる方法を教えてくれ

676 :デフォルトの名無しさん:2009/10/22(木) 20:25:17
やだ

677 :デフォルトの名無しさん:2009/10/22(木) 20:48:27
>>675
ホワイトスペースやブレインファックでCGIを書く

678 :デフォルトの名無しさん:2009/10/22(木) 21:54:27
phpの利点を教えてしい

679 :デフォルトの名無しさん:2009/10/22(木) 21:56:35
デザインとロジックを近くに配置することで、非常に高いメンテナンス性を得られます

680 :デフォルトの名無しさん:2009/10/22(木) 22:57:58
>>672
ありがとん!

681 :デフォルトの名無しさん:2009/10/22(木) 23:20:02
何で近いとか遠いがメンテナンス性に関係するん?
疎や密じゃないん?普通

682 :デフォルトの名無しさん:2009/10/22(木) 23:21:37
マジレスする殿方って……

683 :デフォルトの名無しさん:2009/10/22(木) 23:39:50
JavaScriptの悪口はそこまでだ

684 :デフォルトの名無しさん:2009/10/23(金) 00:02:30
どんな超反応だよw

685 :デフォルトの名無しさん:2009/10/23(金) 00:28:25
>>678
変数宣言をせずに、好きな型を代入できること。

686 :デフォルトの名無しさん:2009/10/23(金) 00:45:26
それはぶっちゃけここでいうLLの全てに当てはまるので、特にPHPの利点じゃない

687 :デフォルトの名無しさん:2009/10/23(金) 00:56:41
ガ━━(゚Д゚;)━━ン!知らんかった。
じゃあ何でもいいや。

688 :デフォルトの名無しさん:2009/10/23(金) 01:42:01
Pythonは互換性がごにゃごにゃになったのでもう使う気がしないんだが。
いまさらPerlってのもなあ・・Rubyとかいや論外かな。
JavaScriptはいいよね、でもサーバサイドがなあ。
大体今こんな感じに思う。ろくな選択肢がないね。

689 :デフォルトの名無しさん:2009/10/23(金) 02:26:20
>>685-686
いや、もうちょっと微妙な話をするなら、確かにPHPが一番お手軽とは言えるかもよ。
次点がRuby・Python、ちょっと下がってJavaScript、ずっと下がってお情けでPerlと
言って言えなくもない > 変数宣言と代入のお手軽さ

ただそれに伴う副作用の話とかすると順位とか単純につけられるもんじゃないって
ことなんだろうが。・・・詳細は俺に聞くなよ?

690 :デフォルトの名無しさん:2009/10/23(金) 06:34:30
Pythonの互換性云々を言うヤツがJavaScriptはいいよね、って正直信じられん。

691 :デフォルトの名無しさん:2009/10/23(金) 09:44:43
PerlもPythonもRubyも変革の途上だから互換性で言えばどれも微妙な感じ

692 :デフォルトの名無しさん:2009/10/23(金) 10:40:46
じゃあ速度を取って Perl で。
とか言えないよなぁ。


693 :デフォルトの名無しさん:2009/10/23(金) 13:58:27
速度優先ならPythonだろ

694 :デフォルトの名無しさん:2009/10/23(金) 14:22:23
確かにPerlは速度で言えば速いと思う…
だが、やっぱ今となってはやや使いにくい
Perl6で一旦整理するんかねえ

695 :デフォルトの名無しさん:2009/10/23(金) 14:23:41
新参優先がPythonで古参優先がPerl
Perlを始めるなら早いほうが良い
Pythonは乗り遅れても古い仕様はすっきり切り捨てられているはずなので問題ない

696 :デフォルトの名無しさん:2009/10/23(金) 14:37:17
>>695
Perlの場合乗り遅れると逆に新しい方の仕組みについて行けなくなるよ。

697 :デフォルトの名無しさん:2009/10/23(金) 14:41:22
Perl5 までは、それ以前の文法や意味を尊重して発展してきた
Perl6 は Perl5 までの文法や意味を殆ど亡き者にしている
Perl6 が完成しても Perl5 は、別言語として発展していって欲しい

698 :デフォルトの名無しさん:2009/10/23(金) 14:48:47
Perl5を簡単に消せるならPythonがこんなに苦戦するわけがない

699 :デフォルトの名無しさん:2009/10/23(金) 15:19:23
Python がアホほど速ければっ!

700 :デフォルトの名無しさん:2009/10/23(金) 16:17:29
Perlはautomakeやら、spamassassinやらで使われてる。
Pythonはgnomeで使われてる。
Rubyも意外な場所で使われてる。
進む方向を決めて好きなのを選べばいい。

701 :デフォルトの名無しさん:2009/10/23(金) 19:38:30
PerlはPlack/PSGIとかAnyEvent, Coro辺りが
ワクワクすると思うんだがどうよ。

702 :デフォルトの名無しさん:2009/10/23(金) 20:23:54
phpは?

703 :デフォルトの名無しさん:2009/10/23(金) 23:06:53
Perl6使うくらいなら、Rubyいくわ

704 :デフォルトの名無しさん:2009/10/23(金) 23:55:41
php5とphp6の相当の違いはびびった。
別言語並みの改変じゃねーか('A`)

705 :デフォルトの名無しさん:2009/10/24(土) 00:08:44
PHPにはよくあること

706 :デフォルトの名無しさん:2009/10/24(土) 00:09:27
>>701
イベント駆動型も含めて、コンポーネント化・スレッド(コルーチン)・分散処理って
Javaを別角度から追いかけてるようにも見える。

Perl/PSGI,Python/WSGI,Ruby/Rack
このあたりはPythonが一番進んでるんじゃないか。

707 :デフォルトの名無しさん:2009/10/24(土) 01:16:35
>>706
>イベント駆動型も含めて、コンポーネント化・スレッド(コルーチン)・分散処理って
>Javaを別角度から追いかけてるようにも見える。

んー、JavaじゃなくてPythonじゃないかな。スレッドはJavaだけど、コルーチンはPythonのgenerator相当だし。
あとスレッドとコルーチンは別物だと主張したい。

>Perl/PSGI,Python/WSGI,Ruby/Rack
>このあたりはPythonが一番進んでるんじゃないか。

だね。もとはPythonのWSGIがあって、それをRubyがパクッて、さらにそれをPerlがパクった。

708 :デフォルトの名無しさん:2009/10/24(土) 01:50:00
>>707
あれ、Pythonのgeneratorは互いにyeild出来たっけ?
PythonのgeneratorはPerlのCoro::Generator相当だと思うが。

709 :デフォルトの名無しさん:2009/10/24(土) 01:51:28
>>708
× yeild
○ yield

710 :デフォルトの名無しさん:2009/10/24(土) 10:14:40
>>650
Railsアプリで、Rubyのコマンドラインデバッガ使って、Railsのソース追ってた時はマジ発狂しかけたww

Rubyの動的な言語の仕様とRailsの黒魔術的ソース構造と、コマンドラインでのデバッグの組み合わせは、
一人のデバッガーを容易にかつ精神的にも死に追いやることを理解した

711 :デフォルトの名無しさん:2009/10/24(土) 11:21:31
>>708
>あれ、Pythonのgeneratorは互いにyeild出来たっけ?
すまん、呼び出し側に戻ることしかできない

>PythonのgeneratorはPerlのCoro::Generator相当だと思うが。
そうかも


712 :デフォルトの名無しさん:2009/10/24(土) 11:50:31
>>700
spamassassinをPythonで書き換え中

713 :デフォルトの名無しさん:2009/10/24(土) 12:59:23
VBSじゃダメなん?

714 :デフォルトの名無しさん:2009/10/24(土) 14:01:32
適材適所


715 :デフォルトの名無しさん:2009/10/24(土) 21:04:08
pythonやperlと比べたときのrubyのドキュメントの少なさときたら

716 :デフォルトの名無しさん:2009/10/24(土) 21:34:03
IronPhthon2.0はexe作れなくなったのですか?

717 :デフォルトの名無しさん:2009/10/25(日) 01:04:49
>>715
そこでtwitterですよ

718 :デフォルトの名無しさん:2009/10/25(日) 03:34:15
RubyはAPIが見れない人にはキツい

719 :デフォルトの名無しさん:2009/10/25(日) 05:01:08
APIを見るって何だよw

720 :デフォルトの名無しさん:2009/10/25(日) 05:47:53
何だよと言われましても

721 :デフォルトの名無しさん:2009/10/25(日) 06:41:25
ソースの中を見れってこと?API見るって、普通、そういう使い方しないのでは。

722 :デフォルトの名無しさん:2009/10/25(日) 07:16:07
うむ

723 :デフォルトの名無しさん:2009/10/25(日) 13:16:21
あぴぃぃ

724 :デフォルトの名無しさん:2009/10/25(日) 16:58:26
俺も普通そういう使い方しないと思う。

「API出せ」とか言ってるのと同じくらい意味不明。

725 :デフォルトの名無しさん:2009/10/25(日) 18:13:16
Pythonが成功したのはPerlよりC言語に文法が似ているから。

726 :デフォルトの名無しさん:2009/10/25(日) 18:15:05
似ているか?

オフサイドルールとか def なんちゃらとか、全然違う様な気がするけど

727 :デフォルトの名無しさん:2009/10/25(日) 18:30:29
それはあくまで見た目上の話
本質的な文法はCとかなり似てる

728 :デフォルトの名無しさん:2009/10/25(日) 18:32:19
本質的な文法とは例えば?

変数の前に$がいらないとかw?

729 :デフォルトの名無しさん:2009/10/25(日) 18:40:55
本質的な文法とは何ですか?
レキシカルアナライザとパーサの用語で説明してください。

730 :デフォルトの名無しさん:2009/10/25(日) 19:07:51
Javaが成功したのもC言語に文法を似せたから。Pythonがもし
インデントをやめ、Java/C#/ECMAScriptと同様の文法を採用
していたら、世界制覇できてた。

731 :デフォルトの名無しさん:2009/10/25(日) 19:24:11
たらればをいくら言っても意味ないし

732 :デフォルトの名無しさん:2009/10/25(日) 19:46:06
:


733 :デフォルトの名無しさん:2009/10/25(日) 19:50:26
self なんかも C++ の this とはかなり違う

でも >>725 の言いたいことはなんとなく分かる

C との類似度でいえば

C - Python - Ruby - Perl

php は似て非なるもの外見とは裏腹の全く別物

734 :デフォルトの名無しさん:2009/10/25(日) 20:04:24
PerlがCに似てるとか無いわー

735 :デフォルトの名無しさん:2009/10/25(日) 20:33:56
PerlがCに似てるなんて誰も言っとらんが

736 :デフォルトの名無しさん:2009/10/25(日) 20:41:54
外見が似てればいいんだよ。実際PHPのシェアはPythonより大きいだろ

737 :デフォルトの名無しさん:2009/10/25(日) 20:48:02
似てる人はどこが似てると思うのかを言ってほすい。

738 :デフォルトの名無しさん:2009/10/25(日) 21:22:39
そんなこと言ったら、全部BASIC系だよな。これ。

739 :デフォルトの名無しさん:2009/10/25(日) 21:27:38
こういうときはALGOL系というのではなかったか?


740 :デフォルトの名無しさん:2009/10/25(日) 21:28:55
>>739
お前はAlgol系列とBASCI系の区別もつかんのか

741 :デフォルトの名無しさん:2009/10/25(日) 22:02:36
>>739
ブロック化、再帰呼び出しのサポートからすればAlgol系だけど、
sh,bash,cshの違いはどこだみたいな話になっとるの。

742 :デフォルトの名無しさん:2009/10/25(日) 22:12:14
>実際PHPのシェアはPythonより大きいだろ

Linuxの鯖だとPythonは嫌でも入っているがPHPは選択しないと入らない気がするが。

743 :デフォルトの名無しさん:2009/10/25(日) 23:18:48
JavaはC++じゃなくてVBに似てると思うんだが
漏れだけ?

744 :デフォルトの名無しさん:2009/10/25(日) 23:39:42
予約語類はC系に準拠しているし、
言語仕様もおおむねC++を弱めたり改良したものだと解釈できるから
C++に似ていると評されるのは妥当だと思う

近年のVBは話が逆で、むしろJavaから影響を受けてるっぽい

745 :デフォルトの名無しさん:2009/10/25(日) 23:45:18
イディオムが貧弱で
無駄にソースが長くなる点では
似ていると思う

746 :デフォルトの名無しさん:2009/10/26(月) 00:27:46
つまりPerl最高ですね。
わかります。

747 :デフォルトの名無しさん:2009/10/26(月) 00:35:54
PHPはJavaScriptがPerlを喰って突然変異を起こした上にC++まで飲み込もうとしてる雰囲気w

748 :デフォルトの名無しさん:2009/10/26(月) 00:41:25
JavaもPHPも、書き方が愚直に見える。
だから、Perlが好き。

749 :デフォルトの名無しさん:2009/10/26(月) 01:13:32
PHPはあらゆる言語の悪いとこどりをしているのではないかと感じる。

750 :デフォルトの名無しさん:2009/10/26(月) 01:27:28
PHPは月100円のレンタルサーバでも動くとか、ファイル1枚にまとめる事が出来るとか、何かしらエラーメッセージがブラウザに出るとか、いろいろとメリットはある。

751 :デフォルトの名無しさん:2009/10/26(月) 01:54:17
PHP
Java
VB
saiko

752 :デフォルトの名無しさん:2009/10/26(月) 01:58:26
>750
>何かしらエラーメッセージがブラウザに出るとか

python も先頭に

import cgitb; cgitb.enable()

書いておくといい

753 :デフォルトの名無しさん:2009/10/26(月) 03:25:46
>>750
一番目以外はどの言語でも同じだと思うが

754 :デフォルトの名無しさん:2009/10/26(月) 09:31:12
他の言語だと、テンプレートファイルを用意したり、エラー処理の為の記述が必要になる。

755 :デフォルトの名無しさん:2009/10/26(月) 09:32:15
抽象木レベルでは、構造化以後の言語はみな同じだろ。
Forth以外。

756 :デフォルトの名無しさん:2009/10/26(月) 13:22:21
文法解釈では確かにForthは変わってるよな

757 :デフォルトの名無しさん:2009/10/27(火) 12:16:34
でも、VMのレベルでなら FORTH と Java は同じ

758 :デフォルトの名無しさん:2009/10/27(火) 12:32:06
>>724
「API出せ」はよくいうぞ。webサービスでAPIないサービスにあったら、必ず言うことにしてる

>>753
1番目は相当でかいだろ
まあ、もちろん用途にもよるけど。

Ruby≒Railsは最悪な点。100円/月でpassengerインスコ済みは見たことない

759 :デフォルトの名無しさん:2009/10/28(水) 00:37:00
フレームワークで言われちゃうと
CakePHPやCatalystやDjangoはどう?と聞きたくなるけど。

760 :デフォルトの名無しさん:2009/10/28(水) 17:48:04
>>759
どうでもいいが今のCatalystはMoose使ってるから、
CGI環境では使いものにはならんな。

もしCGI環境でCatalystと似たようなフレームワーク使いたかったら、
発展途上だけどkayacのArkを使うのが良いと思うな。

まあ簡単なアプリならPSGIアプリケーションにしとくのが吉ってとこか。

761 :デフォルトの名無しさん:2009/10/28(水) 22:30:53
CGIでフレームワーク使う理由って何?

762 :デフォルトの名無しさん:2009/10/28(水) 23:17:51
>>761
システムよりもコンテンツに注力できる。

763 :デフォルトの名無しさん:2009/10/28(水) 23:39:51
意味がわからん

そのCGIってのはFastCGIとかを前提としてるの?

764 :デフォルトの名無しさん:2009/10/29(木) 02:45:12
糞なフレームワークに振り回されるのと、俺流でがんばるのには微妙な駆け引きがある。

765 :デフォルトの名無しさん:2009/10/29(木) 17:17:10
>>763 はアホ

766 :デフォルトの名無しさん:2009/10/29(木) 17:18:04
>>764
俺流で糞なフレームワークもどきのものを作ると良い床鳥で馬

767 :デフォルトの名無しさん:2009/10/30(金) 09:36:57
一回フレームワーク使うと、いちからCGIで構築とかやっとれん

768 :デフォルトの名無しさん:2009/10/30(金) 09:44:52
フレームワークもCGIでは

769 :デフォルトの名無しさん:2009/10/30(金) 09:54:47
同列に並べるもんではないよな

770 :デフォルトの名無しさん:2009/10/30(金) 10:03:18
C使ったらアセンブラには戻れんって言ってるようなもんか


771 :デフォルトの名無しさん:2009/10/30(金) 12:20:24
>>768
PHPもCGIとか言い出しそうだなw

772 :デフォルトの名無しさん:2009/10/30(金) 12:23:02
とかいいつつ、試しに聞くんだが、
PHPやPerlやRubyでwebサービス動かす仕組み全般のことなんていうの?
一昔前なら、イコールCGIといってもよかったが、CGIて今はもう個人くらいしか使わないしな。
「LAMP」は環境と仕組み全部入りだから何か違うし、Google app engineとかも入らないし。

773 :デフォルトの名無しさん:2009/10/30(金) 12:26:27
フレームワークとは言わないな〜
Ruby on Rails のRailsがフレームワークであって、Rubyの総称では無いし。

スクリプト言語じゃないの?perl、PHP、rubyと言えば分かってもらえるだろうし。

774 :デフォルトの名無しさん:2009/10/30(金) 14:47:33
Webアプリケーション ゲートウェイ インタフェース
とか言ったらそれっぽいかな。

775 :デフォルトの名無しさん:2009/10/30(金) 14:49:28
web2.0
ajax

776 :デフォルトの名無しさん:2009/10/30(金) 14:50:20
WSGI だな

777 :デフォルトの名無しさん:2009/10/30(金) 14:51:46
777

778 :デフォルトの名無しさん:2009/10/30(金) 14:52:36
また python 厨の荒らしですか

779 :デフォルトの名無しさん:2009/10/30(金) 16:15:14
>>772 が言ってるのは、WebサーバーとWebアプリを繋ぐ手段でしょ?
CGI は Common Gateway Interface だったんだから、 Gateway Interface が
一般用語だと思うよ。

780 :デフォルトの名無しさん:2009/10/30(金) 21:07:07
>>779
Gateway Interfaceかなるほど。

ただ、いや、なんというか、昔あったCGI≒Perlみたいなのをイメージしてるの。
スクリプト言語環境+上で言うGateway Interfaceというか。
webアプリっていうと、アプリ環境全体をさすけどそうじゃなくて、スクリプト側のこと

781 :デフォルトの名無しさん:2009/10/30(金) 22:28:26
CGIもスクリプトそのものを指す言葉じゃないけどな

782 :デフォルトの名無しさん:2009/10/31(土) 01:14:56
CGIはSSIに対して付けられた名前のような希ガス

783 :デフォルトの名無しさん:2009/11/02(月) 21:24:01
perlで書かれたプログラムでの他人のバグを探すとか、想像すると嫌すぎ
ライブラリとの直交性と可読性、ドキュメントの量、ユーザ数から、
OSS界隈は今後ともどもpythonが勝利
言語の機能や速度がどーこーよりか、平均以上のプログラマの貢献が重要
そして、rubyが勝てない理由


784 :デフォルトの名無しさん:2009/11/02(月) 23:17:35
煽りじゃないよ
隠さず言うよ
rubyがんがれ

785 :デフォルトの名無しさん:2009/11/03(火) 20:22:57
クラスが使えない言語は滅ぶべき

786 :デフォルトの名無しさん:2009/11/03(火) 20:25:45
bless {}, __PACKAGE__;

787 :デフォルトの名無しさん:2009/11/03(火) 20:53:52
クラスが使えないのもアレだが
ActionScript3のように、1ファイルに1クラスしか定義できないっつうか
ファイル名に依存するっつうか


788 :デフォルトの名無しさん:2009/11/03(火) 21:27:20
>>787
別ファイルにしてインポートすればよかったような

789 :デフォルトの名無しさん:2009/11/03(火) 21:33:35
1ファイルに1クラスしかつかえない言語?wwワロタそんなのあるのかw

790 :デフォルトの名無しさん:2009/11/03(火) 21:56:14
Java様がお怒りの様子です

791 :デフォルトの名無しさん:2009/11/03(火) 22:47:55
Javaは複数クラス書けるぜ?

792 :デフォルトの名無しさん:2009/11/03(火) 22:49:05
書けるっちゃ書けるが、ファイル名と同一のクラスが存在することが好ましいとされてるな

793 :デフォルトの名無しさん:2009/11/03(火) 23:06:12
好ましい/好ましくないの話じゃなくて
出来る/出来ないの話をしているんですが?
>>787 様がおっしゃっています

794 :デフォルトの名無しさん:2009/11/04(水) 00:08:07
AS3は1ファイルに複数クラス(Internal Class)定義できるぞえ

795 :デフォルトの名無しさん:2009/11/04(水) 00:16:57
AS3がダメなのはむしろこういうところ

・privateなコンストラクタが作れない
・オーバーロードができない
・ジェネリクスがない

全部ECMAの影響だと思うが、4(草案)がポシャったんだから、
もう独自路線を突っ走って欲しい

言語仕様自体は、PHPよりだいぶマシな作りだと思う

796 :デフォルトの名無しさん:2009/11/04(水) 09:05:48
>>795
そんなの、別にダメじゃねーだろ。
たぶんC++の影響を受けすぎ。


797 :デフォルトの名無しさん:2009/11/04(水) 09:22:16
>>796
えっ

798 :デフォルトの名無しさん:2009/11/04(水) 10:13:52
オーバーロードもできない静的型付け言語なんて・・・

799 :デフォルトの名無しさん:2009/11/04(水) 10:21:19
Haxe使っとけ。

800 :デフォルトの名無しさん:2009/11/04(水) 13:51:08
rubyって島根の奴が1人でシコシコ作ってると思うと
本当にスタンダードになるの?とか思っちゃうよなぁ。

801 :デフォルトの名無しさん:2009/11/04(水) 17:17:20
Linuxだってもともとはフィンランドのヲタクが・・・

802 :デフォルトの名無しさん:2009/11/04(水) 17:23:48
厳密には今のRubyも1人で作ってるわけじゃないしなあ

803 :デフォルトの名無しさん:2009/11/04(水) 17:59:34
Rubyスレで必死な奴を引き取ってくださいw

804 :デフォルトの名無しさん:2009/11/04(水) 20:37:19
フィンランドのオタクって、OO嫌いなんだっけ?
C++プログラマをこき下ろした記事はみたことあるけども、
スクリプト言語に関して、なにかしら記事かいてるの見たことないな

805 :デフォルトの名無しさん:2009/11/04(水) 20:54:01
>フィンランドのオタクって、OO嫌いなんだっけ?
>C++プログラマをこき下ろした記事はみたことあるけども
こういう理解になるのが空恐ろしい

806 :デフォルトの名無しさん:2009/11/04(水) 20:56:57
C++はOOPL好きでも酷評したくなる言語だと思うぜ

807 :デフォルトの名無しさん:2009/11/04(水) 20:57:36
それじゃ、どう解釈したらいいんだ
プロジェクト全体がゲロゲロのウンコになるって書いてたぞ

808 :デフォルトの名無しさん:2009/11/04(水) 21:26:10
C++って作者自身が否定していた言語だったと思うが

809 :デフォルトの名無しさん:2009/11/04(水) 21:30:34
C++は書かないといけないコードの量を増やしてプログラマが職を失わないように配慮したすばらしい言語なんですと言っていた

810 :デフォルトの名無しさん:2009/11/04(水) 21:35:17
>>808,809
それは誰かが書いたネタであって、作者自体は否定しているはずだぞ

811 :デフォルトの名無しさん:2009/11/04(水) 21:47:03
C++から見たらJavaはOO的に優れているというよりかはGCを評価しているフシがあるからな。

812 :デフォルトの名無しさん:2009/11/04(水) 22:07:45
C++: ゲロまみれのウンコ
Java: 綺麗なウンコ

813 :デフォルトの名無しさん:2009/11/04(水) 22:25:26
>>810
>>809のレスの内容は自虐的に否定してるじゃん

814 :デフォルトの名無しさん:2009/11/05(木) 00:08:24
汚物は消毒だな

815 :デフォルトの名無しさん:2009/11/05(木) 01:08:32
Javaが綺麗とか冗談www

816 :デフォルトの名無しさん:2009/11/05(木) 01:28:47
C++より綺麗だよ。

817 :デフォルトの名無しさん:2009/11/05(木) 01:59:23
どっちも糞だけどな

818 :デフォルトの名無しさん:2009/11/05(木) 02:00:01
どんな言語でもPHPよりましだと思ったでござるの巻き

819 :デフォルトの名無しさん:2009/11/05(木) 02:03:55
そもそも純粋にOOな言語がいいならJAVAとか使えばいいわけで
C++使うのは他のパラダイムで書きたかったり速度が必要だったりする場合だな

820 :デフォルトの名無しさん:2009/11/05(木) 02:06:48
いちばん書くコードが少なくて済むのはどれ?

821 :デフォルトの名無しさん:2009/11/05(木) 02:11:50
python

822 :デフォルトの名無しさん:2009/11/05(木) 08:59:00
>>820
他人を雇う。


823 :デフォルトの名無しさん:2009/11/05(木) 12:42:28
確かに書かないが

824 :デフォルトの名無しさん:2009/11/05(木) 20:35:24
見た目が綺麗になるのはpythonだろうな

>>820
言語レベルではRuby
モジュール使っていいならCPANがあるからPerl

825 :デフォルトの名無しさん:2009/11/05(木) 22:16:51
>>818
なぜだ?
phpだめ?

826 :デフォルトの名無しさん:2009/11/06(金) 00:08:07
phpは基礎(言語設計)が腐ってるからどうしようもない。

827 :デフォルトの名無しさん:2009/11/06(金) 00:13:12
またこの話か
PHPはその目的に特化されている
たまたまその上に乗っかってるものがちょっぴりギガ盛りでちょっと溢れてちょっと漏れてるだけだ

828 :デフォルトの名無しさん:2009/11/06(金) 20:17:21
>>820
awk

829 :デフォルトの名無しさん:2009/11/06(金) 20:40:53
>>820
django

830 :デフォルトの名無しさん:2009/11/07(土) 10:03:09
wiresharkなりgimpなりOOoなりで遊びたい。
windowsや*nixの間を行ったり来たりしたい。とか考えたら、とにかくpythonの一択


831 :デフォルトの名無しさん:2009/11/07(土) 18:37:44
Javaの、あの長ったらしい文はキモイ

832 :デフォルトの名無しさん:2009/11/11(水) 09:41:33
phpってファミコンに拡張音源とかチップのせてまでいろいろやってる感じ。
もうライフゼロだから

833 :デフォルトの名無しさん:2009/11/11(水) 17:04:40
馬鹿め

834 :デフォルトの名無しさん:2009/11/12(木) 02:38:22
アホのいい見本だな

835 :デフォルトの名無しさん:2009/11/12(木) 08:16:33
PHPって文法はアレだけど実装の性能はそこそこいいよ
そうでなかったら大規模なサイトで実績挙げてないから

836 :デフォルトの名無しさん:2009/11/12(木) 11:54:51
低スキルでも開発できてそこそこ速く動くのが良い

837 :デフォルトの名無しさん:2009/11/13(金) 04:18:15
ロジックに捉われず、流れで書けるところが良い。
今は可読性重視だよねー

838 :デフォルトの名無しさん:2009/11/13(金) 11:21:27
>> 83
大規模なサイトでは、PHPはテンプレートとしてしか使ってない場合が多い。
ロジックは他の言語で実装されてる。

839 :デフォルトの名無しさん:2009/11/13(金) 12:06:32
WikipediaもPHPだけど部分的にはC++で書かれてるね。
PHPで書いてしまった拡張機能がいっぱいあるせいでPHPを捨てられないでいるだけなんだけどね。

840 :デフォルトの名無しさん:2009/11/13(金) 14:26:52
捨てる事ができたら結局C++って事か?

841 :デフォルトの名無しさん:2009/11/13(金) 14:31:30
>>840
それはどうだろうね。
C++がネイティブ言語のうちC++と相互運用しやすいという理由で選んだわけだろうけど、
もしかするとPHPを捨てたら今度はC++を捨てたくても捨てられない状態になってるかもしれない。

842 :デフォルトの名無しさん:2009/11/13(金) 14:32:23
>>841の二つ目のC++をPHPに置換.

843 :デフォルトの名無しさん:2009/11/14(土) 03:46:52
まぁ速度と効率でいくとC++辺りで落ち着くだろうねぇ

844 :デフォルトの名無しさん:2009/11/14(土) 03:50:00
PHPが好まれるのは、mod_phpの取り扱いが簡単なのに処理が速いからだと思うよ。しかも安い。
JavaとかPerlとかは面倒だからね。知識が要求されるし。Windowsだとお金がかかるし。


845 :デフォルトの名無しさん:2009/11/14(土) 03:52:42
DBと連想配列の相性の良さは異常。

846 :デフォルトの名無しさん:2009/11/14(土) 10:28:19
そう、言語自体のよさではなくて、mod_phpのお手軽さでウケてるんだよね。

847 :デフォルトの名無しさん:2009/11/14(土) 12:51:36
環境が安くて、敷居が低いってことだよな

なんか聞いたことあるフレーズだと思ったら、VBか・・・
一時期のDelphiもだ

848 :デフォルトの名無しさん:2009/11/14(土) 13:40:45
いまだと ruby なんかも

849 :デフォルトの名無しさん:2009/11/14(土) 13:49:12
RubyはUNIX色が比較的強いから、Perl寄りじゃないかねえ。

850 :デフォルトの名無しさん:2009/11/14(土) 14:21:28
>>848
そういうイメージをRubyに持ってる人多いけど、実際は全然お手軽じゃないよ。

RORでまともなサービス立ち上げるとなると、
スレッド起動できないmongrelをポート単位でいくつも起動して運用しなきゃいけなかったりで
敷居が低いとは言い難い。

開発はしやすくて良いんだが、デプロイのことまで考えると悩ましい。
同じことさせるのでも、他言語(他フレームワーク)より重いから結局台数増やさなきゃいけなかったり。

851 :デフォルトの名無しさん:2009/11/14(土) 14:28:37
それはRoRの問題であってRubyの問題じゃねえし

852 :デフォルトの名無しさん:2009/11/14(土) 14:38:58
Rails周辺のことでなければ>>848は一体何を指して敷居が低いといったのか

853 :デフォルトの名無しさん:2009/11/14(土) 15:09:44
mod_phpだとかの話の流れだしな


854 :デフォルトの名無しさん:2009/11/14(土) 16:43:12
Passengerなら敷居が低いと言えるのでは?Windowsで動かんらしいけど。

855 :デフォルトの名無しさん:2009/11/14(土) 16:52:04
>>852
逝ってみたかっただけです

856 :デフォルトの名無しさん:2009/11/14(土) 19:07:08
言ってみたかっただけっていうことなら、

俺も
「それはRoRの問題であってRubyの問題じゃない」
とか言ってみたい

857 :デフォルトの名無しさん:2009/11/14(土) 19:36:38
言えばいいじゃない

858 :デフォルトの名無しさん:2009/11/15(日) 23:31:11
lol

859 :デフォルトの名無しさん:2009/11/16(月) 13:26:41
perl2rubyとか機械的なものでもそういうのがあれば便利なんだけどな
人任せだがどこかにないもんか

860 :デフォルトの名無しさん:2009/11/16(月) 15:01:29
vmでいいじゃん。ソースコードレベルで変換する意味がわからない

861 :デフォルトの名無しさん:2009/11/16(月) 16:52:22
質問:

PHP で、クラスの中からメンバ変数 x を参照するときは、
$this->x のようにします。

でもいちいち $this->… と書くとくどいし、
見通しが悪いコードになる。

これを回避する方法はありますか?

862 :デフォルトの名無しさん:2009/11/16(月) 16:59:26
「Python信者とRuby信者による戦争で200レスぐらい埋まるのを見たいです」
としか読めなかったw

863 :デフォルトの名無しさん:2009/11/16(月) 18:17:54
PHPはダメだな。やっぱPythonこそが至高

864 :デフォルトの名無しさん:2009/11/16(月) 19:40:21
Pythonが一番いいって言ってる人って、仕事で使ってるの?
使ってるなら、自分が作ったサイトとか晒してみてくれるとうれしい。
なんか見たことないんだが・・・


865 :デフォルトの名無しさん:2009/11/16(月) 20:01:34
Python仕事で使っているしサイトでも取りあげているけど、ここで晒す気はないなぁ。

866 :デフォルトの名無しさん:2009/11/16(月) 20:23:25
> なんか見たことないんだが・・・
何使ってるかって見て分かるもんなの?
CGI、PHP、JSP、ASP.NETみたいにURLに拡張子がつく系は俺でも見て分かるが
他はよう分からんわ

867 :デフォルトの名無しさん:2009/11/16(月) 20:29:26
>>866
いや、そういう意味じゃなくて
「この会社はPython使ってる」だとか、「このサイトはPythonで作られた」とか
そういう話を聞いたことないし、今まで関わったエンジニアにPython使いがいないっていう意味。

それはそうと、cgiと拡張子が付いてたら言語が分かる貴方はエスパーだと思う。

868 :デフォルトの名無しさん:2009/11/16(月) 20:35:19
>この会社はPython使ってる

だったらGoogleで十分だろ。


869 :デフォルトの名無しさん:2009/11/16(月) 20:36:41
>>867
ああ、cgiって拡張子だとわからんねw

870 :デフォルトの名無しさん:2009/11/16(月) 20:42:33
>>868
何が十分なのか分からないんだが。実績の話じゃないし。
このスレでPythonが一番と言ってる奴はgoogle社員なのか?

871 :デフォルトの名無しさん:2009/11/16(月) 20:53:25
>>870
2chで自分の社名出したいヤツいないから、「俺の会社でPythonで○○作ってる」は言い難いだろうな。
Google App Engine でできてるWebアプリたくさんあるし、Webアプリ以外でOSSはたくさんあるし。
この前のPython Hack-a-thon では90人弱のPythonistaが集まったから、
そこに行けばいくつも社名聞けただろうけど。

872 :デフォルトの名無しさん:2009/11/16(月) 20:55:50
>何が十分なのか分からないんだが。実績の話じゃないし。

実績の話じゃないなら、何を知りたいんだ?
Pythonで構築されたサイトならググレカスで終わるが。

873 :デフォルトの名無しさん:2009/11/16(月) 20:58:23
Rubyは「これはRubyで作られてます!」となぜか宣伝してたりするのが目につくけど
Perl,PHP,Pythonはそれほど自己主張はしてない感があるな。

874 :デフォルトの名無しさん:2009/11/16(月) 21:20:34
PHPで作ったら極力それを隠すしな

875 :デフォルトの名無しさん:2009/11/16(月) 21:34:14
>>873
マカーがmacを自慢するようなモンじゃね?

876 :デフォルトの名無しさん:2009/11/16(月) 22:12:20
>>873
語弊があるが、Rubistはよくも悪くも自己主張したい人が多いみたいね
PHPは拡張子でわかるし、CGIといえばPerlの時代が長かったからかPerlも明示してないのが多い
Pythonは…なんでだろうw

877 :デフォルトの名無しさん:2009/11/16(月) 22:26:59
ttp://www.nicovideo.jp/watch/sm8517855
こういうのを
wxPythonかPyQtで
あるいは
Ruby+GTK+
とかでやってほしいです
perl/phpはどうでもいいです


878 :デフォルトの名無しさん:2009/11/16(月) 22:37:15
やればいいじゃん

879 :デフォルトの名無しさん:2009/11/16(月) 22:47:16
いや、ここ君の日記帳じゃないんで
情報が埋もれるだけだからマジ勘弁して

880 :デフォルトの名無しさん:2009/11/16(月) 23:19:15
>>876
つmod_rewrite
PHPerが一番使ってるし妙に詳しいってのは公然の秘密
PHP以外は、ぶっちゃけPATHINFOでも全然おkってメンタリティが多い、様な気がする

881 :デフォルトの名無しさん:2009/11/17(火) 01:30:52
拡張子なんて関係ないだろ・・・
拡張子phpで、中身は他言語なんてApacheの設定一行じゃねーか

882 :デフォルトの名無しさん:2009/11/17(火) 03:48:06
何その保守管理泣かせ

883 :デフォルトの名無しさん:2009/11/17(火) 04:00:21
要素が見える事が怖いんだけど・・・

884 :デフォルトの名無しさん:2009/11/17(火) 07:01:16
エレメントが見えることがどうしたんだ?

885 :デフォルトの名無しさん:2009/11/17(火) 11:29:51
私はCGIの拡張子は付けずにapacheのconfにforcetypeでCGIの動作をするよう書いてる

886 :デフォルトの名無しさん:2009/11/17(火) 15:50:07
LL温泉の季節ですよー

LL温泉 2009 大分(湯布院) 開催のお知らせ ? LL温泉
http://ll-onsen.jp/

887 :デフォルトの名無しさん:2009/11/18(水) 00:12:24
小、中規模のWebアプリをいくつか作らなければならないが、
同僚がどうしてもPerlが良いという。
Perl  - 枯れてて信頼性がある
Java  - 信頼性がない
Python - 知らん
Ruby  - 論外
PHP  - Perlの子分だから、まぁ許せる
という事だそうなのだが、どうも今更PerlでWebは俺は抵抗を感じる。
上記の理由にも非常に違和感を感じるが、どう理論立てて反論していいか解らん・・・。
漠然と、Perlは書き捨てのスクリプトなら書きやすいとは思うが、
それ以外に向いてると思えない。
Perl以外を推めるのに、どう説得すれば良いと思います?

888 :デフォルトの名無しさん:2009/11/18(水) 00:30:44
PerlにあってJavaにない信頼性って何ものなんだろう。
ウェブアプリを作るにあたって、Catalystなりのフレームワークを使うなら別にいいのでは。
オレオレフレームワークや素のCGIで作る気なら、その後の保守に困るだろうね。
その同僚がずっと面倒みるならいいけど。

889 :887:2009/11/18(水) 00:45:29
そうなんです、それ(信頼性)が説明できなくて・・・。
Catalystも、例えばRailsと比較して、書かなくてもいいことを書かせてる、
と思えてしまい、あまり好きではないです(これは完全に自分の好みですが)。
もっとも、Catalystを使う事すら視野に入れてないようでしたが。

890 :デフォルトの名無しさん:2009/11/18(水) 01:58:32
同僚は根拠出してきてないんでしょ
議論にならんじゃん

891 :デフォルトの名無しさん:2009/11/18(水) 02:31:15
PHPはCの子分ではあってもPerlの子分ではありません。
どっちかと言うとRubyのほうがPerlの子分と言えるでしょう

892 :デフォルトの名無しさん:2009/11/18(水) 02:38:19
結局まともな言語が一つもないって事でおk?
今ここで挙げられた欠点を補うようなそれなりの言語作れば決定打になるんじゃね。

893 :デフォルトの名無しさん:2009/11/18(水) 03:09:27
Luaこそ至高。Lua以外のLLは勉強しなくて良い

894 :デフォルトの名無しさん:2009/11/18(水) 04:38:55
>>891
部分的に文法は似てるとはいえCとは全く異質のものじゃない?
Perlのモジュールだったから子分って表現したんだろうと思うけど。

895 :デフォルトの名無しさん:2009/11/18(水) 12:34:09
まー、その中ならPHPかなー。
入社1年目の人にみっちり教えたら書けるようになったし。

896 :デフォルトの名無しさん:2009/11/18(水) 13:58:12
意味不明。

897 :デフォルトの名無しさん:2009/11/18(水) 19:18:57
>>890
それはどっちとものようだが。w

一方はぜひPerlと主張し、他方はなんか
違和感があるからと言い訳を探す。
この争いだったら、ぜひと言ってるほうが
勝つべき。


898 :デフォルトの名無しさん:2009/11/18(水) 19:30:44
yum が python製である件について

899 :デフォルトの名無しさん:2009/11/18(水) 19:50:18
>>887
まず、そこに挙げられている言語なら、どれも十分枯れている。
どの言語でも、枯れたバージョンと枯れてないバージョンがあり、枯れたバージョンを使うならどれも同じぐらい枯れている。
もちろん枯れてないバージョンを使えばバグにぶつかる可能性が高いのも、どの言語でも同じ。
たとえばPythonは2.5系と2.6系はどちらも枯れている。3.xは枯れてない。
PHPは(私見だが)5.2.11は十分枯れている。5.3はまだ枯れてない。
Rubyは、1.8.6はすごく枯れている。1.8.7も十分。1.9はまだ。
JavaはJava5とJava6は十分枯れている。Javaが枯れてないというなら、その根拠を示すよう、その同僚とやらに聞いてみろ。
大事なのは枯れているバージョンを使うことであって、言語じゃない。

あと、枯れ具合を気にするべきは言語じゃないくて、フレームワークやライブラリのほう。
かりに「枯れているから」という理由でPerlを選んだとしても、Moose使ったら意味がない。
また言語のバグよりもフレームワークのバグの方がずっと多いので、フレームワークの枯れ具合を気にしてないのに言語の枯れ具合を気にするのは、はっきりいってバカ。

まとめ:
・枯れているバージョンを使えば、どの言語でも十分枯れているし信頼性はある。
・気にすべきはフレームワークの枯れ具合であって、言語のではない。

・・・とりあえず、これで言語を選ぶ理由として「枯れ具合」を持ち出すのは止めさせられるだろう。



900 :デフォルトの名無しさん:2009/11/18(水) 20:33:33
>>894
それ言うとPHPer(笑)がファビョるよね。
RubyやPythonが問題外なのは当然であり格下のPerlがルーツなのは
自尊心が傷つくらしい。

901 :デフォルトの名無しさん:2009/11/18(水) 21:26:40
>>887
Ruby論外っていうPerl使いは、大抵、Rubyを使ったことない奴。ちゃんと調べたこともない。
簡単。お子様仕様。お遊び。とか勝手にイメージ持ってたりしてる。

Rubyが流行った理由がRailsだから、簡単というのは合ってはいるんだが、
Perl使いも結局、RailsインスパイアなCatalyst使うわけで。

902 :887:2009/11/18(水) 22:04:20
様々な意見、ありがとうございます。とても参考になります。
違和感がある、と言ったのは、特にJavaが信頼性がなくて、
Perlが信頼性があるとの意見です。
Javaは基幹系に使われてるのは見聞きますが、Perlで、というのは聞いたことがないですし。
PerlはMoose使わないとまともにClassっぽいものも書けないし。
枯れを気にするよりも、自分のプログラム技術の方を心配しろとも思ってます。
Perlは単純に今の時代のWeb作成には、多言語に比べ劣っている、
というのが、私のPerlを回避したい理由です。
実は同僚と言っても、かなり年上で反論し難いので自分の意見が言えなかったことも
ありますが、明日、意見交換会を行うので、勇気出したいと思います。
PHPは学びやすい言語で、私もそれなりに好きなんですけども、
ところどころ、致命的に好きになれない部分もあるので、
Ruby、Javaを押したいと思っています。
Pythonも個人的には気になりますが、名前が(うちでは)あまりにも知られていないので・・・。
Rubyをなぜかすごい嫌ってるんですよね・・・。なんでだろ・・・。

903 :デフォルトの名無しさん:2009/11/18(水) 22:13:21
>>902
いや、まあ、ここだけでもつっこんでみるけど

> Rubyをなぜかすごい嫌ってるんですよね・・・。なんでだろ・・・。

自分のレスを3回くらい読み直して、嫌らしいところが全くないって断言できるんなら、あんたには
それは一生わからんだろうと。
Perl使いでRubyを嫌ってる人間のほとんどは、言語そのものを嫌ってるわけじゃなかろうと思う。

> PerlはMoose使わないとまともにClassっぽいものも書けないし。
「まともにClassっぽいものを書けな」きゃそれでだめってのも能力の幅的にどうかという見方も
あるっちゃあるだろうしなあ、とも思った。

904 :デフォルトの名無しさん:2009/11/18(水) 22:13:25
LLには信仰心の問題もあるからな

でもJavaをweb用途に使うことの善し悪しは別として、
信頼性がないとかいいきっちゃう人の言うことには耳を貸したくないね。
金が掛かるとかならまあわからんでもないけどw

905 :デフォルトの名無しさん:2009/11/18(水) 22:15:03
rubyは僕みたいな糞でも使える神言語

906 :デフォルトの名無しさん:2009/11/18(水) 22:19:44
俺も糞だけどPythonのほうが使いやすかったな

907 :デフォルトの名無しさん:2009/11/18(水) 22:28:38
>>898
それがどうかしましたか?

>>902
あなたの意見を総合的にまとめると
Ruby より Python を使った方が良いと思う


908 :887:2009/11/18(水) 22:40:38
同僚がRubyをすごい嫌ってることと、自分が嫌らしい人間だということの
関連性が解りませんが、Perlは自分もリアルタイムで使ってますので、
嫌いではありません。
それでも、Catalystを使うのと、Railsを使うのではRailsを使う方が、
コードの書きやすや、見やすさから良いと思いました。
Classっぽいものを書けない、というのは一例です。
ここがダメ、あそこがダメ、と書いても冗長かと思いましたので。
当然、Ruby含め、他の言語も一長一短で、Perlの事だけ悪く言ったと思われたなら、
申し訳ないです、すみません。

909 :デフォルトの名無しさん:2009/11/18(水) 22:46:42
>>908
いやらしいとかはどうでもいいけど、Rubyを推すとして1.8なの?1.9?
ぶっちゃけその辺には興味がある

910 :887:2009/11/18(水) 22:47:36
>>909
1.8.7のつもりです。

911 :デフォルトの名無しさん:2009/11/18(水) 22:48:19
Railsだもんね
その辺が微妙なんだわな。スレタイ的に喧嘩腰に行くとw

912 :デフォルトの名無しさん:2009/11/18(水) 22:51:13
>>908
その上司は Ruby を嫌ってるんじゃなくて
お前を嫌ってるんじゃないのか? w

913 :887:2009/11/18(水) 22:54:22
>>912
それはあ・・・、いや、実はもう一人Java派の同僚と
その人が揉めてまして・・・。
その時自分は日和って、「自分は何でもいいです」というコウモリ君になりました。


914 :デフォルトの名無しさん:2009/11/18(水) 23:01:28
Java厨はすっこんでろ。スレ違い

915 :デフォルトの名無しさん:2009/11/18(水) 23:10:00
質問を勝手に自分の理解できる範囲の問題に解釈し直すのはいくない

916 :デフォルトの名無しさん:2009/11/18(水) 23:13:35
>>913

同僚A=Perl派-(もめてる)-Java派=同僚B

質問者=観戦者=Ruby派

ってところか
参戦するつもりが無いならRubyはあきらめろw

917 :デフォルトの名無しさん:2009/11/18(水) 23:16:40
もうJavaでいいな。Perlの人はその会社では辛そうか
会社ってのは人が作るもんで、むしろJavaとPerlのエキスパートという
ニッチで頑張ってもらいたいもんだができるかな

918 :デフォルトの名無しさん:2009/11/18(水) 23:18:02
所詮、雇い主との相性

919 :デフォルトの名無しさん:2009/11/18(水) 23:28:33
JRubyで丸く収まるんじゃね?


920 :デフォルトの名無しさん:2009/11/18(水) 23:34:42
なんという落としどころw
Perl野郎全敗なだけじゃないか。納得しそうで怖いわw

921 :デフォルトの名無しさん:2009/11/19(木) 01:07:17
PHPは豚肉や牛肉まで入ったちゃんこ鍋という感じw

922 :デフォルトの名無しさん:2009/11/19(木) 01:08:10
スリッパも入ってる病み鍋だろ

923 :デフォルトの名無しさん:2009/11/19(木) 01:21:45
闇鍋にスリッパというのは、年齢を感じてしまう

924 :デフォルトの名無しさん:2009/11/19(木) 23:00:38
>>919
天才あらわる

925 :デフォルトの名無しさん:2009/11/20(金) 08:21:54
結論:perl5でpythonばりに綺麗に書けばいいんじゃないかな。

926 :デフォルトの名無しさん:2009/11/20(金) 08:30:32
$hoge->{moge}

この時点で拒否反応が出る人がいるからむりっぽ

927 :デフォルトの名無しさん:2009/11/20(金) 08:56:30
hoge.moge
のタイプ量の3倍はあるからな

928 :デフォルトの名無しさん:2009/11/20(金) 09:19:01
Shiftキー入れても2倍にしかならなくね?

929 :デフォルトの名無しさん:2009/11/20(金) 09:24:38
そうやって打ってそれを変換するスクリプトをperlで作れば良いじゃない

930 :デフォルトの名無しさん:2009/11/20(金) 10:34:48
質問どうぞ



931 :デフォルトの名無しさん:2009/11/20(金) 12:28:24
>>926
これってなんていう言語?見たことない。PHP?

Perl、PHP、Python、Rubyとメジャーなのは一通り触ってきたはずなんだけど・・・。

932 :デフォルトの名無しさん:2009/11/20(金) 12:32:06
( ´д)ヒソ(´д`)ヒソ(д` )

933 :デフォルトの名無しさん:2009/11/20(金) 12:34:08
( ´д)ヒソ(´д`)ヒソ(д` )( ´д)ヒソ(´д`)ヒソ(д` )

934 :デフォルトの名無しさん:2009/11/20(金) 12:52:37
Perl

935 :デフォルトの名無しさん:2009/11/20(金) 13:40:14
$hoge = { moge => 1 };
print $hoge->{moge};

936 :デフォルトの名無しさん:2009/11/20(金) 14:24:34
Love Wicket 2008/10/21 11:40 Railsのブームが終わってしまったので、必死こいてユーザーを引きとめようとしているように思えますね。

Railsがすごいという事で使ってみたが、生産性が良いなんて全く感じなかったです。
scaffoldで簡単な雛形を作る所まではいいが、それ以降は生産性があるとは思えないですね。周りからもよく聞きますし。

まともなIDEもないからひたすらしこしこコーディングをしないといけないし...
結局、新しい物好きのお宅が、自身が先端を行っているという事を主張するための道具になっているのと、Railsで儲けようと企てた連中に乗せられていたんだと思う。

やはりPythonとPHPとJavaでしょう。

937 :デフォルトの名無しさん:2009/11/20(金) 15:03:26
ブームに乗って押し掛けてきた連中に迷惑してたってのを知らんのかね。


938 :デフォルトの名無しさん:2009/11/20(金) 15:43:11
>>936
このコメントより元の文章の方がはるかに読む価値があると思います。

Ruby on Railsの作者より:高まった生産性を仕事を余計にこなすためではなく自分の将来に向けて使おう
http://d.hatena.ne.jp/himazublog/20080927/1222445526

ところでコメントの結論が唐突ですね。
「Love Wicket」と「まともなIDE」からJavaという結論は分かるのですが、
PythonとPHPにはどこから出てきたのでしょうか?

939 :デフォルトの名無しさん:2009/11/20(金) 17:33:11
「私はわかりやすいRubyアンチです」という自己紹介だろw

940 :デフォルトの名無しさん:2009/11/20(金) 17:50:50
phpだって変数に変なの付くんでしょ?

941 :デフォルトの名無しさん:2009/11/20(金) 18:10:37
rubyもへんなのあるよ
@とか$とか#とか

942 :デフォルトの名無しさん:2009/11/20(金) 18:12:34
:が付くリテラルとかあるよね

943 :デフォルトの名無しさん:2009/11/21(土) 21:23:35
IDEからはいったプログラマw

944 :デフォルトの名無しさん:2009/11/22(日) 11:03:10
>>943
DOS時代からIDEばかりだよ俺はw
PerlでCGI(笑)やってたときは、エディタしかなくて気が狂いそうだった

945 :デフォルトの名無しさん:2009/11/22(日) 11:04:13
ああ、エディタつっても、Vimとかemacsじゃなかったんだんだよな、当時。今から思うとソーセージ使って置けばよかったわ・・・

946 :デフォルトの名無しさん:2009/11/22(日) 11:22:16
スレタイに入ってるLL系の言語使うときに、
IDE使ってる人ってどれくらいいる?

947 :デフォルトの名無しさん:2009/11/22(日) 11:28:38
PHPはEclipseのプラグインが良くできてる
あとのはテキストエディタでもそんなに変わらんイメージ
まあ書くソース量の問題なんだろうけど

948 :デフォルトの名無しさん:2009/11/22(日) 12:04:51
DOS時代のIDEってTurbo Pascalか?

949 :デフォルトの名無しさん:2009/11/22(日) 12:16:37
>>946
RubyとかRailsでコード書くのに、NetBeans使ってる

950 :デフォルトの名無しさん:2009/11/22(日) 12:17:19
>>948
Quick Basicの後に、Turbo C使ってた

951 :デフォルトの名無しさん:2009/11/23(月) 01:35:16
昔のBASICも、一応IDEしてたよなそういや

952 :デフォルトの名無しさん:2009/11/23(月) 11:17:31
TurboCの統合環境はCOM実行形式がギリギリ書けるぐらいだったな。
メモリが足らなさ過ぎた。つーかmakeが走らなかった気がする。

953 :デフォルトの名無しさん:2009/11/23(月) 12:17:43
それは既にCでは無い気がw

954 :デフォルトの名無しさん:2009/11/23(月) 12:23:48
tinyモデルかな
セグメントモデルが4つもある時点でCじゃないな

955 :デフォルトの名無しさん:2009/11/25(水) 17:32:31
A ドライブに TurboC を入れて
B ドライブに ATOK の辞書ファイルを入れていた。

956 :デフォルトの名無しさん:2009/11/25(水) 18:22:41
ATOK使いにくいからWXIIとか使ってたわ

957 :デフォルトの名無しさん:2009/11/25(水) 19:05:14
>>955
EMSメモリとかにATOKの辞書を乗っけたとき感動した
4MBってすげぇとか

958 :デフォルトの名無しさん:2009/11/25(水) 19:56:47
で、結局結論として、LL最低は何なのよ。

959 :デフォルトの名無しさん:2009/11/25(水) 20:03:56
perl

960 :デフォルトの名無しさん:2009/11/25(水) 23:28:24
低レベルさに定評のあるLua

961 :デフォルトの名無しさん:2009/11/26(木) 08:47:10
http://www.gizmodo.jp/2009/11/post_6416.html

962 :デフォルトの名無しさん:2009/11/26(木) 11:37:40
Google で使われている Python
ハッカー御用達の Perl
現在主流の PHP
となると、消去法で Ruby なのか

963 :デフォルトの名無しさん:2009/11/26(木) 12:15:33
Matzと愉快な仲間たちに仲間入りしたければ。

964 :デフォルトの名無しさん:2009/11/26(木) 12:29:33
Rubyは仕事で名前を聞いたことがない。
誰か大規模案件でもっと喧伝してくれよ。

965 :デフォルトの名無しさん:2009/11/26(木) 12:46:11
最低のLLならば Perl に決定だな。
どうしても設計の古さは否めないし。
Perl6 は、別言語だし。

次に良くないのは、 PHP だね。
とりあえず動く物を作った的な設計の悪い所は、徹底して悪いし、しかもコアの部分だから変え辛いけど、
良い設計を取り入れての進化が結構早くて挽回してきてるように思う。

他はどっこいどっこいだな。
Python は、堅苦しい感じもあるけど、それは、意図してそうしてて、それが良さなんだし。

966 :デフォルトの名無しさん:2009/11/26(木) 12:55:14
Perl6 は、別言語というか、まだ正式伴じゃないか

967 :デフォルトの名無しさん:2009/11/26(木) 13:00:47
何に重点を置くかでどれが最低が変わるね

968 :デフォルトの名無しさん:2009/11/26(木) 13:17:45
Rubyは重いのが最大の欠点か

969 :デフォルトの名無しさん:2009/11/26(木) 13:44:00
重い時点で終了じゃね?

970 :デフォルトの名無しさん:2009/11/26(木) 14:04:52
Rubyはメモリーもよく食うよね

971 :デフォルトの名無しさん:2009/11/26(木) 16:52:04
その辺はほら、プログラミングの楽しさでカバーですよw

972 :デフォルトの名無しさん:2009/11/26(木) 16:52:40
http://www.asahi.com/business/topics/economy/TKY200911220277.html

973 :デフォルトの名無しさん:2009/11/26(木) 18:56:41
サルでもできるシストレ必勝法はこちら
http://www.sikyou.com/main/trade/ecotore.html

974 :デフォルトの名無しさん:2009/11/27(金) 01:45:09
言語を利用する技術者の平均レベルで考えたら、PHPは最低だろうな。主に職業グラマ
PerlもPythonも海外での知名度は高い。と、人が増える分だけ平均レベルも下がる。
世界的に見たときRubyなんてのはマイナー言語だとすると、
それを見つけて使い出した国外の技術者たちのレベルは高くなる。
技術者の平均レベルで考えたらRubyが最高になるか?オタク度ともとれるが

975 :デフォルトの名無しさん:2009/11/27(金) 04:24:36
まあいまや趣味ウェブ製作者にも「タグ」として紹介されてたりするからねえ

976 :デフォルトの名無しさん:2009/11/27(金) 09:17:44
つまり、HTML すらまともにわからない奴等のための言語、ってことか。

977 :デフォルトの名無しさん:2009/11/27(金) 09:42:05
それはそれで大きな武器の一つだな。
その尻拭い的な仕事が回ってくる人には気の毒だが。

978 :デフォルトの名無しさん:2009/11/27(金) 09:50:28
Ruby は、処理が重い位しか欠点が無いか。
処理が重いというのは、言語としての本質とは関係無いな。

979 :デフォルトの名無しさん:2009/11/27(金) 10:01:31
>>978
Pythonと比べると、実績が少ない、ライブラリが少ない、動く環境(OSという意味でなく
GAEやOpenOffice、ゲーム等に組み込まれていてユーザーが利用できるという意味)
が少ない、Linuxでプリインストールされていない、仕様の安定性に疑問をもたれている、
Windowsではどれをインストールしたらいいのか判らない、etc, etc...

言語の本質じゃないとはいえ、環境面ではかなり出遅れてるから、Pythonよりも
生産性が高いと言い張れないようじゃPythonを押しのけての普及は無理なんじゃね?

980 :デフォルトの名無しさん:2009/11/27(金) 10:11:55
Ruby はフレームワークが Rails 一択しかないのも最悪。
好きじゃないから。Merb が Rails に統合されてがっかり。

981 :デフォルトの名無しさん:2009/11/27(金) 10:19:27
よくRubyの参考書籍がPythonより多いっていうのを利点に挙げる人がいるけど
大き目の本屋に行けば確かにある
んでもよく見るとRailsブームに乗ったような糞本が多い

間違えないでほしいのは、全てのRuby本は糞っていってるわけじゃない。
まともな本の冊数は、結局Pythonと変わらないのではないか、という事。

982 :デフォルトの名無しさん:2009/11/27(金) 10:24:16
RubyはBTSみたいな社内で動かすアプリはあるけど、
不特定多数に提供するWikiやblog、ECみたいな
実用アプリがほとんどないこと。
あと、無料サーバで動かすには重くて制限が厳しいこと。
Rubyは「理想的」だが「現実的」ではないと感じる。
Rubyユーザもピュアな学生みたいな夢見る子が多すぎる。

983 :デフォルトの名無しさん:2009/11/27(金) 10:33:28
>>979
確かに環境で比較すると、Ruby が最低なのは、否めないな。

PHP は、 Web アプリ開発の分野ならば、最も良い環境ではないだろうか。

他の分野も含めてという事なら、歴史が長い分、 Perl が有利な筈だ。

しかし、今は、Python が、かなり追い上げている状態なのだろうか。
boost に Python との連携をするためと思われるモジュールがあった。

そう言えば、RPGツクールがRubyを使っているようで、驚いた覚えがある。


984 :デフォルトの名無しさん:2009/11/27(金) 10:39:14
言語が恋愛なら、Rubyはギャルゲーみたいなもんだな。

985 :デフォルトの名無しさん:2009/11/27(金) 10:59:43
Ruby は CGI でもまともに動く、
もしくは Rails がまともに使える無料環境があれば化けると思うけど、
ない限りは、いくら言語が美しくても駄目だと思う。

986 :デフォルトの名無しさん:2009/11/27(金) 11:01:00
>>983
最後の一行で気を抜くな
ちゃんと空白入れろ

987 :デフォルトの名無しさん:2009/11/27(金) 11:02:45
xreaでは動くよ
そもそも、rubyでスクリプト組んでCGIで使おうなんて考える奴は、無料環境で何とかしようなんて思わないのではないか。

988 :デフォルトの名無しさん:2009/11/27(金) 11:02:59
そして次スレという奴を立ててくる

989 :デフォルトの名無しさん:2009/11/27(金) 11:04:32
【Perl,PHP】LLバトルロワイヤル8【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1259287439/

990 :デフォルトの名無しさん:2009/11/27(金) 11:05:03
O2

991 :デフォルトの名無しさん:2009/11/27(金) 12:42:56
バージョン管理にHgってかい。

992 :デフォルトの名無しさん:2009/11/27(金) 12:53:04
>>987
Ruby使うためだけにさくらの月500円レンタルサーバ借りた
Railsは動作上無理だが、サイト(上で利用するデータ生成)のプログラムをRubyメインにできるという点でまあ満足

でもrubyインタプリタの起動を厭ってSSIとシェルスクリプトを併用しまくってるのが我ながらなんとも
いやだってレンタルサーバでHTML返すためだけにruby(しかもrubygemsつき)を起動するなんてなんか間違ってるじゃん?

993 :デフォルトの名無しさん:2009/11/27(金) 13:00:32
Ruby は 5年前も現在も 5年後もプログラマの手元でのみ使い倒されるベター Perl

Web アプリケーションがないと負けだというのなら、生まれた時点でたぶん Ruby は負けてる
sed や awk で作られたプログラムって何があるんですか、みたいなもんだと思う
狙ったのかどうかはわからんが、うまい位置につけたなと

そういう意味で、わざわざ Ruby で Rails やってる人は負け組

994 :デフォルトの名無しさん:2009/11/27(金) 14:51:10
そうそう、使い捨てじゃないプログラムをRubyで書くとかありえん

995 :デフォルトの名無しさん:2009/11/27(金) 18:58:43
http://www.lifehacker.jp/2009/11/091124backup_lh5.html

996 :デフォルトの名無しさん:2009/11/27(金) 19:50:15
http://techon.nikkeibp.co.jp/article/COLUMN/20090928/175713/?P=3

997 :デフォルトの名無しさん:2009/11/27(金) 21:24:19
>sed や awk で作られたプログラムって何があるんですか、みたいなもんだと思う
>狙ったのかどうかはわからんが、うまい位置につけたなと

漏れはそういうケースはRubyよりもPythonを選んでしまうが・・・。

と言うか少しでも他人が読んだり再利用する可能性がある場合はPythonで
自分以外絶対使わないと言うケースがRuby。

998 :デフォルトの名無しさん:2009/11/27(金) 21:35:04
他人が読んだり再利用する可能性があるものにPython選ばないだろ。
(日本での)知名度、利用度的に。

999 :デフォルトの名無しさん:2009/11/27(金) 21:35:16
windows上だとLLよりpowershellのほうが使い勝手良くなってきた

1000 :デフォルトの名無しさん:2009/11/27(金) 21:40:35
チェック

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

200 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)