1 :デフォルトの名無しさん:2011/05/14(土) 23:35:38.48
またその理由は?(やりながらお金儲けできる、アイデア次第で色んなものを作れる、など)

やってて楽しいプログラミング言語は? 2言語
http://hibari.2ch.net/test/read.cgi/tech/1303357967/

やってて楽しいプログラミング言語は?
http://hibari.2ch.net/test/read.cgi/tech/1298628324/


次スレも立てられないおまえらはPHPの刑、VBの刑

296 :デフォルトの名無しさん:2011/06/07(火) 16:23:42.79
pdfにあるよ。OOCとかで。言語を英語圏にして、ググってみれば?
gtkなんかは、大量のマクロつかって無理矢理なOOP
そこまでして、なぜCで書く必要があったのか疑問

315 :デフォルトの名無しさん:2011/06/20(月) 01:26:34.87
疑似コードを書くのが楽しい

リファレンスを引いたり、文法を手直ししたり、現実のプログラミング言語に落とし込むのが辛い
Haskell を勉強したら幸せになれるだろうか・・・

328 :デフォルトの名無しさん:2011/06/21(火) 12:46:59.54
使える使えないは別にして
「なでしこ」楽しいぜw

プログラム作ってるはずなのに
なんか良く分かんない小説みたいなの書いてる気分になるw

359 :デフォルトの名無しさん:2011/07/08(金) 17:55:35.75
rubyだけは馴染めなかった。

366 :デフォルトの名無しさん:2011/07/08(金) 22:59:44.92
・中途半端なPascal記法が気に食わない
・ソースのparser.cの汚さは異常なレベル


386 :デフォルトの名無しさん:2011/07/09(土) 15:42:55.40
言語仕様に対する不満が出て来ないのは、大きな問題は無いって事かな?

399 :デフォルトの名無しさん:2011/07/10(日) 20:59:52.19
あーでも

p (1 �\
+ 2)

とか

p("a very long string" �\
+ "another string")

ならオケなのか
納得したわ

401 :デフォルトの名無しさん:2011/07/10(日) 22:29:40.74
>>399
なんだこの\記号。VBのアンダーラインみたいなもん?
気持ち悪いな

406 :デフォルトの名無しさん:2011/07/11(月) 00:39:19.96
>>401
Cで複数行のマクロを見た事無い?

421 :デフォルトの名無しさん:2011/07/11(月) 15:59:23.28
Rubyの演算子の優先順位ってどうなってんの?
x,??y??,z??を変数として

x??=??y??+??z
x??+??y??=??z

のどっちも通るんだが、上は+が先に評価されて
下は=が先に評価されるんだけど(というか下が通るのはさすがRuby)

550 :デフォルトの名無しさん:2011/07/23(土) 11:18:47.99
末尾再帰が最適化されるからこそ関数的なスタイルで実用コードが書けるんだが

601 :デフォルトの名無しさん:2011/09/18(日) 19:54:52.22
ちょっと感動したんで書いとく

まずはプログラミングhaskellからの引用


x^2+y^2=z^2を満たす正の整数をピタゴラス数と呼び、三つ組(x,y,z)で表す。ピタゴラス数のリストを生成する関数pythsを定義せよ。ただし、ピタゴラス数の要素は、与えられた上限以下であるとする。

以下に例を示す。

>pyths 10
[(3,4,5),(4,3,5),(6,8,10),(8,6,10)]

引用終わり

これ、haskellで書くと(と言うか、リスト内包表記使える言語だと同じ感じ)、こうなるんだけど、

pyths n = [(x,y,z) | x <- [1..n], y<-[1..n], z<-[1..n], x^2+y^2 == z^2]

リスト内包表記以外の方法だとこんなに短く書け無いんじゃ無かろうか

pythonはリスト内包表記あるの知ってるけど、他の言語でも、こんなに短く書けるんだろうか。。。




604 :デフォルトの名無しさん:2011/09/23(金) 01:23:21.32
Matlab:
function f = pyths(n)
[x y z] = meshgrid(1:n, 1:n, 1:n);
sol = x.^2 + y.^2 == z.^2;
f = [x(sol) y(sol) z(sol)];

こういう例題って効率良く解こうとすると
途端に汚くなるんだよな

605 :デフォルトの名無しさん:2011/09/23(金) 01:56:00.40
Mathematicaだと
Select[Tuples[Range@#, 3]^2, Plus @@ Most@# == Last@# &]^.5 &

もしくは問題文をそのまま書いて
Solve[x^2 + y^2 == z^2 && 0 < x <= # && 0 < y <= # && 0 < z <= #, {x,
y, z}, Integers] &

>>604
こういう初等整数論の問題をガリガリ求めるのは
結局C/C++が最速なのかな?

606 :デフォルトの名無しさん:2011/09/23(金) 07:22:42.02
Prolog
途中ちょっと必要ないことをやってますが。勘案のログということで。
http://nojiriko.asia/prolog/pythagorean_su_3.html

607 :デフォルトの名無しさん:2011/09/23(金) 11:33:34.37
>>604
手続型でも短く書けるもんですね。
>>606
短くないけど面白そうですね。
手続型、関数型と発想が違う

609 :デフォルトの名無しさん:2011/09/23(金) 15:40:31.27
C++の超難解な文法に自虐的な快感を覚えつつプログラムを書くのが好き

>>605
http://dada.perl.it/shootout/

使用しているコンパイラが古いけどおおよその傾向がつかめる
大部分C/C++が最速だが、OCamlも馬鹿に出来ない

614 :デフォルトの名無しさん:2011/09/24(土) 00:54:35.46
短く書くならperlやrubyが得意そうだが。俺書けんけど

617 :デフォルトの名無しさん:2011/09/24(土) 02:14:43.29
Scratch版があった
http://scratch.mit.edu/projects/DarthPickley/986731

623 :デフォルトの名無しさん:2011/09/24(土) 12:44:40.81
コード量が同じ、柔軟性も同じなら、速いに越したことはないと思うが


632 :デフォルトの名無しさん:2011/09/24(土) 16:39:37.87
それ使えば>>601が短くなる?

634 :デフォルトの名無しさん:2011/09/24(土) 16:45:55.92
>>632
少しだけ短くなる

使用前:let??pyths??n??=??[(x,y,z)??|??x??<-??1--n;??y??<-??1--n;??z??<-??1--n;??x*x??+??y*y??=??z*z]
使用後:let??pyths??n??=??[l??|??l??<-??1--n^3;??let??[x;y;z]??=??l??in??x*x??+??y*y??=??z*z]

643 :デフォルトの名無しさん:2011/09/25(日) 01:57:56.43
ああ、そう。


こんなのに興味がないが、FORTRANでいい。


この言語にしかできないってことあるか?
どうせ、この言語だとこんなに綺麗に書けますよ
といった好みの問題だろ。

お前が変態を美しいというのなら、別にそれでいい。


相手する気にもならん


664 :デフォルトの名無しさん:2011/09/27(火) 22:36:44.92
C別解、product()だけ関数化してみた
そんなに長くないように見えるが、main()がごちゃごちゃするのを
見ての通り使いにくく、ベタループよりずっと効率が悪くなるのが
C的にはやはり問題

#include <stdio.h>
int product(int nelem, int *elems, int *limits)
{
?? ?? int i;
?? ?? for (i = nelem - 1; i >= 0 && ++elems[i] == limits[i]; --i)
?? ?? ?? ?? elems[i] = 0;
?? ?? return i >= 0;
}
int main()
{
?? ?? int ix[] = { 0, 0, -1 };
?? ?? int limits[] = { 10, 10, 10 };
?? ?? while (product(3, ix, limits)) {
?? ?? ?? ?? int x = ix[0] + 1, y = ix[1] + 1, z = ix[2] + 1;
?? ?? ?? ?? if (x * x + y * y == z * z)
?? ?? ?? ?? ?? ?? printf("%d, %d, %d\n", x, y, z);
?? ?? }
}





681 :uy:2011/10/03(月) 04:20:58.60
俺は最近
>>664
こういうソースコードをみると、古めかしさを感じるだけど、お前等はどうなの?

特に { ... } これが古めかしいよね


Rubyみたいに思い切ってendとか、Pythonみたいにインデント構造にするとか
Lisp、XML、 ぱっと思いつくだけで4種類も別の方法がでたが


古いものがよいとも限らないところがIT技術だねぇ

718 :デフォルトの名無しさん:2011/10/10(月) 00:57:34.51
haskellをメインで使いつづけたら?手続き型のポトペタなアプリが書ける奴なんて、
その辺の道端に犬のウンコぐらいいくらでも転がってんだろ

haskellでCSP、TSPなりパーサーなりをスラスラ書ける奴と
手続き型でありきたりなウェブアプリしか書けない奴を同時に面接するとして、
自分が経営者ならどっちを雇いたい?

751 :デフォルトの名無しさん:2011/11/08(火) 18:27:55.23
8クイーン別に大げさなもんじゃないよね
Pythonで書くとこんなもんだ

def queens(size):
?? ?? solve = lambda y: ((),) if not y else \
?? ?? ?? ?? ?? ?? ?? (((x, y),) + qs
?? ?? ?? ?? ?? ?? ?? ?? for qs in solve(y - 1)
?? ?? ?? ?? ?? ?? ?? ?? ?? for x in range(1, size + 1)
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? if all(x != u and abs(x - v) != y - v for u, v in qs))
?? ?? return solve(size)

for x in queens(8):
?? ?? print x

782 :デフォルトの名無しさん:2011/11/11(金) 00:53:33.39
やべえ、Cはわかったけど
ハスケルもオカムも全然わからん

789 :デフォルトの名無しさん:2011/11/11(金) 18:50:21.25
OCamlやHaskellのリストはimmutableだから挿入や連結も苦手だけどな
本当に速いのは先頭への追加/削除だけ

790 :デフォルトの名無しさん:2011/11/11(金) 19:11:05.69
>>789
え?

add3 (n1:n2:n3:ns) x = n1:n2:n3:x:ns


792 :デフォルトの名無しさん:2011/11/11(金) 19:20:12.07
>>790
「先頭に近いところ」への追加は速いと言ってもいいけど、
add3を一般化てaddNにしたら、addNはNに比例する時間が掛かる

797 :デフォルトの名無しさん:2011/11/11(金) 20:06:58.39
>>792
騙されたなw

add3 (n1:n2:n3:ns) x = n1:n2:n3:x:ns



add (n:ns) x 0 = x:ns
add (n:ns) x num = n:add ns x (num-1)

も同じ。二つは、再起でメモリ消費するかしないかだけで、データ構造としてのリストは「先頭から順に辿る」のは変わらずO(n)だw

破壊的かどうかも、メモリ上でリストをコピーするか、しないかだけで、データ構造としてのリストはどの言語でも、「先頭から順に辿る」は変わらず、O(n)なんだよwww

破壊的かどうかってのは、リストと言うデータ構造の速度とは別の問題。


798 :デフォルトの名無しさん:2011/11/11(金) 21:55:00.65
>>797
何に騙されたって?

ともあれ、破壊的更新ができるリストなら、あらかじめ末尾へのポインタを持っておけば
定数時間で連結できるよね

799 :デフォルトの名無しさん:2011/11/12(土) 07:51:00.78
>>798
変動する末尾へのポインタ保持するのに結局最初から辿らないといけなくね?
うろ覚えだが、Cのデータ構造としてのリストも

struct intList
{
   int value;
   intList *next;
}

みたいなのじゃなかったっけ?


850 :デフォルトの名無しさん:2011/12/31(土) 23:21:06.08
今まではMFCで書いとけばWinでは何とかなるだろう感があったが、Vista以降微妙な感じはするな。

851 :デフォルトの名無しさん:2012/01/01(日) 12:17:56.31
>>850
VS2011のMFCのクラスの強化具合が分かるまでは何とも言えないが、VS2010でも順調にMFCは新しいクラスが追加されてるみたいだし、これまで通りパフォーマンス向けはx86 or x64に特化でMFCも残るんじゃないかな
そんなパフォーマンスが必要な場面は確実に減ってるけど、無くなりもしないだろうし

個人的にはARM向けにもネイティブ吐けるようになると嬉しい
(その分、for x86, for x64, for ARM。みたいになるんだろうけど)


854 :デフォルトの名無しさん:2012/01/06(金) 23:00:01.96
どう考えてもObjective-C
Cocoa, iOSの言語だから

859 :デフォルトの名無しさん:2012/01/08(日) 12:17:54.22
Javaに素晴らしい所があるとすればJVMで動作する数多くの優秀なソフトウェアがある事だし、
プラットフォームの魅力って重要だよね。
連携すればすぐに出来のいいソフトウェアが作れるのは楽しい。
構文とか意味論とかの面で見る所が無くてもね。

860 :デフォルトの名無しさん:2012/01/08(日) 14:17:08.19
>>859
> Javaに素晴らしい所があるとすればJVMで動作する数多くの優秀なソフトウェアがある事だし、
大量のCPUを並列に動かせないのでつまんないんですけど


904 :デフォルトの名無しさん:2012/03/07(水) 13:08:50.58
JavaScriptは関数型言語

914 :デフォルトの名無しさん:2012/05/14(月) 18:50:55.74
今までC~JAVA系書式の言語ばかりやって来て
ちょっと関数系でもかじろうかな~ってことでF#とHaskell試してみたらチンプンカンプン
こりゃこの書式に慣れるまで苦行だなあ

917 :デフォルトの名無しさん:2012/05/15(火) 00:27:02.66
>>914
慣れると、関数型の方が楽だよ
オブジェクト指向はライブラリがサポートしてる範囲はメソッドを利用するだけになるけど、そこから外れるとメソッドを手続き的に作る必要がある
ライブラリのサポート範囲によってプラットフォームが変わってしまうので、考え方が違ってくるけど、関数型言語は、基本は関数適用という同じ考え方で統一されてる

小さい関数は再帰関数が多いけど、それも自分自身を「関数適用する」し、大きめの関数は、既存の関数を「関数適用する」だけ


919 :デフォルトの名無しさん:2012/05/15(火) 07:42:18.49
>>917
> オブジェクト指向はライブラリがサポートしてる範囲はメソッドを利用するだけになるけど、そこから外れるとメソッドを手続き的に作る必要がある

私は Haskell も C/C++ や Java も日常的に使っていますが、
オブジェクト指向言語に対するこの認識が私にはよくわかりません。

オブジェクト指向でライブラリがサポートしてる範囲の
メソッドを利用するだけの部分も、どう考えても「手続き的に」記述して
利用する必要があると思うのですが。

もしかして、メソッドを呼ぶだけの場合は宣言的になるという意味でしょうか?
環境が変化する順(フロー)を意識しなければならないメソッド呼び出しは、
宣言的とは言いがたいと私は思います。
違うことを言っているのでしたらごめんなさい。

あと、関数適用あるいはメソッド呼び出しにおいて、
その記述的な違いは表層的なものであり本質ではないと思います。
Haskell のような関数型と C++ のような手続き型で本質的に違うのは、
記述的なことではなく、関数型は参照透過性が保たれること、
これに尽きると思います。

921 :デフォルトの名無しさん:2012/05/15(火) 08:30:54.40
>>919
>環境が変化する順(フロー)を意識しなければならないメソッド呼び出しは、
>宣言的とは言いがたいと私は思います。

これは、Haskellでもdo構文使えば同じように手続き的になると思うのですが・・・

それは置いておいて、rubyやsmalltalkのような純粋なOOだと、メソッドチェーンが繋がりやすいのですが、これは関数型言語も関数適用の連鎖で最終的にほしい関数を作るのに似てるな・・・と感じます
ただ、ほしい関数(やメソッド)の部品として作られた関数(やメソッド)の作り方が関数型言語はやっぱり関数適用であるのに対して、オブジェクト指向は手続き的になるな・・・と感じました

そして、順序を意識したHaskellのdo構文は、関数数適用という考え方のまま、手続き型をエミュレートしてるという感覚を最近感じています


923 :デフォルトの名無しさん:2012/05/15(火) 22:12:00.04
>>921
ごめんなさい、言葉が足りなかったです。
私が言っている環境というのは、アプリの振る舞いに影響を与える情報を蓄える
メモリ全体の内容の事です。

手続き型の場合、あるメソッドを呼んだ時に、
環境の複数の部分が同時に変化する事は普通にあります。
そして、ある部分の変化がその後に呼ぶメソッドの振る舞いに影響を及ぼします。
このためプログラマは環境の変化の順を意識します。
言語仕様も意識する必要がある部分を可能な限り局所化しようと工夫され、
プログラマの方も環境の局所化に苦心しますが、根本的に宣言的にはなりにくいです。

Haskellでこのような意味での環境の変化順を本当に意識しなければならないのは、
ほとんどの場合IOモナドを使っている時だけではないでしょうか(do表記かは無関係)。
この時ばかりは、変化する環境に影響される部分がコードの広範囲に渡る可能性があり、
アプリのコード全体でちゃんと意識しなければなりません。

それ以外のモナドでは、わざと環境の変化順を意識させるような構造・使い方でない限り、
たとえdo表記で見た目手続き型っぽく書いても、それほど意識する必要はないです。
せいぜいリストを map f に通してから map g に通す、程度の順の意識で良いはずです。
(この場合の環境変化は、超局所化されて引数と戻り値の関係だけになり、意識すらしない)

なので、IOモナド以外のモナドでは、
普通にHaskellコードを書くのと同程度には宣言的に書けます。
例えばYesodというWebフレームワークではdo記法を多用しますが、
むしろdo記法でより宣言的に書けるように工夫されています。

924 :デフォルトの名無しさん:2012/05/16(水) 06:31:56.43
>>923
私の言いたいこととあなたの言いたいことは概ね同じなんですが・・・

要するにですね
何か処理させたければ、必然的にOOでも関数型でも何らかのメソッドや関数を作らないといけません
その時点で、OOは手続き的にならざるを得ないが、関数型はどこまで行っても関数適用(宣言的)だ。と
(do記法すらも、モナド記法よりも手続き的に書いたほうが読みやすい場合に使う為の構文糖衣だと感じている)

OOな人たちに波風立てたくないから、オブラートに包んでいるのに、オブラートを引き剥がさないで下さいw

Listモナドも「先頭から順に」という順番はありますよ
意識しないといけないほど順序がハッキリしてるのは確かにIOモナドだけかもしれませんが


925 :デフォルトの名無しさん:2012/05/16(水) 07:53:49.96
>>924
> OOな人たちに波風立てたくないから、

気づかなくて申し訳なかったです。

> Listモナドも「先頭から順に」という順番はありますよ

私が言ってるのは環境が変化する順なんです。

では、どのような時にListモナドに対して
「先頭から順に」という順番を気にするのでしょう。


>>917
> オブジェクト指向はライブラリがサポートしてる範囲はメソッドを利用するだけになるけど、そこから外れるとメソッドを手続き的に作る必要がある

やはり私には、コードの中でメソッドを利用するだけの部分も、
どのように利用するか、つまり環境をどの順でどう変化させるかを考える必要があり、
その手続きをコードに書いている様にしか見えないです。

926 :デフォルトの名無しさん:2012/05/17(木) 01:57:31.19
>>925
え、リスト使うときに(x:xs)とかしない?それが、順序を気にしてるところだよ
環境・状態って言うよりは構造って感じで、あなたも私もあまり意識はしないけど

モナドそのものが順序の無い関数の世界に順序をもたらすものだから、環境・状態に限らず、順序を意識するものはモナドで定義されてる
そのおかげでIOモナドも宣言的に書けると言える(大抵はIOモナドはdo記法の方が読みやすいが)

数学セミナーによると静的マンセー(ここで言う静的は恐らく宣言的)な数学で動的なものを表現しようってのがどうやら圏論(モナドの元になった数学の分野)らしいんですね
(数学セミナー2011年7月号第一回圏論の歩き方・参照)


一応、擁護すると、最近のオブジェクト指向言語(主にLL)は関数型言語とも被りますが、イテレータ等でループを表現できるようになってますよ
Haskellで言うfoldlがeachに、mapはまんまmapという「メソッド」として

もちろん、それでも関数型言語ほど宣言的には出来ないし、一応OOも宣言的を目指してるはずなんですが、どうしても全部宣言的とは行かない(というか、ほとんど手続き的)です
(ついでに言うと、蒸し返したこの部分がまさにオブラートですw)



http://toro.2ch.net/test/read.cgi/tech/1305383738/l50/../人気ブログランキングへ