タグ

Haskellに関するd_akatsukaのブックマーク (11)

  • Haskellの勉強で詰まってる部分 - mizchi's blog

    まず前提として、大量に間を割いたわけではない。週末気が向いた時にちょろっとやるぐらい。わからないと放置するので全然進んでない。 このテキストについて、名前空間の扱いやcabalについて一部批判と受け取られない表現があるかもしれないが、これはおそらく僕の無知より発しているので、わかってる人はバーカと罵っていただきたい。(この界隈、教えてといっても教えてもらえないので、罵ってもらうのが楽ではある) あくまで現在の状況。すごいHは読んだが全部は理解していない。頻繁に詰まるが解説を読めばなんとかなったりならなかったりしている。 モナドについて 箱のメタファは適切ではないとかなんとか言われているのをたまにみるが、自分はアレで理解している。 Functors, Applicatives, And Monads In Pictures - adit.io 問題はモナドがわかってもモナドで包まれた値の中

    Haskellの勉強で詰まってる部分 - mizchi's blog
  • マルチコアでスケールするようになったHaskell | IIJの技術 | インターネットイニシアティブ(IIJ)

    (※)このページで紹介している事項は記事初出時点の情報に基づいたものです。ページはアーカイブとして掲載しています。 ツイート 2015年2月12日 Glasgow Haskell Compiler(GHC)は、関数型言語Haskellの主要コンパイラです。GHCは(並列性に加えて)並行性を主要な目的として長年開発されてきました。そのため、GHCには、 軽量スレッド(グリーンスレッド) マルチコア用の軽量スレッド・スケジューラ マルチコア上での効率的なメモリアロケータ マルチコア用のガベージコレクタ など、マルチコアで簡潔に並行性を実現するための部品が揃っています。そこで、Haskellで Web サーバなどの並行プログラムを書き、GHC でコンパイルすれば、マルチコア環境でスケールするのを期待したくなります。 残念ながら GHC 7.6.3 までは、入出力を司るIOマネージャの実装にボト

    マルチコアでスケールするようになったHaskell | IIJの技術 | インターネットイニシアティブ(IIJ)
  • Rubyにはウンザリ!動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD

    この記事を書き上げるには、相当長い時間がかかりました。来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって? それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発(TDD)の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい

    Rubyにはウンザリ!動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
  • Scala の Future と Haskell の IO

    大量の ESLint エラーに対処する技術 / The technology to fight with many ESLint's errors

    Scala の Future と Haskell の IO
  • プログラミング言語Frege(フレーゲ)を紹介します - uehaj's blog

    これはマイナー言語 Advent Calendar 2013の21日目の記事です。 Frege(フレーゲ*1 )を紹介します。 Fregeは、Java VM上で動作するHaskell風の言語です。以下のような特徴を持っています。 純関数型言語 非正格評価(いわゆる遅延評価) Hindley-Milner型推論に基づく静的型言語 これらの特徴は、Haskellと共通するものであり、構文も基的なところについてはHaskellとだいたい同じか似ているかもしくはサブセットです。標準関数やデータ型やモジュールについても、Haskell 2010からたくさん引っぱってきているそうです。 しかしながら、Fregeはその目標において、Haskellとの完全な互換性を達成しようとはしていません。実際かなり違っています。特にJava VM上で有用であることに重点が置かれており、プリミティブ型はJavaのもの

    d_akatsuka
    d_akatsuka 2013/12/21
    JVMで動くHaskellっぽい言語
  • 「Haskellは企業でも十分実用になる」、NTTデータがソースコード解析サービスの舞台裏を披露

    NTTデータは、レガシーシステムのソースコードを解析して設計書として出力するサービス「設計書リカバリーサービス」を提供している(ニュースリリース、ITproの記事1)。このサービスは「Haskell」というプログラミング言語で実装されている(ITproの記事2)。2013年11月22日に開催されたイベント「数理システムユーザーコンファレンス2013」のセッション「COBOL meets Haskell ~ Haskellを用いたCOBOLのプログラム解析ツールの開発事例 ~」では、NTTデータ 技術開発部 ソフトウェア工学推進センタの岡田譲二氏が、このサービスをHaskellで実装した理由などを明らかにした(写真1)。

    「Haskellは企業でも十分実用になる」、NTTデータがソースコード解析サービスの舞台裏を披露
  • Retiring FP Haskell Center - FP Complete

    Back in April, I announced plans for the future of School of Haskell and FP Haskell Center. We’re now half a year later, and it’s time to start moving ahead with those plans. The summary is: FP Haskell Center will be retired by the end of the year, please migrate your projects now. School of Haskell will be transitioned to its own domain name, schoolofhaskell.com, with hopefully no interruption in

    Retiring FP Haskell Center - FP Complete
    d_akatsuka
    d_akatsuka 2013/09/18
    Haskell用のIDEらしい
  • http://www.girlloveshaskell.com/index.php

  • HaskellでJSON Web APIを作ると幸せになれるかもよ - Fujimura

    先日Yesod勉強会第2回でHaskellでJSON Web APIを作る話しをしました。 内容的には下記のような感じです。 Web開発はクライアントサイドの技術が発達して、Web APIを作る機会が多くなった最近のフロントエンドは難しいし、分業したほうがいいっぽいYesodは独自技術&フルスタックすぎて分業辛いではscotty + persistent + aesonでJSON Web API作ろうぞなんか想像以上の相性の良さ。幸せになれそうなイキフンがビシビシ来てる発表資料はこちら。 ちなみにscottyはsinatraみたいな奴、aesonはJSONライブラリ、persistentはORマッパーです。 何しろaeson + persistentの相性がバッチリでした。発表後に@thimuraさんが見つけた じつは persistent のスキーマ定義で、テーブル名の横に js

    HaskellでJSON Web APIを作ると幸せになれるかもよ - Fujimura
  • 高速WebサーバMighttpdのアーキテクチャ | IIJの技術 | インターネットイニシアティブ(IIJ)

    (※)このページで紹介している事項は記事初出時点の情報に基づいたものです。ページはアーカイブとして掲載しています。 ツイート 2012年5月29日 IIJ-II技術研究所では、2009年の秋からMighttpd(mightyと読む)というWebサーバの開発を始め、オープンソースとして公開しています。この実装を通じて、マルチコアの性能を引き出しつつ、コードの簡潔性を保てるアーキテクチャにたどり着きました。ここでは、各アーキテクチャについて順を追って説明します。 ネイティブ・スレッド 伝統的なサーバは、スレッド・プログラミングという手法を用いています。このアーキテクチャでは、1つのコネクションを1つのプロセスかネイティブ・スレッドが処理します。 このアーキテクチャは、プロセスやネイティブ・スレッドを生成する方法で細分化できます。「プール」方式では、あらかじめ複数を起動しておきます。例としては

    高速WebサーバMighttpdのアーキテクチャ | IIJの技術 | インターネットイニシアティブ(IIJ)
  • 1