06/06/17 08:44:44
数型言語が注目されている。
Ｌｉｓｐはマクロ使用できプログラミング言語をプログラムしやすく、プログラムが非常にはやくかけるといわれる。
またクロージャも利用しやすい。
さて、ここで実際以下の２つのアプリを実際作るとなった場合、LispとC/C++ではどんなメリット、デメリットがあるだろうか。
（１）Ｗｅｂサイトの実装：ＣＧＩアプリケーションを作る場合
（２）クライアント用ブラウザ：Windows環境などのＧＵＩをともなうクライアントアプリケーションを作ろうとした場合。
2:デフォルトの名無しさん
06/06/17 08:47:02
>>1
ライブラリの充実度は確実にC/C++に分があると思う。
3:デフォルトの名無しさん
06/06/17 08:59:41
Lispがコンパイル言語であるという認識が俺にない
4:デフォルトの名無しさん
06/06/17 09:04:45
1の文章の校正
--------------------------
関数型言語が注目されている。
Lispはマクロを使用でき、プログラミング言語をプログラムするということが簡単にできる。
また、マクロを駆使すれば、プログラムが非常にはやくかけるといわれる。クロージャも利用しやすい。
では、下の２つのアプリを実際作るとなった場合、LispとC/C++ではどんなメリット、デメリットがあるだろうか。
（１）Ｗｅｂサイトの実装：ＣＧＩアプリケーションを作る場合
（２）クライアント用ブラウザ：Windows環境などのＧＵＩをともなうクライアントアプリケーションを作ろうとした場合。
5:デフォルトの名無しさん
06/06/17 09:08:28
商用のlispコンパイラを使うとすれば
（１）(Java,Perl,Ruby)>>>Lisp>C/C++
（２）C/C++=java>>Perl,Ruby>lisp
6:デフォルトの名無しさん
06/06/17 09:28:05
CGIだろ？つまりシェルを逐一叩いて使うわけだ。
C++でクラス作っちまえば終わりだからCGIはC++に分がある
ここらへんはJavaのServletを参考に作ればいいだけだしな
Cにまで掘り下げるとLispとどっこいだろ
GUIだろうが同じ、OOP至上主義は当面安泰
7:デフォルトの名無しさん
06/06/17 09:30:28
と思ったが、CGIに関しては構造体レベルで十分だからCでもいいじゃんｗ
8:デフォルトの名無しさん
06/06/17 09:51:13
>>5
クライアントアプリケーションでJavaはそんなに良くないと俺は思うけど。
9:デフォルトの名無しさん
06/06/17 09:57:46
>>6
CGIだろ？つまりシェルを逐一叩いて使うわけだ。
lispはマクロ使えば開発効率が相当よくなるからCGIはlispに分がある
GUIだろうが商用lispライブラリ使えば同じ、関数型言語は最強
10:デフォルトの名無しさん
06/06/17 10:00:44
>マクロ使えば開発効率が相当よくなるから
ならないよ、暗号化が加速するだけ
11:デフォルトの名無しさん
06/06/17 10:15:11
>>10
暗号化といえば継承
12:デフォルトの名無しさん
06/06/19 14:12:50
保守要員の確保の容易さにおいてLispは完敗。関数型言語は絶望的。
13:デフォルトの名無しさん
06/06/20 01:41:57
Lisp なら DSL を書いて終わりだな。
>>1
Lisp は関数型言語というよりも C++ と同じマルチパラダイム言語だよ。
オブジェクト指向も標準装備だし、手続き型的にも書ける。
Erlang や Clean なら分かるけど。
14:デフォルトの名無しさん
06/09/25 09:51:35
実用比較 C/C++ ＞＞＞（越えられない壁）＞＞＞ Lisp
Lisp使っててまともなソフトは、俺の中で、emacsや、xyzzyくらいしかない。
それも、Lispを搭載しているだけで、Lispで作られているわけではないあたり、
Lispのそこが知れる。
15:デフォルトの名無しさん
06/09/25 10:58:55
Lisp厨、晒し上げ
16:デフォルトの名無しさん
06/09/25 22:04:12
>>1
サーバープロセスがずっと上がってるてのがLispの長所なのに
CGI作ってどうするｗ
せめてCGIじゃなくWebアプリケーションと書いて欲しかった。
>>14
emacsちゃんと使ったことあるのか？？
17:デフォルトの名無しさん
06/09/26 02:25:33
>>16
emacsはクソいいたいのですね。
そんなことはないと思います
18:デフォルトの名無しさん
06/09/26 03:19:09
>>14
>Lispのそこが知れる。
残念ながら君のそこが知れたようだ。
19:デフォルトの名無しさん
06/09/26 12:56:20
>>18
実際の例を挙げもせずに、人格攻撃ですか？ププ
2cｈネラーらしいですね。
20:デフォルトの名無しさん
06/09/26 17:36:01
xyzzyは兎も角、emacsは殆どlispで実装されていると言っても過言ではない。
#X版? なんのことやらw
21:デフォルトの名無しさん
06/09/27 06:52:49
>>19
> 実際の例を挙げもせずに、人格攻撃ですか？
いいえ。例は挙がっていますし人格攻撃などではありません。
従ってあなたのこのレスは「何も言い返せなくて狂った」ということになりますね。
> 2cｈネラーらしいですね。
大嘘でしか反論できないあたり、良い自己紹介になりましたね。
22:デフォルトの名無しさん
06/10/10 23:07:43
lambda age
23:デフォルトの名無しさん
06/10/12 17:08:11
lisp で作られた商用アプリって Autocad とか Povray とかだっけ？違う？
24:デフォルトの名無しさん
06/10/13 19:35:16
25:デフォルトの名無しさん
06/10/14 02:14:52
結 論
「現時点」では、「実用的な」アプリケーションを作成する場合、C/C++>>>>lispである。
26:デフォルトの名無しさん
06/10/14 02:28:20
Lisp は Xlib を使わずに X protocol を喋る事の出来る数少ない言語の一つ。
27:デフォルトの名無しさん
06/10/15 01:10:12
最近はｱﾚだ、Cでもようやくhtmlテンプレートエンジンがでてきたようだし。
圧倒的な動作コストの低さでC/cgi盛り返すかな？
URLﾘﾝｸ(www.clearsilver.net)
28:デフォルトの名無しさん
06/10/15 21:53:12
用途次第だろ。
応答速度のチューニングならサーブレットにすればいいし、
手軽にかければそれでいい状況ならLispでいい。
CでCGIってのは中途半端な状況だな。
実行効率が大して必要でないならCよりはLispの方がCGI向きだとは思う。
CGIって文字列操作が多いと思うが、Cだとそれが面倒でかなわん。せめてC++で。
29:デフォルトの名無しさん
06/10/17 00:05:39
いいや、LISPこそが実行効率を必要とする現場で発揮される言語だい！
なんつって
30:デフォルトの名無しさん
06/12/02 22:40:35
OrbitzがLISPで書かれている
31:デフォルトの名無しさん
06/12/04 13:21:35
CGIっていうか、LispってAPサーバあるじゃん。
32:デフォルトの名無しさん
06/12/23 19:40:34
C++でもテンプレートを駆使すれば関数型プログラミングもなんとかできるのでは？
マクロはLispにかなわないだろうがプリプロセッサとテンプレート飲めたプログラミングで頑張って。
33:デフォルトの名無しさん
07/02/16 01:33:37
このスレにKahuaが一切出てこないのはなぜですか
34:デフォルトの名無しさん
07/02/16 08:15:13
そこに山があるからです
35:デフォルトの名無しさん
07/02/17 22:35:30
haskelと比べるとどうなの？
36:デフォルトの名無しさん
07/02/18 04:16:34
現在主流な LISP は静的型じゃない、デフォルトの評価規則が遅延評価じゃない、純粋関数型じゃない。
最強厨とか理論厨とか言語比較厨なら間違いなく Haskell を選ぶべき。
37:デフォルトの名無しさん
07/02/20 20:59:24
Lispは記述力は高いけど
実行速度とのバランスも考えるときにはhaskell
という理解でいいのでしょうか？
38:デフォルトの名無しさん
07/02/20 21:45:07
>>37
よくない
39:デフォルトの名無しさん
07/02/21 00:58:16
>>37 Haskell 使いたいなら Haskell 使ったほうがいいよ…
チューニングの仕方とかが全然違うし。「どっちか」を選ぶなら Haskell でいいだろ。
Lisp やるなら両方やっといたほうがいいけど。つか、なんで比べたがるんだ？
40:デフォルトの名無しさん
07/02/21 04:18:45
>>37
ていうかLispは速いよ。
ネイティブ吐く処理系使えば、C/C++よりちょっと遅い程度。
41:デフォルトの名無しさん
07/06/10 14:25:41
普通に書く効率
LISP＞＞＞＞＞＞＞＞＞＞Haskell
結論
HaskellにはHaskell脳(遅延評価脳)が必要。
一般人は無理。
42:デフォルトの名無しさん
07/07/04 17:00:06
>>41
っていうか数学科とかに入るような人のうち脳内でｎ次元ベクトルの状態をグリグリ動かせる様な人ならHaskell得意だろうな。
そういう人を何人かしってるけど、俺には想像もできないよ。
43:デフォルトの名無しさん
07/07/06 02:36:06
>>36
でも言語比較厨とかの間でもLispは人気あるぞ
そういう奴は、Lispのソースコード＝リストであるところに
惹かれてるわけで、Haskellはむしろ嫌いである可能性すらある
最強厨とか理論厨とか言語比較厨でも「HaskellよりLisp」派は間違いなくいる
44:デフォルトの名無しさん
07/07/17 23:37:27
>>23
ちなみにAutoCADはかなり前にC++化されてる。
今でもLisp使って拡張できるけど、推奨ではないです。
45:デフォルトの名無しさん
07/11/07 13:55:51
内心楽しみなMSの関数型言語 F#
URLﾘﾝｸ(www.itmedia.co.jp)
・狭い市場を狙う
・VB C# の後釜じゃないよ
・関数族は孤立してる←ｗｗｗ
実際、どこまで実用なのか。
はたまたベーパーウェアに終わるか？
46:デフォルトの名無しさん
07/11/08 01:01:54
何つう今更な話題…
47:デフォルトの名無しさん
07/11/10 06:36:11
【.NET】F#について語れ【OCAML】
ｽﾚﾘﾝｸ(tech板)
48:デフォルトの名無しさん
08/01/04 17:06:38
あれだよね。newlispとか便利だよね。
49:デフォルトの名無しさん
08/02/08 20:57:31
ＬＩＳＰには変わったマクロあって埋め込み言語実装が簡単だけど
Haskellにはあるのかな？
50:デフォルトの名無しさん
08/02/08 22:48:34
>>49
「変わったマクロ」ですと？？？
あの程度書けなきゃマクロって言わんちゃいますか？
51:デフォルトの名無しさん
08/04/22 14:07:28
>>41
慣れたらhaskelの方がlispよりも速い場合ってあるの？
52:デフォルトの名無しさん
08/04/22 22:33:40
>>51
ある。
「慣れることが出来ない」という事実に目をつぶれば。
53:多色グリグリ＝ＬＩＳＰワカンネ派？
08/06/11 10:37:40
印欧語族母語話者が考え方を自然に書くとＬＩＳＰみたいになる。
ＵＴＦ‐８で組むＸＭＬ書式はＬＩＳＰのカッコの対応を明示しただけ。
ＵＴＦ‐８コード環境は日本語「だけ」が苦手→はぶられる(ｵﾜﾀ
こうですか＞＜ ワカリマセン（＝間違い）…だといいな？
54:デフォルトの名無しさん
08/06/15 20:28:52
頭大丈夫？
55:デフォルトの名無しさん
08/06/16 01:55:46
ｽﾚﾘﾝｸ(tech板:860番)
これを書いた人だから。
56:デフォルトの名無しさん
08/06/18 00:55:30
あっちこちで見かけるよね。「印欧語族母語話者」はNGワード推奨？
57:デフォルトの名無しさん
08/07/04 20:05:27
Lispが欧米の自然言語に近いとかはウソだな。
set b to a
が
(setq a b)
だもん。
単に
コマンド 引数 ...
で引数にコマンド 引数 ...が入れられるようにしただけじゃん。
58:デフォルトの名無しさん
08/07/11 23:35:40
>>57
それではリストを正確に表していない。
59:デフォルトの名無しさん
08/07/29 23:30:34
値の代入？のような処理はどっちも自然言語と違うと思うけど。
ただlispで値を比較したい場合
( s == o)
という風にSVOで書けないからちょっとだけ見にくい感じはするな。
まあオペレータオーバーロード出来ない言語だと、特定の型以外は
関数で比較とか混在するので似たようなもんか。
ところでlispのどういうとこが自然言語に近いの？
60:デフォルトの名無しさん
08/08/16 15:43:56
今までプログラミング言語が自然言語と近いかどうかなんて気にしたこと無かったなあ。
プログラミング言語にそんなこと求めたこと無いし・・・
何でそういうことを気にする人がいるのか興味があるなあ。
61:デフォルトの名無しさん
09/02/10 07:33:42
自然言語に近いとかはどうでもいいよな。
そんな事言ってたら再帰とかどうすんだよとw
lispは人間が機械をサポートしなきゃいけないのが面倒で嫌だったなぁ
コードそのものがS式ですとか言ってみても、言い換えれば人間がそうなるように頑張ってるわけで・・
62:デフォルトの名無しさん
09/02/11 01:39:12
頑張るってのは方向を間違えてないか？プログラムを書くプログラムを書くのが目的に最適化されてるの。
そこを履き違えたならたしかにS式は一方的に人間が機械に譲歩してるだけに見えるだろう。
実際には人間が機械に半分歩みよると同時に、機械を半分人間に歩み寄らせてるんだよ。
63:デフォルトの名無しさん
09/02/11 10:09:45
一般人から見たら、S式もアルゴル系の手続き言語(代表的なC言語でもいいや)も
大してかわらん。
義務教育で教えて概念が入っていればそっちが学びやすい分、
四則演算がそのままかける、手続き言語に軍配があがるかもしれんが
64:デフォルトの名無しさん
09/02/11 11:13:38
なまじ四則演算がそのまま書けるせいで、
x = x + 1
を等式だと思って混乱するっていう落とし穴もあるし。
65:デフォルトの名無しさん
09/02/11 11:42:42
副作用のない関数言語なら大丈夫。ってか、そんなん書けない。
66:デフォルトの名無しさん
09/02/11 13:12:27
代入が等式に見えるという悪癖はFortran以来（COBOLは知らん）
BASICやCも引き継いでいる、人気のある言語ほど採用しやがる仕様
なんだよな。
67:デフォルトの名無しさん
09/02/11 13:30:56
>>62
現実には仕様上無理だとしても
S式を壊して記述しても機械がサポートできるということにすれば
よくある後半の）の山はほとんど消せるよなw
(+ 1 2)も + 1 2でいいことになる。
もっといえば 1 + 2でもいい。
そりゃすでにS式じゃねーだろというかもしれないがその通り。
S式に依存して書かなければならないという仕様は人間が負担し、担保してるし省略形（あるいは省力形といっても・・）で簡素に書く事が出来ない。
結果的に可読性が悪くなる最大の要因と化しているのも事実だと思うよ。
だからといって技術的にどうにかできるものじゃないから
「仕様です」で終わりだけどw
まあ・・この辺がスマートに解決される魔法があったらBASICが使われる事もなかったんじゃないかとさえ思う今日この頃。
68:デフォルトの名無しさん
09/02/11 20:32:39
Lisp と C で括弧の数が大きく違うのは、演算子周りくらいじゃないかな。
普通の関数呼び出しとか、 if や for みたいな制御構造とかには、 C だって括弧が要る。
演算子が大量に連なった式でもない限り、 Lisp で閉じ括弧が山ほど続くようなコードは、 C で書いても同じくらいの閉じ括弧が続くと思う。
+ 1 2 みたいに書く場合、式と式を区切る手段が必要になる。
その一行だけを評価するならそれでいいんだけど、実際のプログラムってもっとたくさんの式でできてるよね。
式が入れ子になってるようなのも普通だし。
で、特に入れ子になった式を書く場合、どこからどこまでが一つの部分式かを明示しないといけないんで、括弧で括るような記法が便利。
S 式って別に可読性悪くないと思うんだけどね。
69:デフォルトの名無しさん
09/02/11 21:32:10
>>68
>C で書いても同じくらいの閉じ括弧が続くと思う
いやーそれはないない
そんなコード見た事無いわ
括弧の数カウントして同じように並べたらって話ならまだ別だけど
それ自体意味はないし・・
70:デフォルトの名無しさん
09/02/11 22:35:18
S式の閉じ括弧の連続は、それなりのエディタを使わないと面倒だと思う。
というか、メモ帳→Vimと移ってそこがすごい便利だと思った。
71:デフォルトの名無しさん
09/02/11 22:38:48
>>68
たいしたことないLispのコードでもケツに7,8個カッコが付くなんて普通にあるから、真ん中あたりの閉じカッコがどこに対応してるんだなんて見たってわかりゃしないよね。
エディタの支援機能がないとあんまり触りたくはない・・かな。
Cだと文化違うけど、カッコを２種類使えるのとindentの関係でブロック構造は視認しやすいってのはある。
ま、ブロック構造だけはw
Lispでも同じようにやりゃいいじゃないかってのもあるけど
Lisperになるほどそうしないからね、人のコード見るときは結構うんざり気味になる・・
72:デフォルトの名無しさん
09/02/11 23:24:05
俺だってそもそもワンライナー以外のプログマムをエディタなしに編集したくはねーよ。Lispに限らずね。
俺はLispでインデントしか見ないので、Cっぽく括弧だけの行があるコードをみるとうんざりするよ。
73:デフォルトの名無しさん
09/02/11 23:54:57
俺もLispの制御構造はインデントでしか見ない。
インデントが崩れていても、emacsならコマンド一発で自動整形できるし
あの括弧のおかげで、自動整形の精度も高いんだぜ。
74:デフォルトの名無しさん
09/02/12 00:26:17
同じくインデント任せ。
ぶっちゃけ Emacs 以外の環境でまともに読み書きできる自信はない。
75:デフォルトの名無しさん
09/02/12 08:05:33
・閉じ括弧は基本的に見る対象ではない
・主にインデントを見る
この2点があるから、Lispには閉じ括弧をまとめる慣習があるわけだよね。
見る対象ではないから、出来るだけ小さく存在していたほうが良いし、
閉じ括弧に一行与えると、縦がスカスカになって、目でインデントをなぞりにくい。
76:デフォルトの名無しさん
09/02/12 12:21:20
>>75
>この2点があるから、Lispには閉じ括弧をまとめる慣習があるわけだよね。
必ずしもそうとは言えないぞ
インデントは意識されてても１行に詰め込み杉で
インデントの意味がないコードも多いし。
閉じ括弧まとめるのは慣習的な意味合い強いよ。
77:デフォルトの名無しさん
09/02/12 22:42:13
>>76
少なくともLisperの間でコンセンサスは取られている。
フレームだらけのLisper同士の喧嘩でもインデントに関するものはほとんどない。
タブ幅に関する個人的な考察だの括弧の配置に関する俺理論とかうんざりなんだよね。
一行につめこみ杉だったら、改行入れて整形するだけであとは>>75の主張の通りだよ。
78:デフォルトの名無しさん
09/02/13 12:26:03
CLとSchemeが誕生した前後は、エディタは、edとか、使っていたのかな？
79:デフォルトの名無しさん
09/02/13 12:43:24
>>77
>少なくともLisperの間でコンセンサスは取られている。
それはないよ。
80:デフォルトの名無しさん
09/02/13 18:07:49
>>78
TECOじゃね？
81:デフォルトの名無しさん
09/02/14 09:10:46
そういえばスーパー閉じ括弧ってどうなったんだろう？
82:デフォルトの名無しさん
09/02/14 13:36:44
shcemeでは[]だって使えるんだぜ。
83:デフォルトの名無しさん
09/02/14 13:37:39
cとhが逆だったよ。よめねえよ。