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

最強のＬＬ＝軽量プログラム言語は、どれよ？

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

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

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

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

■過去スレ
【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バトルロワイヤル２【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1209289408/
【Perl,PHP】ＬＬバトルロワイヤル【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1188997302/

乙＞１
とりあえず　見ちゃったんで

レンタルサーバーを借りたので、
これから、Webアプリを作ってみようと思っているのですが、
今なら、Perl、PHP、Ruby、Pythonのどの言語が良いでしょうか？

上記4つの言語しか使えないサーバーです。

チャットルームにも掲示板にもなるようなのを
作りたいと思っています。

>>3
スレ違い
さらには板違いの可能性もある

>>3
Perl
理由は答えられない。

LLTV Coming Soon!!

共用なら開発は自重した方がいいよ。
そういうのが主目的じゃないんだからレンタルサーバー借りたからWebアプリを
作ろうっていう発想になるのはどうかと思う。

>>4
個別具体的な事例についての優劣は、議論しないという事ですか……。
申し訳ありません。

>>5
4つの言語の中で一番経験がある筈なのが Perl なんですが……。
(ただし、Web アプリではありません)

>>6
もうすぐ LL のイベントですか。
そういえば、毎年夏にあるんでしたっけ。
今年のは、テレビ番組を意識した気軽に楽しめるようなイベントを構想してるとか……。
まだ、一度も行った事がないので、行ってみたいですね。

>>7
当初 Web アプリを自作するつもりがなかったため、
何も考えず共用のを借りました。
総合的に考え直そうと思います。

さっき WebProg という板を見つけたので、
プログラムについてはそちらで相談しようと思います。
サーバーいついては、レンタルサーバーの板のほうで、
相談しようと思います。

板違いで申し訳ありません。

LLTV! LLTV!

今年の公式サイトが作られていますね。

Lightweight Language カンファレンス 2009
http://ll.jus.or.jp/2009/

>>7
別にいいじゃん。Webアプリなんて、日曜大工とか夏休みの工作みたいなもんなんだし。

誰かまとめてくれ
Perl-------
PHP.------
Python----
Ruby------
JavaScript-
VB--------

Perl------- Larry Wall
PHP.------ The PHP Group (, Zend Technologies ?)
Python---- Python Software Foundation
Ruby------ Yukihiro Matsumoto
JavaScript- ???
VB-------- ???

とりあえず。
VBはまあMSだろうけど、JavaScriptは、それぞれの実装について
いろいろあるんだろうか。

Rubyが一番。　時点はPHP

確かにRubyは一番遅い

>>15

Perl------- 5
PHP.------ 2
Python---- 4
Ruby------ 1
JavaScript- 未知数
VB-------- 3

こうでつか？そんな気もする。

PHPは確変したからPythonよか軽いと思う

ここでは、mod_perl とか mod_php の類はどういう扱いになるんですかね。

>>16
キモイ奴が多い数でおけ？

LLって和製英語なの？

http://ja.wikipedia.org/wiki/%E8%BB%BD%E9%87%8F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E

日本以外では言わない。海外ではリソース消費が軽量という意味でC言語などを指すのでむしろ逆。
日本でもごく一部でしか言わないし、「スクリプト言語」がポピュラーな呼称。

Lightweight Languages（複数形）という語は英語圏にも無くはないが
動作の軽い言語のことみたいで「プログラマの負担が軽い」という意味で使われるのは基本的に日本だけ

…もっとも俺もWikipediaかじった程度の知識だから実態は知らんが

「過去ログ嫁」

>>20-22
またこのネタかｗ 何回目だ？

>>20
「サラリーマン」や「ガソリンスタンド」的な意味での和製英語ではない。
なにしろ言い出しっぺはアメリカ人らしいし。（ソースは2chとWikipedia）

ただ、新語ではあるので用語として定着しておらず、また>>1の意味で利用
されている範囲もそれほど広くないんじゃないかな〜という程度のもの。

LL和製ネタ、デジャブ・・・

まぁ、些末な事柄が繰り返し話題になるとか、
常識のはずのことが繰り返し尋ねられるとかは困るけど、
この場合、スレ的に根幹を成す物事で、その割には常識までは行ってない物事だから、
ある程度繰り返されるのも仕方ないかな、とは思う。

この流れは テンプレ化 しとこうぜ

Q. LLって和製英語なの？
A. >>28

和製英語ではありません

こうして歴史捏造が始まった。

じゃ、事実って奴を示せばいいわけだな？
ll-duscuss
ttps://lists.csail.mit.edu/pipermail/ll-discuss/

それとも、このアーカイブが全部捏造なのかなw

>>30
それMITの日本人学生が作ってるのモロバレじゃん。

>>31
Gregory T. Sullivan
ttp://people.csail.mit.edu/gregs/gregs.html

いかつい日本人学生もいたもんだな

>>31
>それMITの日本人学生が作ってるのモロバレじゃん。

ねつ造してんのはおまえじゃんかwwwww

めんどくさいよな。スクリプト言語でいいじゃん

流行語にしてお金稼ぎたいんです！＞＜

>>32
実はひいばあさんの一人が...

スクリプト＝開発補助のイメージを払拭したい人達ががんばってるけど叶わずみたいな状況

LLはスイーツみたいなもんか

趣味でもJavaやC++しか使わないような奴等ばっかなの？
STLやコンテナやら面倒なだけじゃん

別に面倒じゃないけどな
IDEで作って右クリックで実行するだけだから結局同じだし
インタプリタインストールしないとならないLLの方が面倒じゃない？

>>39-40関連じゃないが、
最近、Ruby仕事してるんだが、
昔、DelphiでIDEでサクサク補完しながら作ってたころより生産性があがったように見えん。

どっかのひがやすをblogじゃないが、
> 「コードが多くても、実際の作業としては ctrl+spaceとctrl+1 を押すのが大半だから、生産効率に差はないんですよ。」

とか言われて、Ruby長年使っててRuby脳になってるはずなのに微妙に納得しかかってる。
もっとサクサク補完しながらかけるLLってねーの？

Ruby好きなんだけど、くだらんスペルミスとかで平気でとまる。ガバレッジテスト秋田・・・

LLだけじゃなくて、開発環境とかでもいいっす。
今時、言語の優越に開発環境引いて考える時代でもなかろう。

俺は、前はxyzzyでRuby書いてたけど、最近はNetBeans。でもどっちも補完はダメダメだね…
aptanaは重すぎワロタ
RubyとIDEでの補完の相性の悪さは、しゃーないことはわかっているんだけどさ

JavaからRubyへって本が酷かったな
どんだけJavaの生産性が酷いかしか説明してない本ｗ

ctrl+space とかで補完って、

LLでも普通にctrl+spaceで補完だが…


今更テキストエディタって、20〜30行までの捨てスクリプトでもないかぎり
そんなことしない。


LLでもIDEがないと結局プロジェクトとしてのソース管理が困難になるのだし。

Rubyはダメでしょ。

統合環境使うなら、統合環境での利用に最適なシンタックス
を搭載しているpythonがベストと思うが。

開発環境まで言い出せば、VSでC#。これで決まり。

まあ、WindowsでRuby初心者ってのが最近多いみたいだが
そういう人は素直にC#勉強すればいいと思わないでもない

なんでもやりたいんだったら
LLから入るより普通にJavaでもやった方がいいと思う

素直にとか普通にとか

C#はクライアントのアプリはまだしも

Linux系サーバーになるとどうにもならなくなる。

また、CG開発系スクリプトでも全く威力を発揮しない。

C#はとても良い言語ではあるものの、
あくまでもC++のハイなレベル版に過ぎない。

Javaも意外なほど応用範囲がせまいな。
VMというもの自体が制約になるためだが。

そこで、parrotなのですよ。奥さん

いや、よー知らんけれど

>>50
だから何？

向き不向きならどんなものにもある。

>>52
だから、「何でもやりたい」ならjavaは別段向いてないのではということ。
(というか非常に向いていない）

個人がやるなら、クライアントアプリか、WEBアプリ、
あるいは、Excelやファイル処理などの簡易なマッチング処理・置換の類、
が最もありがちなのではないかと思われるが、
それら全てにjavaは凄まじく向いていない。

個人が1人でやる場合にjavaが向いているのは、iアプリぐらいかw

WebにJavaが向いてないとかすげー理論だな

サーブレットとクライアントとあると思うが。

サーブレットの場合はJavaの利点がよく見えないし、クライアントは
Flashに押され気味だし。

は…はぁ…
そうですね…

次の方どうぞ

＞サーブレットの場合はJavaの利点がよく見えないし

だったらPerlやPHPだと利点ありまくりなのか？


なんでもやりたいとか言うならPythonやC++くらいでたいていの事はできると思う。

とは言え職業プログラマならJavaやC++くらいできんと話にならん気がするが。

>>53
せっかくなので、あなたがオススメする

・クライアントアプリ
・WEBアプリ
・Excelやファイル処理

それぞれのオススメ言語おしえてくださいな

>>58
PHP
クライアント: ×、 Web: ○、Excelやファイル処理: ×

Perl
クライアント: ×、 Web: ○、 Excelやファイル処理: ○

Ruby, Python
クライアント: ○、 Web: ○、 Excelやファイル処理: ○

PerlやPHPでGUIのクライアントアプリ作る人ってあんまりいないね。
Ruby、Python は汎用言語だから全部こなせるけど、GUIのbinding が
より整備されているのは Python だったりする。
他にも OpenOffice.org ではマクロがPythonで書けたりする。

何でRubyとPython一緒にするかな
Pythonはガチだけど、RubyはGUIクライアントだと×か△ぐらいじゃねえか？

いやだから、GUIクライアントを簡単に作りたかったらC#でもJavaでも使えって。
中身のコードに関しても、JavaはともかくC#ならかなりコーディングの負荷は軽いぞ。
Windows限定では困るGUIクライアントを本当に作りたいの？

GUIってだけでスレチな気がすごくする。

GUIが必要になる状況って考えてみると、作ったツールを
プログラムやPCに疎い人間に使わせるときくらいだよなぁ。
自分で使うツールで必要になることって滅多にない。

PHPだとWinBinderとかあるけどな
適当なIDEが無いんでデバッグがしずらくて1週間で投げたけど

DropBoxのクライアントやBitTorrentのクライアントはPythonでできた
GUIプログラムだよ。

GUIプログラムって、よほどそのツールキットに精通していない限り
APIリファレンス見て、「こう設定したら期待する動作になるのかな?」
って試しながらプログラム書くことが多くて、その時は IPython という
強力なインタラクティブシェルを使って試しながらプログラムが書ける
Pythonは強い。

>>64
TortoiseHgもどうやらPythonですな。
UNICODEまわりがまだメタクソだけど、かなりよい感じ

>>65
Unicodeまわりがメタクソなのはhgの仕様だからなぁ。
ファイル名はバイト列ってフザケてるのかと。

bzrはコマンドライン引数でファイル名を渡す部分でWindowsでは
ファイル名をUnicodeにできなかったけど、次のbzr1.16では
コマンドライン引数をGetCommandLineW()を使って処理するように
なるからそれに対応するtortoisebzrもそれを使う方向に進んでる。

素人が前スレとここまで読んで判定すると、Pythonの圧勝です

ちょっと見たけど｛｝がない分いいかも、と思ったが
行末に：付いたり付かなかったり意味不

>>68
行末に : が付くのは、新しいブロックが始まる前(=インデントが増える
直前)で統一されていると思うけど?

なんで文法がVBで、出来ることがC++っつう理想言語が出来ないんだろうね？
if i=0 then j=0 else j=1;
これくらい共通にしろっての
インデントも｛｝も==も:も、なんで無駄なものを付けたがるんだ？

Webは技術よりもコンテンツだからな。んだからWebスクリプトプログラマーなんてアニメーター
同様カス扱い。

英語とドイツ語でこれはペンですくらい共通にしろって言ってるようなもんだぞ

>>70
文法がVBはやだなあ

Sub Hoge
End Sub

For i=0 to 10
Next

If a = 0 Then
b = 1
Else
a = 0
End If

どの辺がどう無駄のない文法なのかkwsk

BASICから覚えてきたはずなんだが、今見ると区切りが無くて見づらいな

C#でいいんじゃない。

一口にBASICっつーても色々方言があるけどな

10 CONSOLE,,,1
20 CLS 3
30 X=INT(RND(1)*7+1)
40 Y=INT(RND(1)*7+1)
50 Z=INT(RND(1)*7+1)
60 LOCATE 10,10:COLOR X:PRINT X
70 LOCATE 15,10:COLOR Y:PRINT Y
80 LOCATE 20,10:COLOR Z:PRINT Z
90 IF INKEY$=" " THEN GOTO 100 ELSE 30
100 IF X=Y AND Y=Z THEN PRINT "OOATARI!!":END
110 IF X=Y OR Y=Z OR Z=X THEN PRINT "ATARI!":END

…いや、ネットに転がってたからｗ 懐かしい。
そのうち、25 とか 105 とか の行番号で処理を差し込んだりするんだよなこれ。

N88あたりか、それ？
懐かしさと同時に、読みにくさも思い出すなｗ

今のBASICの規格だとIF〜END IFやDO〜LOOPはサポートすることになってるし
WHILE〜WENDはその後のほとんどのBASICがサポートするようになったし、VBもEnd Ifを持ってるのもあって
今のBASICならGOTOで書いたりはしないだろうけど

>>69
Pascal(Delphi)の then とか do だと思えば納得ですな。
しかし、Rubyとか慣れてると、なんでいらないところにいるのん？と思わんこともある

>>73
Rubyっぽくしたら落ち着くのでは？

sub hoge
end

i.times(10)

next

if a == 0
　b = 1
else
　a = 0
end

ぼくがJavaのひとに「ガツン」と申し上げられて思ったこと - 梅雨ですな - ずっと君のターン
http://d.hatena.ne.jp/technohippy/20090613#codes


Google App EngineのGreetingモデル定義 の Pythonコード

from google.appengine.ext import db

class Greeting(db.Model):
author = db.UserProperty()
content = db.StringProperty(multiline=True)
date = db.DateTimeProperty(auto_now_add=True)

一方Javaは…

package guestbook;

import java.util.Date;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
import com.google.appengine.api.users.User;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Greeting {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;

　　　　@Persistent
　　　　private User author;

　　　　@Persistent
　　　　private String content;

　　　　@Persistent
　　　　private Date date;

　　　　public Greeting(User author, String content, Date date) {
　　　　　　　　this.author = author;
　　　　　　　　this.content = content;
　　　　　　　　this.date = date;
　　　　}
　　　　public Long getId() {
　　　　　　　　return id;
　　　　}

　　　　public User getAuthor() {
　　　　　　　　return author;
　　　　}

　　　　public String getContent() {
　　　　　　　　return content;
　　　　}

　　　　public Date getDate() {
　　　　　　　　return date;
　　　　}

　　　　public void setAuthor(User author) {
　　　　　　　　this.author = author;
　　　　}

　　　　public void setContent(String content) {
　　　　　　　　this.content = content;
　　　　}

　　　　public void setDate(Date date) {
　　　　　　　　this.date = date;
　　　　}
}

Python圧倒的すぎワロタ

※インデント崩れたスマソ・・・

言語思想が違うから一概にどーこーと言うのはないが、
Pythonは実用主義な言語だからそういうモノだと思うしかないな。

Javaのコードも実際は補完がバリバリ効くから、コードを打つのは苦痛では
ないだろうけど、コードの可読性でPythonに勝てる言語はそうそうないワケで。

>79
あのコロンのお陰で、エディタの補助にありつけたりするから要らないとは言えないなぁ

LLの場合、メソッドの引数の型がわからないから
未知のライブラリはコメント頼りになる。

静的型付けだと、引数の型からなんとなく仕様が想像できる場合がある。

補完が強力なエディタはどれ？やっぱEclipse？

あぁごめ、>>87はPythonでの話

>86
たまに変数名で分かるライブラリもあるけどな

>>84
Javaのコード補完の効き方と、
Pythonのコードの補完の効き方はかなり近いっしょ。

自分で定義したクラスやメソッドなどのコメントまで
補完時に見れるという点まで含めて。

Python は、ブロックが分かりにくいな。
インデントでやっているが、
ブロックの尻を明示する句や記号が無いから、
尻切れトンボみたいで気持ち悪い。

さんざん既出だが、スクリプトの始めの方に
end=1
と書いておいて、あとはブロックの終わりとか
目印代わりに「end」と書けばいい。

俺も気持ち悪いと思ってたが
しばらくLispやってたら帰って来たら慣れてた

# ここからブロック１

# ここまでブロック１

これで解決

>>92, 94
文法じゃないから、抜けててもチェックできないし、
書く人毎に違ってたら嫌じゃん。

>書く人毎に違ってたら嫌じゃん。

コード規約完全否定か

>>96
組織とかグループごとに独自のコード規約があって、
ブロックの書き方がそれぞれ毎に違ってたら意味無いじゃん。

Pythonの規約って標準化されたものないのか？
Javaは殆ど規約一本化されてるし
PHPもフレームワーク毎に規約あるぞ
仮になくてもせめて社内で統一くらいしろよ

PEP 8

Pythonはインデントを強制するのが規約

インデント強制は規約と言うより言語仕様。
公式規約はPEP8がある。
乱立はしていない。

Javaとかになれてる人には色々最初は気持ち悪いかもしれないけど、
使っているうちにそれがすごく合理的だと理解して慣れていくよ。

他人のコードを読むのが一番ラクな言語はPythonだと思うが。

Pythonはエスペラント語のようなもんで
いくら読みやすくてもみんな知らないから読めない

これほど共感できない例えも珍しい

Pythonは実行できる擬似コードと言われるくらいで、
Pythonを知らない人にも読みやすいコードが多いよ。

Pythonが読みやすいってのは
RubyがJavaより生産効率いいってくらい基準があいまいな話だと思う

とりあえず漏れの場合はRubyやJavaと比較するならば、Pythonの方が読みやすい。

つか個人的にRubyはJavaを意識する前にPythonよりも生産性を上げてから言うべきだろうに。

Pythonはまだ仕様が固まってないから、6.0くらいまでは様子見すべき。

PerlやRubyは、同じ処理をするのにいろんな書き方があるけど、
Pythonはそれを極力避けているから、多少冗長になっても
誰が見てもわかりやすいコードになるのがウリじゃなかったっけ？

紛らわしければpassを使えばよいのに(python-mode派)。

pythonって、どうやってコピペすんの？インデント崩れるんだけど

>>111
replace(" ", " ")

あわわ
replace(" ", "&nbsp")

＞Pythonはまだ仕様が固まってないから、6.0くらいまでは様子見すべき

それを言い出したらRubyなんて100.0くらいまで使えない希ガス。

>>99 >>101

PEP 8 ってこれで全部？
http://oldriver.org/python/pep-0008j.html

ざっと見たところ、ブロックの終わりを示す語句(記号)についての記述がないようだけど……

>>115
つまり、 end = 1 とかは使わないで普通にインデント解除するのが
標準コーディング規約

>>41
コード書くときの自動補完は、言語が静的型付かどうかに大きく使い勝手が
左右される。RubyやPythonみたいな動的言語だと、変数名が任意の
オブジェクトへのラベルに過ぎないので、適切なメンバを
候補として提示することが本質的に不可能。

WindowsでもLinuxでも、クライアントもサーバもってことなら、
Mono 2.4 + MonoDevelop 2の出来がびっくりするくらいいいので、
(多言語・多プラットフォーム・REPL等。 ただし、GTK#で日本語は地雷)
1回さわってみるのをおすすめ。
商用サーバでもLinux + Mono + ASP.NETって増えてきてるしね。

インデントを戻すタイミングについて、エディタに知らせる方法が問題なのかな？
pass でいいんじゃなかった？

>>106
読みやすさに明確な基準は持たせにくいからね。
でも、複数の言語を知っている人はやっぱりPythonは読みやすいと感じるよ。
dankogai も、
--
私ははっきり言って Python の哲学は好きになれない。でも Python のコードは好き。
「動く pseudocode 」としてのチャンピオンは、今や Python だ。Python はもっと知られ、
もっと使われて良い。 Pythonistas のみならず、 Perl Mongers のためにも、 Rubyists
のためにも。
--
とか言ってる。

pythonのコードが読みやすいことは認めるが
dankogaiを引き合いに出すのはやめてくれ
まるで「東スポにそう書いてあった」といわんばかりだ

この件は、誰を引き合いに出しても信頼性は変わらない

まぁそういうことだね。
「それ」にある程度重きを置く場合、Rubyは使えない。到底。

フランス人がフランス語は美しいって言ってるレベルの話だろこれ
フランス語がわかる奴じゃないと意味解らんから無駄って話

そういう話だということにすると救われるんですね。

この手の話は20年前からまったく進歩がない

インデントの規則が決まってるからPythonは見やすいってのなら
コード規約に従って書いた他の言語だって同じように見やすいんじゃないかと思うが

>>126
インデントだけじゃないよ。
予約語が少ない、特殊変数が無い、ビルトイン関数・変数が少ない、
式を複雑に組み合わせないで文に分けている、etcetc...

で、結局、 Python は、ブロックの終りを示す語句・記号が無くて、
気持ち悪いことに変わりないと。

文法にないどころか、標準のコーディング規約にすら無いから、
end = 1 とか、コメントとか、結局、独自の工夫をするしかなから、
統一的にはできないと。

標準に従うなら、むしろ、ブロックを閉じちゃいけないから、
ブロックを閉じないと気持ち悪く感じる人は、
選択肢に入れられないと。

↑
ヴァカ？

ブロックはちゃんとアンインデントで閉じるだろ、閉じる記号が文字としては無いってだけで

Python は,ブロックを閉じる記号がないから
気持ち悪いことには変わりない。

所詮慣れの問題なのにこんだけ熱く語れるってのはなんだかなあ
おれがPythonで気持ち悪いのは、インデントよりもむしろ文字列リテラルの方だったりする。

u'ユニコード文字列'

とか

"""コメント
コメント
コメント"""

ってなんだよ

だって、気持ち悪いんだもん。
しょうがないじゃん。

"""
文字列
"""
はRubyにもあったような…
まぁ、確かに範囲コメントはちょっと欲しいかも

ユニコード辺りはああいうモンと諦めている。

"""のｌ機能は便利だと思うけど。
ドキュメンテーション文字列もほどよいいい加減さがあって好きだが。

Pythonのu'文字列'は歴史がそうさせるので仕方ないだろう。
r'文字列'は随分とコードが読みやすくなるのでいいと思う。

気持ち悪い気持ち悪い言ってる人はこちらのスレで存分にどうぞ。

Pythonに見られるインデントによる制御構造の是非
http://pc12.2ch.net/test/read.cgi/tech/1169473442/l50

てか、数学の記法とか、普通の箇条書きとか、インデントを戻すことで
リストの終了を示してるけど、そういうものが全て気持ち悪いんだろうか？

箇条書きの場合は、ネストを深くする毎に頭の記号を変えるとか、
番号の後ろに番号を加えるとかするから、違うん感じがする？
数学のは、どういう事か分からないけど、
関数型言語(ML系、Haskell)とか、Prolog のは、気持ち悪いな。

LISP は、括弧だから（・∀・）イイ！

>>138 書き間違ったので修正します。

箇条書きの場合は、ネストを深くする毎に頭の記号を変えるとか、
番号の後ろに番号を加えるとかするから、違う感じがする。
数学のは、どういう事か分からないけど、
関数型言語(ML系、Haskell)とか、Prolog のは、気持ち悪いな。

LISP は、括弧だから（・∀・）イイ！
ブロックの閉じる記号がないから気持ち悪いという文脈で
LISP が出てくるのが、理解できなかった。
LISP は、全部きっちり括弧で括るから、 Python とは全然違うのに。

end があっても、 Pascal は気持ち悪くて、 Ruby はいいんで、
ブロックだけの問題じゃない気がしてきた。

歴史だから仕方ないっていいわけになってないけど

>139
しかし閉じ記号をブロックの中身に書いちゃうのは、それはそれで…

Cかschemeが最強だと信じている。LLは複雑怪奇すぎ

一時期Scheme勉強して、Pythonに戻ったら
map の前と後ろのどっちに ( つけるか毎回迷って困ったｗ

そういえばSchemeのmapとかCommon Lispのmapcarって、
何で関数引数が前なんだろう？
Rubyのブロック構文に慣れた身としては、
でかいlambdaを渡す時には非常に読みづらくなる気がするんだが・・・・・

>>145
map は引数として任意の数のリストを取れるので、
必須の引数である関数は必然的に一番最初になります。
あとまあ、その結果として apply と相性がいいとか部分適用しやすいとか。

でかい lamabda を直接書くと読みづらいのは確かだけど、
逆に読みづらくなるほどでかいなら適当にくくりだすかなあ。
さもなければ dolist 使うか。

あーなるほど感謝。やっぱりそれなりの理由と作法があるのか

Rubyのあの構文は、引数として渡す関数はたかだか1個、という前提に
最適化したものだからね。

まあ、Pythonしか使わない人（もしくはRubyしか使わない人）にはそれが見やすいのかも知れないけど、仕事上いろんな言語を使う必要がある場合、PythonやRubyは特殊で非常に見づらい。

色んなって…色んな、がどんな言語かによるだろうに

map(lambda x,y:x+y,[1,2,3],[4,5,6])
PyhtonのmapはRubyとは違ってLispのと同じような感じだが

C/C++ Java C# Perl PHP JavaScriptなどメジャーな言語。

要はC系言語のことを指してるワケね。
個人的にはC系の記法は数ある言語の中でも読みにくい部類に入ると思ってるんだが…

日本語は漢字があって読みにくい
英語は簡便でよみやすい
って言うようなもんだ
日本人に取っては難しい日本語の方が読みやすい
C系PGはC系言語が読みやすい

Basicだけは何をどうやっても読みにくい

Perl挙げてるあたり、自分の慣れてない言語が読めないってゴネてるだけだろ

読めないって話しじゃなくて
Pythonは特に読みやすい言語ではないって話な

メジャーな言語が読みやすくて、PythonとRubyはそれらと比較して非常に読みづらいとか
んなこと唐突に根拠もなく言われても

だから、Pythonだけ使ってる人にはいいんだろうけど、世の中やC+Java+Per+PHPを使ってる割合の方が遙かに多いわけ。
ハングルは世界一読みやすいって言われても、世界中の人はハングルなんて読めないの。

PythonやRubyしか使わないって人のほうが珍しいだろうし、
読みやすいってのはいろんな言語を使ってきた人たちが
比較して言ってるんでしょ？

メジャーな言語は読みやすい
メジャーでない言語は非常に読みづらい
なぜならユーザが少ないから

みたいな論理展開する人がプログラム書いてるのか・・・

読み辛いというか仕様やその言語特有の作法がよく分からない。探すのも面倒。
重箱の隅をつつくルールを覚える暇で、主要言語でやりたいことを模索する方が良さそう

ちょっと粘着気味でしんどいな
もうちょっと楽しい切り口でよろしく

既出すぎる話題ばかりだしな

Pythonは他のメジャーな言語に比べて、より少ないルールで高い生産性を
実現できている言語だけどな。

しかし根底にある概念が理解しにくい
手続き型って、かなりな部分の人間の思考過程に、
素直に馴染みやすい形態なのかもよ。その方向で
発展出来ないのかな
そう言う意味でもRubyはいいとこどりなんじゃね？

「可読性」なるものの定量的な比較基準が欲しい所だが、
果たして存在するのかすら分からん
記号含有率・・・・はある面で悪くないが、じゃあCOBOLは読みやすいのかって話になる

どのみち高級言語なんだしな
末尾再帰とかできて喜んでる人間ってなんなんだろう
それって、正直読みやすいのかな

>>166
Python は高級な手続き指向言語じゃん。
Ruby に比べたら圧倒的に記号や特殊ルールが少ない分、
Pythonを知らない人でも推測しながら読むことが可能。

Rubyがいいとこどりなんて言う人はもっといろんな言語を勉強するべき
全然いいとこどりでないぞ、むしろいろんな面で中途半端

そんな抽象的なレスじゃ何も言えんよ・・・・・・
なるほど中途半端だ

何も言えないなら「何も言えない」で終わっておかないとね。
後ろに捨て台詞付け足したら、それはもうしっかり言っちゃってることになる。

Pythonはエスペラント語
志は高いがシェアは低い

シェアが低いってww
日本で流行ってないだけだろ。
世界中では至る所で使われてるぞ。

と日記には書いておこう。

>>173
Ruby使っている人が自殺しそうな発言だな。

あれこそユーザー数は少ないしシェアはPythonと比べるのが可哀想なノリだが。

つかPython粘着ウゼェ。
アンチ専用スレあるんだからそっちで餌まいとけよ。

日本っつーか、日本のWindowsでは、ってところじゃないかな。
MacやLinuxの大手ディストリなんかではPythonが最初から入ってたりして
「あんまり知らなくても、いつの間にか身近なところで使われてる」言語になってるんだよね。

とりあえず日本のWindows環境でもRubyとPython比較するならば、
Pythonの方が恵まれた環境にあると感じるが。

Rubyのあのやる気の無さはなぁ。

とりあえずPythonがシェア低いなんて、モノを知らないにも限度がある発言だろうに。

>>177
使われてないなんて誰も言ってない
シェアが低いだけ

>>179
自分のまわりが世界なんですね、わかります。

シェアという単語の定義から始めないといけないのか

とりあえずpythonは3が普及したらがんばる。

自分のまわりが世界な人はLinux環境でならRubyはいい言語だと思うよ。
どうせ仕事じゃないんだろうし。

しかし、C/C++って読みやすいか？
つか、***pとか(p++)やらint (*p)()とか組み合わさったら、キツいノリがある言語だと感じるが。
パーな#defineされていると殺意を覚えるし。

Pythonの関数ポインタもかなりアレなノリがあるので微妙だが。

>>183
そんな程度で殺意わくようでは、
perlとかまともに読めない、書けない人かね？

perlは別に最初から読みやすい言語でもないだろ。
個人が使い捨て殴り書きするには最適な言語だから、そこにケチつけるのはおかしいし。

C/C++は運が悪いと延々とメンテされる可能性が高いからアレなんだろ。

誰もPerlが読みやすい言語だなんて言ってないだろうに
Pythonは特に読みやすい言語じゃないというのが肝であって
他の言語で特別読みやすい言語があるって話じゃない

＞Pythonは特に読みやすい言語じゃないというのが肝であって

さすがに、Pythonは特に読みやすい言語だし、コレが読みにくいと言うのは
プログラムをヤめた方がいい。

>>183
その辺をある程度改良しようとしたらDになるんだろう
型変換はcast式、プリプロセッサは排除

実際仕事でやってると言語なんて「これメンテして」で選択肢ないからなあ。
いっそそんな言語知らないとでもシラをきり通せた方がいいな。

C言語は、読みやすさを犠牲にして、書く量を減らした設計だろうから仕方ない気がする。
ただ、C言語が普及したせいで、C言語っぽい文法を採用する言語が多くなったから、
C言語っぽい文法の方が読みやすいと思われる事が多いかも知れない。

BASIC が読みにくいと言うのは、理解が出来ないな。
それで、 Python のソースは読めるのか？

Ruby は、「Perl の次」以上でも以下でもないと思う。

Ruby と Python では、明らかに Python の方がメジャーだな。
OS のインストーラのアナコンダ（だったっけ）が Python で書かれてるとか。
Python は、Google がよく使ってるんだっけ。
Perl は Yahoo がよく使ってるんだっけ。他にも、 はてな とか mixi とかいろんな所が Perl を使っていると聞く。
PHP は、ネット上の至る所で .php を見かける。
しかし、 Ruby を良く使っている所ってあまり聞かないな。
Twitter が使ってて話題になってたけど Scala に変えたんだっけ。

自分は、Python よりは Perl, PHP, Ruby が好きだな。

Python のは、読む気がしない。
Python のを読むくらいなら LISP の括弧を追っている方が、
いや、アセンブリ言語でレジスタの使われ方を追っている方が
よっぽどましだ。

>>190
馬鹿じゃねーの？
氏ねよ！！！！
長文ウザイ

2chで長文ウザイ言う人って、単に頭が悪い人なんだよね。
100個の1行レスは読むけど、1個の10行レスは嫌いな人種。要は根拠や例示を読めない人。
>>190なんて、>>191を書いて送信ボタン押してスレをリロードするより早く読めるのにね。

190,192はいつもの粘着だと思うが。

BASICっつーても方言によるが…
とりあえず規格は文法そのものは読みやすいが
命令によって微妙に書き方が違うのと
大きなコード書くと引数が多くなりがちなせいで慣れるほど限界を感じると思う
設計からしてプログラミング初心者向けだから仕方ないけど

>>187
いやだからね
いくら読みやすくても、その文法が特殊だとみんな馴染めないわけよ
だからC言語派生やBASIC派生の方が流行るわけでさ
英語は読みづらいから、もっと簡単な言語つくったので
みんな読めるはず、って言われても無理なのと同じ

後発のプログラミング言語はいろんなところから構文や機能をぱくってるから
自然言語で例えるのは微妙
日本語分かっててもハングル全く分からんけど
java分かってればpython5割ぐらいはだいたいこんな感じだろってわかるべ

ちがうパラダイムの言語じゃなければ
プログラミング言語でもっと簡単な言語を作った、みんな読めるはず
たぶん本当にみんな読めるんじゃないか？

今は読める読めないでなく読みやすい読みにくいの話じゃないのか？

みんなって誰だ。
コッチ・ミンナさん(AA略)か？

>>195
>いやだからね
>いくら読みやすくても、その文法が特殊だとみんな馴染めないわけよ

HaskellやML系の文法ならまだしも、Python の文法になじめないとしたら、
さすがにそれは文法が特殊だからではなくておまえの頭が悪いだけ。
いくらなんでも、Pythonの文法が理解できないというのはおかしい。

これがpy脳か…

>>187
書き手しだい。
Pythonに限らずインデントが深くて波打ってるようなコードとかあるだろ？
そういうのは例えPythonでも読み辛いもんだよ。

>>201
今はそういう話じゃない。
195が、いくら読みやすくてもPythonの文法は特殊だから読みにくいという主張に対しての反論。
書き手次第とかは今は関係ない。

特殊って言い方は変だと思うな。
プログラミング言語全体で「特殊」なんてのはあんまり無いと思う。
単に書き方の派閥があるだけで、その中に特殊なんてのは存在しないんじゃないかな。

つーかLLスレ的にはC風の書き方のほうがむしろ異端じゃなかろうか。

主観の問題なので、実際にリサーチしてみないと判断は無理。
自分を中心にして、相対的に語ったところで意味はないだろう。

C風の書式のLL：
・Perl
・PHP
・Ruby
・JavaScript
・(Python)

C風でない書式のLL：
・(Python)

>>202
読みにくいじゃなくて、他の言語に比べて特別読みやすいわけじゃない、だろ。
読みやすいか読みにくいかは、その言語に精通しているかどうかが大きな肝で、
Pythonが特別読みやすい言語仕様になっているから読みやすいわけじゃない。
インデントが綺麗かどうか程度の差でしかないから、
コーティング規約に従って書かれたJavaやPHPと、
可読性は殆ど変わらん。

RubyのどこがC風なんだ

class SuperClass
end
class MyClass < SuperClass
    attr_reader :x
    def initialize(x)
        @x = x
    end
end
def func1
    MyClass.new 'Hello'
end
func1
puts func1

>>206
>読みにくいじゃなくて、他の言語に比べて特別読みやすいわけじゃない、だろ。
まず>>195を読もうぜ。
おまえの意見なんか問題にしてない。

>>207
キーワードがちょっと違うだけじゃん

じゃあpythonも十分C風ってことで

>>207
キーワードはAlgol風味だが、
メソッドとかの命名はC系の影響を受けてると思う
to_sとか、アンダーバー記法でギリギリ意味が取れる程度に短くする

pythonは制御構造を作るのに end も { } も; も必要ない。
余計なものが少なくてシンプルに見えるんだがなー。

だから見分けづらいんでしょ

慣れかもしれんがdelphi触ってたときは
begin endの嵐でうへぇって感じだった
俺的にはシンプルのがいいわ
見分けづらいとも感じない

俺はCやPerlの記号ごちゃごちゃ出す感じが嫌いなんだよなぁ
Rubyも書き方次第で記号ごちゃごちゃになるけど

PerlはOne-linerが流行るような、出来るだけ縮めてしまえっていう文化だよね。
Rubyもその流れを汲んでいる。

漏れの周りのPython知らなかった人もPythonの制御構造の仕組みは
解りやすいとコメントしていたな。

見分けづらい、と言う人は極少数だと思われ。

会社とかのコーディング規約で「ifやforのブロックはインデントして見やすく」とか
している組織だとPythonのコードは読みやすく感じるだろうな。

それにPythonだとswitchやcase文がないところからしても、「覚えやすく、見やすく、シンプルに」って
哲学みたいなのがあるんだろ。

pythonの制御構造に関していえば、別段、特殊でもないし、
括弧が、インデントが、begin-endがなんて、本質的な分かりにくさじゃないだろ
〜です、〜ゴザル、〜ニャとか、そのぐらいどうでもいい違いだよ
メモリ上でオブジェクトがどうなっているかとか、どうやってソートするのかとか、
スコープや数値、配列、文字列の扱いやライブラリの利用なんかの方が遥かに謎

>>218
ifやforでインデントしない奴のソースなんか100人中98人までは読みたくねーよ
規約の遙か以前の問題で、またPythonのインデント強制とも次元が違いすぎる

switch〜caseなんかもifの構文糖衣だし、なんか的はずれすぎてﾜﾛﾀ

＞switch〜caseなんかもifの構文糖衣だし、なんか的はずれすぎてﾜﾛﾀ

ぶっちゃけ違う。

同じと思っているならソレは>>220のレベルが極限まで低い証拠。
そういう低レベルがPythonをどーこー言うのは的外れ。

>>221
どう違うのを書かないと、>>221のレベル（笑）もわからんな
例えば、ifで代替できないシンプルなswitch文をあげてみるとか、
コンパイラ方面での話をしてみるとか

ifでswitchの振り分け真似ると、orだらけになったりするコトも

後で指導するが、明らかにアレは見づらい

ifとswitchは似ている様で違うだろ。

Pythonはswitchなくてもほとんど困らないが、その理由が解らない>>220は
ちょっと頭が可哀想な人なんだと思う。

>>220が攻撃される理由が分からん。

pythonのは、OOだ！OOを使え！ルーク！って教えでしょ。
Perlは、ライブラリだ！ライブラリを使え！ルーク！って教えだし。

しかし、switchはifのシンタックスシュガーじゃないのか？
ifで代替できない場面が分からない。
見易さだけなら、ただのシンタックスシュガーだし。

Python教こえーな
異教徒排除が徹底しすぎ
敵がJavaだけのRuby信者より質悪いわ

ということにしたいのですね？

一応考えてみたが、switchには、if〜else単独にはないラベルへのgotoも複合されている
C#みたいなものもある、とかいう点なのかな？
この場合は、switchってif〜else+gotoの糖衣構文じゃん、とか言ってみたらどんな反応が
来るんだろう。やっぱり同じ反応な気もするが。

あとはコンパイラの最適化でなにかあるのかな〜くらいしか思いつかないが、「違う」理由を、
純粋に勉強のためにせっかくだから誰か教えてくれないもんだろうか。気になる。

正露丸糖衣A

xがOまたはPまたはQのときは処理aと処理b
xがRまたはSのときは処理bのみ
それ以外のときは処理cを行なうってコードとか？

C言語だと switch と if が違うというのはわかるが、LL だとどうなんだろ？
C言語は、コンパイラやコードによっては、テーブルを引いてジャンプするコードに変換される場合があるらしいが。

>>230
switch( str )
{

Enter押してしまった・・・ orz

>>230
switch( str )
{
　case 'O':
　case 'P':
　case 'Q':
　　function_a();

　case 'R':
　case 'S':
　　function_b();
　　break;
}

こういうのはifよりswitchのほうが楽だね

if s in 'OPQ': function_a()
elif s in 'RS': function_b()

あ、function_aの後は下へ流れるのか

Python には暗黙のルール、見た目から意味が推測できない記号が
少ないから、メタクラスとか駆使した一部分のコードをのぞき、Pythonに
それほど精通しなくても大体のコードは読める。

その反対は(非モダンな)Perlで、初心者どころか中級者になっても
他人のコードが読めなかったり、下手すると昔の自分の書いたコードが
読めないなんてことが起こる。

>それ以外のときは処理cを行なうってコードとか？
・・・ (´･ω･`)

switch( str )
{
　case 'O':
　case 'P':
　case 'Q':
　　function_a();

　case 'R':
　case 'S':
　　function_b();
　　break;

　default:
　　function_c();
　　break;
}

もうねまふ。。。

>>233
if str in "OPQ":
    func_a()
if str in "OPQRS":
    func_b()

>>237
if str in 'OPQ':
      func_a()
if str in 'OPQRS':
      func_b()
else:
      func_c()

str の内容が 'RS' とかだったらどうするんだろ？

リスト使えばええがな

Pythonのinって何が起きてるんだ？
何となく分かるようで分からん。文字単位でのマッチング？

文字列は文字のリスト

http://www.python.jp/doc/release/ref/comparisons.html

俺的には K&Rが読みやすいから、GNUだなんだの見るよりは
インデントが統一されてるなら、読みやすくはあるんだろうなー
とは思う。　最終的には慣れだろうけど…

今は括弧がないとなんか読みにくい感じ。
do endもなんかなれないんだよなー

なんか場末のスナック的なスレだな

スナックに行った事が無いからワカンネ。

GNUスタイルとかは先頭ブレースの一行分長くなる点が好きでない
行数は可読性に直結すると思う
（だからといって、無理やり圧縮するのが良いとも思わないが）

その点、インデントベースは末尾のブレースやendも削れるのが素晴らしい
でも何となく好きになれないというワガママｗ どうも宙ぶらりん感がある

あとはS式みたいに、末尾に畳んじゃう記法だが・・・・編集がしずらいような
エディタの支援があればイケるか？

○　しづらい

S式は対括弧表示できるエディタ無いと苦しいね
まあ、Windows標準のメモ帳で開発しる！
なんてことが無い限り大丈夫だとは思うが

S式は文字数でインデントするからプロポーショナルだと崩れて読みづらい。
アメリカだとプロポーショナルでコーディングしてる人も結構いる印章だけど、彼らはどうしてるの？

>>240
具体的に >>233 で str の内容がRSの例を出してくれ。
とりあえず、
s = str[0]
if s in "OPQ":
  func_a()
if s in "OPQRS":
  func_b()

Python は他にも、 10 <= a && a < 20 を 10 <= a < 20 と書けたりするし、
if, elif の後に書ける条件式が強力だから switch 文が要らない。

えーと…OPQRSが文字として扱われるとは思なかった（・ω・）
それぞれ何らかの値と結び付けられてる定数のつもりだったんだけど…

>>253
if s in (O,P,Q):
  func_a()
if s in (O,P,Q,R,S):
  func_b()
else:
  func_c()

Pythonにswitchが無いのは、散々議論された上で必要ないと判断されたから。

RubyやRoRって、生産性が高いって言うけど、それは膨大な規約を丸暗記した上での話だよな。俺的には分かりづらいったらありゃしないよ。

人の作った物だと丸暗記になるが、作った本人は丸暗記だと思ってないだろう

>>255
それは、他のでも変わらん

caseと三項演算子があればむしろif関係いらなくない？

ぶっちゃけswitchの方が意味解りやすいな

RubyやRoRは、どうだこれだと直感的で分かりやすいだろうっていう教条的な態度が我慢ならない。設定より規約って、大量に規約を覚えれば設定が省けるに過ぎない。

Strutsはわかりにくいうえに傲慢な態度だからな。しかも制約が多いくせに手間は省けない。
それよりは100万倍まし。

Javaだとmavenの思想が好きだ。
とりあえず何も書かなくても動く。
動きを変えたいところだけ、書く。

>>262
それならまさにRailsの思想じゃないかと

Ruby on Railsを使った事ない奴は、一度使ってから批評しような、とちょっと思った
中身をいじる必要も機会も、Java APIやJavaのframe workと同様に無いわけだしなｗ
もちろん、上書きは自由だし可能だしなあ

だから、結局、どんなフレームワークだって、最初に使うときは、
覚えなきゃならない事が沢山あるって事に違いはない。
フレームワークどころか、多機能な道具は、皆、
使った事が無ければ覚える事が多いってだけだ。
あとは、その道具の体系化の仕方が、
使おうとする個人に合っているかどうかというだけの事だ。
極めて、普遍的で当たり前の事であって、
わざわざ、キーボードを打つ手間を掛ける価値のない事だ。

>>265は、
> 使おうとする個人に合っているかどうかというだけ
が、普遍的で当たり前でキーボードを打つ手間を掛ける（、ましてやサーバ準備して
実行環境を整えるなんて！）価値のない事と言い切るが、それは本当にそうなのか。

足りていれば問題ないが、足りなくなったときにそれでは足るまい（←自己撞着）
まあ何でもいいが、それなりに使って評価してる人間がいるときに使わない人間の
評価なんて糞だと思うな。

>>261
そんな君にはWicketが向いている

>>265
Railsはあまたあるフレームワークの中でも暗黙の了解が半端なく多い。少ないコードで組めるっていうのは、それに頼ってるだけ。

まあ、言語自体が覚えること多過ぎな言語とか
標準ライブラリも拡張ライブラリも全部予約語扱いで予約語一覧だけで何ページにも渡る言語とか
そーゆーのもあるけどな

そんなことより、Erlanの話しようぜ

もしかして：Erlang

Erlang の話をする位なら Scala の話をしようぜ

今更ながら Python は良い言語かもしれないと思えて来た。
上の方のレスで、気持ち悪いと書いてしまってすまんかった。

>>272
ちょっと触ってみてるけど、
現時点では良いやら悪いやら分からん言語、という感想

狙いは合ってると思う
次に注目される言語が何かは分からんが、たぶんマルチパラダイムだろうし、
静的型付けの利点を残したまま記述量を減らすなら型推論は妥当
C#とかもその方向ではある

ただXMLリテラルは個人的に疑問。XMLは言語レベルで密結合させるほど絶対的なものか？
あと、背反しがちなオブジェクト指向と関数型を調和させようとして
言語が複雑奇怪になりかけてる（？）のも気になる。まあ仕方ない感はあるけど

>>274
>あと、背反しがちなオブジェクト指向と関数型を調和させようとして

そうなの？なぜ背反になるのかだれか教えて。

>>274
難解な表現はやめてもうちょっと簡単にいって。
じゃないとこのスレでは立ち入り禁止します。

おいおい、なんのためのスレだよ

Pythonにブロックスコープ無いけど、これは利点なの？欠点なの？
Rubyにも無いみたい。

グローバル変数さえ判り易ければいいと思うが、どうなんだろ
スコープ無しはプログラミングしたことないわ

ブロックスコープに頼って長々とメソッド書くんじゃない、ってことじゃないかな。
Ruby のブロック（は他の言語のブロックと違うけど）には、ブロックローカルが
あるけどね。

>>275
自分は >>274 じゃないが、
関数型だと変数は一度設定したら、書き換えない物であるのに対して、
オブジェクト指向だと、変数はドンドン書き換える物だから、
相容れないという事では？

>>280
ブロックスコープもそうだが
ローカル関数 (メソッドではない) に頼ってもメソッドは長くなる。
そういう書き方が嫌なのはOOへの拘りが強いせいでもあるんじゃないか。

でも拘るならスコープを狭い範囲に留めてさせてほしいなぁ。
その関数(やらメソッド)でしか使わない処理を、その関数(ry と同じ層に
おくのはなんかイヤらしい感じ。

JavaScriptにもブロックスコープがないのは盲点。

ブロックスコープの意味が未だに判らない。
for や while の中だけで有効な変数を作りたいってこと?
>>283 の言ってる、関数でしか使わない変数って、Pythonでも関数の中の
ローカル変数になるよね?

for や while の中、じゃなくて、
ブロックはブロックなんだけど。

for や while じゃない、ただ単にブロックだけのブロックも
あるわけで。

>>286
Pythonには無いよね>ブロックだけのスコープ

まぁ、関数より小さいスコープ作るよりも、関数自体を
小さくする方が良いんじゃないかな。

>>281
>関数型だと変数は一度設定したら、書き換えない物であるのに対して、

そんなことはない。関数型言語のうちで、そういうのもあるけど、たいがいのはそこまで厳しくない。
Lisp, Scheme, OCaml, ...
Haskellみたいなほうが少数派じゃね？

>>287
サブクラスを作るよりも、クラスの階層構造を小さくする方が良い
って思ったことはないのか？

>>278
>Pythonにブロックスコープ無いけど、これは利点なの？欠点なの？
>Rubyにも無いみたい。

一般的に、インタプリタではないと思う。これがあるのはコンパイル型言語の特徴じゃないかな。

もしインタプリタでブロックスコープを実現しようとすると、ブロックに入るたびに
新しい変数テーブルを用意し、ブロックから抜けるとそれを破棄しないといけない。
さすがにこれは、インタプリタでは性能がでない。

コンパイル型であればこれはコンパイル時に行なわれるから、実行時のペナルティはなしですむ。

インタプリタではあきらめろっつーことだな。ブロックスコープは、あったほうがうれしいけど、なくてもそうは困らない機能だから。

the requested operation has failed とエラーが出てapacheとphpの連携が取れない
システムファイルを変更すね前はapacheの起動はうまくいったのに、何をやっても
上のエラーが出てくる、誰か助けて〜〜〜〜〜〜〜〜!

>>285
変数だけじゃなくて、関数内関数も定義したいってこと。

>>291
まずはログファイルを探して読んでみよう

やっぱりブロックスコープがどうのこうの言ってるのが意味わからん。
たとえば、Perlではほぼできてる、ってこと？

#!/usr/bin/perl

my $a = 'a';
my $sub = sub(){ print "page\n"; };
{
　my $a = 'b';
　my $sub = sub(){ print "hoge\n"; };
　print $a . "\n";
　$sub->();
}
print $a . "\n";
$sub->();

本題からはずれるけど Perl で $a は使わないほうがいいよ

そう言えば、C++で昔 forのルール変わったよね。

for (int i = 0; 〜)　の i のスコープがfor文内になった。

>295
確か一部の組み込み関数とかで $a と $b を使うんだっけ？

>>292
少なくとも Python なら関数内関数作れるよ。
decorator なんて関数の中の関数の中で関数を作ったりする。

perlのブロックは変数の共有にも使えたりする。
今はさすがにオブジェクト指向で書くけどね。

set(12);
print get();
exit;

{
my $common;

sub set{
my ($value) = @_;
$common = $value;
}
sub get{
return $common;
}
}

関数内関数がやりたいだけならブロックにスコープ必要ないんでは
for文とかforeach文のブロックにスコープがあるのはいいような気がしないでもないけど
ブロックにスコープがあることの必要性がよく分からぬ

my $fizzbuzz;
{
my @a = qw(FizzBuzz - - Fizz - Buzz Fizz - - Fizz Buzz - Fizz - -);
$fizzbuzz = sub {……};
}
今はさすがにオブジェクト指向で書くけどねｗ

>>288
余り詳しくないけど……。
Lisp, Scheme は、一般的に広い意味で関数型言語と言われているけど、
本当の関数型言語（純粋関数型言語）ではないと聞いたと思う。
OCaml は、 ML の方言にオブジェクト指向機能を追加した言語で、
純粋な関数型言語ではなさそう。

流石にFizzBuzz問題にOOPは使わないなｗ
やろうと思えば、ジェネレータ使ったりするかも知れないがｗ

>302
OOPでも状態を変更するとは限らないから、やはり
OOPと関数型が相いれないとは言えないよ
例えばフィールドへの代入もコンストラクタでしか行わないとかいくらでもやりようはある

>>302
そんなことこのスレの住人のほとんどが知ってることだと思うけど
何が言いたいの？

>>304
静的な関数型言語だと
OOPは関数型によくある型システムの利点の一部を削り取ってしまう

>>305
そんなに突っかからなくてもいいじゃないか。
うゎーん（泣）

ブロックスコープは当然有効な機能だわ。その点、Perlは実にいい。

>>300
必要か否かでいってたら、たいていの便利なものは無くてもなんとかなるになっちゃうよ。
可読性を損なわないなら便利なものは使いたいな。

誰か、HSPの存在価値を教えてくれ。
あれもLL？DSLではあるみたいだが（どっちかというと、ゲーム特化(BASIC風)）

HSPはエントリーされていないのですれ違いデス。

価値はそれこそ個人の価値観の問題だろう
DSLだという見解には同意する
小規模なゲーム・グラフィカルなアプリの作成に特化している

ここで話題に上るような、いわゆるLLではないと思う

>>309
>必要か否かでいってたら、たいていの便利なものは無くてもなんとかなるになっちゃうよ。

うん、そうだよ。それでいいじゃん。
ブロックスコープは、あれば便利だけど、なくてすごく困るほどのものでもない。
すくなくともインタプリタにはペナルティが大きそうだから向かないと思う。

>可読性を損なわないなら便利なものは使いたいな。

便利でもペナルティが大きければ導入されない。
便利さのかげでなにも犠牲にならないのならいいけど、犠牲になるものがあるなら
あとはトレードオフでしょ。

ちゃんと計算されてる？　ペナルティとか

>>313
だから>>309が言ってるのは、必要か否かなんていう切り口で語ったら
ブロックスコープだろうがそれ以外のものだろうが、
大概のものは同じ結論しか出てこない、だから「ブロックスコープを」決め打ちで語りたきゃ
もっと踏み込んだ切り口を何か出さないと、ってことでは。

すみませんが教えてください。

下記のコードの3行目と5行目が何をしているのかわかりません。

特に3行目。。。

なぜrefで判定する必要があるのかもわからないので
詳しい方教えて下さい。


if(exists $form_data{$name} ) {
if(ref $form_data{$name} ) {
push @{ $form_data{$name} } , $value;
　　} else {
$form_data{$name} = [$form_data{$name} } , $value ];
　　}
else {
$form_data{$name} = $value;
}

>>313
＞便利でもペナルティが大きければ導入されない。
ところが、Perlにはあって、それでああいう
パフォーマンスがでているのだが。
ペナルティとかおおげさにいうほどのことは
ないんでは。

>>316
つ　配列のリファレンス、デリファレンス

>>317
Perlはmyやlocalで変数宣言をしているじゃないか。
Rubyとかだとそれがないから、ブロックスコープを実現しようとすると、
ブロックごとにチェックをいれないといけない。
じゃあ変数宣言のないRubyがウンコなんじゃないかということなら、否定はしない。

HSPは米国国防省の省内統制システムへの採用が内定してるらしいし
Rubyと同じパターンで「欧米で評価」→「日本で再評価」みたいな予感はする。

>>319
そもそも、変数宣言がなかったら、
ブロックスコープはどのように
表現すればいいの？

>>321
ブロックスコープは、無名関数をその場で1回だけ呼ぶのと同じ

変数宣言させることで、汚いコードを書けないように制約を受けるわけで、それは凄く楽だわ。PHPとかJavaScriptとか関数ベースのスコープの言語と比べると、そう思う。

>>321
必要に応じて変数名の前か後ろにスコープを記述すればいいんじゃない？

>>324
よくわからんので擬似コードでも書いてみればいいじゃない

>>316
まず、$form_data{$name} に配列のリファレンスを入れたいようだ、っていうのはわかるよね。
んで、その配列に$valueを追加する、っていう処理だとおもう。
そのさい、配列のリファレンスならデリファレンスする必要があるし、ただの配列なら単純にリスト
で追加してからリファレンスとして格納。

んで、５行目のこれ
> $form_data{$name} = [$form_data{$name} } , $value ];
typoってないか？

そして上記前提を覆す８行目
$form_data{$name} = $value;
このカオス。$valueは何者よｗ

結論から言うと、このコードは読めなくていいよ。 おれは読めないｗｗｗ
おれが勘違いしてるのかな。そうだといいな。

うん。やっぱり勘違いしてた。
最初に値（単純にスカラー期待）が与えられたときは、普通にスカラー。
もいちど飛んできたときは、配列のリファレンスとして格納。それだけだね。
どうせなら最初から配列のリファレンスにするよね、っていう固定観念があった。

>>325
擬似っつーかPowerShellだけど
> $hoge = 100
> & { $hoge = 111; "global: $global:hoge　local: $hoge" }
global: 100　local: 111

みたいな感じ
まあブロックの中にまたブロックを〜みたいな話になると別の方法になるけども

>>325
どうでもいいけどその言い回しおもしろいな

Rubyは、変数への代入で宣言も一緒にされるようなもんだっけ…
グローバルというかブロックの外に変数があるとそれを使い、ないとブロック内でのローカルになる。
たまにハマるんだよなー。

↓こういうの

10.times do |x|
i = x
end
puts i

unko.rb:4: undefined local variable or method `i' for main:Object (NameError)

>330
その場合、timesより前に i = nil でも i = 0 でも良いから代入が要るんよね
何回かやると慣れるがｗ

>>331
宣言だけじゃ駄目なんだっけ?

Rubyに変数宣言文は無いよ
最初の代入が宣言の代わりになるから、スコープ入る前に何か値を入れればスコープがそこに決まる

代入が無ければメソッド呼び出しと区別できない
というか宣言に相当するような構文が無い。代入が宣言を兼ねるというか

同じ変数名で局所化することはできるの？ブロックの外でiを使って、ブロックに入って、別のiを使うっていう。

不安に思ったら関数のはじめあたりで初期化してやればいいだけ

>335
変数名被るほど長いメソッドにせず、素直にprivateメソッド作る

>>337
また後付け前提ですか

>338
「それぐらいしか無い」とでも解釈すれば良いじゃない
具体的な挙動は相手にお任せするのがOOP流さね

>>339
二行目が全く>>337etcとつながらないな
意味不明

>340
ん？二行目はすぐ上の行としか繋がってないよ？
同じ文章でも各自で解釈は違いうる、ってポリモーフィズムっぽいよなあ、と

ブロックスコープの話とＯＯＰの話がどう結びつくのよ

どこともつながってないだろw

>>337
privateメソッドにしてそのメソッドから外に出したら、(そのオブジェクトの)他のメソッドからも呼べちゃうんじゃない？

動くUMLだと思えば
そんなもんだろ

>>335
最新過ぎて第三者ライブラリの対応が追いついてないRuby1.9からはデフォルトでできる
一般的に使われてるRuby1.8ではそもそもできない

s = '無くしたら地球がヤバいデータ'
[1, 2, 3].each do |s|
s*10 # 適当
end
puts "#{s} は超重要だ！"

# Ruby1.8.7
3 は超重要だ！

# Ruby1.9.1
無くしたら地球がヤバいデータ は超重要だ！


Ruby1.8 のせいで地球がヤバい

うは。便利だけど 1.8 との互換性を考えると恐ろしい。

単なる変数じゃなくて、ブロックの引数であることに注意。

これでRuby使わない決心がついた。ありがとう。

似たようなのはPythonでもあるね。
x = "hoge"
y = [x for x in range(10)]
print(x)

Python 2.x なら xは9で、 3.xなら"hoge"のまま。
内包表記の中だけの名前になってる。

for や while を使う人がいないって言ったら Ruby 嫌がった人もいたし、人それぞれだな

>>346
Rubyって変数のスコープないの？
大昔に作られたLispですら変数のスコープがあるのに…
だめだめじゃん

は？

>>352
>>346を煽るのに「スコープがない」と言ってしまうような人はこのスレに来ちゃだめでちゅよ

>>354
> ブロックの外でiを使って、ブロックに入って、別のiを使うっていう。
スコープだろうが

Rubyは local や my といった予約語を使わずに、文脈上でスコープを定義する
ブロック内に変数が出現したとき、その時点で可視かどうかで

　可視　 → その変数を使う（つまり、書き換える）
　不可視→ 新規変数（ブロックローカル）として定義する

という動作になってる

>>346では [1, 2, 3].each のブロック内での s は可視なので、変数を単に再利用する
これを最初から不可能にすることもできなくはなかったんだが、そうすると

out = 外部データ'
someblock do |s|
　puts out #=> undefined
end

というように、ブロック外の変数にアクセスする方法がなくなってしまう

メソッドの引数も、ブロックの引数も、ライブラリの名前とかも宣言するのに
変数を宣言しない理由がよくわからない

R++ が出来たら Ruby を認めてやるよ。

>>357
変数は使う場所多いからいちいち宣言するのめんどいじゃん？ というような趣旨のことをどっかで聞いた覚えがある

変数宣言なんか導入されたら現状のRubyの利点である
「ローカル変数かインスタンスメソッドかよくわからないがとにかく返り値を返す何かであるhoge」
というのができなくなるじゃないかー

それ、やってるのお前だけだから。

>357
ライブラリ名の宣言というのがよく分からんが
メソッドやブロックの引数はRubyの場合、代入だろ？

モジュールやクラスの定義は
Module、Classのインスタンスを作成し定数に代入
さらに最後の式の結果を返す文

メソッド定義だけは少し毛色が違う気がするね
あれはProcのインスタンス作成とかしないだろうし

>>352
変数のスコープが無い　って、言ってることがよくわからんな。
ローカル変数もインスタンス変数もクラス変数もスコープはちゃんとあるし。

ブロックがスコープを作らないってならPythonもJavascriptも一緒だし。

JavaScript1.7だったかからはブロックごとのスコープを持つletというのが出てきてvarの影が薄くなってる

Rubyの通常のブロックはスコープ作るよ
ブロック開始時の文脈でブロック内の変数の新規性をチェックしてるに過ぎない

うん、
class C
def initialize
hoge = 'hoge'
@block = lambda{puts hoge}
end
def run
hoge = 'MODIFIED!'
@block.call
end
end

C.new.run

は、call で実行された環境ではなく block が定義された文脈を考慮して

'hoge'

を表示する

本スレにもクロージャのスコープが理解できなくて延々文句垂れてた奴がいたな
そんな特殊なものでもないしちょっと調べれば分かるのに、Rubyばっかり話題になる意味がよく分からん

それは別の話じゃね

>>365
単純に、initializeとdefとは違うスコープになってて
呼び出し先が違うだけって事じゃないの？

>>349
遅すぎだろ。ｊｋｗ

なー、シンプルにそれぞれの最も優れてる実例を出してくれないか？
結局大事なのは使えるかだろ？

http://www.google.com/

えっ

何これこわい

>>372 の脳内
（検索しろ！と言う。俺かっこいいべ！昔はmanだったけど今はGoogleだべ。）

http://www.youtube.com/

http://d.hatena.ne.jp/keyword/Python
googleに使われてるよ

>>377
で？

>>378
Pythonが一番

Pythonはいいけど信者はうざい。この点rubyを凌駕している。

信者「ではない」よ
たぶんね

信者は「他称」だからなｗ

傍目にウザい時点で他人が装ってる可能性が大
>>380みたいに単純な人はいいオモチャ

信者はうざい。はここの書き込みに言ったのではない。

>>380
ルビ厨のほうがひどいだろ。ｊｋ

どの言語信者も最近はわりと皆おとなしいだろ
弾やmatzも

>>384
>>379がageてるのに気づいて後出しじゃんけんですね。わかります。

お前に何がわかるっていうんだ!!

JavaってLLじゃね？

>>1にエントリーされていないのでスレ違いとなります

>>390
ダメです。

久し振りにラクダ本を開いた。
テキトーなページを開いたら「配列の配列」について書かれていて
for $i ループ内には

$AoA[$i] = @array; # 間違い
$AoA[$i] = [ @array ]; # 正しい

と書かれていた。

…俺は読むのをやめた。

>>392
それのどこに嫌要素が？
超わかりやすいだろ。

>>392
何が問題なん？

で、��1は誰なんだよ

お前に決まってるだろ

じゃあ独断と偏見でPythonって事で

もう俺JavaScriptでいいや

Python最強ですよねー

>>392は、以前にPerlを触ったときにはスカラーの概念やリファレンスまでは
たどり着けなかったんだと。
まあどの言語でも、一つずつ覚えてちょっとずつ進歩していけばいいと思うよ。

俺には393や394の感覚がわからん。400もな。
392の例はあからさまに直感的じゃないと思うよ。

$AoA[$i] = $@array;

配列のリファレンスも分からないようなPerl素人がいきなりラクダ本なんて読もうと思うのが間違い。
もっと初心者向けび本にしとけ。
というか、リファレンスとかポインタとか理解出来ない人間は職業プログラマーの素養がないので、PHPで日曜プログラマーでよい。

〜が理解できないとかPerl上級者とかそういう話はしてないよ

リファレンスが解るかどうかと、392が直感的かとは別問題でしょ…
俺だってCやJavaやPythonやRubyでリファレンスなら扱えるさ
Perlのは同じ記述がコンテキストで意味変わり過ぎてちと無理だわ

$AoA[$i] = [ @array ]; # usually best
$AoA[$i] = \@array; # perilous; just how my() was that array?
@{ $AoA[$i] } = @array; # way too tricky for most programmers
perldscから引用

直感的ではないなどと主観で言われても、
ああ、そうですかとしか言いようが無いけどね。

>>402
それ、エラー出ないか？

ちなみに同じページに

$AoA[$i] = \@array;

もほぼ間違い、と書かれていた。

@arrayがループ内でmyされたものなら問題は起きないが
ループより外にスコープがあるものだった場合
\@arrayは毎回同じ配列へのリファレンスを取得してしまうから、だそうだ。

言語毎にまとめてみた。
上はコピーされてリファレンスが渡され、下は直接リファレンスが渡される。

Perl
$AoA[$i] = [ @array ];
$AoA[$i] = \@array;

PHP
$AoA[$i] = $array;
$AoA[$i] = &$array;

Ruby
AoA[i] = array.dup
AoA[i] = array

Python
AoA[i] = list(array)
AoA[i] = array

Perlの場合リファレンスとかがわかりにくいというより
コンテキストが問題を分かりにくくしてると思う

今回の例に限って言えば、配列（およびハッシュ）の要素にはスカラー値のみ格納できる、
っていう言語仕様を知ってるかどうかだけのことなんだろうけどな

配列の配列とかが直感的に思った通りに出来る言語が勝ちだな。

>>411
直感は個人によって違うわけだから、そんなに直感的にやりたいなら自分で言語作ればいいんじゃないかと

つプログラミング言語を作る　前橋 和弥 (著)
http://www.amazon.co.jp/dp/4774138959/

@hoge = (1, 2, (3, 4, 5), (6, 7, (8, 9)), 10);

いつ見ても、Perlの文法は糞過ぎる。
なんで未だにこれを擁護出来る人が居るのか不思議でならない。

糞であるが故のバッドノウハウ症候群。
そして今更捨てられることができない認知的不協和。

無名関数を積極的に使いたい人は
クラス・メソッドの関係にこだわらないperlの方がむしろ癖がなくて良い

>416
まともな関数型言語触った事無い奴が、そんな寝ぼけた事言ってるんだろうな。

無名関数を積極的に使うならJSが割と最適解かも

416 は Perl しか使っていない

使いまわしの出来るクラスの一つや二つ作れるようになってから（ｒｙ

>>418 合意

>>408
Javaに慣れてしまった俺としては、Rubyが一番素直に見える。
次はPython、でPHPの順かな。
Perlはやっぱり複雑怪奇だ。
配列をオブジェクトとして扱えた方が、array.lengthみたいな書き方が出来て便利だと思う。

>>418
確かに。
最初のうちは無名関数の使いどころがよくわからなかったけど、
JavaScriptを使っているうちになんとなく身についた。

無名関数を関数型言語で覚えた奴は、純粋な関数処理を書く。
JavaScriptで覚えた奴は、副作用大前提のプロシージャっぽいのを書く。

>>414
いつ見ても、Rubyの文法は糞過ぎる。
なんで未だにこれを擁護出来る人が居るのか不思議でならない。

と、何にでも適用可能だな。ｗ

>>423
副作用大前提のおかげで、ジェネレータが発明されたんだぜ

LISPだって副作用バリバリだろ。

perlだけはレベルが違う

>>422
Java はどのへん？
C# は？

ラクダ本って言うのは、Perlに詳しい人が読む本。初心者が無理して読む本じゃない。

Javaは数値以外は基本的に参照、だからコピーのときに明示
C#は知らん

ダウト。ラクダ本は多言語上級者がPerl入門のために読むもの。

盛大にコンテキスト（文脈）を読み間違えたぜ…

結局コードも示さずに複雑怪奇やら、糞やら、呪詛を吐くしかできないのか。
だめだこりゃ。

>>433
そりゃほとんどの人間の悪口は脳内の言語イメージに対して言っているものだから仕方ない
そういう馬鹿がよりつかなくてよかったと思うしか

package MyObj;
sub new {
　　my ($class) = @_;
　　my $self = { 'items' => [] };
　　bless $self, $class;
}
sub set {
　　my ($self, $newitem) = @_;
　　push @{ $self->{'items'} }, $newitem;
}
sub take {
　　my ($self) = @_;
　　pop @{ $self->{'items'} };
}
1;
いまPerl初心者の俺のコードが簡単に言うとこんな感じになってるんだが
Perl使い的にはどう書くんだ？

Perlスレで聞けばいいのに。
モダンに書くとしたら。
package MyObj;
use Moose;

has 'items' => (
    is => 'rw',
    isa => 'ArrayRef',
    default => sub { [] }
);

sub set {
    my ($self, $newitem) = @_;
    push @{ $self->items }, $newitem;
}

sub take {
    my ($self) = @_;
    return pop @{ $self->items };
}

1;

これだけ単純なら、use Mooseじゃなくてuse Mouseでも。

モダン（笑）
ハイソ（笑）
ハイカラ（笑）

ニーソ馬鹿にすんな

perlerの連中も、意識的にモダンに書かないと、非モダンな出来上がりになる事は
認めてるらしい。

perlの文を見ると吐き気がする。C++の仕様の方がカワイイぐらいだ
いい加減に間違った進化だったって、さっさと淘汰されないかな

Perl系の言語って、Perlそのもの以外になんかあるんだっけ？

>>439
まあ、モダンでなければ非モダンだわな。>>435そのままだし。
>>436でもAny::Mooseぐらい使えとか、no Mooseしとけとか突っ込まれそうな気がする。

>>441
直系はPHPとRuby。既に別物。

>441
JPerlとIronPerlがあるよ

PHPってPerl系なのか

PHPは元を辿ればPerlの派生だけど、
ポリシーの無い付け足しをしまくりでワケワカメ状態。

モノポリー

のんぽり

>>440
Rubyの文を見ると吐き気がする。Pythonの仕様の方がカワイイぐらいだ
いい加減に間違った進化だったって、さっさと淘汰されないかな

というレスを書いて「何にでも当てはめられるなｗ」とかご満悦の奴が時々いるけど、
オリジナルのようには的を射ていないのが大半で、ミジメな抵抗に終わる。

的を射

>>451
ATOKまじお勧め

ATOK は自分を指すミスまでは直してくれないんだね

ATOK なんかをつかうやつはばかです

SKKこそ正義

ATOK使ってみたら草生やすのが大変すぎてﾜﾛﾀ

っっっっっっっっっっっっw

っっｗの状態でファンクションキー１回押すだけだよ

ファンクションキーを押さないといけないなんて
ATOK のインターネット経由の辞書もたいしたことないですね

つまんない

ｯｯｯｯｯｯｯw

的を射る、であってるんだよな。不安になってきた

お姉ちゃんにお任せだぞっっっっっっっっっっ！！
http://d.hatena.ne.jp/keyword/%C5%AA%A4%F2%C6%C0

語源の『大学』・『中庸』にあるように、「正鵠（せいこく）を失う」という表現からきています。
この場合の正鵠は「正も鵠も、弓の的のまん中の黒星（『角川漢和中辞典』）」のことで、
射てど真ん中の黒星に当てることができたかどうか、
当たったら「得た」といい、はずれたら「失う」と表現していたのです。
矢で的を射るのは当り前としても、
必ずしも的に、まして正鵠に当たるかどうかは示していない表現が「的を射る」です。

なるほど。確かに的を（狙って）射るのには、当たるかどうかは関係ないわな。

しかし、話題のATOKさんでは、「まとをえる」と打って変換しようとすると
《「当を得る／的を射る」の誤用》とか、赤い字でお節介に教えてくれたりもするｗ

まあ結局、言葉なんて意味が通じればなんでもいいってこった。

>>464の「まとをえる」は、「まとをいる」って打ったとき、ね。間違えた。

あれ？「まとをえる」の時でいいんだ。もういいや＞＜

今年のLLイベントは面白そうなのか？

つまり、的外れだと言えばいいんだな

ゲーム作るのに最適のプログラミングは？

C++
このスレ的には、ＲＰＧツクールに内蔵されてるRubyってことになるか。

じゃあRuby覚えようっと

http://itpro.nikkeibp.co.jp/article/NEWS/20090701/333034/?ST=oss
ググったらサポート1件3万とかふざけた金額が出たんだけどそんなムズいの？

2chで聞けばいいのにｗ

2chはゴミみたいな情報しかねーだろ
ってかサポートってこんなかかるのに何でプログラマは死にそうなの？

サポートをやれるような大企業はプログラマ以外にもたくさん人が必要で、
その人たちの給料やらなにやらを考えたらたいして金が残らんから。

その人たちっていらない人たちなんじゃねえの？
過労死させるような最低の企業が多い癖に不景気だし

>>472
基本料金などが不要な「トライアルプラン」では，1インシデント3万円で問い合わせに回答。
月額基本料金10万円の「ベーシックプラン」は2インシデントまで無料で，以降1インシデントごとに1万円。
「プレミアムプラン」は月額基本料金15万円で4インシデントまで無料。以降1インシデントごとに5000 円となる


割引になってないしww

素晴らしい詐欺だったのか

おそらく技術者は小人数
電話取り次ぎとマニュアルで解決できない問題の技術者への引継までは
派遣スタッフがやってるんだろうね
かなりいろんな段階でピンはねがあるかと

この会社に就職するのも悪くは無い

http://www.ec-one.com/recruit/index.html
採用情報持ってきてやったぞ

>>481
資格で要求されている経験と、
「学歴、前職規模、業界不問、24〜35歳位まで」ってのが乖離しすぎて無理ありすぎ。

Ruby厨はキチガイしかいないようで

スクリプトで生計立ててる人って・・

>>484
それで生計が立つならいいんじゃないか？

いやいいんだが、そういう奴の一人称って「ぽっくん」が多くね？
いままで5,6人のスクリプターと接してきたけど3人がそういう奴しってる。
しかも全員SOHO。やっぱ人と会話してないとアレになっていくのかなあ…

立たない人間が大半じゃないですかー

>>486
ただキチガイと当たっただけじゃね？

ぽっくんって何？

僕君？

おぼっちゃまくん以外でそんなの聞いたことねーよｗ
パチンコの影響か？

馬鹿にされてるんじゃねーの？

>>486
お前それ、奇跡みたいな確率だぞｗ
一般的な現象として語るとキョトンとされるだけだろうが、
初めから「嘘みたいなホントの話」として語ればウケるかも。

で、結局最強はどれなの？
全然バトルをロワイヤルしてないじゃん

隔離スレなんだから終わらせちゃ意味がないだろ

しかし言語ってそんな大事かね

大事でなければ、こんなに乱立するわけがない

まあ>>496は、（CPUごとに違うらしい）マシン語だけ使ってろってこった

えっ？

同系統のCPUならある程度の互換性はあるけどな
流石にPowerとかになると全然違うが

x86とPowerとSHは違うんじゃね？

このスレで（高級）言語の存在意義が問われるとは意外と言えば意外。

しかし>>496はどうとでもとれるので、本人的には、
「俺は言語なんかこだわらないぜ、なんでも書けるよフフン」
って意味で書いただけかも知れんが。

ruby / pythonを使う利点ってなんでしょうか？

ruby信者になれる

>>503
rubyやpythonのソースコードが読めるようになります
また、rubyやpythonを好きで使っている、頭のいい人達の
言ってることが理解しやすくなるかも知れません

>>503
オブジェクト指向

しかし、RunyとPythonはいっしょくたに語られる言語でもないと思うが。
Perl,PHP,Ruby,Pythonってくくりならわからんでもないが。

信者のキモさで一括りだろ

Rubyはキモいと感じるが、PHPとPythonはそれほど差はないと感じるが。

俺はRubyとPythonは大丈夫だがPerlとPHPはキモく感じる

そして世間の皆からキモく感じられてる>>510

Rubyは作者が喧嘩売ってるってかそんな感じｗ

おいデブ涙拭けよ

>511
残念ながら、俺はお前が想像してる以上にキモいぞ。

そろそろスレ違いも度を越してるだろ

この辺のｶｽ言語仕事で覚えさせられるのって、ねじ穴の型番たくさん覚えさせられる
バイトみたいなもんだよな。
履歴に書いても、あぁちょっと開発をかじってんのねくらいの経験にしか扱われねーし

PHP信者は単にプログラミング経験が浅いだけだと思うよ。

LLなんてどれも目糞鼻糞じゃね？

特定言語の信者になっちゃう時点であれだな。
LL言語って、優劣じゃなく好みの問題じゃね？

Perl 素人〜一般人〜変人 くまなくカバー
PHP 素人から圧倒的な支持
Python 一般人〜変人
Ruby 変人

Perl アル・ヤンコビック
PHP 田中要次
Python ばんばひろふみ
Ruby もっとがんばりましょう

20代専用Webページプリントごっこツールってことに気づいたのは30代になってから

>>520
Perl：素人、変人
PHP：素人〜一般人
Python：一般人〜変人
Ruby：一般人、信者

こうじゃね？

お前らのとりあえずPHP馬鹿にしとけばオレカコイイって言うスタンスワロタｗ
マジで違い分かってんのかよｗ

>>524
その反応は痛いなぁ。
お前だって今、ひらがなしか使えない奴に「かんじをつかえばかっこいいとおもってるおまえにわろた」
って言われたら呆気に取られるだろ？　そういうレベルのこと言ってると自覚したほうがいいｗ

レベルング

おっと(r

つーか、PHPはどう考えても言語使用がぐだぐだだろ。
まぁ、言語として比べること時点でおかしいんだが。

PHPは書きやすい言語なんだろうね
ただ、例外処理についてはもっとやりやすくして欲しかった

PHPの言語仕様は破綻している。Perlと同じくらい。
まだJavaScriptのほうがまし。

PHP: Personal Home Page Tools（笑）

どうやら壊れてしまったようだ

PHPの言語仕様ならとっくに壊れてますよ。

JavaScriptで要改善な仕様って、このくらい？

・コンストラクタ内で関数定義したときのthisの扱い
・連想配列とオブジェクトの関係

言語仕様という点ではPHPとRubyはある意味対極にあるからな。
そりゃ信者同士の小競り合いが絶えないわけだ。

>>534
ブラウザ・バージョンでの挙動統一

挙動統一は仕様じゃなくね？たしかに問題点ではあるが

>>534
配列関連
変数スコープ
文の区切り

>>530
Perlの言語仕様は破綻していない。
破綻していると思うのは、訓練が足りないせい。

訓練を洗脳に変えるなら同意。

んなこと言ったら、どんな言語でも洗脳だべ
Rubyのdef〜end にしても、Pythonのselfやインデントにしても

Javaなんかの洗脳も強烈だし。
Car car = new Car();
なんだこれ

def、end、インデントはどんなに厳しく見ても洗脳と言うには無理があるだろww

Perl信者が話をドローに持ち込もうと必死なんだろう。
失敗してるけど。

def end self インデントは、既存のプログラムを読むときに簡単に
推測可能なもの。
Perlの特殊変数をはじめとする記号の数々は推測不可能。
phpは関数名や動作が推測不可能。

> Perlの特殊変数をはじめとする記号の数々は推測不可能。
だとすると、Rubyの組み込み変数も推測不可能ってこったな。

> phpは関数名や動作が推測不可能。
意味ワカンネ。

記号が書いてあれば推測の手がかりになるけど、
文字間の略されてる部分を脳内補間して理解するのは
かなり信仰を深めないと無理。

記号の意味なんてのは覚えりゃいい話だよ。
推測の可・不可なんて、覚えるまでの短期間だけのオハナシ。（馬鹿以外には）本質的ではない。
もちろんその記号群が数千とかあるなら、同じことはとても言えないけど、そうじゃないし。
そう滅多に増えもしないし。

記号の意味っつーか、変数の中身を考えながら記号書かなきゃならんのがなあ
スクリプト言語なのにC言語でポインタ触ってる気分になる

PHPの関数の名前から動作を推測するのは簡単だと思うけど、
関数が多すぎだし、関数名が長すぎる。

array_push($array, ..)みたいな書き方よりも、
$array->push(..)の方がすっきりするでしょ。

$打つのがドルい

>>549
この場合は順序が本質ではないか
オブジェクト指向脳であれば、というかデータ構造を操作するという視点に立てば
「arrayにpushしたい」と考えるのが自然だと思う

PUSH ... TO ARRAY. でいいよ。

>>551
それは単に思考が日本語だからではないか

>>553
だからいいんじゃねーの？

そんなあなたには、なでしこです。

>>534
スクリプトにバグがあったときのIEのメッセージをなんとかして欲しい
もしかして今の新しいIEでは改善されてるのかな

>>555
わざわざ日本語変換なんぞしてられるか

ひらがなで打てばいいよ

>>557
俺様専用言語でも作っとけ。

>>547
>記号の意味なんてのは覚えりゃいい話だよ。
いやいや、Perlは$_をつかって記号すら省略してしまうじゃん
あんなのワンライナーを優先しすぎたクソ仕様
しかも@var=(1,2,3)の要素を参照するのが$var[i]とかウンコすぎる
@var[i]でいいだろ、ややこしいんだよ

>推測の可・不可なんて、覚えるまでの短期間だけのオハナシ。（馬鹿以外には）本質的ではない。
まさに洗脳された信者

能力が著しく低くないとわからない物ってのも、世の中にはあるものね。
俺の婆ちゃんが一人暮らししてた頃、市販品の蓋一つ、取っ手一つとっても
手が不自由な婆ちゃんにとっては性質次第で色んな不便があることをよく言ってて、
ああそうなのかぁ、と気付かされることが多かった。

たしかに記号だとググりにくい。

grepっていえよ

>>560
まだまだ訓練が足りない。

＞$_をつかって記号すら省略してしまう
省略するかしないかはプログラマの自由。
言語仕様だけが原因ではない。

＞$var[i]
@var[i]で参照してもよい。
そうするとスライスになるが、違いが
問題になることはあんまりないだろう。

>>564
dankogai 乙

おもちゃはおもちゃらしく簡単に使えないとねぇ。C#でいいやってなっちゃうし

>>564
まだまだ実践経験が足りない。

結局自分のスキルに自信アリマス！って奴なんか
本当の意味で一人もいないと思うんだけどどう思う？

だから>>567みたいな煽り食らうと

「そうか・・・（´・ω・｀）」ってなる。

あの…VBScriptは…
すみません。土台にすら上がってませんよね。ごめんなさいごめんなさい。

perlは正規表現だけの言語だな。
他はなんか気に食わない。最近はいないけど、perl信者もかなりうざかったしｗ

>>560
記号が嫌ならEnglish.pm使えば？

> いやいや、Perlは$_をつかって記号すら省略してしまうじゃん
変数省略できるが、記号の省略の意味ワカンネ。

> しかも@var=(1,2,3)の要素を参照するのが$var[i]とかウンコすぎる
> @var[i]でいいだろ、ややこしいんだよ
@var[..]は配列の範囲を返す。
リストコンテキストとスカラコンテキストは理解しようぜ。

頭で理解しててもパッと見て判らんのよ、コンテキストって。
本質じゃないところに考える時間を割くことになる。
同じ表記が同じように通用しない。

Rubyは今は言わなくなったが、昔は「驚き最小限」なんて言葉があった。
元々PerlのパクりであるRubyにおいて
その驚きってのはコンテキストのことだったんじゃないかなと思う。

昔は最小限での入力とか結構持てはやされてたな

今はなんだろ？
自分は入力保管とかバリバリ使うから見易さ・判り易さ重視で組むが。

たとえ入力補完が発達しても数学みたいなもんで
最小限での入力というか、最小限での表記のほうがロジックが分かりやすいな。

今は、一貫性だと思う。

RubyってHSPに毛が生えたようなもの、みたいな印象しかないな。

>>575
今・・・は・・・？ｺﾞｸﾘ

>>575
一貫性重視なら最初からPython使えばいい。
Rubyは、Matzが書きたいように書けるのが第一で、一貫性なんて
対して重視されていない。

便利さのための一貫性の犠牲は歓迎。
単なる不統一は修正すればいいだけ。
その修正をまったく受け入れないのであれば問題だけど、
まぁまぁ直している。

TOMOYO Linux で受け入れてくれるための交渉術、
とあったけど、Ruby には交渉下手な上から目線が多くて残念。

>>578
御意

$hoge = hage;
print @hoge, hoge, $hoge;

>>571
>記号が嫌ならEnglish.pm使えば？
自分一人がEnglish使ったところで、ほかの人が使ってなかったら、結局記号の意味を勉強しないといけないんだから、意味薄いだろ。
そのくらいわかろうぜ。

>変数省略できるが、記号の省略の意味ワカンネ。
記号変数すら省略するってこと

>@var[..]は配列の範囲を返す。
だからそれがいけてないってことだよ。
@var[0]は最初の要素、@var[0,3]は0番目を含めて3つの要素、とかできたはずなんだから。
もちっと他の言語勉強しな。Pythonのスライスとか勉強してみ。

>リストコンテキストとスカラコンテキストは理解しようぜ。
そんなのが存在する時点でもうね。
そしてそれを「理解しようぜ」なんて言ってる時点で洗脳されすぎ。

だから、嫌いな奴は洗脳とかキツい言葉を使ってればいいさ
普通の感性では習熟とかいうんだけどな

Perlのコンテキストにしても、関数の戻り値を柔軟に持てるとか
それなりの利点もあるし、便利に使える場面もある。
あんまりしつこいと下衆っぽいよ。

関数の戻り値を柔軟に持てるってどういうこと？

まともなPerl批判も世の中には存在するんだけど、
この子が言ってるのは単に「俺は嫌い、俺は苦手」ってレベル。

あらゆる言語をあっという間に修得してしまう、優秀な俺とは関係ない次元で吠えてる。

気持ち悪いのキタ

スクリプトぱっと憶えたら優秀ってなんかピエロだな

Perl批判は俺が知る限り少なくとも2人居るんだが、この子ってどっちのことを指してるのだろう

面接でPerlが得意とか恥ずかしくて言えない

>>584
言葉通りの意味なら、コンテキストによって返値を変えることができるってことだろ。

my $ret = hoge(); #=> '2つあったよ！'
my @ret = hoge(); #=> ('hoge', 'page')

ただ、あんまり便利に使う状況ってのに出くわしたことはないような気もするｗ

my $self=shift;

>>587
ぱっと覚えられない奴がどうしようもない馬鹿なだけだものな。

@baka=(9,8,7)
@aho=(1,2,@baka,4,5)
print @aho

>590
そういや配列はスカラーコンテキストだと要素数だな
しかし、混乱の元になった記憶しかないｗ
普通にlen(ary)なりsize(ary)なり用意すれば良かったのにとしか思わないんだよなあ

perlはいまやLL界のCOBOLだな

Perlはすぐ使える鉛筆みたいな道具
Pythonはきちんと書くときにつかう筆
rubyはうんこふく時の紙

rubyが一番重要ってことだな

>>582
> @var[0]は最初の要素、@var[0,3]は0番目を含めて3つの要素、とかできたはずなんだから。
> もちっと他の言語勉強しな。Pythonのスライスとか勉強してみ。
start..(start+number-1)で指定すればいいじゃん。
まあ、勉強してみますか。

Perl
範囲でしか指定できません。

Ruby
list = %w( a b c d e f )
p list.slice(2, 3)
で、
["c", "d", "e"]
が返りますね。

PHP
$list = array('a', 'b', 'c', 'd', 'e', 'f');
var_dump(array_slice($list, 2, 3));
で、
array(3) {
[0]=>
string(1) "c"
[1]=>
string(1) "d"
[2]=>
string(1) "e"
}
が返りますね。

では、Pythonではどう書くのでしょうか。
>>582さん、教えていただけますか？

ここは質問スレじゃないから自分で調べろ
http://0xcc.net/blog/archives/000043.html
http://www.diveintopython.org/native_data_types/lists.html
http://www.python.org/doc/2.3.5/whatsnew/section-slices.html

>>598
list = [ 'a', 'b', 'c', 'd', 'e', 'f' ]
list[2:5]

>>600
残念ながら、それは範囲指定だから意味が違いますね。

L[2:5]をL[2:2+3]に読み替えればいいじゃないか

>>600の書き方ならば
Perl
my @list = qw( a b c d e f );
print "@list[2..4]";

PHP
書式なし

Ruby
list = %w( a b c d e f )
p list.slice(2..4)

Python
d = ["a", "b", "c", "d", "e", "f"]
print(d[2:5])

で行けますが。

スカラ/リストの表記がきもい(他言語ではもっとシンプルな仕様で成立してる)って話のはずなのに、一体何をどう曲解してるんだ

>>604
単にキモイっていう単なる主観の感情の問題だというのか？
アホか。

 っつーかlistに代入するなんて(r

$や@を使うのは、ハンガリアン記法要らずで、分かりやすく便利。Rubyはソースコードが見づらすぎる。JavaとかC#みたいにVSとかEclipseとかのIDEを使うのが当たり前の言語なら、そう言う言語機能は不要かなと思うけど。

コンテキストがあいまいなことによる
読みにくさとバグの温床になるプログラムの例を
各PPPRでおながいします↓

>607
ハンガリアンとは根本的に違うというか、むしろ相反するような気がするが

@tmpと%tmp、前者が配列で後者がハッシュであることは一目瞭然。@tmp_listや$tmp_map等とする必要はない。

配列とハッシュが同じ名前になる場合よりも
@tmp_A, @tmp_B みたいな名前の使い方が多いから、
それがメリットだとしても機会は少ないな。

@tmp は文脈により要素数だったりするので配列とは限らない

ん？
@tmpは配列だろ？scalar(@tmp) はスカラだが。
ちなみにscalar(%tmp)は楽しいことになる。Perl大好き。

>>608
PPPRってなんぞ

$a # スカラ

@a # 配列
$a[index] # 配列の要素 = スカラ
@a[indices] # 配列のスライス = リスト

%a # ハッシュ
$a{key} # ハッシュの要素 = スカラ
@a{keys} # ハッシュのスライス = リスト


この美しさわかんねえかなあ…

リストをスカラ評価すると長さになってしまうのは、
たしかに気持ち悪いがそれとこれは別の話だと思う。

>>596
もうなんとか用の言語って時代じゃないだろ。もう役目を終えたよ、Perlは。

>>615
それは別の話ってのに異存ないが、まあ今はコンテキストの話なので、
その気持ち悪さが問題になってるんじゃね？

@$$#tmp

使い捨て言語で君も使い捨てに！

>>615
＞@a{keys} # ハッシュのスライス = リスト
これが有効に使えるときなんかあるの？

>>616
DSLがどうこうという時代なんだが？

>>607
>$や@を使うのは、ハンガリアン記法要らずで、分かりやすく便利。
使うデータが文字列と配列とハッシュだけだった時代ならそれでもいいけど
オブジェクト指向が一般的になった現在において、この仕様はクソだよ。
それがわからないPerlerが不憫でしょうがない。

>>622
しょうがないだろ。アヒルのように最初に覚えた言語をry

>>598
話がぜんぜん違う方向に進んだね。
もとの話は$var[]が配列の要素を返し、@var[..]は配列の範囲を返すのが、いけてないしわかりにくという話だったんだけど。
別にこんなことで@varと$varを使い分ける必要なんかなく、どっちも@var[]でできるようにすれば
誰にもわかりやすいのに、Perlはそうなってないから変だよねという話が、
いつのまになんで範囲指定の方法の話になっちゃったんだろう。

とりあえず、
配列の要素をスカラーとして取り出す方法と、
そのスカラー1個だけを要素とする配列を作る（スライスする）方法は
別々に用意した方が言語仕様的にはいいんじゃないのか？

Python なら、
a = range(5) # [0,1,2,3,4]
b = a[3] # 3
c = a[3:4] # [3]

d = a[slice(3, 4)] # [3]

>>620
ハッシュに代入するとき役に立つ。

>>620
ハッシュから複数の値を取り出すときに使う

# Ruby

a = (0..4).to_a # [0,1,2,3,4]
a = (0...5).to_a # [0,1,2,3,4]
p a[3] # 3
p a[3..3] # [3]
p a[3...4] # [3]
p a[3,1] # [3]
p a[-2] # 3
p a[-2..-2] # [3]
p a[-2...-1] # [3]
p a[-2,1] # [3]

>>628
kwsk

急に書き込みが増えたねw

>>630
なにそれこわい

どの言語であれ、配列をスライスする処理なんか、一年に一度も書かないが。

>>631
@names = ("Alica", "Bob", "Chris")
@ages{@names} = (28, 31, 72);

$ages{"Alice"} == 28

何故にアリカ？

@names = ("Alica", "Bob", "Chris");
@ages{@names} = (28, 31, 72);
print %ages;
@ages{'Chris','Bob'} = (34, 37);
print %ages;
Bob31Chris72Alica28Bob37Chris34Alica28

>>637
なるほど。勉強になった。

機会はなかなかなさそうだけど、
使い道はちゃんとあるんだな。

>>622
どんなにオブジェクト指向を強くしたところで、プリミティブ型や配列型のないプログラミングなどあり得ない。
スカラ変数とリファレンスを分けるシジルがあればより便利だということに過ぎない。何もないよりずっといい。
>>610の$tmp_mapは%tmp_mapの間違いだが、これはPerlであればコンパイルエラーを起こすので、未然にバグを防げる。

記号の付け間違いなんてバグは、その仕様がなかったらそもそも起こらないだろ

配列にアクセスしているつもりが、その変数はハッシュだったということ。誰にでもよくあるミス。

>637を見て、
「さすがPerl、記述性が高い」と感じるのがperler。
「滅多に書かない記述の為に文法が歪められてる」と感じるのが一般人。

>>642
Pythonistaは、Pythonではどうするか考える。
names = "Alica Bob Chris".split()
ages = dict(zip(names, (28, 31, 72)))
print ages
ages.update(Chris=34, Bob=37)
print ages

ハッシュのスライスって初めて聞いたがそんなのあったんだな。
ただ、スライスのイメージとちょっと違うな。ハッシュの範囲指定だと、キーがある正規表現にマッチする集合とかならわかるけど。

>>644

%h = ('hoge'=>1, 'page'=>2, 'moga'=>3, 'guge'=>4);
@a = @h{grep {/ge/} keys(%h)};

まさにそういう事をしやすくするためにPerlは柔軟なリストなわけで。
まあ、高尚な原理や理論より便利（っぽ）さ上等

>>645
結果もハッシュで欲しいならこうかな

my %h2;
my @keys;
@h2{@keys} = @h{@keys=grep{/ge/}keys(%h)};

まあなんだ。面白いんだが、こういったことをやりすぎると
読みにくくなるのは否めないという

ttp://anond.hatelabo.jp/20090617130518

10 == "0x0A"
がtrueで
"0x0A" == 10
がfalseになるスクリプト言語はありだと思う

>>647
これが「コンテキスト」の上を行く「場当たり」って奴か
勉強になるな〜

この8進数はねぇよ・・・

でも、PHPのこのいい加減な解釈ってずいぶんお世話になってるなぁ自分

var_dumpで出るのは格納してる型であって、==で比較される時に自動で解釈されるんだよな

>>648

問題は常にそう解釈されるのでは無く
PHP自身がどのようにコンパイルされたか
という環境によって動作が異なることに在る

不安なときは===を使えというのがPHPとJSのお約束

多言語だと軽くスルーできるMap/Vectorの話でこんなに混乱してるってのは結局便利じゃねーん
だろうなって思うw

http://codezine.jp/article/detail/4065

配列のスライスがあるんだから、ハッシュのスライスもあるだろうと思うのは自然なことだろ。

>>656
似たようなことができるようになってるだけで、
根本的には概念が違う気がする。

リストの２〜３番目に、１０要素を代入するとかできるからスライスってのが便利なわけで。

>>639
>どんなにオブジェクト指向を強くしたところで、プリミティブ型や配列型のないプログラミングなどあり得ない。
>スカラ変数とリファレンスを分けるシジルがあればより便利だということに過ぎない。何もないよりずっといい。

何をいいたいのかまるでわからない。プリミティブ型や配列型を排除しろとは誰も言ってないし、うーん。
@tmpがリスト、%tmpがハッシュ、で、それ以外のデータ構造を使ったら$tmp
。
べつに、ぜんぶ$tmpで統一してくれていいんだけど。

>>>610の$tmp_mapは%tmp_mapの間違いだが、これはPerlであればコンパイルエラーを起こすので、未然にバグを防げる。
これもなにがどうエラーになるのか不明なので、解説よろしく。

つーか、もちっとわかりやすい文章書こうぜ。Perlerだから仕方ないけど。

JSON

>>657
部分集合の操作が近いかもね。
perlのハッシュスライスの書式は座標が直感的に使えるからか、
概念増やすのが面倒で配列スライスに似せたのかのどちらかのように思う。

perl
my %color = (R => 0, G => 0, B => 0);
@color{'R', 'G', 'B'} = (63, 127, 255);
print @color{'R', 'G', 'B'};

ruby
color = {'R' => 0, 'G' => 0, 'B' => 0}
color.replace({'R'=>63, 'G'=>127, 'B'=>255})
p color.values_at('R', 'G', 'B')

Perlerはバカにされやすいからな。がんばって難しく言おうとしちゃうんだよ

$ perl
my %color = (R => 0, G => 0, B => 0);
@color{'R', 'G', 'B'} = (63, 127, 255);
print @color{'R', 'G', 'B'};
63127255

$ ruby
bash: ruby: command not found

$ python
>>> color = dict(R=0, G=0, B=0)
>>> [color.__setitem__(k, v) for k, v in [('R', 63), ('G', 127), ('B', 255)]]
[None, None, None]
>>> print [color[k] for k in color]
[255, 63, 127]

>>662
color.update( (k,v in [('R', 63), ('G', 127), ('B', 255)]) )
の方がPythonicなんじゃない？

NameError: name 'k' is not defined

ここが言語を比較できる僕かっけースレですか

color.update([('R', 789), ('G', 456), ('B', 123)])
print map(lambda k: color[k], ('R', 'G', 'B'))

yes you does

doesだってｗｗｗ

http://thestar.com.my/english/story.asp?file=/2009/3/13/lifefocus/3446185&sec=lifefocus

334 ：可愛い奥様：2007/06/26(火) 09:46:19 ID:raxdPvfD0
OLだった頃、会社で働いていた日本に超詳しいベルギー人が言ったことに納得してた。
日本文化は身内受けの凝り性文化だそう。
外国文化に負けまいとしているのではなく、
世に意図的にインパクトを与えようとしているのでもなく、
今ここにいる同じ価値観を共有する仲間からの喝采を浴びたいと考える。
その結果、同じものを志す者同士の「これすごいだろ、おもしろいだろ」合戦が始まり、
そこで生み出される物が自然と研ぎ澄まされていく。
でもその競争は、敵対的なものではなく、お互いを尊敬しあいながら、静かに深く進行していく。

そしてある日、偶然目撃した異文化出身の人間（外国人）から、
それがすごいものであることを知らされる。
ほとんどの日本人はその日が来るまで、自分たちが作り上げた物がすごいものとは知らない。
もろもろの伝統文化、芸能、電化製品、アニメ、他、みんな同じパターンで世界に広まっていった。
だから、日本がここまで発展してきたのも必然的なものだし、
この精神が衰えない限り、これからも日本は誰に頼まれることもなく、
知らないうちに勝手に世界にインパクトを与え続けていくだろうと。

英語について ｢Do｣と｢Does｣は何を区別して､使い分けるのでしょうか？
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1320176013

｢Does you play golf？｣
これは間違いだとおもいます。

｢Does your father play golf？｣

ならあってます。

でも口語や歌詞などで
She don't know.
なんてのも有りなんで、流行ってるのかも知れませんね。

Does　youが有りだからyou doesも有りだと思ってる小学生ｗｗｗ

how foolish you are

hows じゃね

wish you were dead

use English;

By the way, please listen to me. This doesn’t have any relevance about that.
Few days before, I went to the Yoshinoya in my town. Yoshinoya.
But I can't step in; because there are too many people. Then looking around,
I found advertisement Curtain. It said "150 yen off"
Don’t come to the Yoshinoya which you don't generally come to, just because of only 150yen off.
You must be foolish or stupid! Oh! There is parent-and-child, and the Father of which is saying "I'm going to order Tokumori
Are you all eat in Yoshinoya? Congratulations! I can’t stand it ever more! I'll give you 150yen and please go away!
Yoshinoya should be more bloody & violent.
You cannot predict when the tow man face each other in the character table of U begins to fight. Stab or be stabbed.
This is the Yoshinoya. Women and Child, Go away! Don't exist in Yoshinoya.
Then, I could sit on the seat, the man in next seat ordered "Ohmori Tuyudaku"
That was sufficient reason to enrage me absurdly violently. Hey! You said Tuyudaku?
It’s perfectly out of date. It’s old fashioned Do you really want to eat Tuyudaku?
How foolish you are. I want to question you whether you really want to eat it or not.
I want to question you for one hour! You just want to say Tuyudaku.
In the side of expert of Yoshinoya, The newest fashion is "Negidaku" Year this is.
It has more negi but less meat. And put egg on this. This has no enemy.
Yes this is. But if your order this, your face must be memorized. It may be the sword of many edges.
I don't recommend to bigger. Gyuhsaketeisyoku may be fit on you.

Why don't you talk about here?

>$ ruby
>bash: ruby: command not found

　　　　　　　 |ﾘ u' }　 ,ﾉ　_,!V,ﾊ |
　　 　 　 ／´fト､_{ﾙ{,ィ'ｅﾗ　, ﾀ人　　　　　　　　Ты думаешь, из меня,
　　　　 /' 　 ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ　　　　　　я не могу сказать.
　　　　,ﾞ　 ／ )ヽ iLﾚ 　u' |　| ヾｌﾄﾊ〉
　　 　 |／_／　 ﾊ !ニ⊇　'／:} 　V:::::ヽ　　　　　　Я не знаю,
　　　 /／ 二二二7'T'' ／u'　__ /:::::::/｀ヽ　　　　что случилось.

な、何を言ってるのかわからねー(以下略

>676
それはツッコミかｗ

for my $x (@{$self->{'ls_ref'}}) {

for x in self.__ls_ref:

@ls_ref.each{|x|

334 ：可愛い奥様：2007/06/26(火) 09:46:19 ID:raxdPvfD0
OLだった頃、会社で働いていた日本に超詳しいベルギー人が言ったことに納得してた。
日本文化は身内受けの凝り性文化だそう。
外国文化に負けまいとしているのではなく、
世に意図的にインパクトを与えようとしているのでもなく、
今ここにいる同じ価値観を共有する仲間からの喝采を浴びたいと考える。
その結果、同じものを志す者同士の「これすごいだろ、おもしろいだろ」合戦が始まり、
そこで生み出される物が自然と研ぎ澄まされていく。
でもその競争は、敵対的なものではなく、お互いを尊敬しあいながら、静かに深く進行していく。

そしてある日、偶然目撃した異文化出身の人間（外国人）から、
それがすごいものであることを知らされる。
ほとんどの日本人はその日が来るまで、自分たちが作り上げた物がすごいものとは知らない。
もろもろの伝統文化、芸能、電化製品、アニメ、他、みんな同じパターンで世界に広まっていった。
だから、日本がここまで発展してきたのも必然的なものだし、
この精神が衰えない限り、これからも日本は誰に頼まれることもなく、
知らないうちに勝手に世界にインパクトを与え続けていくだろうと。

>>684
どう考えても褒めすぎ
今の日本は屑しかいない

>>658
> >>639
> >どんなにオブジェクト指向を強くしたところで、プリミティブ型や配列型のないプログラミングなどあり得ない。
> >スカラ変数とリファレンスを分けるシジルがあればより便利だということに過ぎない。何もないよりずっといい。
>
> 何をいいたいのかまるでわからない。プリミティブ型や配列型を排除しろとは誰も言ってないし、うーん。
> @tmpがリスト、%tmpがハッシュ、で、それ以外のデータ構造を使ったら$tmp
> 。
> べつに、ぜんぶ$tmpで統一してくれていいんだけど。

何を言ってるわけ？
$tmpに統一って、$tmpしかないことは機能性の後退だろ。
Perlがシジルを使ってデータ型を表すこと、それはハンガリアン記法という広く普及してる変数命名法を言語レベルで保証しているということ。

> >>>610の$tmp_mapは%tmp_mapの間違いだが、これはPerlであればコンパイルエラーを起こすので、未然にバグを防げる。
> これもなにがどうエラーになるのか不明なので、解説よろしく。

お前、Perl知らないだろ？

> つーか、もちっとわかりやすい文章書こうぜ。Perlerだから仕方ないけど。
>

お前がアホだからというか、Perlを知らないからだろ？

だいたい$tmpに統一なんて言い出すところからして、PHPだろ？PHPは、論外だから。

Ruby脳的には、せっかく動的言語なんだから
型の決定は実行時に遅延させたいなあ
・・・・というわけなのかは知らんが、$やら@はスコープの表記に使っちゃった

Ruby GJ!! www

Rubyは何でカッコの省略を認めたのか。あれは最高に見づらい。変数だかメソッドだか分からない。

分からなくていいじゃん

問題なのは関数渡しがまんどくさい

いいわけないだろ。そのせいで、いちいちソースを追う羽目になるんだから。

変数もメソッドも同じオブジェクトっていう発想は画期的なものなんだが。

$xxx = "Subject: =?SHIFT_JIS?B?W5FLXYNUg0ODZ5NvmF6CzY2hgqqStIFggqiTvoH0?=";
$xxx = mb_decode_mimeheader($subj);
$xxx = mb_convert_encoding($subj,"SJIS");
echo $xxx;

　　↓

Subject: [?]?????????????

になっちゃうんです。
どうしたらうまく変換できますか？

rubyにおいてメソッドはオブジェクトじゃないお

関数でもメソッドでもいいが、少なくとも引数がある場合はカッコあった方が良くね？
引数ないときに()を省略できるかどうかはまた別だけど、俺はあった方がいい。

引数がある場合でも括弧付けない言語なんざいくらでもあるけどな

つかRubyの場合、フィールド参照もメソッド呼び出しだから
必ず括弧付けるとなると、なんだか読みにくくなりそう

その場合、複数行になる場合はどう書くの？

>>695
滅多にお目にかからないが、Methodクラスってのはある
ファーストクラスかと言われると怪しい

Methodクラスのインスタンスはオブジェクトだから、ファーストクラスだお
でもそれ自体はメソッドじゃないお

Rubyでメソッド呼び出しの括弧省くと、なんだかんだでパースエラーに
なる事が多くて、結局格好付ける事になりがち。

で、括弧が多くなってくると、「不統一なのもかっこわるいから、
全部付けとくか」ってなる。

Ｌｉｓｐも有る意味、引数に括弧はないな

>698
改行が文末として扱われる言語ならば、行を継続する場合に明示する。
例えばVBは行末に _ を書くし、Rubyでも行末にバックスラッシュを書くと文末として扱われない。

Pascalなんかは引数が無い場合には括弧を書かないが
Cなどと同じくセミコロンを置くことで文末を示す言語なので、複数行でも何ら表記は変わらない。

>>703
そういうことか。

しかし、数学では普通関数をf(x)ってカタチに書くから、
カッコがないってのがなんか気持ち悪い。

>> 690
レシーバselfかつ引数なしのときは俺は()つけて書く。
func()みたいに。

もし()省略できなかったら、
require('library')
include('module')
みたいになって逆にキモくなるんじゃない？

まあ括弧省略可でうれしいのは,print,putsだろうけどね。

まぁ、Rubyでも戻り値を式として使う場合には括弧付けたほうが無難だけどね。

Perlみたく @ary = sort keys %h みたいな書き方は認められてないよ。
Rubyにはsort関数もkeys関数も無いが、もしあったなら
ary = sort(keys(h)) と書かないとエラーになるはず。

ただブロックなどで「最後の式の結果を返す」となってる場面でも省略できちゃうから
そこは個人的にはちょっと何かないかなぁと思うけど。

>>706
foo = p p 1 とか普通にできるけど？

ちょっと前までは、括弧が将来必要になるかも、ってwarningが出てたけど、

> 「文法を簡単にしようと思ってたんだけど、RubyConfで『括弧の省略を駆使していかに
> 英語っぽいコードを書くか』という内容でまるまる1セッション使った発表があって、諦めた」

という奴だね。

まとめると、
文系：省略派
理系：非省略派
ってことだな。

>707
ま　ぢ　か
じゃあ俺の使ってるバージョン古いんだな…

>>708
ガチガチの文系で理系にコンプレックスのある漏れが非省略派なのでうそ臭いです

括弧の省略は

・省略した方が明らかに読みやすいと思われるケースがある
puts("hello ruby")
puts "hello ruby"

・言語内DSLにとっては、省略が効いたほうが有利なことがある
例えばrake（Ruby版make）だと
task :default => [;test]
task :test do
　ruby "test/unittest.rb"
end

などなどの事情もあるわけだから、
たぶんコーディングスタイルのレベルで対応するべき問題ではないか

rubyの場合省略不可にするとプロパティ構文とか導入しないとめんどくさそうではある

requireだろうがattr_accessorだろうがカッコ付きでいいじゃん、と
割り切ればいいのでは？

括弧の省略が嫌いならPythonに改宗すると幸せになれるよ

今度は、ブロックにカッコつけるとかなんとかで（ｒ

>>711
puts( "hello ruby" )

括弧論争は、シェルスクリプトの延長でRuby書いてる人と、
CやJavaの延長でRuby書いてる人との対立な気がする。

文字列の出力くらい
"hello ruby"
だけでいいじゃない

Pythonの場合「関数呼び出しの括弧を省略できない」というのは
結果的にはそう見えるんだが、その中身を考えるとその表現は違う気がする

まず関数にバインドされた変数／フィールドがあって
括弧を付けるのは、その関数に対して「呼び出し」を試みる操作だからね

括弧をつけると、変数／フィールドにバインドされてるのが
・関数なら、関数の処理を行い結果を返す
・クラスなら、インスタンスを生成しそれを返す
・他にも、呼び出しが可能なオブジェクトにバインドされていればそれぞれの挙動を示す
・呼び出しに対応していないオブジェクトの場合、例外を発生させる

()ありの場合は
関数的に使い、かつ引数なし
メソッドチェーン
引数が複数

それ以外のときは()省略。俺はこれがシンプルなルールだし、
可読性も高いと思ってる。
ちなみに俺はC→C++→Python→Rubyの順で習得したけど、結構省略派。
性格的にも学歴的にも理系。

Pythonはint()とかlen()が関数なのにダックタイピングしようとしてる所が好きじゃない。
self、インデントは全然許せるが、インスタンス変数をprivateにすると、self.__var
ってなったりするのが、激しく嫌いかな。あと動的言語なのにglobal宣言とかね。

でも、()を省略したくないような人なら()以外の面でも、
RubyよりPythonの方が好みだろうね。

PythonとJSで呼び出し時に括弧が省略できないのは
メソッドが関数の代入されたプロパティとして実装されているから，って認識でOK？

括弧省略ルールは、Scalaのが明解だな。
後発だけに。

()を省略すると、
f = hogehoge.func
って書いたときに、fが何を表すのか不明になる。

そもそも、Pythonは関数・メソッドが完全にファーストクラスだから、
名前が変数名なのか関数名なのかで呼び出す・呼び出さないを
分けられない。
def foo(): pass
bar = foo
del foo
bar()

()なしは変数なのか関数なのか、一見でわからなくなるからやめて欲しいわ

def __call__():
でなんかなるんだっけ

様は読めればいいわけですね。
省略する人は、Lisp嫌いですか？

育ちによって、
hoge = func1
を「変数hogeにメソッドfunc1を呼び出した返値を代入する」と読んだり、
「変数hogeに関数func1を代入する」と読んだりするわけだ。

「hogeはfunc1と同等」とか「hogeはfunc1と同一」もあるかも知れないぞ

Pascalは代入が := で = が同一判定だね
C言語とかと一緒にやろうとすると見事にハマるw

>>730
どちらかといえばそっちの方が好みだな。
一般的に = は等号という意味が定着してるんだから
プログラミングにおける代入という新しい概念には新しい記法を与えるのが自然。

正直、代入を'='にしたのはCの負の遺産だと思う。

つーてもBASICとかでも = を代入に使うけどな
BASICだと同一判定も = だけどさ

FORTRAN 以来の負の遺産だな。

>>731
その考えはある意味正しいと思う一方で、
代入操作は比較的頻繁に行われることを考えると
短いトークンを与えようとするのは実用上正しいとも思う

確か、C言語で代入に短いトークンを割り当てたのは、
比較より代入のほうが多い、という判断があったからなんだけど、
サンプリングが偏ってた、って何かで読んだような。

Perlが出るまでは、~ とかその他記号も空いてた様な気もする
イメージ的に=の要請が強かったのかなあと思う
その頃から別に、代入に=で違和感なかったんじゃね？

!=ってのもあるんだから、比較を==にして文字数を合わせた方が収まりが良い

>>736
~はbitwise not

代入はSmalltalkみたいに、専用の文字（「←」とか）を用意するのがよい。
今なら、Unicodeに入れてもらえばなんとかなるだろ。

いらんですよ、そんなもん

APLでもやってろよｗｗ

いや、内部コードUTF-8全盛のこの時代、決して非現実的ではないので、思考停止はいくない

単純に、欧米圏の人間にフォントを入れてもらえばいいだけさね
頑張れMicrosoftおよびその他ディストリビュータ

入力が面倒

そろそろ欧米圏の人間にも、IMEのなんたるかを知ってもらういい機会になるかもよ
悪平等の見本みたいな意見だがなｗ
だが、いい加減英語アルファベット+αがグローバルスタンダードと思っていられても困る

-> pointer
<- assign

すまんが、釣りは昼間にやってくれんかねｗ

夜釣りには夜釣りの良さがあるんだぞ

そこでfortressですよ。

とりあえず代入は = でいいと思う。
= のどの言語でも、そこには不満ないw

ここで比較の=と代入の=と代入の:=がある恐ろしい言語が

正格評価と遅延評価で代入演算子が異なる言語もあるでよ

= の一般での意味をかえてもらえば解決

define変数定義 :=
assign =!
equals =
not equals !=

空文字列やゼロが偽って話は聞いてたけど
"0"（ゼロ）って文字列が偽だなんて聞いてねえよ…

>>754
PerlとPHPかな。他にもあるんだろうか。
その二つしか使わないおれはなんかそれに慣れちゃったな。

===

>>756
null === false #=> false
なのでそいつもちょっと。

帯に短しタスキに長しと。（ちょっとちがうか）

isset(), empty(), is_numeric()

if(!isset($var) || empty($var) || !is_numeric($var)){}

こうでつか？

PHP、DSLとしては別に悪い言語じゃないと思うが
ネームスペースとかタイプヒンティングとか大規模開発向きの機能が中途半端なのがなんとも。
タイプヒンティングなんかarrayとオブジェクトだけとかいう謎の仕様だし。
ある程度の規模を越えたところで辛くなってくるんだよなあ。
比較演算が曖昧すぎてつまらんバグ起きやすいし。

>>690
関数でもどっちみちソース追うよ。
この手のは最初に入った言語の影響や慣れってのが大きいよ。

>>754
真面目にそれ何ていう言語？
もし俺も使ってたら気をつけないと…

perlだろ

PerlかPHPっていってるそばから…
なんか無性にイラついてきた。
>>762めー！俺は絶対にお前を許さんからな！

>>764
　　　　　　iヽ　　　　　　　/ヽ
　　　 　 　|　ﾞヽ、　　　　/ 　ﾞi
　 　 　 　 |　　　ﾞ''─‐'''"　 　 l
　　　　　,/　　　 　 　 　 　　 　 ﾞヽ
　　　　 ,iﾞ 　　　／　 　 　 　 　＼ ﾞ
　　　 　i!　　　　　●　 　 　　●　,l　そんなこと言われても
　　　　 ﾞi,,　　　* 　 （__人__）　　,/　　　　　わて猫やし…
　　　　　 ヾ､,,　　　　　　　 　 ,／
　　 　　 /ﾞ "　　　　　　　　　ヽ
　　　　/　　　　　　　　　　　　 i!
　　(⌒i 　　　丶　　i　　　!　　 i!.,
　　　　γ"⌒ﾞヽ　　l　　　l　　γ'.ヽ
　　　　 i　　 　 i,__,,ﾉ　　　i,__,,ﾉ_,,丿
　　　　 ヽ,＿,,ノ"~´￣ ￣　　　　　　

鰻まだ売ってるところを教えてくだされ

土用はまだじゃなかったっけ

猫はどんなプログラム言語使ってんだよ

今年は二回有る

>>769
おお。知らんかった。thx
ttp://ja.wikipedia.org/wiki/%E5%9C%9F%E7%94%A8%E3%81%AE%E4%B8%91%E3%81%AE%E6%97%A5#2004.E5.B9.B4.EF.BD.9E2011.E5.B9.B4.E3.81.AE.E5.A4.8F.E3.81.AE.E5.9C.9F.E7.94.A8.E3.81.AE.E4.B8.91.E3.81.AE.E6.97.A5

自分はPerlとCのさわりがわかるくらいだけど、Perlの事が書いてる本をよんだりしてると
今まではPerlが最良の選択肢出会ったけど、今後はRubyにシフトするであろう
みたいなことが書いてあるのを何度かみた。
Rubyってそんなにいいの? なにがいいの?
自分はWeb屋だから、Rubyがまだ選択肢に入らないんだけど、選択肢に入るようになるのであれば勉強しておきたい。

Web屋に対してのRubyの利点を教えてくれ

Python>Ruby>PHP>Perl

WebとしてのRubyも廃れつつあるんじゃないか？と思う。
ちょっと前になにがなんでもRoRってノリな時代があったのは確かだが。

日本だとやっとPythonが地味に伸びてきているし、世界的にあいかわらずPHPは多いし。

>>772
その順位は結構妥当だなと思ってしまった。
PHPを叩くPerlerが多いけど、PerlよりPHPのほうがまだましというのが正直な感想。

>>774
なんでやねん。

｛Perl,Python｝>Ruby>>PHP
だろ。ｊｋ

Perler以外の全方位から叩かれるPerl、という感じだな。

しかしPythonが不自然なまでに叩かれないのを、Python自体の功績のみと思うべからず
知らなきゃ叩けない

Pythonは微妙だなあ。
ウェブは PHP/Java, ちょっとしたツールは Java, 性能要求が厳しれば C/C++ という鉄板の中で立ち位置がよくわからない。

Googleが使ってる→普及させる気満々

>>771
Web屋限定じゃないけど、単に時代遅れになってるってことじゃないの？
テキストの読み書き検索なんかに特化していたため、
単純な一個の掲示板を作るのには便利だったけど、
スカラー、配列以上のデータ構造になるとリファレンスを勉強しないと使えない。
オブジェクト指向になると「blessって何?」みたいな無理矢理な増築でわけわかめになってる。

Pythonは良くも悪くも中庸だと思うよ
プログラミング言語、と呼ばれるほどガチガチでもなく
スクリプト言語、という言葉から連想するほどテキトーでもない

>775
PHPは言語として問題があってもWeb特化っていうアドバンテージがあるし
PythonはPerlとは全く別方向のスクリプトとして需要はあるだろう
Rubyが名前通りPerlの進化系として使えるから、Perlの需要って過去資源だけだと思うんだが

Rubyの場合、松本からしてPHPを叩きまくってるだろ。

Rubyは明らかにRailsのブームが終了したな。そもそもウェブの開発に時間がかかる部分は、言語機能でどうにかなるようなもんじゃない。

まあ、自由に言語を選択出来る場合なら、PHPを選ぶはずはない罠。PHPは話にならない。

Ruby鎮静化の責任の一旦は日本のユーザーにもあると思うけどな。
自国製の言語をまともに評価できず、海外に評価されて逆輸入の形でしか受けいれなかった。
結局、そうこうしてるうちにユーザー文化が十分に育まれず
十分勝機のあったPythonの侵食を許してしまった。

早く……しないと間に合わない系の話に釣られない民度の高さを評価すべき

ウェブは Python, ちょっとしたツールは Python, 性能要求が厳しれば Python という立ち位置

Web - PHP
適当 - Perl
速度 - C
綺麗ならよし - Python
好き勝手やれ - Ruby
お前の世界だ - Lisp
分散処理なら - Earlang
とりあえず新しい - D
Wolfram - Mathematica
俺は嫌い - Java
Javaとくっつきすぎな - Scala
なんか面白そうな - OpenCL
なんじゃそりゃ - white space

>>781
＞Rubyが名前通りPerlの進化系として使える
使えない。

がんばってなんとかそのように使う人も
いるだろうが、そんな人ばかりではない。

>>787
s/Python/Perl/g

RubyとPHPはちょっとキツいな。ｗ

Perlが普及してしまったのは歴史の誤ちだよなあ。
unixのシェルスクリプト強化版みたいなポジならよかったのに。
ウェブの普及がもう少し遅くてCGIの言語選択肢が広ければ、
いや他の言語がもう少し早く登場してくれていれば…と悔やまれてならない。

>ウェブの普及がもう少し遅くてCGIの言語選択肢が広ければ
>いや他の言語がもう少し早く登場してくれていれば

どっちも起こらなかったと思う
Perlが糞だったからこその展開

Webの発達にperlの発達がついていけなかった。
perlの発達を待つよりも、pythonやrubyに乗り換える方が早くて楽だった。

Pythonってそんなにいいかなあ？俺はRubyのが好み。
Google言語ということもあってそこそこ勉強したが、
オブジェクト指向やり始めると途端にに気持ち悪くなるから好きになれん。
ってか、一度Rubyistになった人なら、そうそうPythonに寝返ることはないと思った。

PHPなら普通に使うけどね。

>>786
日本人は釣られる時は世界屈指に釣られまくるよ。
世界よりも国益よりも善悪よりも、周囲の顔色が一番大事な民族性だから、
一旦周囲が特定の空気に包まれたら、その集団ヒステリーたるや物凄い。
一方、今はまだ周囲に無い世界の潮流とかの話になると、お互いに対する様子見で牽制しあって
なかなか動かない。
これを「釣られない」「民度の高さ」と表現すれば聞こえはいいけど、現代ではこの民族性は
国際競争における宿命的な負けフラグにもなってるな。

Pythonに寝返ったRubyistですが何か質問ありますか？

>>796
何千行、どんなコード書いた？

まじかーいｗ
まあ実は俺はPy=>Rubyなんだが。

Pythonのどういうところが好きで、Rubyのどういうところが嫌いか聞きたい。

ちょｗRubyの本買ってきた俺ボコボコの予感ｗｗｗ

書き始めはRubyが楽なんだけど
ある程度の長さになるとPythonで書こうかなって思うなぁ

Perlは使い道が思いつかない

Pythonはモジュールが書きやすいと思う。
でも、len()とかって未だ慣れないなぁ。

俺も変数名を打った後に「ああlen()か…」って思いながら←キーを数回叩く
Python的発想からすると戻り値が数値であることをlen()が保証してくれるってのは
素直に好きなんだけど、書く時には相変わらず慣れない

つttp://d.hatena.ne.jp/methane/20090702/1246556675

>>> s = 'python'
>>> len(s)
6
>>> s.__len__()
6
>>> 'python'.__len__()
6

つーか、Blenderとか3DソフトはやけにPython。

速度が求められてるからじゃないの

速度を重視するならLLは有り得ないと思う
単に拡張を取り入れる時点でpython以外に
十分に成熟している
扱いやすい
埋め込みが楽な言語
が無かっただけではないかなとか適当な事を言ってみる

Pythonは昔のTclのように拡張言語としても使われ出してるね。

それから、Webとの親和性が高いアプリの拡張には、JavaScriptなどのECMAScript系が多い印象がある。
EmacsがLispでどんどん拡張できたように、MozillaもJavaScriptで拡張できたりしてるし。

あと、RubyもJRubyとかIronRubyとかあるから、
実は同じようなことが簡単にできるんじゃないかと思う。

安定しているからだよ。
言語仕様も、埋め込みや拡張に使うCのAPIも、Pythonは
Rubyよりもバージョン間の互換性に気を遣っているし、
バージョン間で動作が異なる場合もできるだけ以降を支援する。

書くときの気持ちよさはRubyが上でも、書きやすさは大して差が無く、
読みやすさ・メンテのしやすさ・バージョンアップへの対応しやすさは
圧倒的にPythonが上だもん。
書くときの気持ちよさも、PythonがあえてRubyのような書き方を採用しない
合理主義を理解するとRubyがアホらしくなるし。

>>809
なんか、今までの中で一番納得

ウェブの発達って、何も変わってないジャン。HTTPもHTMLも10年前も今も変わってないんだから。
Ruby（=Rails）が一時期流行ったのは、Web2.0とかのしょうもないドットコムバブルの再来願望に乗っかっただけだろ。

なんもわかってないな

HTML ver5も出るし、何も変わってないわけじゃーないけどね
Ajaxもあるし、

HTML5だろうがXHTMLだろうが、サーバ側の言語から見れば何の違いもないから。Ajaxは最後のアウトプットがHTMLからJSONだとかXMLだとかに変わっただけ。

つまり、開発側も変わってるし
ユーザー側が見るものも変わってるって言ってるんだろそれ？

>>804
$ cat test01.py
class MyClass:
        def __len__(self):
                return 'Hello'
obj = MyClass()
print obj.__len__()
print len(obj)
$ python test01.py
Hello
Traceback (most recent call last):
  File "test02.py", line 6, in <module>
    print len(obj)
TypeError: __len__() should return an int

>>809
>書くときの気持ちよさはRubyが上でも、書きやすさは大して差が無く、
>読みやすさ・メンテのしやすさ・バージョンアップへの対応しやすさは
>圧倒的にPythonが上だもん。

そんなことないけどなあ。両方使った素直な感想として。
おまえ、Pythonしかろくに使ったことないだろ。

Pythonのほうが読みやすくてメンテのしやすいという具体的な例を出してみな。

Pythonを使ってる人にとって、Perlの亜流は不要という。

>>817
Pythonの方が、メソッドチェーンみたいな一行にゴチャゴチャ詰め込む文を
誰も使わない。a = b は必ず a に b を代入しているのでbが関数かどうか
調べなくて良い。名前空間が大事にされているので、何かの require したら
勝手に既存の型にメソッドが追加されてしかもそのメソッドがどのrequireから
持ち込まれたのか判らないって事がない。

Rubyでも判りやすく書けるとかじゃなくて、Pythonは判りやすく書く方法が
文化として定着しているため、ワザと読みにくくされていない限り誰のコード
でも読みやすい。

=> が嫌い

Rubyからすると self.__ のせいでどうしても長くなりがち
メソッドチェーンを使わないんじゃなくて長くなるので使えないと見えてしまう

最後の2行は、Rubyもそうだと思うが
「○○でも判りやすく書ける」なんて言葉、Perlでぐらいしか聞かない

おまいら、Lispを忘れてませんか？

LispはLispで需要があるからいいの。
新たなパラダイムが生まれても、自分で実装できるし

Lispはなんか別格だよね

別格はforth

Lispネタは前も出たけど、あまり盛り上がらなかった。

Lisp系言語が活用されてるのって、Emacs Lispくらいしか思いつかない。
Lisp製の有名アプリなんてとんと聞かないし。
あとは研究用の教材くらいかなあ。

AutoCAD を知らんのか

マイクロソフトのエイジオブエンパイアは
NPCの作成言語にlispを使っていたと思ったが

一方Civilization4はPythonを使った

・・・いやあれはまあUI絡みの部分が多いがな

LLがLispのLか

>>827
GIMPのAddinはLispでは？

単に 827 の無知でした (^-^)

まあ、応用例がしょぼいのは否めないが。
PHP -> ウェブデファクトスタンダード
Python -> Google 社内デフォルト
Ruby -> Ruby on Rails
Perl -> CGI の権威
Lisp -> AoE の NPC 作成言語

>>834
恥ずかしくないか？

むしろ俺の中でPerl/CGIは
Perlの印象もCGIの印象も悪くしたイメージしかない

I think so.

WebでのJavaScriptと同じ現象？

いや、どちらかというとラーメン屋に置いてある漫画本と同じ現象。

>>819
>Pythonの方が、メソッドチェーンみたいな一行にゴチャゴチャ詰め込む文を
>誰も使わない。
べつに1行でもいいんじゃない？読みやすければ。
Rubyは１行で書いても十分読みやすいよ。
それにPythonだって内包表記だっけ？あれ使って１行にごちゃごちゃ書いちゃうじゃん。

> a = b は必ず a に b を代入しているのでbが関数かどうか
>調べなくて良い。
これは意味分かんない。だれか解説して。

> 名前空間が大事にされているので、何かの require したら
>勝手に既存の型にメソッドが追加されてしかもそのメソッドがどのrequireから
>持ち込まれたのか判らないって事がない。
これは善し悪し。スタイルの違いだけ。
オープンクラスを思いっきり利用したほうが便利なことも多いことはRubyを使えばわかるんだけど、
それがわかってないみたいだからこいつはRubyをちょろっとかじっただけみたいだな。

>Rubyでも判りやすく書けるとかじゃなくて、Pythonは判りやすく書く方法が
>文化として定着しているため、ワザと読みにくくされていない限り誰のコード
>でも読みやすい。
べつにRubyでもほかの言語でも同じだと思うけど。なんでPythonだけが特別だと思うんだろう。

俺を怒らせたね？

>>840
おそらく自前で関数を書いたり他人の書いたスクリプトのメンテやったことないのかと
全部判ってるって状態での開発？そんな楽な職場あるんだったら就職したいわぁ

趣味でも仕事でも使える素敵な言語
それは
↓

C++

ウェブの場合、コンテンツが大事なんであって、どんな言語使おうとコンテンツに影響はないんだよな。
結局HTMLを吐くだけだから。
だから、PHPみたいな明らかなウンコ言語が一番普及してる。

RubyはPythonに比べて汚くて見づらいねって話だろ？そりゃそうだろ。

スタイルだけならアセンブラが一番キレイ

しかし、HTMLにコードを埋め込めるのが売りだったはずのPHPで、
それを全否定するかのようなフレームワークが主流になっているのが、どうしても理解できない。
テンプレートすらPHP的な書き方じゃないのが主流になってるし。
それなら結局Webでも言語関係無くない？と思うんだけど、PHP信者の意見を聞きたいわ。

>>845

「○○の場合、××が大事なんであって、どんな△△使おうと××に影響はないんだよな。」

これコピペパターンに登録しとくか。

>>848
言語的な扱いよりも環境作りやすい、移植しやすいとかそういう用途を優先してるんじゃね？

>>848
HTMLにPHPコード直書きだと
触れないって怒る自称Webクリエイターがいるから

だからプログラマーもそれじゃ触らせないよってことになって今の状態

>>848
MVC

>>849
詭弁のガイドラインですね

>>845 はいいこといってるんだけどなぁ

RubyとPythonで読みやすさ論争やっても宗教論争にしかならないけど、
言語仕様の安定性は普及度の違いにかなり影響してそうだな。
後は英語の一次情報充実度合いとか。

>>848
俺もフレワ開発してるが、ある程度の規模になると PHP のコード埋め込みなんか大して使えん
というかまず使わない。ほぼ <?php の中で echo だわ。無理に埋め込み式にすると
色んな言語触ってる奴はスタイル的に違和感覚えるしそれほどメリットがあるわけでもない。
テンプレートはある程度内容を制御できるのとキャッシュとか細かい機能があるから
結局はSmartyみたいなエンジン使う。だから言語機能としてPHPである必要はない。

それでもPHPを使うのは普及度が高くてデプロイに手間がかかることが少ない、
ウェブに特化した関数やらライブラリやらが充実しててそこそこ保守されてる、
そこそこ性能も悪くない、情報もそこそこある、
など積極的にというより無難さによるところが大きい。
欠陥は多いが、かといってわざわざ乗り換えるほどのスクリプト言語もない。

>>853
そうか？

> コンテンツが大事なんであって、どんな言語使おうとコンテンツに影響はない
と
> だから、PHPみたいな明らかなウンコ言語が一番普及

の間に何の論理的な繋がりもないぞ。
何が「だから、」なんだか。

>>849
登録してもいいと思うけど、それって単に物事の切り込み方としての定番であって、
成り立っていれば有効、成り立っていなければ無効、っていうごく普通の話だよ。

>>855
極端な話、Smartyを使うためにPHPを使うという逆転が起こってても不思議はないかもね。
他の言語のテンプレートエンジンって、露骨に不便なの多くね？

> コンテンツが大事なんであって、どんな言語使おうとコンテンツに影響はない
と
> だから、PHPみたいな明らかなウンコ言語が一番普及
は矛盾しないってことが言えるだけ

Web開発で何を選んでも同じだから、単価の安いPHPを使うってだけだな。

>>842
Rails使ってるけど、Railsなんて既存のクラスに大量のメソッドを追加している。
でもそれが便利だから、世界中のみんなが喜んで使ってるし、別に困ってない。

なんかPythonのやり方しか知らないやつが他の言語を批判してるだけじゃん。

コンテンツ云々の方々は>>1を100回読むべき

>ここでいう「軽さ」はプログラマの負担の軽重を指し、

>>861
大量に作って、大量に捨ててるんじゃないの？ >rails

Railsの互換性のなさは数年後、地獄を迎える

最初に書くのは楽でも、山ほどテストコード書かなきゃならないのなら、
プログラマの負担が軽いとは言えないのでは？

>>864
そのうち収束するんじゃないの？

>>865
Javaで書いたからってテストコードの量が減る訳でもないんじゃないか

PHPの関数名の節操の無さも限界越えてるけどな

実際に使ってる奴がいるからとかいう世俗的な話には興味ないな。
純粋に言語の仕様で戦って欲しい。

それが新しい言語の礎となる。

世俗的を排除すると、究極的には
0
とかでいいじゃん。0がすべて。0以外は必要ない。
この言語が出来ること、言語の目的は、0の存在を示すこと。

最近のアイちゃんは本当に賢いな

言語の進化って書き手が楽になるようにとか、保守性あげようとかでしょ？
何が必要なんでしょうね

>>827
>あとは研究用の教材くらいかなあ。
Maximaとか？

>>863,864
話をそらすな。
Pythonは名前空間を大事にしているけどRubyはそうじゃないからRubyよりPythonのほうが
優れている、という主張に対する反論なんだから、Railsの互換性の話とかは今は関係ないだろ。

もとの話はこれ↓
>>840
>> 名前空間が大事にされているので、何かの require したら
>>勝手に既存の型にメソッドが追加されてしかもそのメソッドがどのrequireから
>>持ち込まれたのか判らないって事がない。
>これは善し悪し。スタイルの違いだけ。
>オープンクラスを思いっきり利用したほうが便利なことも多いことはRubyを使えばわかるんだけど、
>それがわかってないみたいだからこいつはRubyをちょろっとかじっただけみたいだな。

で、これって結局どうなった？

>>840
>>Pythonの方が、メソッドチェーンみたいな一行にゴチャゴチャ詰め込む文を
>>誰も使わない。
>べつに1行でもいいんじゃない？読みやすければ。
>Rubyは１行で書いても十分読みやすいよ。
>それにPythonだって内包表記だっけ？あれ使って１行にごちゃごちゃ書いちゃうじゃん。

Pythonでも内包表記つかえばRubyみたいにごちゃごちゃして読みにくい？
それともPythonなら1行にごちゃごちゃかいてもRubyより読みやすい？

>オープンクラスを思いっきり利用したほうが便利なことも多いことはRubyを使えばわかるんだけど、
Railsの互換性の話とかは関係あるだろ

>>875
Pythonでは普通内包表記を使うことですっきり書き下せるときだけ
内包表記を使うから、複数の文に分けた方が判りやすい文を
ゴチャゴチャ詰め込んでるの見たこと無いよ。

Rubyは書くときの楽しさ、Pythonはすっきりさ重視。

┐(´д｀)┌

>>876
Python系のバージョン間の互換性を大切にする文化は、
名前空間を大事にしているから可能って部分あるよね。

urllib がダメになったら urllib2 作ったりw
で、Deprecation Warningを消せた人のみPy3kにアップグレード可能

Python++がほしいなあ。

Rubyってなんで楽しいの？

楽しくはないんだけど、
言語仕様の貧弱さを「楽しさ」という曖昧な要素で補うPR戦略を取ったところ、
いつのまにか既成事実化してしまい、それに乗せられたユーザーが残って共同幻想を形成している。
というのが最新の分析。

足りないものは自分で作れっていう死ね

Rubyは楽しくないと言うと
周囲に「分かっていないなぁ」と馬鹿にされるので
「楽しいです」と言ってます

>>884
Rubyの「楽しい楽しい詐欺」は非常に巧妙に日本人的なユーザー心理を突くんだよね。
周りがそういってるからなんとなく、みたいな。
10人Rubyが楽しいという人がいたら、そのうち8,9人は884みたいな人だと言ってもいい。
ある意味PR戦略としては高く評価できる。

>>840
Rubyのメソッドチェーンで読みにくいと思ったことはないんだけど、具体的に
どんなコードで読みにくいと思ったの？

おまいら
パイチョンの日本語処理はどんな具合ですか？

衆議院議員をめざしている人が、
本当のところどう思っているのか、
きいてみよう。
ttp://moderator.appspot.com/?hl=ja#16/e=9df89
"名前を連呼するだけの選挙宣伝カーを、「スパム認定」して禁止しませんか？"
Lambda  

Rubyは文字コードのマジックコメントが嫌だな。
Pythonは3.0からUTF-8になったのがいい。

>>889 大漁おめでとう

Perlをけなして、Rubyをほめるような
ヤツをオレは決して信用しない。

そいつは間違いなく排他的で狭量な
バカだからだ。

>>880
Objective-Pythonにするべき。

略して、「おっぱい」！！

oops!

>>884
>Rubyは楽しくないと言うと
>周囲に「分かっていないなぁ」と馬鹿にされるので
>「楽しいです」と言ってます

どんなものでも、できるようになれば楽しい。
おまいらの嫌いそうなスポーツも、運動できる人間にとっては楽しい。
大半の人間は勉強ができないから嫌いだけど、できるやつにとっては勉強すら楽しい。
Rubyも同じ。マスターしたら楽しいけど、>>884みたいなやつにとっては苦痛でしかないだろうな。

出来云々と好みは違うからなぁ
エリートの悩みとか知らんのか

スラスラ出来るけど楽しくないっていうのを
長年続けてると鬱になるらしいよ

プログラミングや言語の扱いよりも、
その結果が思い通りに動くが楽しい。
マラソンが楽しい人がいるのはわかるけど、
大抵の場合は、クルマや電車でさっさと楽しい目的地に行くことが重要だ。

RubyがPythonより楽しいとよく言われる理由が知りたいの。
短く書けるから？いっぱいimportしなくていいから？

楽しいか楽しくないかなんてのは理屈じゃねえんだよ

>>894
> どんなものでも、できるようになれば楽しい。
そんなことあるか。

思い浮かんだことをすぐ形に出来る
ストレスフリーのプログラミングってのは楽しいもんだ。

それを実現できるのは
コンパイル不要＝スクリプト
用途無制限＝汎用
洗練された文法＝現代的
ライブラリなどショートカット充実＝RubyかPython
などここで二つに絞り込まれるわけだが
Rubyの場合は更に規約主義による簡潔な記述が加わる。

結果としてRubyが最も楽しいプログラミング言語といわれる。

>>828
亀レスだけどAutoCADはlispで書いてあるのか?

>>901
> 結果としてRubyが最も楽しいプログラミング言語といわれる。
ナイスジョークだ。

要するにRubyとPythonの決定的な違いは
書いてて楽か（短かい記述）、読んでて楽か（スタイル統一）、ってことだな。
趣味プログラマとして楽しいのは前者だろう、ってことで。

わしゃ覚える時が楽しいが
頭のできの良い人の中はようわかりません
達人の域に達した人は何を楽しいと思うのかな

Rubyでもまあいいけど、何か人間関係で疲れるｗ
なのでPythonの方がいいｗ

>>89
> どんなものでも、できるようになれば楽しい。
えらい適当な話だし、もしこれをそのまま受け入れるとすると
Ruby信者がウリにしていることは1�_たりともRubyの特徴説明になってないなｗ

Rubyが汚くて読みづらいのはPerlから受け継がれてる。

たぶん、Rubyが冗長で多彩な記述を許しているのがあるのかなあと
意図的に構文を正規化しない
簡単な例「0から9までの値を出力する」でも、ざっと

(0 .. 9).each {|x| puts x }
(0 ... 10).each {|x| puts x }
10.times {|x| puts x }
0.upto(9) {|x| puts x }

・・・・まだある。よく知らんのだけど、
この辺はPythonの哲学と対立するんではないなかあ
上のレスを読んでいると、Pythonはコードの正規化（誰が書いても同じコード）に
重きを置いているように思われる

>>909
つーか、色々な書き方が出来るのはいいとしても、どれも美しく見えないな。

puts (0..9).to_a
puts *(0..9)

無理矢理1行に纏めたコードだからそもそも美しくはないだろうな
本当はその下にforで回すパターンもあるが
それはあんまりRubyっぽくないのと、1行にするにはちと長いというだけだろう
あとブロックの関係で意味も微妙に変わるから同じ文とは言えないし

for x in 0...10 do
　　puts x
end

むしろ 0..9 だけでいい

>>910
そりゃあ好みの問題だろう
RubyはRubyで、このメソッド呼び出しとブロック構文で豊かな世界を作ってる
だから、これはこれで統一された美しさがある

Lispも括弧ばっかりで美しくない
けど強力
rubyの売りはどこだ

頭の中に浮かんだ順番でだいたい書けるところ
PerlやPythonだと、書いて「戻る」とか、頭の中に「置く」とかしながら書くことが多くなる

Rubyは言語制作者の想定した範囲内で使う分には快適な言語だと思う

例えばブロック構文なんてのは
「高階関数は多くの場合高々1つの関数が渡せれば十分」
なんて決めつけが背後にある

それもあるだろうが、Rubyの場合はそもそも「関数」が少ないから
引数として渡すって形式だと辛いってのがある

>>906
I think so.

俺的に勝手にRPGゲームに例えると

Perl = Wizardry
PHP = Ultima
Python = World Of Warcraft
Ruby = ドラゴンクエスト
Tcl/Tk = Might and Magic

って感じです。
Lispは何だろうな・・・。

>>909
>Pythonはコードの正規化（誰が書いても同じコード）

残念だがそれは幻想だ

>>920
Lispは俺的にはElder Scrollだな。

どういう例えなのか解らんし
例え話ってどうとでも解釈できるから
すっげぇ不毛な水掛け論になりやすいと思うんだ

>>920
それがまじなら、俺はPythonを取る
Perlってそんなまぞいのか？…

「RPGゲーム」に突っ込まない優しさ

a = [1,2,3,4] で、 a.size でも a.length でも自由に使えるのがRuby
自分で作るクラスでも、 size だろうが length だろうが len だろうが自由に使える。

Pythonの場合、 len(a) としか書けないし、自分で作るクラスでも
.length じゃなくて .__len__ って書かないとバカにされる。

>>921
Pythonで書けば誰が書いても同じコードになるってのは幻想だけど、
同じプログラムの同レベルの書き方を増やすためだけに構文や組み込み関数を
増やしたりはしないよね。
内包表記みたいに、良く出る3行を1行にすっきりまとめられるなら新しい
構文を作る価値があるけど、 range(3,5) と 3...5 じゃぁ大して短くならないから
通常の関数の構文のみで対応できるrangeを選んで構文を拡張しないとか。

Rubyはこれが楽しいプログラミングなんだっていう作者の教条的な態度が肌に合わない。まさに宗教的。

print range(3, 5)
print ','.join(x for x in range(3, 5))

宗教的でない言語など聞いたことないが
宗教的でないことを宗教的信条とする言語はあるかもしれん

それはごもっともだけど、俺（Python）の考えは違った

LLスレでこんなこと言うのもなんだけど、動的型が為に実行時に型違いで
プログラムが停止するのが、プログラミング作業の中で一番ムカつく瞬間だと
思う。

実行時に停止するか
コンパイル時に停止するか
の違いだけだろw

コンパイルさえ通れば
型エラーで停止しないことを保証してくれる言語って
そんなに多くないような？

OCaml!

Rubyの3...5に相当するのはxrangeだと思うがな
3...5自体は配列を生成するワケでなく、Rangeのインスタンスを生成するだけだから
Perlの同様の構文に相当するのはrangeかな？

>>915
>>827の2行目以降に反論してくれないか？

以外に知らない人が多いってことか
とりあえず、common lispのwikiでも読んでみればいいんでない

>>938
さすがLISPだ。有名アプリがひとつもない。こういうニッチなところで使われてこそLISPの真骨頂だ。
>>822の”研究用の教材くらいかなあ”は見事に言い当てている。

>>939
MITにOSをschemeで書いたコンピュータがあると昔ストールマンに聞いた事があるよ。

LispはCPUのリソース食いまくりの言語だけど,BSDに仮想記憶が導入されたのもLispのおかげだし
結構使いやすい言語ですよ。

>>939
頭が固くてLISPを使いこなせないので使われてないと思いたいんですね
わかります

情報学方面だとLisp大好きな人結構いるよねえ。

うちの教授なんてマインドストーム上でLisp実装したとかいって大喜びしてたし。
未踏ソフトウェアの補助金受けてまでやることかとは思うけど。

それをマッカーシーに見せたら氏の方が更に喜んだとかなんとか．

>>940
> MITにOSをschemeで書いたコンピュータがあると昔ストールマンに聞いた事があるよ。
ものすごく遅そそうなOSだ。
>
> LispはCPUのリソース食いまくりの言語だけど,BSDに仮想記憶が導入されたのもLispのおかげだし
それLISPの欠点だけど。

> 結構使いやすい言語ですよ。
ruby信者がrubyは使いやすいと言う程度には信用します。

>>941
証拠に基づいてレスをお願いします。

>>942
> うちの教授なんてマインドストーム上でLisp実装したとかいって大喜びしてたし。
Lispの良さは実はそこなんだと思う。実装するのが楽しいのだ。だからemacs-Lispや
autoLispがある。どちらもCで書かれていると思うのだが間違っている？

勘違い上から目線ﾜﾛﾀ
君が理解できなくても君の損であって誰も困らんよｗ

本当にRubyユーザはキモいですね

Cで書かれていると思うのだが間違っている？

Common Lispの場合、仕様にコンパイラが入ってるので
処理系の実装言語が何であるかは重要ではないような
しかも下手な言語より速い

perlのideは何がありますか

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　 　　　おっぱい！おっぱい！

>>947
Lispがそんなにいいものなら処理系もLispで書いてしかるべき。
common lispはコンパイラがあるのならcommon lisp処理系はcommon lispで
書かれていると思うのだがどうだろう。そのとおりなら間違いを認める。

シェアの話をしたければPHPの話でもしてればいいのに。

ゲップが出るけど。

>>950
書かれているよ。処理系にもよるけど。
LispじゃないけどGaucheはCみたいだね。

ある処理系を記述するのに最適な言語はその言語自身とは限らないんだがなあ

つったってCommon Lispの処理系はいっぱいあるしなー

>>953
だれもそんな話してない

> Lispがそんなにいいものなら処理系もLispで書いてしかるべき。

俺は仕事では手続き型しか使ってないし、Lisp系はSchemeしか知らないけど、
技術者としての楽しみが詰まってる言語だと思う。

実際の仕事で使うかどうかは別として、Lisp系を楽しいと思えない奴は技術者に向いていないと思う。

人工知能＝Lisp

ゲームとシミュレーション以外の分野で使える言語が大方のニーズです。
まあ>>957の言うとおり、遊びで使える言語があるってのは楽しいだろうけど。

WikipediaのLispマシンの項目が充実していて吹いた。

梅の季節

>>943
AutoCadはCommon-Lispで書かれてるよ。
それにLispの処理系はOSがらみ以外の部分は結構Lispで書かれてるよ。
SchemeはMITでは公式言語と言って良い程使われてるし
Lispが使われてないという根拠は何なの？
証拠に基づいてレスしてもらえる？

処理系をその言語だけで書けるなんてアッセンブラー以外にあるのかねぇ？

つーか、鶏が先か卵が先かみたいに、
新しい言語をその言語自体で実装するってできるん？

>>964
そりゃ、理屈から言えば可能。
ただし言語による、としかいえんわな。
実装言語の制約によるだけじゃないかと。

>>962
MITはPythonにスイッチしたとかなんとか

ブートストラッピングできないコンパイル言語は、
評価にも値しないと言われた事もあったな。

>>964
よくあるブートストラップだよ。
1. その言語のインタプリタを別言語で作る。
2. インタプリタ上でその言語のコンパイラを作る。
3. インタプリタ上のコンパイラで、コンパイラ自身をネイティブ・コンパイル。
4. 以降はネイティブ・コンパイラで開発。

>>968
実例は、c-front(C++の前身）だね

で、お前らPHP使ってどんな糞な仕事してんの？

1. その言語の仮コンパイラを別言語で作る。
2. 仮コンパイラで、コンパイラ自身をネイティブ・コンパイル。
3. 以降はネイティブ・コンパイラで開発。

ブートストラッピングってどこまで処理系を書ければおkなん？
CでもI/Oまわりはライブラリーを使わなければ不可能だし
gccは算術演算回りはアッセンブラーで組んであったと思うよ

>>966
それは授業のテーマがロボティクスに変わったから。

>>972
結局どんな言語でも、少しはアセンブラが必要だし、
コンパイラでなければ、完全なブートストラップは不可能。

理論的には、インタプリタからコンパイラを合成することはできるし、
PyPyではできているけど、PyPyを実用で使ってる例ってある？

>>962
> AutoCadはCommon-Lispで書かれてるよ。
俺が無智だった。ひとつだけでもメジャーなので使われてて良かったな。

> それにLispの処理系はOSがらみ以外の部分は結構Lispで書かれてるよ。
Liso支持者はあらゆるところでLispが使われている（または最強）と言うもんだ。
そんなに奥ゆかしくていいのか？

> Lispが使われてないという根拠は何なの？
いくらLispでもFORTRAN程度には使われているだろう。使われてないとまでは言っていない。

> 証拠に基づいてレスしてもらえる？
俺がそうレスした相手は断定していたが俺は断定していないからそのかえしは当たらない。


Lispの話題はLispの衰退に反比例して盛り上がる。Liso支持者はこれからも頑張ってほしい。

>>962
今のAutoCadはc/c++実装だと聞いた気がするが。
Lispが残っているのはマクロだけらしい。

>>975
>俺が無智だった。ひとつだけでもメジャーなので使われてて良かったな。

Emacsについても思い出してあげてください。

次スレ

【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1248487404/

時々、Yahoo Storeは今でもLispを使っているのかと聞かれる。
答えはイエスだ。Lispコードはそっくりそのまま、まだある。
Yahooはサーバー側のソフトウェアを、エリック・レイモンドが
薦めた5つの言語全てを使って書いている。

>>977
EmacsはCで書いてある。マクロはlispで書いてあるので両者の境界は知らない。

>>975
お前 態度の割に無知だな

>>976が事実なら無知は>>962のほうだが。>>981も無知だけど。

いや 断然975だろ 無知なのはな
書き込みが馬鹿丸出しで内容が全然無い
プログラムをした事無いというより能力がないから言語を使いこなせない
というのが見え見えだろ
違うというなら自分で書いたプログラムをUPしてみ
見栄はってコピペしたらいかんよ

>>980
EmacsのCで書かれてるのは基本的なUIとLispの評価器だけ。
ほとんどの機能はEmacs Lispで実装されてる

>>983
おまえがやれよ。おれはたまに2chでないところでは発表してるから。
2chでさらせなんてバカじゃないか?

なんか975=982=985って人材派遣会社の営業っぽくね？
客先と話ができるように必死で勉強したけど全然的外れって感じだな
またグダグダ言って自分の無能さをさらけだしてるし
ちなみに馬鹿はお前な

>>985
見栄張るな ボケ！

CADはわりかしLispで書かれてると聞いたがなぁ
とくにアートワーク用のCADについてるルーターなんて限りなくLispでコーディング
するのにに適してるように思う
最近のパソコンはCPUパワーやメモリー容量がやたら増えたから
スクリプト言語やLispやJavaみたいにリソース食いまくり言語が実用面でも使えるように
なったんだろうな

Mozillaが主要コンポーネントだけCで書いて、
UIなんかはXMLとJavaScriptで書いてるのと通じるところがあるな。
Mozillaは現代版Emacsなのかもしれん。

>>986
素晴らしい想像力に感服した。

人材派遣会社の営業が客先とLispの話をするなんて。

人材派遣会社の営業　"うちはLispのエキスパートを揃えています"。
客先　　　　　　　　"Lisp？　なにそれ　うまいもの？"

おれにはこんな場面しか思い浮かばない。

Lisp最強なんていってないが、強力だとはいったな。

このスレと次ぎスレ読むと、
Lisp=かまってちゃん
ってことが良くわかった。

>>990
想像力がないとアルゴリズムを考える時に苦労しない？

>>992
俺にはお前がかまってちゃんに見えるよ。

この中だったら、Pythonが一番Lispに近いか？

DSLを作るって意味じゃRubyかな
関数型って意味じゃPythonだけどそれってLispっぽさとはちょっと外れてるかも

PythonってLispのマクロみたいにプログラムを作るコードを書けたりする？

>>994
あえて言えばPythonはScheme、RubyはCommon Lispかなあ

>>993
> 想像力がないとアルゴリズムを考える時に苦労しない？
人材派遣会社の営業が客先とLispの話をするところを想像できないと苦労するって
どんなアルゴリズムだよ。

1000ならLisp大勝利

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。