タグ

Programmingに関するkakkun61のブックマーク (117)

  • 継続渡し・コールバックを読みやすくする言語機能たち(Koka・Gleam・Roc) - 星にゃーんのブログ

    継続渡しスタイル、あるいはコールバック関数は非常に強力なテクニックだ。 例えばJavaScriptでは、非同期処理を扱う.thenメソッドが有名どころだろう。 fetch("http://example.com/movies.json") .then((response) => response.json()) .then((movies) => console.log(movies)) 継続渡しスタイルは読みにくい。そこで、JavaScriptではasync構文が導入されている。 const response = await fetch("http://example.com/movies.json"); const movies = await response.json(); console.log(movies); awaitの振る舞いは、以下のような読み替えルールがあると考えると

    継続渡し・コールバックを読みやすくする言語機能たち(Koka・Gleam・Roc) - 星にゃーんのブログ
  • C99 doesn't need function bodies, or 'VLAs are Turing complete'

    C99 doesn't need function bodies, or 'VLAs are Turing complete' 19 Feb 2022 Preface The 1999 revision to the C programming language brought several interesting changes and additions to the standard. Among those are variable length arrays, or VLAs for short, which allow array types to have lengths that are determined at runtime. These can show up in different contexts, but for the purposes of this

  • プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog

    κeenです。最近JEITAのソフトウェアエンジニアリング技術ワークショップ2020に参加したんですが、そこで五十嵐先生、柴田さん、Matzとパネルティスカッションをしました。その議論が面白かったので個人的に話を広げようと思います。 年末年始休暇に書き始めたんですが体調を崩したりと色々あって執筆に時間がかかってしまいました。 時間を置いて文章を書き足していったので継ぎ接ぎ感のある文体になってるかもしれませんがご容赦下さい。 というのを踏まえて以下をお読み下さい。 いくつか議題があったのですが、ここで拾うのは一番最後の「プログラミング言語の未来はどうなるか」という話題です。 アーカイブが1月末まで残るようです。もうあと数日しかありませんが間に合うかたはご覧下さい。 そのとき各人の回答を要約すると以下でした。 五十嵐先生:DSLを簡単に作れる言語というのが重要。それとプログラム検証、プログラム

    プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog
  • Google Codelabs

    Learn about the Google I/O 2015 codelabs. In this codelab, you'll learn how to add advertisements to your iOS application using AdMob. In this codelab, you'll learn how to get Google Analytics added to your application. In this codelab, you'll learn how to add a Sign In with Google button to your Android App and use it to allow your users to sign in with the Google ID In this codelab, you'll learn

  • FRPの話 - maoeのブログ

    Haskell Advent Calender 2012で久々にブログを書くということで、ついでにはてなダイアリーからはてなブログに移行してみた。記事やコメントはもちろんのこと、はてブも移行でき、なおかつundoもできるという素晴らしい仕様なので、安心して移行することができた。 さて、今回はFunctional Reactive Programming(FRP)の話。FRPとは、時間やシステム外部からの入力に対して応答するプログラムを関数的に表現する方法とでも言えばよいだろうか。 FRPというとまだ定番の実装もなく、実用にはほど遠いと考える人もいるかもしれない。実際、FRPの実装に関してはまだいろいろ研究・改良の余地があるとは思うものの、以前のように簡単にメモリリークするようなことも無く、最近では試してなるほど便利そうと思える段階にまでは洗練されてきていると思う。 FRPが登場してからの1

    FRPの話 - maoeのブログ
  • Crystal : The Crystal Programming Language

    Batteries includedCrystal’s standard library comes with a whole range of libraries that let you start working on your project right away. Check the API docs # A very basic HTTP server require "http/server" server = HTTP::Server.new do |context| context.response.content_type = "text/plain" context.response.print "Hello world, got #{context.request.path}!" end address = server.bind_tcp(8080) puts "L

    Crystal : The Crystal Programming Language
  • Coding Games and Programming Challenges to Code Better

    Level up your coding with games, puzzles, and challenges.

    Coding Games and Programming Challenges to Code Better
    kakkun61
    kakkun61 2014/10/10
    おもろい
  • カーネルハッカー・小崎資広の「コードを読む技術」 | サイボウズ式

    サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回(毎週火曜日に掲載、これまでの連載一覧)。「WEB+DB PRESS Vol.80」(2014年4月24日発売)に執筆した「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部) 文:西尾 泰和 イラスト:歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通エンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。

    カーネルハッカー・小崎資広の「コードを読む技術」 | サイボウズ式
  • わかりやすいREADME.mdを書く

    GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに

  • オブジェクト指向は禁止するべき - きしだのHatena

    プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムのに、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ

    オブジェクト指向は禁止するべき - きしだのHatena
  • Elm - delightful language for reliable web applications

    A delightful language with friendly error messages, great performance, small assets, and no runtime exceptions.

  • ATSプログラミング入門

    このは Introduction to Programming in ATS の日語訳です。 日語訳の維持管理は JATS-UG - Japan ATS User Group が行なっています。 翻訳に参加するには ATS2公式マニュアルの日語訳 を参照してください。 プログラミング言語としての ATS は豊かな構文と機能を両立しています。 このでは ATS の中心となる機能を読者に解説します。 それらは基的な関数型プログラミング、単純な型、(再帰的に定義された) データ型、多相型、依存型、線形型、定理証明、定理証明によるプログラミング (PwTP)、そしてテンプレートを使ったプログラミングなどです。 一般的なプログラミングに馴染みのある読者を仮定してませんが、このは相当のプログラミング経験のない読者には少し難しいかもしれません。 All rights are reserve

  • 意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観

    意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の

  • プロトタイプベースの誤解 - Smalltalkのtは小文字です

    クラスベースのOOとプロトタイプベースのOOで決定的に違うのは、プログラムを動かしている最中にオブジェクトが出来ること、すなわちメソッド(method)を追加したり再定義したりできるかだ。 404 Blog Not Found:タイプ・クラス・プロトタイプ - OOの語彙 これはひどい。w オブジェクトに対して動的(実行時)にメソッドやインスタンス変数を追加できることと、“プロトタイプベース”においてオブジェクトがそれが属するクラスによらず独自のメソッドやインスタンス変数を持てることとは別の話です。 あらためて、「プロトタイプベース」という用語自体に問題が多いことを実感させられる記事でもありますね。個人的には、クラスを用いないオブジェクト生成手法の話でないのならば(つまり、「プロトタイプの複製でオブジェクトを生成する」ことが話の筋でないならば)「プロトタイプベース」ではなく、「インスタン

    プロトタイプベースの誤解 - Smalltalkのtは小文字です
  • “オブジェクト指向”の本質 - Smalltalkのtは小文字です

    「OO(OOP)とは何か?」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。 リスコフのユーザー定義型(aka、抽象データ型。データと手続きのセット)そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするOO(ストラウストラップ。aka、クラス指向。継承を使ったプログラミング)。もしくはそれらを一般化したOO(クック。aka、手続きによる抽象化)。 メッセージングにより動的性を実現しようとするOO(ケイ。aka メッセージ指向) 今回登場した、後者のメッセージングのOOのミニマリズムをおしすすめることによって派生的に生じたOO(アンガーとスミスからの 派生 変形。aka、プロトタイプベースOO。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“

    “オブジェクト指向”の本質 - Smalltalkのtは小文字です
  • オブジェクト指向の概念の発明者は誰ですか? - Smalltalkのtは小文字です

    忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。(ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない) アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現(オブジェクトにメッセージ送信)するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ(前後して抽象データ型を発案したリスコフ人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている)による、ユーザー定義型(抽象データ型)を SIMULA67 にあった「クラス」という言語機能を使って実現(カプセル化、継承、多態性)するアイデアに基づく「抽

    オブジェクト指向の概念の発明者は誰ですか? - Smalltalkのtは小文字です
  • Advanced Go Concurrency 3 つのパターン - Block Rockin’ Codes

    intro ちょっと時間が経ってしまいましたが、 Go研 vol.03 では、 Google I/O 2013 で行われてた Go のセッションの 1 つである下記をテーマに研究しました。 Advanced Go Concurrency Patterns 資料は以下です。 https://github.com/goken/goken/blob/master/goken03/goken03.md また、ここから順に実装しながら解説をしますが、その完成品はこちらにあります。 (commit 履歴も、記事にある程度沿っています。) https://gist.github.com/Jxck/5831269 スライドにそってやったのですが、セッションの内容は結構重ためだったので、 2 時間の Go 研だとちょっと消化不良ぎみだったのが反省点です。 そこで、このセッションの要である、並行処理に関する

    Advanced Go Concurrency 3 つのパターン - Block Rockin’ Codes
  • 2D/2.5Dゲームエンジン Playgroundのセットアップ – ブライテクノBlog

    KLab株式会社さんが、9/25付で2Dゲーム(および2.5Dゲーム)用のゲームエンジンであるPlaygroundをオープンソースで公開されました(KLabさんによるプレスリリース )。 さっそく動作を確認してみようとされた方も多いと思いますが、Android版はハードルの高さに挫折された方も多いのではないでしょうか。弊社でも苦労しました。 まずドキュメントが英語です。この時点ですでに振り落とされる方も多いでしょう。そして、9/26時点でのドキュメントにはいくつか不備があります。 弊社では試行錯誤の結果、MacOS Xとその上で動作させているWindows7 VMを組み合わせて、Playgroundチュートリアルとして公開されているサンプルのビルドおよびAndroid上での動作確認まで行うことができました。その備忘録として、セットアップ手順をまとめておこうと思います。おそらく、数日中にPl

  • はじめの言語の賞味期限 - Kato Kazuyoshi

    ライブドアブログの PSGI 化の話 は良いはなしだと思う。一方で、私はあんまり Perl が好きじゃないので、10年にわたって生き続けた Perl アプリケーションが、次の10年にむけてアップをはじめているのは、ちょっとしたホラーでもある。 TwitterRuby と JVM ライブドアブログが、将来に向けて mod_perl から PSGI + Starlet にかえたように、将来に向けてプログラミング言語をかえる人達も存在する。最近の事例で有名なのは、TwitterRuby から JVM 言語群への移行だろう。 OSCON Java 2011 の Twitter: From Ruby on Rails to the JVM では、JVM への移行に至った理由として Ability to handle server workloads A real concurrency

  • 関数プログラミングのボトルネックとしてのRDBMS

    プログラム開発は、多くの人々が目的達成のため、もがき苦闘するタールの沼である – Frederic P. Brroks, Jr., 人月の神話 モジュール性はプログラミング成功の鍵である – John Hughes, 関数プログラミングはなぜ重要か タールの沼の底から タールの沼と聞いて連想するのは大規模なSIである。業務アプリケーションやWebアプリケーションは規模が大きくなればなるほど、複雑さが増し収拾がつかなくっていく。そしてそのようなアプリケーションを大きな単位で上手くモジュール化し、さらには再利用することは不可能に近い。 その技術的な原因の一端、そして問題を解く鍵は、そのようなアプリケーションが常に携えているRDBMSの周辺にあり、さらに言えばおそらくRDBMSとアプリケーションロジックの組み合わせにあると考えている。 ここでは、アプリケーションロジックの実装に関数プログラミング