@nishio: あ、そうか、10年前からあったけど10年間の間に勢力を拡大したケースがあるからあんまり厳しく切らない方がいいのか(TypeScriptの登場が2012年、Rustの登場が2010年だった)

κeenです。これは 言語実装 Advent Calendar 201713日目の記事です。 RPythonやPyPyについて勘違いしてる人向けに誤解を解こうかと。あんまコードは出てこないやつです。 いきなり話が逸れますが、PyPyとRPythonの話前に二村射影を知っておくと理解が深まるかもしれないので触れて起きます。 二村射影と部分評価 詳しくはWikipediaを見て下さい。 ここでは直感的な話をします。 第一: インタプリタとExecutable インタプリタは抽象的にはソースコードと入力データを受け取って出力データを出しています。 +---------+ +--------+ | in/data | | source | +---------+ +--------+ | | +-------------+ | interpreter | +-------------+ | +--

こんにちは。労働者です。とあるプログラムで学生さんの課題を添削していたら面白い話に出会いました。 僕は今、主に学部生向けのインターン研修的なプログラムでメンターなるものをやっています。メンターとしての仕事は、学生さんの課題へフィードバックを返し、Office Hourというセッションを毎週設けて質問受けやCSに関するトークを行うといった内容になっています。今回話題に取り上げるのはその中の課題の1つ、「行列積のプログラムを書いて時間を計測せよ」という何気ない話で、続く課題たちのいわば前座のようなものです。こういったところに沼は隠されているものですね。 担当している学生さんたちが細かい実験を行ってくれて以下のような疑問が提示されました。 「行列積の計算が N = 1024のときだけ N = 1023, 1025のときに比べて3倍遅いのはなぜ？」 配列のサイズが2のべき乗になるのは避けるべきとい

私がIT業界の片隅に所属をし始めた2000年ごろ、Javaエンジニアはスーパースターだった。Javaエンジニアを名乗るということは、秘奥義オブジェクト指向を習得していることに他ならないからだ。 「オブジェクト指向こそ正義」だった。 Javaとオブジェクト指向を身につければ、20年は食っていけると言われたものだった。 あれから20年。たしかにJavaとオブジェクト指向で20年は食えた。が、もはやオブジェクト指向は絶対でも正義でもない。 僕は、IT講師として新入社員にJavaを教える仕事もしているが「オブジェクト指向こそ正義」と無垢な生徒達に教えなければならない時に、苦痛を覚えるようにすらなってしまった。 2000年代から、新人教育のテキストは変わっていない。継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている。Strutsだけ

C#で非同期処理を行うための機能であるasync/awaitのふるまいに関する説明です。 サンプルコードを見ながら確認していきます。 処理に時間が掛かるメソッドHeavyFunction()を準備する まず、処理に時間がかかるメソッドを用意します。この例ではSleepさせていますが、実際はWebAPIを呼び出すとかDBアクセスのような時間がかかる処理をイメージしてもらうと良いです。 // 時間のかかる処理 private string HeavyFunction() { // 1秒間待つ System.Threading.Thread.Sleep( 1000 ); // 結果を返す return "Hello"; } HeavyFunction()をボタンクリック時のハンドラで呼び出す 先ほど作ったHeavyFunction()メソッドは、以下の形で呼び出せますが、HeavyFunctio

CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今

日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。 https://anond.hatelabo.jp/20190205192741 COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。 SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。

この前の院試でも出題されたのだけど、任意の再帰プログラムは仮想スタックを用いることで非再帰形へと変換することが出来る。 恥ずかしながら院試の本番ではウロ覚えで上手く解答出来なかったが、この程度のことは学部初等レベルの知識なのでちゃんと復習することにした。 実際には二分木で与えられたのだけれど、ここでは簡単のため配列表現を用いた。 元のプログラム 1 #include <stdio.h> 2 #include <stdlib.h> 3 4 #define MAX 11 5 6 int t[] = {0,1,2,3,4,5,6,7,8,9,10}; 7 8 int left(int n) { return n*2+1; } 9 int right(int n) { return n*2+2; } 10 11 void traverse(int t[],int n) 12 { 13 if(n <

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です

以下はThe Mistakes I Made As a Beginner Programmerの日本語訳です。 The Mistakes I Made As a Beginner Programmer 初心者プログラマが犯しがちな間違いと、それらを特定し、避けるための習慣を学ぶ方法。 まず最初に言っておくことがあります。 この記事は、誤りを犯すことを悪いと糾弾するために作成されたものではありません。 むしろ貴方が誤りに自ら気付き、あるいはその兆候を見いだし、それらを避けられるようにするために書かれたものです。 私は過去これらの誤りを犯し、それぞれから学びを得てきました。 今ではこれらを避けるようなコーディングを習慣付けるようにしています。 貴方もそうしましょう。 紹介は順不同です。 1) 設計せずに実装する 高品質なコンテンツは、一般的には容易に作成できるものではありません。 それには慎重

某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない

レオナ @reona396 前職でプログラミング教育の営業を少しやった事があったけど、年配の方には「プログラミング教育の意味？なぁに、家庭科の授業と同じです。食卓に出された物をふんぞりかえって食べてるだけじゃ感謝の心も芽生えず社会のしくみもわからない。ITも自分の手で学ぶのが大事なんです」でイチコロだった 2017-05-10 23:23:07 レオナ @reona396 これを言うと「そーなのよ、うちの娘も寝っ転がってLINEやるばかりで……そうね、自分でしくみを知るのが大事よね…」ってなっていらっしゃった。自分の手元に来るまで色んな人が関わってて、作る人の苦労があってこそ今ここにあるのだ、という意味ではお料理もアプリも一緒ですと説明してたっけな 2017-05-10 23:25:53 レオナ @reona396 あとプログラミング教育の教材について、いくら「簡単だからとっつきやすいです

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

In general, what can we take for granted when we append to a file in UNIX from multiple processes? Is it possible to lose data (one process overwriting the other's changes)? Is it possible for data to get mangled? (For example, each process is appending one line per append to a log file, is it possible that two lines get mangled?) If the append is not atomic in the above sense, then what's the bes

関数の適切な長さとは？ マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘 一般にプログラムは多くの関数などから構成されています。関数には数百行に渡る長いものから数行程度の短いものまでさまざまな長さがありますが、果たして関数にとって適切な長さというのはあるのでしょうか？ マーチン・ファウラー氏は関数の長さについて書いたコラムで、重要なのは意図と実装の分離であり、適切な名前を付けることが大事だと指摘します。同氏のブログは翻訳が許可されているので、記事「FunctionLength」の本文を翻訳しました。 FunctionLength（関数の長さ） 私のキャリアにおいて、関数の長さはどれくらいであるべきか、という議論を何度も聞いてきた。これはより重要な問いに置き換えることができる。それは、どのくらいの長さのコードになったらそれを関数にすべきか、ということだ。 い

2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい

はじめに こんにちは、先日投稿したソースコードの混沌はどこから這い寄るのかという記事が思いのほかストックされて浮かれ気味のMic-Uです。 そのときは「こうしようぜ！」と訴えるだけでしたので、今回は実際に戦った過程を紹介したいと思います。 今回扱うのはこれまた仕事で遭遇したカオスコードですが、先日の記事の投稿後に新たに発見されたものです。 その特徴は簡潔に言うとやたらとネストが深い。 ネストが深いのはカオスコードにはよくあることです。 ネストの深さがもたらす混沌 プログラミング経験者なら誰もが「ネストは深くしてはいけない(戒め)」と言われたことがあると思います。 本当に始めたばかりでそんなこと言われたこと無いという人も、いつか必ず言われます。 ていうか今私が言ってます。 戦いの記録に入る前に、改めてネストが深くなるとなぜいけないのか見つめ直しましょう。 物理的問題 ネストが深くなると視覚的