「ラムダ式」を含む日記 RSS

はてなキーワード: ラムダ式とは

2020-10-22

anond:20201022105554

シェルスクリプトLisp回帰すべきなんですよ。

これが理想プログラミング言語

2020-06-27

プログラミングは一生安泰のスキルではない

プログラミングという言葉アフィブロガー御用達になって、SNSプログラマーを名乗るのが憚られる感じの昨今。

プログラミング勉強すればフリーランスで一生困らないみたいなこと書いてあるけど、そんな夢のスキルじゃないよ。

それなりにベテラン()を見てきたけど、結局はマネジメント層になれなければ会社にしがみつくことになる人が多い。

なぜなら概念レベルでの流行というものがあるから

これはvueかReactか、javaRubyかみたいな話じゃなくて、もう少し基本的な部分。

例えば大きいのはオブジェクト指向クラス/インスタンス概念

他には、ガベージコレクタ例外処理マルチスレッドデリゲートラムダ式、非同期処理、バインディングとビューモデルイテレータ、null安全

プログラミングを学んでる人には当たり前かもしれないけど、これらは十数年かけて徐々に当たり前になっていった。

ITバブルブイブイ言わせていたけど、これらをうまく扱えないベテラン結構いる。

固定長メモリポインタとmemsetで全てをまかなってきた層や、静的なモジュールで全部の画面を作ってたVB屋とか。

若いころは勉強すればいいと思うだろうが、理解はできてもそれを流暢に使いこなし適合するのは意外と難しい。

プログラムの中でその人の担当箇所だけいまいち読みにくくて、取り回しの悪いものになってしまう。いわゆるstaticおじさんというやつ。

これはベテランイラストレータシナリオライターが、デッサン構成力はあっても、なんか古臭いものが出来上がってしまうのに似ている。

こうなると若いチームメイトや新しいプロジェクトから敬遠される。

もちろん、COBOL案件が未だにあるように、レガシー資産を利用した仕事で腕を振るえる場所結構ある。

ただそういった環境既存人材企業にがっちり掴まれてることが多く、後から見つけて入り込むのは簡単ではない。

なので今いる場所仕事があるならば、それを失わないようにしがみ付くことになる。会社員であろうと個人事業主であろうと。

立身出世できなければ社畜。結局ほかの会社員と一緒だよ。

2020-06-21

C++11ラムダ式Auto変数

これきちんと学習すると、おれらベテランで3週間

そうすると一般コースだと半年から1年

そもそもC++11auto変数というと新規に追加されたautoキーワード型推論だと思う人だっているだろう。

1年のものを3ヶ月コース場合、脱落者はそれなりに出るだろう

それそのものはいいが、厚生労働省との話し合いも待っている。

1例を上げたがほかにもいろいろある。このコースの期間をおれらベテラン専門ならともかく、一般向けに3ヶ月とみつもったのだれ?

2020-05-24

さすがに、今話題になっているラムダ式の例の問題については

ノートPCで気軽にといていくには、ややおもい。

さすがに、これはデスクトップで24インチ液晶が2枚ほしくなる。

C++11はあまりすきではなかったんだが、面白いことを言う。

2019-09-10

anond:20190910110247

ラムダ式は分からない。

Linq文書を読んだことがある程度で、初心者と同等だね。

anond:20190910104309

元増田文法がわからないレベルなので、先にC#入門をやっといたほうがいいと思う

無名オブジェクトコード読む分には見た目でなんとなく読めると思うけど、多分ラムダ式とかlinqとかもわからんっしょ?

2019-03-20

anond:20190320104032

if~else~やforeachは知ってていいけど、LINQラムダ式、非同期実行まで教える必要はないって話じゃないの?

2018-11-30

の子IT開発のハードル高すぎない?

入り口スマホだったりするわけじゃない?

swift playgroundとかswiftが知ってる人フレンドリーではあるけど、初心者には分かる仕組みになってるのだろうか?

SI業界に入った子がSQL書けとか、ES6書けみたいなこと言われたってハードル高すぎないかねぇ。

AWSとかアラフォーの俺も全然からない。awscliでスナップショットとれるなんて今日初めて知ったよ。

今のプラグラミング言語って色んな言語を取り込んで高機能化してる訳じゃない?なんでそんなことしてるのか分かんないと思うのね。

伝わる人に言うと、JavaだってAutoBoxingが前提だったりするわけじゃん?42+"円"とか書いちゃう訳よ。コンパイルエラーにならないのも頑張りすぎだろと思うけど。

あとmaven使えば色んなライブラリ使えるわけじゃん?今ならGradleなのかい?よくわかんねぇけど。俺はよく分かんないけど、使いこなせてるのかね?

AWSもES2の説明はできてもS3の説明できる先輩がどれほどいるかストレージ仮想化知識が前提にない人は説明はキツいなと。AIMとか混ざると地獄よね。

プログラミングに戻ると、今どきの言語って最先端で書かれると記号や謎予約語が多かったりするんだけど諸先輩方は大丈夫かなと。

っていうか、ラムダ式とかもSI業界とかだとキツいよねと思うのだ。全然最新の技術じゃないのにね

2018-10-04

anond:20181004145230

俺が知ってるのはswitchよりelseifの方が早いとかラムダ式遅延評価とか

詳しい人はメモリとかレジスタレベルで語るからついていけない。ってか尊敬してる。

でもまあ理由あってうっとおしがってるから、語ってくる奴らは大したことないんだろう

2018-05-03

ラムダ式ってなんだよ

実務でもがんがん使ってんの?

2018-03-23

anond:20180323152408

でもたまにラムダ式とか書くときにfunction(){}って書くの面倒臭いよね…とかは思う。

2017-08-09

10年後も戦えるプログラミング言語

Java

ScalaとかKotlinかいろいろ言ってる奴いるが10年後にはどうせJavaが勝ってる。

ラムダ式とか取り入れてJavaも着実に進化しているからね。

Javaはnull安全じゃない!とかほざく奴はもちろん@CheckForNullアノテーション使ってから言ってるよな…?

フレームワーク流行り廃りがあるから微妙だが、勉強するならSpringにしておけ。それだけでいい。

JavaScript

Webブラウザに標準搭載のJavaScriptが無くなることもまずありえない。

あとやるならjQueryね。AngularJSとかすぐ廃れるから

学習コストが高いものって結局広まらいからさ…素直に現実を認めよう。

シェルスクリプト

AnsibleやFabric使ってるやつがいるがどうせ10年後にはブームが去り技術負債となっている。

シェルスクリプト代用できるのだからシェルスクリプトでやっておけ。

SQL

これだけ広まったRDBが今後使われなくなることはまず考えられない。

ORMは流行り廃りがあるが、SQLが無くなることはまずありえないのだからSQLをやっておけ。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2015-10-15

C# LINQ ラムダ式デリゲート型ではないため...

var val = list.Aggregate((a,b) => {});

コードを書いた時点で発生。

var val = list.Aggregate((a,b) => { return a; });

のように、戻り値指定すれば、型を推論できるようになって、エラーは消える。

関連として、こちらのページ重宝しそうっす。

http://csharp30matome.seesaa.net/article/129993518.html

2015-09-10

こんなラムダ式はありかな? .NET Framework C#

var s1 = (new Func<string>(() => { var o = "Wow!"; return o; }).Invoke());

var s2 = (new Func<int, string>((f) => { return f.ToString(); }).Invoke(100));

var s3 = (new Func<int, int, string>((f, g) => { return (f + g).ToString(); }).Invoke(100, 30000));

半角の不等号が使えないとか、pre記法?で日本語文字化けするとか、ほかの皆さんはよく不便しないよな。。

タダで使っているからまあいいや(過去には一応はてなポイント買ったことはある)。

2015-05-01

クロージャ」という言葉について

http://b.hatena.ne.jp/entry/kenokabe-techwriting.blogspot.com/2015/04/blog-post_30.html

http://kenokabe-techwriting.blogspot.jp/2015/04/amazon102-93.html

この記事自体はどうでも良いのだけど、以前「クロージャ」という言葉の初期の使用例を探したことがあったのを思い出したので、参考までに。

Landin "A λ-Calculus Approach" (1966)

We represent the value of a λ-expression by a bundle of information called a "clusure", comprising the λ-expression and the environment relative towhich it was evaluated.

我々は、ラムダ式の値を「クロージャ」と呼ばれる情報の束で表す。「クロージャ」はラムダ式とそのラムダ式評価に関する環境から成る


Moses "The Function of FUNCTION in LISP,or Why the FUNARG Problem Should be Called the Environment Problem" (1970)

A useful metaphor for the difference between FUNCTION and QUOTE in LISP is to think of QUOTE as a porpous or an open covering of the function since free variables escape to the current environment. FUNCTION acts as a closed or nonporous covering(hence the term "closure" used by Landin).

LISPでのFUNCTIONとQUOTEの違いについては、次のように考えるのが有用比喩になる。QUOTEは多孔的または開放的関数をおおっていて、自由変数現在環境へと脱出できる。FUNCTIONは閉鎖的(closed)または非多孔的に関数をおおっている(このことからLandinはクロージャ(閉包)という用語を使っている)。

(訳はhttp://kreisel.fam.cx/webmaster/clog/img/www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/funarg/funarg.html から)


Sussman and Steele "SCHEME: An Interpreter for Extended Lambda Calculus" (1975)

In order to solve this problem we introduce the notion of a closure which is a data structure containing a lambda expression, and an environment to be used when that lambda expression is applied to arguments.

この問題を解決するためにクロージャという概念を導入する。クロージャラムダ式とそのラムダ式引数適用されるときに使われる環境から成るデータ構造である


Steele and Sussman "The Art of the Interpreter" (1978)

We say that the procedure is closed in the current environment, and the &PROCEDURE-object is therefore called a closure of the procedure, or a closed procedure.

この手続き現在環境に閉じられている(closed)と言い、それゆえ&PROCEDUREオブジェクトはその手続きの「クロージャ」あるいは「閉手続き」と呼ばれる。

2014-10-30

C++って人類が扱えるのか?

昔 Modern C++ Design を読んだあたりで自分にはついていけない世界だわっておもいだしてSTLの使いにくさとかもあってしばらく興味を失ってたけど、ラムダ式とか導入されたとか記事をみかけるようになったあたりで「お、これなら書きやすそう」とか興味が復活してきたんで、本の虫とかQiitaあたりのC++記事を拾い読みするようになったけど、やっぱ「こんな細かい複雑な規則を把握して落とし穴にはまらないでコードを書くのは不可能」って結論に落ち着いた。

2014-06-19

http://anond.hatelabo.jp/20140619010953

forループは全部再帰に直せるので再帰を使う。

f(a, b, total)みたいな関数を考える。

aはまだ読んでない値のリスト、bは既に読んだ値のリストtotalは読んだ値の総和を意味している。

まり、aの先頭をx、残りをxsとしたとき

f(xs, b+x, total+x)と再帰的にa,b,total更新していけば、一個ずつリストを読んでいくことができる。

後はf(randoms, [], 0)を呼んで、totalが50を超えたらbを返すようにすればいい。

まあこんなん実質変数使ってるみたいなもんじゃねえか、というハナシではあるけど。

関数型のメリットはパーツの再利用がやりやすいというところにつきると個人的には思う。

たとえばこれの応用として、総和が50を超えたらじゃなくて総和が素数になったら総和を返すような関数f2を作れと言われたら?

コピペしてif文の中だけ変える?

……手続き型の発想だけだとそうするしかないかもしれないけど、

関数型言語なら、fにcheckという引数を追加して、check(total)がtrueならbを返すようにすれば簡単にf2f3を作ることができる。

ラムダ式を使って、条件を判定する関数をその場でポンと作ってfに与えることもできる。(今はJavaとかC++ラムダ式使えるね)

再帰があんまり深くなりすぎるとStack Overflowになってしまったり、速度がどうしても犠牲になりがちだったり、

もちろん向き不向きはあると思うけど、関数型便利ですよと、そういう話でよかった?

2014-04-10

http://anond.hatelabo.jp/20140410140446

ラムダ式最高だよね。

「○○が理解できないとオワコンになるぞ。」

という言葉の真意は、

勉強し続ける覚悟がないとオワコンになるぞってことだよね。

常に新しい技術革新が進む世界プログラマは大変だ。

2014-03-26

http://anond.hatelabo.jp/20140326140828

パラダイムが一緒ならあとは方言みたいなもんだよね。

パラダイムが違うと、パラダイム理解するのに時間かかるけど、それはもはや言語の問題じゃないし。


とか偉そうに言うけどLisp系(っていうかラムダ式?)は自分の自由時間じゃ覚えられそうにないと食わず嫌いしてます

ログイン ユーザー登録
ようこそ ゲスト さん