【ＣＧＩ】実用比較Lisp vs C/C++【ＧＵＩ】

数型言語が注目されている。
Ｌｉｓｐはマクロ使用できプログラミング言語をプログラムしやすく、プログラムが非常にはやくかけるといわれる。
またクロージャも利用しやすい。

さて、ここで実際以下の２つのアプリを実際作るとなった場合、LispとC/C++ではどんなメリット、デメリットがあるだろうか。

（１）Ｗｅｂサイトの実装：ＣＧＩアプリケーションを作る場合
（２）クライアント用ブラウザ：Windows環境などのＧＵＩをともなうクライアントアプリケーションを作ろうとした場合。

>>1
ライブラリの充実度は確実にC/C++に分があると思う。

Lispがコンパイル言語であるという認識が俺にない

1の文章の校正
--------------------------
関数型言語が注目されている。
Lispはマクロを使用でき、プログラミング言語をプログラムするということが簡単にできる。
また、マクロを駆使すれば、プログラムが非常にはやくかけるといわれる。クロージャも利用しやすい。

では、下の２つのアプリを実際作るとなった場合、LispとC/C++ではどんなメリット、デメリットがあるだろうか。

（１）Ｗｅｂサイトの実装：ＣＧＩアプリケーションを作る場合
（２）クライアント用ブラウザ：Windows環境などのＧＵＩをともなうクライアントアプリケーションを作ろうとした場合。

商用のlispコンパイラを使うとすれば
（１）(Java,Perl,Ruby)>>>Lisp>C/C++
（２）C/C++=java>>Perl,Ruby>lisp

CGIだろ？つまりシェルを逐一叩いて使うわけだ。
C++でクラス作っちまえば終わりだからCGIはC++に分がある
ここらへんはJavaのServletを参考に作ればいいだけだしな
Cにまで掘り下げるとLispとどっこいだろ

GUIだろうが同じ、OOP至上主義は当面安泰

と思ったが、CGIに関しては構造体レベルで十分だからCでもいいじゃんｗ

>>5
クライアントアプリケーションでJavaはそんなに良くないと俺は思うけど。

>>6
CGIだろ？つまりシェルを逐一叩いて使うわけだ。
lispはマクロ使えば開発効率が相当よくなるからCGIはlispに分がある

GUIだろうが商用lispライブラリ使えば同じ、関数型言語は最強

>マクロ使えば開発効率が相当よくなるから
ならないよ、暗号化が加速するだけ

>>10
暗号化といえば継承

保守要員の確保の容易さにおいてLispは完敗。関数型言語は絶望的。

Lisp なら DSL を書いて終わりだな。

>>1
Lisp は関数型言語というよりも C++ と同じマルチパラダイム言語だよ。
オブジェクト指向も標準装備だし、手続き型的にも書ける。
Erlang や Clean なら分かるけど。

実用比較　C/C++ ＞＞＞（越えられない壁）＞＞＞ Lisp

Lisp使っててまともなソフトは、俺の中で、emacsや、xyzzyくらいしかない。
それも、Lispを搭載しているだけで、Lispで作られているわけではないあたり、
Lispのそこが知れる。

Lisp厨、晒し上げ

>>1
サーバープロセスがずっと上がってるてのがLispの長所なのに
CGI作ってどうするｗ
せめてCGIじゃなくWebアプリケーションと書いて欲しかった。
>>14
emacsちゃんと使ったことあるのか？？

>>16
emacsはクソいいたいのですね。
そんなことはないと思います

>>14
>Lispのそこが知れる。

残念ながら君のそこが知れたようだ。

>>18
実際の例を挙げもせずに、人格攻撃ですか？ププ
2cｈネラーらしいですね。

xyzzyは兎も角、emacsは殆どlispで実装されていると言っても過言ではない。
#X版? なんのことやらw

>>19
> 実際の例を挙げもせずに、人格攻撃ですか？
いいえ。例は挙がっていますし人格攻撃などではありません。
従ってあなたのこのレスは「何も言い返せなくて狂った」ということになりますね。

> 2cｈネラーらしいですね。
大嘘でしか反論できないあたり、良い自己紹介になりましたね。

lambda age

lisp で作られた商用アプリって Autocad とか Povray とかだっけ？違う？

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　結　論

　　　　　　　「現時点」では、「実用的な」アプリケーションを作成する場合、C/C++>>>>lispである。

Lisp は Xlib を使わずに X protocol を喋る事の出来る数少ない言語の一つ。

最近はｱﾚだ、Cでもようやくhtmlテンプレートエンジンがでてきたようだし。
圧倒的な動作コストの低さでC/cgi盛り返すかな？

ttp://www.clearsilver.net/

用途次第だろ。
応答速度のチューニングならサーブレットにすればいいし、
手軽にかければそれでいい状況ならLispでいい。
CでCGIってのは中途半端な状況だな。

実行効率が大して必要でないならCよりはLispの方がCGI向きだとは思う。
CGIって文字列操作が多いと思うが、Cだとそれが面倒でかなわん。せめてC++で。

いいや、LISPこそが実行効率を必要とする現場で発揮される言語だい！







なんつって

OrbitzがLISPで書かれている

CGIっていうか、LispってAPサーバあるじゃん。

C++でもテンプレートを駆使すれば関数型プログラミングもなんとかできるのでは？
マクロはLispにかなわないだろうがプリプロセッサとテンプレート飲めたプログラミングで頑張って。

このスレにKahuaが一切出てこないのはなぜですか

そこに山があるからです

haskelと比べるとどうなの？

現在主流な LISP は静的型じゃない、デフォルトの評価規則が遅延評価じゃない、純粋関数型じゃない。
最強厨とか理論厨とか言語比較厨なら間違いなく Haskell を選ぶべき。

Lispは記述力は高いけど
実行速度とのバランスも考えるときにはhaskell
という理解でいいのでしょうか？

>>37
よくない

>>37 Haskell 使いたいなら Haskell 使ったほうがいいよ…
チューニングの仕方とかが全然違うし。「どっちか」を選ぶなら Haskell でいいだろ。
Lisp やるなら両方やっといたほうがいいけど。つか、なんで比べたがるんだ？

>>37
ていうかLispは速いよ。
ネイティブ吐く処理系使えば、C/C++よりちょっと遅い程度。

普通に書く効率
LISP＞＞＞＞＞＞＞＞＞＞Haskell

結論
HaskellにはHaskell脳(遅延評価脳)が必要。
一般人は無理。

>>41
っていうか数学科とかに入るような人のうち脳内でｎ次元ベクトルの状態をグリグリ動かせる様な人ならHaskell得意だろうな。
そういう人を何人かしってるけど、俺には想像もできないよ。

>>36
でも言語比較厨とかの間でもLispは人気あるぞ
そういう奴は、Lispのソースコード＝リストであるところに
惹かれてるわけで、Haskellはむしろ嫌いである可能性すらある
最強厨とか理論厨とか言語比較厨でも「HaskellよりLisp」派は間違いなくいる

>>23
ちなみにAutoCADはかなり前にC++化されてる。
今でもLisp使って拡張できるけど、推奨ではないです。

内心楽しみなMSの関数型言語 F#
ttp://www.itmedia.co.jp/enterprise/articles/0711/06/news104.html

・狭い市場を狙う
・VB C# の後釜じゃないよ
・関数族は孤立してる←ｗｗｗ

実際、どこまで実用なのか。
はたまたベーパーウェアに終わるか？

何つう今更な話題…

【.NET】F#について語れ【OCAML】
http://pc11.2ch.net/test/read.cgi/tech/1186030985/

あれだよね。newlispとか便利だよね。

ＬＩＳＰには変わったマクロあって埋め込み言語実装が簡単だけど
Haskellにはあるのかな？

>>49
「変わったマクロ」ですと？？？
あの程度書けなきゃマクロって言わんちゃいますか？

>>41
慣れたらhaskelの方がlispよりも速い場合ってあるの？

>>51
ある。
「慣れることが出来ない」という事実に目をつぶれば。

印欧語族母語話者が考え方を自然に書くとＬＩＳＰみたいになる。
ＵＴＦ‐８で組むＸＭＬ書式はＬＩＳＰのカッコの対応を明示しただけ。
ＵＴＦ‐８コード環境は日本語「だけ」が苦手→はぶられる(ｵﾜﾀ
こうですか＞＜　ワカリマセン（＝間違い）…だといいな？

頭大丈夫？

http://pc11.2ch.net/test/read.cgi/tech/1201402366/860

これを書いた人だから。

あっちこちで見かけるよね。「印欧語族母語話者」はNGワード推奨？

Lispが欧米の自然言語に近いとかはウソだな。
set b to a
が
(setq a b)
だもん。

単に
コマンド 引数 ...
で引数にコマンド 引数 ...が入れられるようにしただけじゃん。

>>57
それではリストを正確に表していない。

値の代入？のような処理はどっちも自然言語と違うと思うけど。
ただlispで値を比較したい場合
( s == o)
という風にSVOで書けないからちょっとだけ見にくい感じはするな。
まあオペレータオーバーロード出来ない言語だと、特定の型以外は
関数で比較とか混在するので似たようなもんか。

ところでlispのどういうとこが自然言語に近いの？

今までプログラミング言語が自然言語と近いかどうかなんて気にしたこと無かったなあ。
プログラミング言語にそんなこと求めたこと無いし・・・
何でそういうことを気にする人がいるのか興味があるなあ。

自然言語に近いとかはどうでもいいよな。
そんな事言ってたら再帰とかどうすんだよとw

lispは人間が機械をサポートしなきゃいけないのが面倒で嫌だったなぁ
コードそのものがS式ですとか言ってみても、言い換えれば人間がそうなるように頑張ってるわけで・・

頑張るってのは方向を間違えてないか？プログラムを書くプログラムを書くのが目的に最適化されてるの。
そこを履き違えたならたしかにS式は一方的に人間が機械に譲歩してるだけに見えるだろう。
実際には人間が機械に半分歩みよると同時に、機械を半分人間に歩み寄らせてるんだよ。

一般人から見たら、S式もアルゴル系の手続き言語(代表的なC言語でもいいや)も
大してかわらん。
義務教育で教えて概念が入っていればそっちが学びやすい分、
四則演算がそのままかける、手続き言語に軍配があがるかもしれんが

なまじ四則演算がそのまま書けるせいで、
x = x + 1
を等式だと思って混乱するっていう落とし穴もあるし。

副作用のない関数言語なら大丈夫。ってか、そんなん書けない。

代入が等式に見えるという悪癖はFortran以来（COBOLは知らん）
BASICやCも引き継いでいる、人気のある言語ほど採用しやがる仕様
なんだよな。

>>62
現実には仕様上無理だとしても
S式を壊して記述しても機械がサポートできるということにすれば
よくある後半の）の山はほとんど消せるよなw

(+ 1 2)も + 1 2でいいことになる。
もっといえば 1 + 2でもいい。
そりゃすでにS式じゃねーだろというかもしれないがその通り。
S式に依存して書かなければならないという仕様は人間が負担し、担保してるし省略形（あるいは省力形といっても・・）で簡素に書く事が出来ない。

結果的に可読性が悪くなる最大の要因と化しているのも事実だと思うよ。
だからといって技術的にどうにかできるものじゃないから
「仕様です」で終わりだけどw

まあ・・この辺がスマートに解決される魔法があったらBASICが使われる事もなかったんじゃないかとさえ思う今日この頃。

Lisp と C で括弧の数が大きく違うのは、演算子周りくらいじゃないかな。
普通の関数呼び出しとか、 if や for みたいな制御構造とかには、 C だって括弧が要る。
演算子が大量に連なった式でもない限り、 Lisp で閉じ括弧が山ほど続くようなコードは、 C で書いても同じくらいの閉じ括弧が続くと思う。

+ 1 2 みたいに書く場合、式と式を区切る手段が必要になる。
その一行だけを評価するならそれでいいんだけど、実際のプログラムってもっとたくさんの式でできてるよね。
式が入れ子になってるようなのも普通だし。
で、特に入れ子になった式を書く場合、どこからどこまでが一つの部分式かを明示しないといけないんで、括弧で括るような記法が便利。

S 式って別に可読性悪くないと思うんだけどね。

>>68
>C で書いても同じくらいの閉じ括弧が続くと思う
いやーそれはないない
そんなコード見た事無いわ
括弧の数カウントして同じように並べたらって話ならまだ別だけど
それ自体意味はないし・・

S式の閉じ括弧の連続は、それなりのエディタを使わないと面倒だと思う。
というか、メモ帳→Vimと移ってそこがすごい便利だと思った。

>>68
たいしたことないLispのコードでもケツに7,8個カッコが付くなんて普通にあるから、真ん中あたりの閉じカッコがどこに対応してるんだなんて見たってわかりゃしないよね。
エディタの支援機能がないとあんまり触りたくはない・・かな。

Cだと文化違うけど、カッコを２種類使えるのとindentの関係でブロック構造は視認しやすいってのはある。
ま、ブロック構造だけはw
Lispでも同じようにやりゃいいじゃないかってのもあるけど
Lisperになるほどそうしないからね、人のコード見るときは結構うんざり気味になる・・

俺だってそもそもワンライナー以外のプログマムをエディタなしに編集したくはねーよ。Lispに限らずね。
俺はLispでインデントしか見ないので、Cっぽく括弧だけの行があるコードをみるとうんざりするよ。

俺もLispの制御構造はインデントでしか見ない。
インデントが崩れていても、emacsならコマンド一発で自動整形できるし
あの括弧のおかげで、自動整形の精度も高いんだぜ。

同じくインデント任せ。
ぶっちゃけ Emacs 以外の環境でまともに読み書きできる自信はない。

・閉じ括弧は基本的に見る対象ではない
・主にインデントを見る

この2点があるから、Lispには閉じ括弧をまとめる慣習があるわけだよね。
見る対象ではないから、出来るだけ小さく存在していたほうが良いし、
閉じ括弧に一行与えると、縦がスカスカになって、目でインデントをなぞりにくい。

>>75
>この2点があるから、Lispには閉じ括弧をまとめる慣習があるわけだよね。
必ずしもそうとは言えないぞ
インデントは意識されてても１行に詰め込み杉で
インデントの意味がないコードも多いし。
閉じ括弧まとめるのは慣習的な意味合い強いよ。

>>76
少なくともLisperの間でコンセンサスは取られている。
フレームだらけのLisper同士の喧嘩でもインデントに関するものはほとんどない。
タブ幅に関する個人的な考察だの括弧の配置に関する俺理論とかうんざりなんだよね。
一行につめこみ杉だったら、改行入れて整形するだけであとは>>75の主張の通りだよ。

CLとSchemeが誕生した前後は、エディタは、edとか、使っていたのかな？

>>77
>少なくともLisperの間でコンセンサスは取られている。
それはないよ。

>>78
TECOじゃね？

そういえばスーパー閉じ括弧ってどうなったんだろう？

shcemeでは[]だって使えるんだぜ。

cとhが逆だったよ。よめねえよ。