次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/20(木) 04:43:27.12

いざ、語ろうぞ。

スレタイ超過のため、一部省略。
Go, Erlang, Kotlin, etcもウェルカム。
Haskellは協議により次世代失格になりました

前スレ
次世代言語議論スレ[Go Rust Haskell Scala]第3世代
http://echo.2ch.net/test/read.cgi/tech/1488608741/

**デフォルトの名無しさん** · 2017/05/05(金) 01:26:49.15

Haskellは代数的データ型が便利
何気にあのレベルに便利な型システム他に見ない

あ · 2017/05/05(金) 03:41:35.36

>>215
OCamlの方がシンプルかな。
Haxeの方が記法はきれい。
Kotlinはいささか冗長で使い物になるのかな？みたいな羊感出てるけど、when使うときに逆に便利になる。

**デフォルトの名無しさん** · 2017/05/05(金) 05:49:16.66

SmalltalkとHaskellは使ってみるとゴミと分かる二大巨頭
信者が煩いとこもソックリ

**デフォルトの名無しさん** · 2017/05/05(金) 07:09:34.37

>>217
アンチがウザいのもそっくりだよね

**デフォルトの名無しさん** · 2017/05/05(金) 07:18:58.13

>>218
どっちの信者？

**デフォルトの名無しさん** · 2017/05/05(金) 07:39:38.28

>>217
アンチが無知なのもそっくりだよね

**デフォルトの名無しさん** · 2017/05/05(金) 08:48:03.35

IntelliJとかのマトモなIDEを使った後に
Smalltalkの時代遅れのIDEモドキ？を使ってみると、
終わった言語の進化に取り残されてる感がよく分かるし
こんな出来損ないを使うの強制されるSmalltalkerって哀れだなーって優しい気持ちになれるよ

**デフォルトの名無しさん** · 2017/05/05(金) 09:20:19.67

>>221
言語としてはどこらへんがゴミなの？

**デフォルトの名無しさん** · 2017/05/05(金) 09:39:59.96

>>222
動的型言語の中ではぶっちぎりで冗長なコードになるところ

**デフォルトの名無しさん** · 2017/05/05(金) 09:54:56.24

文字列クラスを改変したら元に戻せないという話はSmalltalkにも当てはまるのかな
文字列クラスクラスがあれば壊れたクラスを使い捨てて新品のクラスに交換できるのに

**デフォルトの名無しさん** · 2017/05/05(金) 10:13:52.40

>>224
クラスが壊れるという事自体が糞めんどくさい

**デフォルトの名無しさん** · 2017/05/05(金) 13:00:01.57

Smalltalkっていうか遅延結合の徹底ってスタイルは人類には早すぎたんだな

**デフォルトの名無しさん** · 2017/05/05(金) 16:27:38.21

RESTful API等でサービス間を遅延結合するのは流行ってるしメリットがあるけど
ひとつのプロセス内で遅延結合しても意味が無い

アホは適切な抽象化レベルってものが分からないから
やりすぎてナンセンスになっちゃうんだよね
Smalltalkはアホがナンセンスなデザインした結果死ぬべくして死んだ言語

**デフォルトの名無しさん** · 2017/05/05(金) 17:23:18.30

Haskellは遅延評価が本当に苦痛すぎる
あの辛さはやってみるまで想像もつかなかった

**デフォルトの名無しさん** · 2017/05/05(金) 17:51:23.35

Smalltalkにおいて「遅延結合の徹底」に期待されるのは通常の言語で想定されるそれとは違って
システム構築中に得られた新たな知見を、既に構築済みだったり運用中の部分へ適用できたり
オブジェクトとそのストアを長期にわたって運用し続けるために細胞の新陳代謝を模した試みだから
http://metatoys.org/oxymoron/oxymoron.html
'70年代からほんの数回の再起動で動き続けている同システムは狙いとしては成功しているんだよね

**デフォルトの名無しさん** · 2017/05/05(金) 17:51:28.56

無限リスト扱えるし便利でもあり、バグ取りで厄介でもあるね。
RWHにその辺の解決策載ってるから手元に置いとくと良い。

**デフォルトの名無しさん** · 2017/05/05(金) 17:51:33.32

馬鹿は抽象化することがなんでもえらいと思ってるからね。。

あ · 2017/05/05(金) 19:50:22.56

>>227
意味無いとは言わんがなぁ。
プロセス内でもプロトコル決めてやっとくと、あとでスケールするとか、
固まりへのインアウトが自ずと決まるから可換だと言いやすいとは思う。
やりすぎると自分の重さで死ぬだけで。

**デフォルトの名無しさん** · 2017/05/05(金) 20:29:10.87

FacebookでHaskell採用されたね。

**デフォルトの名無しさん** · 2017/05/05(金) 20:49:47.45

>>216
Haskellと比べてOCamlがシンプルって
SMLと勘違いしてない？

あ · 2017/05/05(金) 20:51:14.85

>>234
してないよw
シンプルってのは字数が少ないって意味じゃないぞ。

**デフォルトの名無しさん** · 2017/05/05(金) 21:21:35.63

>>235
そんなら勘違いしてるね

**デフォルトの名無しさん** · 2017/05/05(金) 21:31:07.05

全然関係ないけど、字数が少ないコードって一目で取れる情報が多くて読みやすくて好きだわ

**デフォルトの名無しさん** · 2017/05/05(金) 21:42:23.21

>>231
時代によって変わる程度問題だけどね。
C++だって、昔はクラスってなんだよ。Cより遅くなるじゃねーかって言われてたらしい。
昔よりも抽象度の高さが問題になる場面は少ない。

**デフォルトの名無しさん** · 2017/05/05(金) 22:47:31.33

いつの間にかHaskellがスレタイから抜けててワロた。

**デフォルトの名無しさん** · 2017/05/05(金) 23:29:21.86

取り敢えず拡張性比べるんならプログラム組むべ。
まずはファイル名とキーワードを受け取って、ファイルの中にキーワードがあったらTrue。無かったらFalseと表示するコマンド。

プログラミング自体から離れてだいぶ経ったので、錆びた頭だったがHaskellでどうにか書いてみた。

search部分を拡張してくから、各自searchは自前で書いてくれ。

import System.Environment

search _ [] = False
search s ns | take (length s) ns == s = True
search s (_:ns) = search s ns

main = do
arga <- getArgs
content <- readFile $ args!!0
print $ search (args!!1) content

**デフォルトの名無しさん** · 2017/05/05(金) 23:31:16.17

前スレのドアのお題をPharo Smalltalkでも書いてみた
http://ws.stfx.eu/JD8JH4XF3I3U

Go版ももう少しマシな感じにしてみた
http://ideone.com/aFqKsd

**デフォルトの名無しさん** · 2017/05/05(金) 23:36:43.64

だから、使い所不明なクラス書いてどうしろと。
プログラム組みたいのであってクラス作りたいんじゃ無いんだぞ？

**デフォルトの名無しさん** · 2017/05/05(金) 23:59:41.96

>>242
いや別に>>240へのレスというわけではないのだが…

これでいいか？（Squeak Smalltalk、もしくはPharo）

| search |
search := [:fname :keywd |
　FileStream oldFileNamed: fname do: [:file |
　　(file findString: keywd) > 0
　]
].
search value: 'test.txt' value: 'something' "=> true "

http://ws.stfx.eu/1UQT4K8GSVHU

**デフォルトの名無しさん** · 2017/05/06(土) 00:04:14.20

>>240
それだとコンパイル通らないよ

import System.Environment (getArgs)
import System.IO (readFile)
import Data.List (isInfixOf)

search :: String -> String -> Bool
search = isInfixOf

main :: IO ()
main = do
　(word:file:_) <- getArgs
　putStrLn . show =<< search word <$> readFile file

**デフォルトの名無しさん** · 2017/05/06(土) 00:23:53.40

え。。。
通ったけど。。。

**デフォルトの名無しさん** · 2017/05/06(土) 00:29:01.13

うん、普通のデータ処理の比較は面白そうだ。

**デフォルトの名無しさん** · 2017/05/06(土) 00:29:23.53

>>243
おk。
強いて言えば、この後拡張する時、どこまで今のコードから書き換えないで済ませられるかが仕様変更に強い基準になると思う。

**デフォルトの名無しさん** · 2017/05/06(土) 00:33:03.34

>>245
そのままじゃ通らなかった
けどごめんね、詳しく見てなかったけど駄目だったのはタイポだけだったみたいだね

**デフォルトの名無しさん** · 2017/05/06(土) 00:35:03.84

あ、argsをargaってタイポしてた。。。
LinuxにHaskell入れたばかりなのでPCで実行確認してiPhoneで書き込んでるんで、コピペでコンパイル出来ない時はどこかタイポあると思う。

**デフォルトの名無しさん** · 2017/05/06(土) 00:50:29.93

次世代言語勢に参戦して貰わんとだから、第二形態は明日の夜発表って感じで良いかな。
一応、第三形態までの予定。
明後日から夜勤なんで、第三形態どうすっかな。

あ · 2017/05/06(土) 02:06:36.33

>>236
そうなのかなぁ。
例えばそれぞれのどんな例からシンプルさがわかる？
後学のため教えて欲しい

あ · 2017/05/06(土) 02:11:17.59

>>241
Go版、マシどころか疎にしておいたところ密にされてしまったな。
ノブのないドア、ノブはあるけどラッチのないドア
実現する術がなくなったね。

With Withなんて気色悪い無理に継承関係を作ったような型作るくらいならもう継承とか全部捨てたほうがマシ。
もうちょっと真面目にやって。

**デフォルトの名無しさん** · 2017/05/06(土) 03:50:07.06

Kotlinになれるためにアプリを作ってるんだけど、久しぶりにc++触るとセミコロンがうっとおしくなるね
参照、ポインタ、値を自由に扱えてかつ新しい言語の特徴を捉えてるような言語が出てほしい

**デフォルトの名無しさん** · 2017/05/06(土) 06:35:37.73

勝手にHaskellをスレタイから省くな。

**デフォルトの名無しさん** · 2017/05/06(土) 07:19:08.10

>>252
前スレの埋め込みを使った再帰型の試みとして、主要なメソッドを再定義しなければならない版より「マシ」と言ったまでで
君のチャンネル版よりマシという意味ではない

それは他言語版と同じ設計で比較しやすくしたって程度だから気にしないで

**デフォルトの名無しさん** · 2017/05/06(土) 07:23:37.59

各自、次世代言語に求めるものが違うのだろうけど、
気を悪くしないで欲しいがHaskell外してKotlinは個人的にはないかな。
敢えて外すなら次世代感満載のAgdaを入れて欲しい。
が、呼び水としての趣旨からしたらHaskellを敢えて外す理由が分からない、個人的な怨嗟？

**デフォルトの名無しさん** · 2017/05/06(土) 08:00:28.21

実用性が乏しすぎるので次世代にふさわしくないとの事
あと前スレでまともなコードを掲示しなかったので、そもそもHaskellerが居ない事が分かった

**デフォルトの名無しさん** · 2017/05/06(土) 08:15:37.40

>>256
Javaより古いHaskellを次世代言語に混ぜた初代スレの>>1がどうかしている。
初代スレはHaskellの美しさを語るエアプログラマーが多かったが
次世代言語の実用性を語るスレに変わってよかったと思うよ。

**デフォルトの名無しさん** · 2017/05/06(土) 08:35:08.14

Haskell推しだが、次世代取れるほどライブラリ充実してないし、速くもないからsmalltalk的な立ち位置だと思ってる。
次世代じゃ無いけど、学ぶべき価値ある言語。

**デフォルトの名無しさん** · 2017/05/06(土) 08:41:48.81

>>255
参考まで、ほぼ同じ設計にした場合の
Ruby版 http://ideone.com/7VnOfe
Python版 http://ideone.com/UngSO8
Scala版 http://scastie.org/30851
Swift版 http://swift.sandbox.bluemix.net/#/repl/59032b64ebfba02b8d274320

**デフォルトの名無しさん** · 2017/05/06(土) 08:43:22.81

>>257
Mix-inとか言われては書けなかったね。
普通のクラス代りなら何とかなったが。
そもそも目的のプログラム作るアプローチとして関数かクラスかなのに、クラス作れは問題としてオブジェクト指向に有利過ぎ。
実際に動くプログラムで拡張勝負のが公平っしょ。
だから>>240提案した。

あ · 2017/05/06(土) 08:50:48.08

>>255
なるほど。申し訳ない絡み方したな。
smalltalkでもパッシングに徹すればひたすらコーディング量はあるけど割りと文句無いのできそう。
>>256
Kotlinなしなの？使いやすいのに。実用性あるから？

**デフォルトの名無しさん** · 2017/05/06(土) 08:56:13.51

各言語、得意分野あるからな。
証明付きでプログラム書けとかなったら、Coqなどの証明支援系の独壇場で、
他言語の入り込む余地がないように思われるが如何？

**デフォルトの名無しさん** · 2017/05/06(土) 08:58:57.84

Bertrand MeyerがEiffelを大事そうに抱えながら>>263を睨んでいるぞ。

**デフォルトの名無しさん** · 2017/05/06(土) 09:31:45.79

自分もRubyやGroovy使ってたせいかもしれないが
Kotlinは言語としては悪くないけど次世代感は感じない
golangぐらい簡素な仕様にしてくれればまた違ったとは思うけどJVM言語だしなあ

**デフォルトの名無しさん** · 2017/05/06(土) 10:21:48.72

言語が次世代でありさえすればライブラリはJVMでもなんでもいいぞ
ライブラリ関係ないなら、ライブラリがない言語でも参加しやすい

**デフォルトの名無しさん** · 2017/05/06(土) 10:22:29.07

>>262
> smalltalkでもパッシングに徹すればひたすらコーディング量はあるけど割りと文句無いのできそう

具体的にはどこらへんにその「量」を感じた？
ドアの振る舞いを記述してるコード自体はGoで書くよりずっと簡潔でステップ数も少ないはずだけど

念のため補足すると件のSmalltalk版では、通常はGUIやIDE任せにするクラスやメソッドの定義
（ちなみにGNU Smalltalkなどを除き、IDE前提のSmalltalkにはクラスやメソッド定義の構文が無い）
をあえてクラスへのメッセージングでやっているのでそのぶん冗長にみえるかもしれないけど

**デフォルトの名無しさん** · 2017/05/06(土) 12:29:53.45

何でSmalltalkerさんは劣った設計で比較する事に拘ってんの？
Goが得意な技法はダメ、Smalltalkで書きやすい技法だけ使って書くっていう縛りでもあるの？

**デフォルトの名無しさん** · 2017/05/06(土) 12:43:22.47

>>259
同意

**デフォルトの名無しさん** · 2017/05/06(土) 12:46:26.00

>>268
どうしてそういう発想になるのか全く不明。
人間の言葉でしゃべって。

>>267 を補足すると、
compile:とかがやたら続いているコードブロックがクラスやトレイトの定義に相当する部分で、
それ以外がドアやストッパーを操作するサンプルコードな。

**デフォルトの名無しさん** · 2017/05/06(土) 12:52:37.52

>>268
いや別に拘ってないですよ

そもそも誤解があるようなので断わっておくとGoを貶めるつもりは全然なくて
Smalltalkに難癖を付けてるID:BE072L/9が前スレからGoが詳しそうなんで
その方がわかりやすかろうとGoを引き合いに出したまでです

Goの得意な技法を駆使した優れた設計ってどんなのですか？ぜひ教えてください
今のところ埋め込みスタイル以外で出ているのだとこういうのでしょうか？→http://ideone.com/yvttId
このお題自体では設計を工夫しにくいと言うことであれば、新たにGoに有利なお題をご提供いただければと

**デフォルトの名無しさん** · 2017/05/06(土) 12:58:55.97

>>268
あと、

> Smalltalkで書きやすい技法だけ使って書くっていう縛り

とのご指摘ですが、少なくとも Ruby、Python、Scala、Swift では Go よりすんなり書けています>>260 から
旧世代言語で書きやすい…ならともかく、Smalltalkで書きやすい技法だけって縛りにはならないですよね？

**デフォルトの名無しさん** · 2017/05/06(土) 13:05:23.06

愚問という便利な言葉がある
答える側には間違えるリスクがあるのに問う側を無リスクで無謬とするのは不公平

**デフォルトの名無しさん** · 2017/05/06(土) 13:51:25.64

その言語特有の機能で書いた方が優劣分かりやすくね？

**デフォルトの名無しさん** · 2017/05/06(土) 14:24:42.57

>Goの得意な技法を駆使した優れた設計

chan と select 使ったサーバープログラムなんでねーの。
ああいうふうにチャンネルに放り込んだものを適当に一列に並べてくれるのはかなり楽。

**デフォルトの名無しさん** · 2017/05/06(土) 15:30:08.75

ここまで次世代言語から>>240のコードが出てない件。
単純な力押し検索だから、難しいアルゴリズムでも無いんだが。。。
おいらも頭悪いんよ。

>>244の書き方でargs書き換えと、nsをcontentから取ってcsへ変更。sも折角だからwordから取ってwへ。

import System.Environment

search _ [] = False
search w cs | take (length w) cs == w = True
search w (_:cs) = search w cs

main = do
(file:word:_) <- getArgs
content <- readFile file
print $ search word content

**デフォルトの名無しさん** · 2017/05/06(土) 15:43:50.78

仕様変更への耐性だから、基準となる第一形態のコードの長さは問わない。
どんな変更があるか事前準備したクラスがあってもおk。
第三形態までの変更箇所の少なさが言語の優劣とする。

あ · 2017/05/06(土) 16:40:50.57

意見≒難癖とは生きづらいな

**デフォルトの名無しさん** · 2017/05/06(土) 18:13:57.91

事実に基づかない悪評価は難癖だわな

**デフォルトの名無しさん** · 2017/05/06(土) 20:12:56.46

エンジニアガイジのGo版ってあのなぜか最初から並列化を意識して書かれてたやつだっけ？

あ · 2017/05/06(土) 23:05:01.66

>>279
主観としての悪評価と客観としての悪評価を混同すんなよ…。
採点してる訳じゃないんだから。そこまで傲慢でも無いよ。

俺Rubyボロクソに言ってるけど、主観としてだよ。

>>280
並列化を意識してるんじゃないよ。
コンポーネントとして存在し得るかを考えただけ。
ノブがノブだけで存在できないなんておかしいじゃん。何にも繋がってない地面に転がったノブさえ定義できないのに、突然ドアについてる突起をノブだと言うくらい不自然じゃないの？
オブジェクト指向ってなんなの？
地面に転がってるのも、ドアについててもノブであって、ノブとしての役割を果たしているか否かでしかないのでは？
確かにそのノブがノブとして成立するのはドアについたときだろうけど、それ以前からそいつ自身の存在が変わったわけじゃないじゃん。

**デフォルトの名無しさん** · 2017/05/06(土) 23:09:30.32

>>281
んー。クローザーついてないドアにもスレッド使ってなかったっけ？

あ · 2017/05/06(土) 23:16:33.79

>>282
スレッドと言うかまあマイクロスレッド使ってるけど。
キューイングしてる所で同期をGoにやってもらった形に近い。
イベントやらメッセージパッシングと変わらんつもりだけど、キュー抜いて中もgoroutineなのは確かに悪手は悪手か。
それは確かにそうだな。

**デフォルトの名無しさん** · 2017/05/07(日) 02:09:25.68

まだHaskell信者が暴れてるのか
ラッチの開閉すら実装出来ないと前スレで判明してのによく再登場出来るな

**デフォルトの名無しさん** · 2017/05/07(日) 02:38:17.71

いやあの問題が糞だと思ったHaskellerが問題出してる流れじゃないの？

**デフォルトの名無しさん** · 2017/05/07(日) 02:59:03.65

>>284
実装はできてたでしょ？

**デフォルトの名無しさん** · 2017/05/07(日) 04:54:40.21

久しぶりに覗いてみたけど、お前らまだやってたの？
良く飽きないな

**デフォルトの名無しさん** · 2017/05/07(日) 08:02:58.35

Smalltalkerはお題で使って良い言語機能に縛りを入れようとするからクソ

**デフォルトの名無しさん** · 2017/05/07(日) 08:26:48.70

まぁここであーだこーだ言ったところで、大手の採用が多くなった言語が次世代扱いになるだけだからな
主に決めるのは外人だ

**デフォルトの名無しさん** · 2017/05/07(日) 09:55:32.27

>>289
まるでトクホや世界遺産に採用されるみたいな
官僚主義だな

**デフォルトの名無しさん** · 2017/05/07(日) 10:05:54.32

>>281
主観で悪評価しているなら、それこそ難癖以外の要素ゼロじゃないか。

**デフォルトの名無しさん** · 2017/05/07(日) 10:48:31.07

嘘ニュースを野放しにして個人の感想を問題視するのは本末転倒

**デフォルトの名無しさん** · 2017/05/07(日) 10:56:51.74

Haskell 難しすぎて叩きたくなるのもわかる。

**デフォルトの名無しさん** · 2017/05/07(日) 11:24:25.93

ほんと難しいよ
物を作る道具としては失格だな

**デフォルトの名無しさん** · 2017/05/07(日) 11:25:56.17

静的型が難しすぎて失格なんだよ
叩きたいことと叩くべきことが一致してない

**デフォルトの名無しさん** · 2017/05/07(日) 11:29:53.16

microsoft word の動作が難しいって意味での難しさだわな。
無意味なむずかしさだわ。

**デフォルトの名無しさん** · 2017/05/07(日) 11:56:43.37

性的型が難しいって。。。
自分で正しくプログラム組めてませんって言ってるようなもんじゃん。。。

**デフォルトの名無しさん** · 2017/05/07(日) 12:01:01.50

溜まってんのかな。。。
x性的型が
o静的型が

**デフォルトの名無しさん** · 2017/05/07(日) 14:33:06.42

お前らのゆう次世代言語って、キャットドア問題を解けるのか？

**デフォルトの名無しさん** · 2017/05/07(日) 14:53:43.84

>>299
キャットドア問題って言いたいだけだろお前
すでに答えは出てるし、そもそも問題の把握すら出来てないじゃないか？

**デフォルトの名無しさん** · 2017/05/07(日) 14:58:24.43

>>240
>>276
ライブラリ使うのとかはありかな？
主旨から外れるかもしれないが、こんなのどうだろう

import System.Environment
import Data.Conduit
import qualified Data.Conduit.Text as CT
import qualified Data.Conduit.Binary as CB
import Control.Monad.Trans.Resource
import qualified Data.Text as T
import Control.Monad.IO.Class (MonadIO)

searchSink :: (Monad m, MonadIO m) => T.Text -> Sink T.Text m Bool
searchSink w = do
n <- await
return $ case n of
Nothing -> False
Just s -> T.isInfixOf w s

main :: IO ()
main = do
(file:word:_) <- getArgs
x <- runResourceT
$ CB.sourceFile file
$= CT.decode CT.utf8
$$ searchSink (T.pack word)
print x

**デフォルトの名無しさん** · 2017/05/07(日) 15:03:42.15

キャットドアが解けて何かいいことがあるんですかね？

**デフォルトの名無しさん** · 2017/05/07(日) 16:13:25.59

>>301
仕様変更への耐性を競うだけなので、まあライブラリ使ってもそれで仕様変更に強いなら構わないけど。。。

Haskellとsmalltalkしか回答寄せて貰えてない。。。
キャットドアのクラス作るだけの問題よりも、客からこんな機能付けてって要望に応える形で仕様変更されたのを如何にコード変えずに対応するかって問題は実践向きで良いと思ったんだが。。。

**デフォルトの名無しさん** · 2017/05/07(日) 16:18:52.35

あと3時間もすれば会社行くからコードは明日。。。も出かける予定で無理か。。。
明後日には書くので、第二形態の問題だけ出しとく。

ファイル中に検索するキーワード見つかったら、見つかった数も表示するように機能追加。
見つからなかった時は表示しなくても良いし、表示を分けるの面倒臭かったら0個って表示で見つかった時と表示機能を共有しても良い。

**デフォルトの名無しさん** · 2017/05/07(日) 16:26:36.91

>>303
なるほどね
ならConduit使った方が処理簡単に挟めるから、仕様変更には強いと思う
あとはストリーム処理だから読み込むファイルが巨大になっても一定のメモリしか使わないってのも考えてみた

**デフォルトの名無しさん** · 2017/05/07(日) 17:24:00.66

>>303
多分実戦向きの問題でいい感じなんだと思うんだけど、出題レスがとっちらかってて全部探すのめんどくさくてやる気起きなくてすまん
綺麗に纏まったレスどれ？

**デフォルトの名無しさん** · 2017/05/07(日) 17:30:40.95

>>240と>>277だけ見てくれればおkかと。

**デフォルトの名無しさん** · 2017/05/07(日) 17:57:04.14

>>307
意図が良く分からないんだけど、Pythonで言えば

from sys import argv

def search(path, word):
____with open(path) as f:
________for l in f:
____________if word in l:
________________return True
________else:
____________return False

if __name__ == '__main__':
____print(search(argv[1], argv[2]))

みたいなのでいいの？　とりあえず書き捨ての簡単なプログラムから初めて拡張していく感じで
多分これ拡張しろって言われたらsearch関数まるっと書き直しちゃうけど

**デフォルトの名無しさん** · 2017/05/07(日) 18:08:49.23

>>308
オブジェクト指向も関数型言語も、仕様変更に強いって言われて広まったり注目されてるから、次世代言語も仕様変更に強くないと使える言語と言えないと思って。

だから、書き捨てでも良いし、どんな変更が来るか事前に予測した設計でも良いけど、設計変更に強いと言うのを示せるか？って感じ。
ちなみに私のHaskellは何にも考えてはいない。
自信があるとかじゃなくて、デザパタとか知らない。
関数型言語が設計変更に強いなら、まあ何とかなるだろうってノリ。

全体の趣旨
>>277

第一形態
>>240

第二形態<-今ここ
>>304

**デフォルトの名無しさん** · 2017/05/07(日) 18:14:46.33

おっと2問目もあったか
Pythonで言えば

def count(path, word):
____with open(path) as f:
________return sum(l.count(word) for l in f)

でも追加しておけばOKだな。うん。searchの内容一切使ってないけど変更は3行やね
つーかsearchももっと短くできたな

**デフォルトの名無しさん** · 2017/05/07(日) 18:18:38.81

>>309
仕様変更に強いっていってもこのお題の長さなら仕様変更というより新たに書き上げる短さを競うことになるな
一切再利用考えなくても三行だし

**デフォルトの名無しさん** · 2017/05/07(日) 18:23:23.71

>>304 Squeak/Pharo Smalltalk

| search |
search := [:fname :keywd |
　FileStream oldFileNamed: fname do: [:file |
　　| count |
　　count := 0.
　　[file match: keywd] whileTrue: [
　　　count := count + 1.
　　　file atEnd ifFalse: [file skip: 1 - keywd size]].
　　count
　]
].
search value: 'test.txt' value: 'something'

http://ws.stfx.eu/RU59LGEMKG9G

**デフォルトの名無しさん** · 2017/05/07(日) 18:23:58.94

そこをどうにか機能追加で
search test.txt hoge
Ture 4

みたいな感じに表示項目増えるように第一形態のコードを育てる様にして欲しいんだが。。。
関数名以外は中身が丸っと変わっても良いけどさ。

**デフォルトの名無しさん** · 2017/05/07(日) 18:27:46.84

え、関数名変えたらいかんの？
それはおかしいやろ
一回作った関数の振る舞いを変更するのはおかしい。別の関数を作るべき