オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/02(日) 16:30:38.65

前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

**デフォルトの名無しさん** · 2017/05/29(月) 22:22:54.39

オッ

**デフォルトの名無しさん** · 2017/05/29(月) 22:25:41.12

ここまで国語力ない奴はじめてみた。

**デフォルトの名無しさん** · 2017/05/30(火) 02:01:38.87

>>652
同等じゃないよ

ポリモーフィズムはそもそも参照先が違う
演算によって処理を分けるif文とは全く違う

**デフォルトの名無しさん** · 2017/05/30(火) 02:16:15.25

>>651
呼び出す側が適宜、相手のインスタンスに「こういう動作して」って派生クラスぶっこむ場合が多いな
まぁ派生元 - 派生先でifしてるって捉え方もできようが
if - elseが下に7コ8コ並んで見難いのよりはマシだろう

**デフォルトの名無しさん** · 2017/05/30(火) 19:10:33.85

>>658
Objectの言葉の意味の通りじゃん

**デフォルトの名無しさん** · 2017/05/31(水) 17:32:41.97

オブジェクト指向開発の理解度を測るために民間団体の主催するJAVA検定を受けようと思うのですが、そもそもここの問題はオブジェクト指向となっているでしょうか

http://www.sikaku.gr.jp/js/jv/img/sample/1/jv1.pdf

過去に構造化プログラムとかクソ味噌言われていたので、オブジェクト指向に造詣の深い皆さんに評価して頂きたいです

**デフォルトの名無しさん** · 2017/05/31(水) 18:37:16.96

>>664
やめとけ

**デフォルトの名無しさん** · 2017/05/31(水) 18:46:16.77

理解度測るならフリーで仕事すればいい
稼いだ金額が理解度

**デフォルトの名無しさん** · 2017/06/01(木) 03:12:10.50

>>664
実務でやるなら、4番のシーケンス図よろしく「N」なんて打ち込ませねぇ
そもそもあんなクソみたいな手数を踏ませるはイカれてるっていうか、ユーザーは怠惰なんス
一手で済ます
たぶんログイン画面でセッション（あるいは何らかの認証情報）を持たすのが前提だあな

っていうか「Fuckyou」とか「let me die」って打ち込んだ時どうすんだね
この図だと未定義だから何してもいいよね、俺だったら「Fuckyou」ってタイプされたら水龍敬ランド出すし
「let me die」ってタイプされたらガルパンのまほお姉さまのエロ同人誌でも表示してやるわさ
……冗談やで？

というくらいなんかアレかも

**デフォルトの名無しさん** · 2017/06/01(木) 03:35:10.17

そしてまさかのNはユーザーの氏名でした、か（今アレって思って見直したら）　orz　ごめん手抜きした
まあいいや、見直すとして……ああうんお呼びでないか

シーケンス図を（マジメに）見る限り

・初めに二回ポップアップ出す（or二発画面遷移をせよってこと、メソッドが二発あるので）
・ユーザーがNっていれたら、初めに出たのとの同じポップアップを2発やる（displayFirstMess/displayPromptMessをもう一度ぶっぱしてるから）
・imputMessageでユーザーが入力をいれたら
　まずユーザー一覧を表示するのか、「検索方法を指定してください」と出すのかして（displayFirstMessはどうもでっかく二分岐してるのかもしれん、あるいはまた「検索方法を指定してください。」と出すのか）
　そのあとでallDisplayでドカっと下に長い表示を出すのか
　この辺要確認、たぶん書き手はそんなの想像してないと思う
　たぶんGoogle検索のようなのを想定してるはずなので
・ユーザーは表示された従業員名とID突き合わせて入力欄にID打ち込んでEってタイプする
　ここも確認が必要、クリックじゃねぇの？

ああうんこれメインフレーム時代のやり方やで

**デフォルトの名無しさん** · 2017/06/01(木) 03:36:55.80

あーうん、let me dieって言われたらまほ姉がおっさんにピーされる機能は実装が必要だな
俺以外望んでないけど未定義だからいいよね（実務じゃしないよ、冗談だから）

**デフォルトの名無しさん** · 2017/06/02(金) 01:49:27.48

今Haskellとの比較にPython/Rubyに追加で究極的なオブジェクト指向言語であるsmalltalkでコマンド作るべくgnu-smalltalk勉強中なんだが、条件分岐やループまでオブジェクトへのメッセージなんで、
squeak/PharoみたいなGUIなsmalltalkじゃない事でシステムブラウザ(動的クラスリファレンス？)無しじゃ相当厳しい。

Ubuntu Linuxでsudo apt install gnu-smalltalkしただけじゃgst-browser起動しなかったから、
tar玉落としてコンパイル段階から環境構築してやっと動いた。

んで思ったんだが、やっぱオブジェクト指向ってクラス覚えないと何も出来ないんじゃね？
中途半端なオブジェクト指向言語って構造化プログラミングの文法に助けられてて、
その辺誤魔化せてるだけのような気がして来た。

**デフォルトの名無しさん** · 2017/06/02(金) 07:47:26.08

>>670
システムブラウザまで使うならなぜGNU Smalltalkみたいな変わり種Smalltalkにこだわるのかわからんけど（何かPharoやSqueakじゃ駄目な事情が？）
クラス（というか組み込みのオブジェクト）の使い方を覚えないと何も出来ないというのはかなり正しい

ただそんなこともあってSmalltalk環境は相当早い段階から組み込みの（クラスを含む）オブジェクトに対する問い合わせ
つまりイントロスペクション機能やそれをサポートする（人間の短期記憶に負担をかけないようにする）
マルチウインドウシステムが発達したわけ

だから、繰り返すけどそれらの機構を大胆に削ったのウリのGNU Smalltalkで
「Smalltalk（やそれが体現するOO）が何か」を論ずるのはちょっと違うかもと老婆心ながら

**デフォルトの名無しさん** · 2017/06/02(金) 07:58:55.45

Smalltalkがウンコなだけだよ
アランケイにも捨てられたゴミ

**デフォルトの名無しさん** · 2017/06/02(金) 08:32:54.40

>>671
> 何かPharoやSqueakじゃ駄目な事情が？

すみません。ちゃんと理由が書いてありましたね。^^;
>>670
> コマンド作るべく

ただ最終的にGNU Smalltalkを使うにしても、まずはSqueakやPharoから入るのがいいかとは思います

>672
> アランケイにも捨てられたゴミ

アラン・ケイが Smalltalk を見捨てた発言をするのは宮崎駿の引退宣言みたいなもので
最初は1976年ごろからはじまって、10年ぶり5度目とかの恒例です

**デフォルトの名無しさん** · 2017/06/02(金) 09:09:40.41

ほい(おそらくガセ)

http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

**デフォルトの名無しさん** · 2017/06/02(金) 09:10:16.04

SmalltalkはIDEがなきゃCよりも書きにくく、
IDEを使うためにはヘンテコなOSモドキの使用を強制され、
それを我慢して使っても他の言語より書きやすいわけでもなく
マイナー言語なのでライブラリも少ない

まさにゴミ

**デフォルトの名無しさん** · 2017/06/02(金) 09:36:01.61

>>675

まあそう言わんと

ただヘンテコなゴミだと簡単に切り捨てるより、いろいろ調べて学びを得た方が面白いですよ

同時期に登場したStar、Cedar、Interlisp-D等、同様のOSモドキはいくつか生み出されましたが、
結局生き残って今も使われ続けているのはSmalltalkだけです

たまたま選ばれたということ（ジョブズやゲイツがそのルック＆フィールを模倣して広めてくれたということも含め）
もあるかもしれませんが、ホストOSに寄生する“異物”という宿命を背負いながらも変化を続け
趣味はあってもスタートアップで言語として選択される程度に有用であることは
ケイらの遅延結合性の徹底というコンセプトの有効性を示すよい例かとも

Smalltalkの底を流れる設計思想 - ダン・インガルス
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

「ソフトウェア工学」は矛盾語法か？ - アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html

**デフォルトの名無しさん** · 2017/06/02(金) 10:52:54.67

>>673
いあ、昔squeakやってたし、当時はクラスブラウザと自由自在Squeakあれば十分なくらい独学しやすい言語だと思ってた。
当時はJavaのクラスリファレンス(とら本)も分厚いのを上下巻2冊で売ってたし、クラスたくさん覚えて行くのが当たり前と思ってたからね。

HaskellもLispも、関数覚えておけば便利だけど、覚えてない知らない場合も自分で自作しやすい。
そう言う意味じゃCとかの構造化プログラミングも関数やクラスを基本にするんじゃなくて、Goto使わなくて済む構文によってスパゲティコードを無くすっていう自作し易さを目指す進化だったんよね。

**デフォルトの名無しさん** · 2017/06/02(金) 11:34:30.40

何というか、オブジェクト指向って出来合いの機能をたくさん用意する事で自作する機会を減らす方向の進化で、自作のし易さを加速させる、根源的な生産性を上げる進化じゃ無い気がして来たのよな。

**デフォルトの名無しさん** · 2017/06/02(金) 11:53:23.75

>>677
Squeakは経験済みでしたかそれは失礼いたしました

ただSqueak等でちょっと調べてみれば分かりますが、他の言語やそのIDEのやり方とは違いSmalltalk環境のGUIツールは基本
クラスを含むオブジェクトの持つイントロスペクション機能にちょっとしたGUIのガワをかぶせただけシンプルなしくみで動いています
それはつまりGNU Smalltalkでも、Squeak等が“GUIのガワ”が中でやっていることを式で書いてやればそれなりのことは事足りるということです

たとえば Integer >> #factorial というメソッドのソースが読みたければそれに methodSourceString というメッセージを送る
(Integer >> #factorial) methodSourceString
といった調子で、そしてこれがSmalltalkのシステムブラウザがやっていることのほぼ全てです

じゃあ、factorial や Integer はともかく、>> だの methodSourceString だのはどうやって分かるかというと
もちろん GNU Smalltalk のリファレンスをググるのも手ではありますが
#>> implementors で実装クラスを一覧したり、
#>> implementors anyOne methodSourceString で定義を見たりするのがSmalltalkでのやり方になります

覚えておくよりはその都度オブジェクトたちに尋ねるという彼らとの対話の妙をぜひお試しあれかし

**デフォルトの名無しさん** · 2017/06/02(金) 12:43:16.45

>>678
> オブジェクト指向って出来合いの機能をたくさん用意する事で自作する機会を減らす方向の進化

出来合いの（組み込みの）機能といっても、元は自作なんですよ（少なくともSmalltalkにおいては）
それらを簡単に実装できるという精神はHaskell、ひいてはFPに通じるところはあると思いますよ

それにHaskellにしてもパターンマッチや型クラスを含む型システムなどの便利な組み込みの機能の助けなしに、あるいは
リストなどのモナドの拡充なしに自作のしやすさの加速ができるわけでもないような気がしますが…違いますかね

**デフォルトの名無しさん** · 2017/06/02(金) 12:44:30.15

>>677
オブジェクト指向は、複雑さ、巨大さとどう戦うかというのが進化の方向
HaskellやLispでデカくて複雑なプログラム書いてみたら、オブジェクト指向にも有用な部分があることを理解できるんじゃない？
ちょっとしたコードの書きやすさだけで言語の良し悪しは決まらないよ

**デフォルトの名無しさん** · 2017/06/02(金) 13:19:41.98

Objective-Cにも動的にクラスに「おまえなにできるの？」って聞くメッセージあるし
基本的にあの辺りはインターネットみたいな動作しっぱなしの世界で
クラスってノードを動作中に抜き差しするみたいな感覚を指向してるからなぁ。

**デフォルトの名無しさん** · 2017/06/02(金) 13:25:35.15

インタフェース以外の継承はすべて糞

**デフォルトの名無しさん** · 2017/06/02(金) 13:27:17.37

>>679
その都度オブジェクトたちに尋ねるのが、まさにsmalltalkがオブジェクト指向の最たるものの所以で、当時も今もそこについては変わらないんですけどね。
さすがにgnu-smalltalkでは一覧性に難ありな所が＾＾；

逆です。
その便利な機能のみで、入出力とかはともかく、自分がこう動いて欲しいと望む機能を実現できる。
そこに関してsmalltalkとFPに通じる所があるのも同意します。
ただあれはsmalltalkであってsmalltalkじゃ無いというか。。。

smalltalkって制御構造もメッセージで実現してるけど、Haskellと同じで構造化プログラミングを模倣してるだけで、やや普通のオブジェクト指向言語より構造化プログラミングから逸脱してる気もしますし、確かに生産性は高いんですけど。

ただ、既存の関数やメソッドを一切使わず新しい機能を実現する手間は、その基本的な便利機能の充実度から、Haskellのが生産性は高いかと。
探すより作った方が早い場面もありますし。
(いあ、smalltalkは探すスピード上げる方向の進化と考えれば、作った方が早いって場面も少ないんでしょうが)

**デフォルトの名無しさん** · 2017/06/02(金) 13:33:45.72

>>681
昔はGUI部分も同じ言語で書いてたからオブジェクト指向が有用だったですが、今はGUI部分はHTMLなりXAMLで書くことも増えて来ましたし、複雑な部分はDSLに任せて分担作業が、複雑巨大なプログラムに対する解の様に思います。

**デフォルトの名無しさん** · 2017/06/02(金) 13:46:34.00

遅延結合って、実行時に型を調べて処理を分岐してるだけでしょ？

**デフォルトの名無しさん** · 2017/06/02(金) 13:57:11.97

>>684
> さすがにgnu-smalltalkでは一覧性に難ありな所が＾＾；
> ただあれはsmalltalkであってsmalltalkじゃ無いというか。。。

具体的にはどういったところがでしょうか？　後学のため教えていたければ幸いです

> smalltalkは探すスピード上げる方向の進化と考えれば、作った方が早いって場面も少ないんでしょうが

SmalltalkがOSモドキと忌み嫌われつつもイメージベースで居続けるのはこの利便性を捨てないためです
ユーザー定義のものも組み込みのものも区別せずにオブジェクトストアに保持し、OODBのように探せます

**デフォルトの名無しさん** · 2017/06/02(金) 14:05:56.39

>>686
実行時についてはそうなのですが、それを設計や運用時にも徹底する（それをサポートできるシステムであること）がミソです
決定をできるだけ先送りにして固定化しない、ぎりぎり直前でも（場合によっては事後でも）差し替え可能に保ちます
基本的な考え方はこちらに書かれていますのでよかったら読んでみてください

「ソフトウェア工学」は矛盾語法か？ - アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html

アラン・ケイもよく言っていますが、これができるのはおそらくLISPとSmalltalkくらいかと

**デフォルトの名無しさん** · 2017/06/02(金) 15:12:57.10

>>687
あれ。
Squeakの時に低レベルのもの書く時って、それ用のsmalltalk無かったでしたっけ？
名前忘れたけど。。。

gnu-smalltalkみたいなのが主流にならないと、結局OSモドキに引き篭もって外とやり取りなんですよね。。。
例えば鯖のログを必要な箇所だけ見れる様に加工したいって時でシェルやLLが使われますが、smalltalkはその代替えにならない。
その為だけにOSモドキを立ち上げる手間が壁になる。

まあ、それはHaskellも微妙な立場なんですが、シェル知らなくても、各種LL(HaskellはLLじゃ無いけど関数知らなくてもって意味でHaskell自身の関数も含む)の関数やクラス知らなくても、Haskellなら、自分の発想でこういう加工したいってすぐに自作出来ます。
ただ、コンパイルが遅いので、LLとどっちが便利かが微妙になるだけで。。。

smalltalkはOSモドキと一体の生産性ですが、現実問題、言語は問題解決の手段であって、手段を使用する事自体に手間が掛かってしまっては元も子もないと考えます。

。。。Haskellもその点で微妙ですけどね。
(runghcでLLとして実行しても型検査はするから起動がLLより遅い)

Haskellのパターンマッチや遅延評価やモナドは作り手の知識が少なくても「作りやすい」仕組みだと感じます。
一方のsmalltalkは知識が少なくても「探しやすい」仕組み。
そう感じました。

LLはどっちも80点だけど、総合点で上回る的な。
でも規模が大きくなると型付言語が欲しくなる。。。

**デフォルトの名無しさん** · 2017/06/02(金) 17:01:43.90

>>689
> シェル知らなくても、各種LL(HaskellはLLじゃ無いけど関数知らなくてもって意味でHaskell自身の関数も含む)の関数やクラス知らなくても、
> Haskellなら、自分の発想でこういう加工したいってすぐに自作出来ます。

つまりHaskellでは組み込みの関数をいっさい知らなくとも（使わなくても）ログの整形作業が自作できるのですか？
それは驚きですね（反語的に）

**デフォルトの名無しさん** · 2017/06/02(金) 17:24:22.28

出来ますね。
結局ライブラリ使った方が早いんですが、学習しながら作ると言う意味では即戦力です。

だからなんだと言われればそれまでですが、GUIとかのライブラリがポトペタで作れたりしないので開発環境としてはまだまだですが、言語としての学習コストは低いと思ってます。

**デフォルトの名無しさん** · 2017/06/02(金) 17:35:52.70

>>691
そんなことが可能な言語がこの世に存在するとはにわかには信じられません
実際に動作するコードを見せてもらうことは出来ますか？

**デフォルトの名無しさん** · 2017/06/02(金) 17:38:49.65

あ、さすがに入出力関数は使いますよ？
でも、その中間の整形処理は一切組み込み関数知らなくても作れますし、その行為自体もそんなに手間じゃ無いです。
Cとかでもある意味整形処理は全部自作出来るわけですが、手間が全然違います。

smalltalkもそう言う意味では少ない知識で自前で作れると思いますが、ロジック部分に関してだけは、Haskellのがより少ない知識で済んでると思います。
GUIまで含めるとライブラリの塊と言うかライブラリそのものなsmalltalkのが生産性は高いんですが。。。

それこそsmalltalkそのものがOSとして普及しないとあんまり意味がないと言うか。。。

**デフォルトの名無しさん** · 2017/06/02(金) 17:44:01.62

>>692
もう出勤1時間前なので流石に今日は作れませんが、何かコードを提示して、組み込み関数を自作して行きましょうか。

上でも書いたですが、制御構造と最低限の入出力関数があれば作れはします。
手間の問題というだけです。

**デフォルトの名無しさん** · 2017/06/02(金) 18:57:35.54

>>694
> 今日は作れませんが、何かコードを提示して、組み込み関数を自作して行きましょうか。

おもしろそうですねぜひお願いします

> それこそsmalltalkそのものがOSとして普及しないとあんまり意味がないと言うか。。。

Dockerとかありますし、ホストOS内でOSモドキを動かすことにマシンパワーや心理的障壁は下がってきていると思いますので
「意味がない」と言うことはないと思いますよ

**デフォルトの名無しさん** · 2017/06/03(土) 02:39:21.79

中規模以上の範囲におけるDRY原則を
実現するための手段が
オブジェクト指向じゃないの？
そういう意味ではオブジェクト指向が
なくてもプログラミング出来る。
しかし重複部分を無くすには
オブジェクト指向しかないでしょ？

**デフォルトの名無しさん** · 2017/06/03(土) 15:57:20.13

>>695
たしかに、昔に比べれば仮想化が当たり前になりましたしそうかも知れませんね。
急ごしらえですが、昼間寝てしまったので３時から急ごしらえで作りました。
使い勝手悪いので、行番号振ったりと改良の余地ありです。

import System.Environment
import Data.List

filterOfLine word = unlines.(filter (isInfixOf word)).lines

main = getArgs >>= \(file:word:_) -> readFile file >>= putStrLn.filterOfLine word

IOな関数は全部mainの方にあるので、自作するのはfilterOfLineのunlines,filter,isInfixOf,linesの４つということになりますね。

**デフォルトの名無しさん** · 2017/06/03(土) 16:19:39.76

まずunlines

unlines [] = []
unlines (xs:xss) = xs ++ "\n" ++ unlines xss

ちなみに、++も自作出来ます。
（全ての中沖演算子はカッコで囲めば２引数の関数になります）

(++) xs [] = xs
(++) [] ys = ys
(++) (x:xs) ys = x:(++) xs ys

**デフォルトの名無しさん** · 2017/06/03(土) 16:42:14.38

次にfilter

filter _ [] = []
filter f (x:xs) | f x == True = x:filter f xs
filter f (x:xs) | f x == False = filter f xs

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

isInfixOf

isInfixOf _ [] = False
isInfixOf xs ys | take (length xs) ys == xs = True
isInfixOf xs (y:ys) = isInfixOf xs ys

もちろんtake,lengthも自作可能。

take _ [] = []
take 0 _ = []
take n (x:xs) = x:take (n - 1) xs

length [] = 0
length (_:xs) = 1 + length xs

lengthはリストｰ>値なので末尾再起にしないとスタック消費するので、
末尾再起な補助関数使って作ったほうが良いですが。

length xs = length' 0 xs
......................where
.........................length' n [] = n
.........................length' n (_:ns) = length' (n + 1) ns

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

最後にlines
変なところでハマってました・・・。

lines ns = lines' [] ns
...................where
......................lines' [] [] = []
......................lines' ys [] = ys:lines' [] []
......................lines' ys ('\n':xs) = ys:lines' [] xs
......................lines' ys (x:xs) = lines' (ys ++ [x]) xs

**デフォルトの名無しさん** · 2017/06/03(土) 19:54:54.78

そういうのはブログでやっていただいて・・・

**デフォルトの名無しさん** · 2017/06/03(土) 21:44:39.04

たぶん2chしか書くところないんだよ
かわいそうに

**デフォルトの名無しさん** · 2017/06/03(土) 21:46:14.14

もともと糞スレだし

**デフォルトの名無しさん** · 2017/06/04(日) 11:29:48.53

てす

**デフォルトの名無しさん** · 2017/06/04(日) 14:24:55.57

>>697
ありがとございます
リストとパターンマッチのコンビは強力ですね

お礼がてら GNU Smalltalk でも書いてみました
普通に手続き的に書くとこんな感じです（インデントの全角スペースは適宜置き換えてください）

#!/path/to/gst -f
argv := Smalltalk arguments.
file := argv first.
word := argv second.

stream := FileStream open: file mode: FileStream read.
[stream atEnd] whileFalse: [
| line |
line := stream nextLine.
(line indexOfSubCollection: word) > 0 ifTrue: [line displayNl]].
stream close

少しだけ関数型的なものを意識するとこんな感じになりますか

#!/path/to/gst -f
argv := Smalltalk arguments.
file := argv first.
word := argv second.

lines := file asFile contents lines.
filtered := lines select: [:str | (str indexOfSubCollection: word) > 0].
joined := String join: filtered separatedBy: Character nl asString.

joined displayNl

**デフォルトの名無しさん** · 2017/06/10(土) 02:56:29.64

>>706
結局メソッド頼りですね。。。
いあ、全てがオブジェクト故のメソッド依存ですね。
Cとかなら、むしろ長くはなりますがロジック部分の関数は自作出来ますもんね。

Haskellの例はよく車輪の再発明と馬鹿にされますが、車輪の再発明しやすいと言うことは、少ない知識で基本的な関数から応用的な関数まで作れると言うことだと思います。

>>697を複数ファイルで串刺し検索と行番号表示に対応させてみました。
(myfunc.hs + searchword.hs)
使用例:
>searchword numbering myfunc.hs number.hs

行番号表示機能のみのコードを以前作ってて、それを改良した形です。
(myfunc.hs + number.hs)

ファイルにmyfunc.hs + OOとなってる通り、共通だったり今後も関数として使いそうなものはライブラリとして括り出してみました。

**デフォルトの名無しさん** · 2017/06/10(土) 02:58:17.25

myfunc.hs

module Myfunc where

import Data.List
import Text.Printf

consNum::(Int,String) -> String
consNum (i,xs) = printf "%4d:%s" i xs

numbering = unlines.(map consNum).(zip [1..]).lines

searchWord w = unlines.(filter (isInfixOf w)).lines

putFileContent (f,cs) = printf "%s\n%s" f cs

number.hs

import System.Environment
import Myfunc

zipFileContent fs = return.(zip fs).map numbering

main = getArgs >>= \files -> mapM readFile files >>=
............zipFileContent files >>= mapM_ putFileContent

**デフォルトの名無しさん** · 2017/06/10(土) 02:58:44.23

searchword.hs

import System.Environment
import Myfunc

zipFileContent w fs = return.(zip fs).
...................................map ((searchWord w).numbering)

main = getArgs >>=
............\(word:files) -> mapM readFile files >>=
............zipFileContent word files >>= mapM_ putFileContent

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

>>707
> Cとかなら、むしろ長くはなりますがロジック部分の関数は自作出来ますもんね。

いや、メソッドでもロジックは記述できますよ→http://ideone.com/xiEftE
逆にできないと考える理屈がちょっとわかりかねます

> 少ない知識で基本的な関数から応用的な関数まで作れると言うこと

言語それ自体の学習には向いていますね
SmalltalkはライブラリはもちろんIDEを含む処理系それ自体もSmalltalkで組まれているので
普段自分が使っている機能がどのように実現されているかを調べる過程で学習ができます
GNU Smalltalkはそこらへんがちょっと弱いのが難点ですね

無用かとは思いましたが、通常の方法で記述したナンバリング＋複数ファイル対応版も
#!/usr/bin/gst -f

(argv := Smalltalk arguments) isEmpty ifFalse: [
　word := argv first.
　files := argv allButFirst.

　files do: [:file |
　　| count |
　　file displayNl.
　　stream := FileStream open: file mode: FileStream read.
　　count := 0.
　　[stream atEnd] whileFalse: [
　　　| line |
　　　count := count + 1.
　　　line := (count printPaddedWith: Character space to: 4), ':', stream nextLine.
　　　(line indexOfSubCollection: word) > 0 ifTrue: [line displayNl]].
　　stream close]
]

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

>>710
ちゃうちゃう。
関数やメソッド抜きと言うか、知識がない場合でもって意味。
確かにsmalltalkの場合はガンガン調べられるのが強みですが。
うーん。。。調べる能力と作る能力の違いと言うのでしょうかね。。。
実際問題、smalltalk程の検索性は無いものの、haskellの関数もhoogleで大体ソース見れるんですが、今回敢えて見ませんでした。
(実はlinesだけ見たけど、逆に複雑過ぎて訳わかめでした)
実際のソースは効率とか可搬性も考慮されたソースですから、私ごときのソースと同じと言うことはないですが、表面上の動きだけは真似られます。
私の中では分岐さえ言語でサポートしてくれれば、ロジック部の自作はどんな言語でも可能で(チューリング同等)、haskellは分岐でifとかの余計な文字入れなくて済むのが楽だなぁとか、リストが基本だからアルゴリズムと相性良いなぁとかですかね。
配列だとリストが基本のアルゴリズムから、配列だったらどう実現する？って考えますから。
多分、最前線でプログラマしてる人はそう言うのを自然としてるんでしょうけど、私みたいなヘッポコは一旦haskellでワンクッション置くと普通の言語でもコード書ける様になりますね。
(少なくとも私は)

**デフォルトの名無しさん** · 2017/06/11(日) 10:27:47.17

>>711
> 分岐さえ言語でサポートしてくれれば、ロジック部の自作はどんな言語でも可能で(チューリング同等)

仰りたいことは分かるのですが、マシン語やラムダ式ましてチューリングマシンで何かを記述するのは
知的愉しみや学術・学習目的でならともかく、通常のプログラミングにおいては苦痛しかもたらしません
生産性を考えるなら、言語の機能や特性は
車輪の再発明のしやすさより、あるレベルまでのレイヤーの適切な抽象化に費やされるべきです

そういう切り口でメッセージングというパラダイムはいろいろなレベルの抽象化されたレイヤーに乗っけて
便利に使えるので私は気に入っています

**デフォルトの名無しさん** · 2017/06/11(日) 13:31:27.60

なにこの気持ち悪いスレ

**デフォルトの名無しさん** · 2017/06/11(日) 14:03:25.44

Person taro = new Person();
みたいな典型的な文法使ってくれる文には問題ないが、
関数内や引数のカッコ内で new したり、
コンストラクタ内でさらに new したり、
Person(new Car() ) みたいにコンストラクタの引数内でnewしてたり、
オブジェクト名のはずが array['taro'] みたいにクォートで囲まれて
'文字列' として連想配列のキーに指定されたりすると、
俺の中での「オブジェクト」のイメージが色々と崩壊する。
これどう解釈すりゃいいの？ってなる。

**デフォルトの名無しさん** · 2017/06/11(日) 14:03:32.47

HaskellerとSmalltalkerの最底辺の争い

**デフォルトの名無しさん** · 2017/06/11(日) 14:36:30.58

>>714
お前のオブジェクトのイメージがおかしいんじゃね？

**デフォルトの名無しさん** · 2017/06/11(日) 16:54:46.48

オブジェクト指向は「playと言ったら"再生"のことだろう」って
コードのわかりやすさ優先だけど
関数言語は「?って書いたらPRINTのことに決まってるだろ」って
『略語でタイプが減ってサイコー』厨が推進してる臭くて
どうにも胡乱(うろん:確かでなく、怪しいこと。うさんくさいこと)なものを感じる。

**デフォルトの名無しさん** · 2017/06/11(日) 17:41:37.82

感想文

**デフォルトの名無しさん** · 2017/06/11(日) 20:23:12.88

Haskellは実装が簡単
オブジェクト指向言語はクラスリファレンスがすべて

**デフォルトの名無しさん** · 2017/06/12(月) 08:23:44.68

>>712
それって結局ライブラリが揃っていて、探しやすければオブジェクト指向とか構造化プログラミングとか関数型とかのパラダイムはどうでも良いって言ってる様なものだなと。
そして、実際その通りなんですが、全てのプログラムのパターンを網羅するライブラリは事実上不可能です。
Delphiのコンポーネントでpascalインタプリタがあってポトペタで一行のコードも書かずにpascal処理系を作れたとしても。
結局どの言語もライブラリの関数なりクラスなりを組み合わせます。
smalltalkは検索しやすい方向へ進化し、Haskellは自作しやすい方向に進化したんじゃ無いかと。

そのsmalltalkコードは出力に依存してますが、私もRubyやPythonでよく書きます。
Haskellの場合は強制的に出力に依存しないコードになるので、number.hsのコードの最後の行を

mapM_ (putFileContent.(\(f, c) -> (f, searchWord word c)))

の様にputFileContentの受け取る値を横取りしてsearchwordコマンドを作っても良いです。
型さえ考慮すればnumbering以降から出力直前まで、好きな段階でsearchWord関数を使えます。

numberingとsearchWordそれぞれlines/unlines使ってるので汎用性高い代わりに無駄な処理も多いと言うなら、汎用性を犠牲にしてsearchWordにnumberingの中身を入れてしまえば良いです。

この様に特異な発想？にも柔軟に答えてくれます。

**デフォルトの名無しさん** · 2017/06/12(月) 11:40:59.36

>>720
> 全てのプログラムのパターンを網羅するライブラリは事実上不可能

ライブラリで、将来起きうるすべてのパターンを網羅しろというのは極論では？
学習目的でないなら車輪の再発明は避けるべきだし
よく使うパターンならライブラリ化（抽象化）されるべきだろうという主張に対し
件のご指摘は本末を転倒しています

> そのsmalltalkコードは出力に依存してます

「出力に依存する」ということの意味がわかりにくいのですが
抽出結果を各行逐次出力しているのが気にくわないのでしょうか？

それならそうでない処理の流れにすれば済む話で実際にも容易に書けます
（>>706 の２番目や >>706 の http://ideone.com/xiEftE 、http://ideone.com/RUJP49 ）
当初要求された仕様がどうなっていたか、何を重視するかといった方針の齟齬に過ぎないと思います

逆にたとえばご呈示のHsakellのコードで
メモリに一気には読み込めない巨大なファイルを扱わなければならないとしたら
今の枠組みのまま対応することはできないでしょう？それと同じ話です

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

？
遅延評価なのでどんなに巨大なファイルを一気に読む様なコードに見えても、実際には表示するぶんずつしか読み込まれませんが。。。

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

>>722
何の話かよくわからんが、遅延評価と遅延読み込みは違う。
遅延読み込みと非同期読み込みも違う。
何か勘違いしてないか？

**デフォルトの名無しさん** · 2017/06/12(月) 13:43:22.37

>>721
同じライブラリ化されるべきなら、より簡単にライブラリが作れた方が良いんじゃないか？と考えます。

また、ライブラリやクラスを使う際にはオブジェクト指向も関数型も差はないでしょうが、ライブラリを作る側だとクラスは使う時より楽じゃないと感じます。

**デフォルトの名無しさん** · 2017/06/12(月) 13:58:04.43

>>723
普通の言語のreadLine的なのが遅延読み込みですよね？
Haskellは表示しない値は無いのと同じ、表示して再度使う予定もないなら用済み。
(その証拠に、読み込んで複雑な処理させるけど表示しないコードは、何が書かれていようとそもそも何もしない。無限リストを表示させるとかも良い例)

一見全部読む混んで全部表示するコード書いても、表示に必要な分だけ読み込んで、表示が終わったら破棄されていきます。
普通の言語の遅延読み込みに相当するものも、遅延評価が勝手に似た様な働きをしてくれます。
違うのは、行毎とは限らない事くらいです。

**デフォルトの名無しさん** · 2017/06/12(月) 14:54:51.94

>>722
失念していました。であれば別の例を考えないといけないですね^^;

要は「部分読み込み→処理→出力」というスキームで進めなければならないシチュエーションでは
今のコードの枠組みは変えざるを得ないということが言いたかっただけです

ところでHaskellのreadFileというのは賢そいのですね
たとえば一番最後の行から逆順に出力するような場合
getArgs >>= \(file:_) -> readFile file >>= putStrLn . unlines . reverse . lines
でもファイル全体を読み込まずに済ませられる（つまり読み込むポジションのみ覚えていて適宜移動して読み込める）程度に賢いのですか？

**デフォルトの名無しさん** · 2017/06/12(月) 16:50:34.40

>>726
そこは痛い所ですね。。。
賢くないはずです。
Haskell.orgも、その弱点を知ってるので良い加減克服されててもおかしくないですが。。。

少なくとも不思議の国のアリスやこころのテキストをwebからコピペして読ませてますが、reverseしないのと体感速度に差が無いですね。
(一文字ずつreverseさせれば流石に体感速度下がりましたが、行毎は感じませんでした)
今時はメモリもGBが当たり前なので余程じゃないと体感出来ないのかも。。。
まあ、すでに(ターミナル次第ですが)Python/Rubyより遅かったりしますけどね。。。
(全面ByteString使用する様に書き換えれば同程度には高速化するでしょうが)

書き捨てコード同士では負けますが、ライブラリ化したらPython/Rubyの書き捨てコードより短くなります。

**デフォルトの名無しさん** · 2017/06/12(月) 20:22:55.90

Haskellでさ、ファイルを読み込んでアルファベット小文字を大文字に置き換えて
読み込んだファイルに上書きできる？

**デフォルトの名無しさん** · 2017/06/13(火) 09:56:27.83

Haskellに限らず楽勝ですね。

**デフォルトの名無しさん** · 2017/06/13(火) 10:23:22.38

ウンコHaskellerには出来ないよ

**デフォルトの名無しさん** · 2017/06/13(火) 20:11:42.46

>>730
いやあ、同名のファイルに直で保存しようとするとロックされるの失念してた。
そう言えばtempファイルがどうとかどっかで読んだなぁとかRWH読んでたけど見つけられなくて、
でも一旦別名で書き込めばtempファイルにこだわる必要無いじゃんって事で元のファイル名の頭にoutって付けて一旦保存して、
それを開き、内容をそのまま元のファイルに書き込んだった。

これこそ発想の転換w

**デフォルトの名無しさん** · 2017/06/13(火) 20:26:50.47

そんな簡単なコードも書けない言語で
まともなシステムなんて書けないと思わない？

**デフォルトの名無しさん** · 2017/06/13(火) 20:31:40.86

ん？
書けたけど？
正攻法じゃなかったのはおいらの知識不足が問題であって、言語の問題じゃ無いよ？
それに発想の転換と言うか、知恵と工夫で解決するのは、どんな言語使ってても必要な事。
だからっておいらがプログラマに向いてるわけじゃ無いのは理解してるが。

**デフォルトの名無しさん** · 2017/06/13(火) 20:31:48.79

>>731
ちょっとググればやり方わかるのにそれすら調べもせずに幼稚で姑息な思いつきをしたり顔で「発想の転換」とか草
結局、readFileのブラックボックス化をよしとしてるからそういうことになるじゃないの
自慢の車輪の再発明のしやすさとやらは何処へ？

**デフォルトの名無しさん** · 2017/06/13(火) 21:33:59.97

少ない知識で作りたいものを作れるってのが利点だと思ってるからね。
車輪の再発明しやすいのも、その一環。
その宣伝のためにも敢えてあまりググらない。
ググって見つからないぐらいで作りたいものを作れなくなる様な言語じゃ困る。

**デフォルトの名無しさん** · 2017/06/13(火) 21:38:43.06

いやググれよHaskellerが馬鹿だと思われる

**デフォルトの名無しさん** · 2017/06/13(火) 22:21:04.68

そゆのは他の優秀なHaskellerに任せる。
おいらは実際頭悪いし。

**デフォルトの名無しさん** · 2017/06/13(火) 22:24:43.82

haskellにはカプセル化の概念がないんだよね

**デフォルトの名無しさん** · 2017/06/13(火) 22:28:26.94

カプセルすべきものがないからな

**デフォルトの名無しさん** · 2017/06/13(火) 22:30:05.60

カプセル化すべきものとは？

**デフォルトの名無しさん** · 2017/06/13(火) 22:31:18.19

つまりカプセル化はオブジェクト指向に本質的に必要ないものとなるわけですな

**デフォルトの名無しさん** · 2017/06/13(火) 22:32:14.23

本質的には何も必要ないよ？
オブジェクト指向をやりやすくするための
言語仕様を備えてるだけなんだから

**デフォルトの名無しさん** · 2017/06/13(火) 22:32:39.86

haskellはオブジェクト指向言語と言っていいでしょう

**デフォルトの名無しさん** · 2017/06/13(火) 22:34:25.58

>>742
何も？何もいらないのか？それでほんとにオブジェクト指向？なんか怪しいな

**デフォルトの名無しさん** · 2017/06/13(火) 22:42:17.98

条件分岐を書かないことで疎結合にする
これがオブジェクト指向の本質

**デフォルトの名無しさん** · 2017/06/14(水) 01:43:10.82

Haskellはモジュール単位で隠蔽機能がある。
モジュール公開側も公開したいものだけ指定出来るし、importする側も、さらに細かくこの関数だけ読み込むとか、この関数以外を読み込むとか、細かく指定出来る。

**デフォルトの名無しさん** · 2017/06/14(水) 01:47:53.66

>>743
オブジェクト指向もメソッドチェーンで宣言的プログラミングを目指したけど、何年経っても手続き的な側面を脱却出来ない時点で失敗作。
一緒にすんな。

**デフォルトの名無しさん** · 2017/06/14(水) 07:43:27.89

Haskellもモナドで手続きも書けるようにしたけど
モナドで手続き書くとマジ終わってるレベルで読みにくくて冗長
かと言ってHaskellでも性能出そうと思うと手続きを書かざるを得ない
つまりウンコ言語

**デフォルトの名無しさん** · 2017/06/14(水) 07:58:06.20

http://qiita.com/as_capabl/items/6919e338340690f37a92

実際には遅くて冗長
それがウンコ言語Haskell

**デフォルトの名無しさん** · 2017/06/14(水) 08:21:45.76

まだカプセル化不要とか言ってるバカが居るのか

**デフォルトの名無しさん** · 2017/06/14(水) 08:25:14.80

>>749
ネットに踊らされてないで自分でやってみなさい

**デフォルトの名無しさん** · 2017/06/14(水) 08:43:15.00

>>751
やってみた？

**デフォルトの名無しさん** · 2017/06/14(水) 08:45:08.83

>>750
カプセル化が必要だとするならそれは設計が間違っているというのがhaskellの議論で明らかになったわけです

**デフォルトの名無しさん** · 2017/06/14(水) 09:03:03.20

>>747
手続き型つまり構造化プログラミング
オブジェクト指向は構造化プログラミングの
延長線上にあるものだから手続き型は友達です
仲良くしましょう

**デフォルトの名無しさん** · 2017/06/14(水) 09:08:24.09

純粋関数型と呼ばれるどこぞの言語にもdoがあるでしょう
つまり手続き型は数学的モデルのあるちゃんとした方法なんです
それを駄目だと思うのは慣れすぎてマンネリ化してるからなんです

**デフォルトの名無しさん** · 2017/06/14(水) 09:10:44.44

原点に帰ろう
c言語からやり直そう
linuxはc言語で書かれていますが
完全にオブジェクト指向です

**デフォルトの名無しさん** · 2017/06/14(水) 09:42:08.75

>>753
前どこかのスレにコマンド引数の偶数番目と奇数番目を分けてリストに入れて、後から1、2番目を一つの組み。3、4番目を2つ目の組み。。。
みたいにして表示するコードをHaskellとPythonとRubyで書いたが、皮肉にもグローバル変数があっても良いはずのHaskellだけがグローバル変数作らないで済んで、
PythonとRubyはグローバル変数作らないとダメだった。

Pythonは書き様によってはグローバル変数無くせそうだったし、Rubyのsliceヒントに別の書き方のが全言語でグローバル変数要らなくなったし、シンプルになったけど。

**デフォルトの名無しさん** · 2017/06/14(水) 09:46:27.58

>>755
doの書き方は手続き型言語でも宣言的と呼ばれる関数(メソッド)呼び出しの羅列の再現。
ループとかの手続き丸出しなのの再現はあくまで再帰。
だが再現はループの代わりにもなるが、あくまで値を返す関数。
メソッドチェーンと同じで返ってくる値の型を意識する。