Page2RRS

• 05 Nov 2009 09:59

  2009年11月04日

  ・配下 なーんか使い方が気になるんだよなw

  ■_ 熱血だねえ

  知恵袋から。

  (cache) C言語について質問です（為替） - Yahoo!知恵袋

  
  C言語について質問です（為替） - Yahoo!知恵袋
  C言語について質問です（為替）
  
  double 型の外部変数 dollar (1ドルが何円かを表す) と euro (1ユーロが何円かを表す) を宣言せよ.
  
  円の金額を受け取り, それをドルに両替したとき何ドルになるかを返す関数 double 
  yen2dollar(double) を作成せよ. ただし, 円をドルに両替するときのレートは, dollar+1.0 と
  する. (例えば, 1ドル110円のとき, 円をドルに両替すると1ドル111円で計算される.)
  
  円の金額を受け取り, それをユーロに両替したとき何ユーロになるかを返す関数 double 
  yen2euro(double) を作成せよ. ただし, 円をユーロに両替するときのレートは, euro+1.0 とす
  る.
  
  ドルの金額を受け取り, それを円に両替したとき何円になるかを返す関数 double 
  dollar2yen(double) を作成せよ. ただし, ドルを円に両替するときのレートは, dollar-1.0 と
  する.
  
  ユーロの金額を受け取り, それを円に両替したとき何円になるかを返す関数 double 
  euro2yen(double) を作成せよ. ただし, ユーロを円に両替するときのレートは, euro-1.0 とす
  る.
  
  今日のドルのレート (dl) とユーロのレート (er) を受け取り, 次のように両替の金額の例を表
  示する関数 void kawase_example(double dl, double er) を作成せよ.
  
  dollar に dl を, euro に er を代入する.
  "今日のレートは 1 ドル xxx.xx 円, 1 ユーロ xxx.xx 円です." と表示する.
  10,000円をドルに両替するといくらになるかを yen2dollar を用いて計算し,
  "10000 円をドルに両替すると xxx.xx ドルになります." 等と表示する.
  同様に 10,000円をユーロに両替した結果を表示する.
  100 ドルを円に両替した結果を表示する.
  100 ユーロを円に両替した結果を表示する.
  100 ユーロを円に両替し, それをドルに両替した結果を表示する.
  同様に, 100 ドルを円を経由してユーロに両替した結果を表示する.
  
  main 関数から
  kawase_example(111.0, 130.0);
  を呼び出すようにせよ.
  
  というプログラムの作り方がわかりません。
  どなたか回答お願いします。
  
  

  
  いくつかある中の4つの問題 「円→ドル」、「円→ユーロ」、「ドル→円」、「ユーロ→円」 
  は、一つが分かれば他のものも全て同じ要領で解けるものですよね。このことから、あなはがこ
  の問題のこと自分でまったく考えようとしていないのは明らかです。
  
  宿題を少しも考えもせずに、丸投げして他人にやらせようというのは、無礼な行為であり、ふさ
  わしくありません。いくつかポイントがありますが、どこまで分かっていて、分からないのはど
  ういう点なのでしょうか。
  
  (1) グローバル変数 dollar、euro の宣言の仕方は分かりますか？ (問題 1)
  (2) 為替の計算式とそれを C言語で表現するコードは分かりますか？ (問題 2～5)
  (3) 関数というものの作り方は分かりますか？ 関数で数値を返す方法は分かりますか？ (問題 2～5)
  (4) dollar に dl を、euro に er を代入する方法は分かりますか？ (問題 6)
  (5) 関数を呼び出して、返された値を受け取る方法は分かりますか？ (問題 6)
  (6) 計算結果の数値を表示する方法は分かりますか？ (問題 6)
  (7) そもそも、各設問で何を求められているか、内容を全て理解していますか？
  
  質問するときは、どんな点が分からないのか要点を絞るべきですね。そうでなくては、あなたの
  投稿は、「質問」ではなく、ソフトウェア作成業務の「発注」、あるいは、宿題代行サービスの 
  「発注」 になります。もっとも、実際のところ、あなたが求めているのは「解説」ではなく、
  プログラムコードの「納品」や「サービスの提供」なのでしょうけど、それは、知恵袋の趣旨で
  はないと思いますよ。
  
  http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1016477880
  
  本当に知りたい/理解したいと思っているのであれば、この投稿自体は取り消して、
  上記のような、要点を絞った形で再投稿することをお奨めします。
  
  【このような回答を書く意図】
  
  このような宿題丸投げなどのマナー違反について、無視したり何も言わないのではなく、不快に
  思っている人がいることを明示するべきだと思っております。それは、そうすることで、
  
  (1) 質問投稿者に、自分がしてることが他人を不快にさせているということを認識してもらうためであり、
  (2) これを読んでいる他の質問投稿者予備軍にもそれを伝えるためであり、
  (3) 「レポート代行愛好家」の方たちにも、考え方の説明や大した解説もない、ほとんどコード
  だけの回答をする 「自販機式」 の回答を自重するよう求めるものになるからです。
  
  こういうものは、そのコミュニティーの「空気感」「雰囲気」のものなので、そのためにも、陽
  に空気を作るべきだと思っています。ご理解・ご賛同いただければ幸いです。
  
  

  最近Ｃ言語で「宿題やってくれ」系の投稿が多くなってきていると思います。中には... - Yahoo!知恵袋
  
  最近Ｃ言語で「宿題やってくれ」系の投稿が多くなってきていると思います。中にはせっかくコ
  ードを教えたのに質問を取り消してくる輩もいます。皆さんはこの現状どう思いますか？
  
  私的には、そういった投稿をするのは容認はしますが、やはりどこまでやったのか、どこがわか
  らないのかを記載してほしいですね。ただきいてくるひとはコピーアンドペーストの無限ループ
  だと思うので、何か対策があっても効果ないと思いますが、どうでしょう？
  
  

  ベストアンサーに選ばれた回答
  
  同感です。
  これまで、なるべくプログラムソースで回答してきました。
  自分にとって最も楽で、誤解の無い回答を出しやすかったからです。
  しかし、
  丸投げそのもの質問について、どうしたものかと迷っていました。
  時間を使って提供しても右から左にコピーして提出し、おしまい・・・
  という状況を思うと、回答するのが余りにも馬鹿げていて白けます。
  しかし、
  習いはじめの時期には、人のコードを見習うことで、思いもかけず
  楽にプログラムを体感することができた、昔の経験を忘れられず、
  何がしかの役に立って、興味を持ち、自立してくれるのではないかと
  幾つかの回答を出してきました。
  
  でも、あまりこの手の質問と回答が横行すると、レベルの大差から
  多くの方の邪魔になり、あげくに本カテゴリの質を落としかねません。
  以後、この手の回答は一切遠慮することに致します。
  
  

  こういった輩が専門学校卒に多い。
  入社して使おうとしたら、全くプログラムの組み方が判っていない。
  
  「わかる言語はなに？」
  
  「HTMLです」
  
  「．．．」
  
  

  宿題やってくれ，を含めた，ふざけた質問．
  それに対して，説教たれたり，からかったりする行為をとめる気はありませんが，
  少なくとも，質問者のことを少しでも考えるなら，
  きっちり黙殺してあげるのが親切というものではないでしょうか．
  
  

  だいたいあーいう人って捨てアカで投稿してるでしょ？
  コインももうほとんど残ってないような。
  
  答えるだけ無駄だね。
  努力の跡が見える人には答えてあげてますが・・・
  
  問題だけのせたものに
  答える人がいるから調子にのるんだろうけど。
  個人的には↑この人が一番悪いと思ったり・・・
  
  
  まぁ不適切な投稿で通報が一番ですかね。
  

  まあ、「教えてやる蔵」くんは結構いるしなあ。 んで、今日の丸投げから。

  構文解析のLL法についての質問（今日中）です。 a+b-c×d と a+b-(c*d)をそれぞれLL... - Yahoo!知恵袋
  
  構文解析のLL法についての質問（今日中）です。
  a+b-c×d
  と
  a+b-(c*d)をそれぞれLL法で構文解析するというものですが、この解析の際の
  構文解析表を作ってください、どうかお願いします。
  
  色々ありまして教授にこの課題を明日（今日）までにやってこいと言われました。
  実のところこういった知識はあまりなく自分でやってみたところ表をもとに
  構文を解析することまではどうにかできたのですがディジタル信号的な
  表現（集合）あたりがどうしてもできません。
  期日は今日の昼過ぎおそらく２時までには出さないといけないので急ではあるの
  ですが、どなたかどうかご教授ください！お願いします。
  
  補足
      あと、よろしければ構文解析表が作る際のコツなどありましたら是非教えてくださると
      大変うれしいです。
  
  

  文法自体の規定(生成規則）がないけど。。。
  
  
  ＞ 構文解析表を作ってください
  
  LL(1) として、非終端記号(行）と終端記号（列）に対する生成規則を示す表のこと？
  
  しかし、「やってこい」というのは、「理解してこい」という意味でしょうから、
  他人に作成してもらっても。。。と思いますけどね。
  わからないならわからないと＜教授＞に正直に言うほうがいいでしょう。
  「どうかご教授ください！お願いします。」は、＜教授＞に言うべきかと。
  
  
  ＞ ディジタル信号的な表現（集合）
  
  よくわかりません。。。。^^;
  

  構文解析表? にしたって、文法も提示せずに構文解析しろって。 まあふつーの算術式くらいを考えりゃあいいのだろうけど。 期日は今日の昼過ぎおそらく２時までには出さないといけないので どうなったのかなあw

  構文解析表が作る際のコツなど …小学校からやり直せ。

  ■_ PLnews

  昨日見落としていた○|￣|＿

  V6 Thompson Shell Port 20091029 Released @ PLNews: Programming Language News
  Nov. 02, 2009
  V6 Thompson Shell Port 20091029 Released
  2009-11-02 19:52:21
  Languages :: Shell
  
  V6 Thompson Shell Port 20091029 has been released. It includes two ports of the 
  original /bin/sh from Sixth Edition UNIX.
  
  This release includes: a fix for a compilation problem on AIX, code cleanups, 
  installation updates, and other changes. 
  
  

  Retro Forth 10.2.1 Released @ PLNews: Programming Language News
  Nov. 02, 2009
  Retro Forth 10.2.1 Released
  2009-11-02 19:43:53
  Languages :: Forth
  
  Retro Forth 10.2.1 has been released. RetroForth is a free, portable Forth implementation.
  
  This release includes a bug fix. 
  

  レトロブームでも来てるのか? Retro, A Minimalistic Forth ふむ。 Retro is a small, minimalistic Forth dialect capable of running on all modern operating systems. It can also be used on cell phones and PDA's supporting MIDP and on most modern web browsers (excluding IE). osaka.forth のネタになるかしらん。

  ■_

  あ、*_s ですか。さすがにこっち方面何もしないというのはないですよね。

  めもがき:2009年11月4日分
  2009/11/4(Wed)
  ○ 今日
  @
  
  kbkさんとこ
  
      そいや、strlcpy/strlcat 的なものの追加はないんだろうか?
  
  TR24731-1のstrcpy_s/strcat_sですね。 
  http://www.open-std.org/JTC1/SC22/WG14/www/projects#24731-1
  

  ■_ Histroy of Programming Languages

  An introduction to functional programming
  
  An introduction to functional programming
  
  Way back in the dark ages when I first started programming in BASIC, the first 
  stumblingblock I encountered on my quest for programmerhood was the statement:
  
  わたしが最初に BASICでプログラミングを始めたころの暗黒時代に戻ります。
  programmerhood のわたしの quest において、
  わたしが遭遇した最初の stumblingblock は次の文 (statement) でした
  
      X = X + 1
  
  My High School algebra training screamed out, “That's an unsolvable equation!”  I 
  soon learned that the above is not an equation at all, but rather a command.  It's not 
  a statement of fact, it's an instruction to alter a fact.  This command begins with an 
  implied “LET” (in some BASIC versions, “LET” is even required) and the correct 
  interpretation of the command relies not only on the previous value of X, but also on 
  the fact that the right side is evaluated before the assignment occurs.
  
  わたしの高校の algebra training は絶叫に覆われました。“That's an unsolvable equation!”
  (これって解けない等式じゃん!)即座にわたしはこの行が等式なのではなくてコマンドであると
  いうことを学びましたこれは実際には文ではなくて、alter a fact のための命令でした。この
  コマンドは implied “LET” から始まっていて(一部のBASIC ではこの“LET”は必須でした)、
  実行前の X の値にだけ依存するのではなく代入が行われる前に右辺が評価されるようコマンド
  は正しく解釈されました。
  
  I may have had good reason to be uneasy about statements like this one, which change 
  the state of a program when executed.  They're the bread and butter of imperative 
  programming, but there is an alternative:  functional programming, or FP for short.  
  Functional programming seeks to eliminate the need for program state by expressing all 
  computations in the form of functions that take arguments and return values, without 
  introducing side effects.  Those functions read much more like functions in 
  mathematics, where “X = X + 1″ could never work.  In fact, functional programming is 
  based on the lambda calculus, which is a mathematical system for investigating 
  functions.
  
  プログラムが実行されたときに状態が変化するという、このような文の uneasy でないことの
  きちんとした理由がわたしにはわかったかもしれません。それは命令型プログラミングの bread
  and butter (パンとバター?) でしたがalternative がありました。関数型プログラミング 
  (functional programming)、略して FP がそれです。関数型プログラミングは、関数 form の中
  でのすべての計算を関数が受け取る引数と関数の戻り値で表現することによって、副作用を持ち
  込むことなしにプログラムの状態の必要性を除去することを狙っています。そのような関数は数
  学で言う関数にもっと近いもので“X = X + 1”のようなものは決して動作しません。実際、関
  数型言語はinvestigating functions のための  mathematical system であるλ算法 (lambda 
  calculus) にその基礎を持っています。
  
  Thinking functionally, “X + 1″ is really syntactic sugar for an “add” function 
  that takes two arguments, X and 1.  The reassignment of the result to X, however, 
  creates a situation where program state is dependent on how many times we've executed 
  this piece of code.  In truly functional programming, that reassignment would not be 
  allowed.  Instead, the result could be assigned to a new variable, and the scope of 
  that assignment would be clearly delineated.  For instance, in Haskell:
  
  関数的に考えると、“X + 1” は二つの引数 X と 1 とを取る関数 “add” に対する構文糖 
  (syntactic sugar) です。しかし X に対する結果の再代入は、プログラムの状態が何回このコ
  ード片を実行したのかということに依存してしまう状況を作り出します。本物の関数プログラミ
  ングではそういった代入は許されず、代わりに結果は新しい変数に代入され、その代入のスコー
  プは明確に delineated (言葉で描写) されます。たとえば Haskell では:
  
  let y = x + 1
  in dosomethingwith y
  
  The value of x + 1 (which is shorthand for “add x 1″) is assigned to a variable y 
  that is defined for the statement “dosomethingwith y” (assuming here that the 
  function “dosomethingwith” is defined elsewhere).  Note that outside the “in” 
  clause, “y” is undefined.  If you need the value of y outside this statement, then 
  it must be returned.
  
  (“add x 1 ”の略記である) x + 1 の値は“dosomethingwith y”という文で定義されている変
  数 y に対して代入されます(ここでは関数 “dosomethingwith”がどこか別の場所で定義されて
  いることを仮定しています)。“in” clause の外側では“y”が未定義であるということに注意
  してください。If you need the value of y outside this statement,この文の外側で y の値
  が必要であるのなら、それを return しておかなければなりません。
  
  What do these restrictions buy you?  A little thing called referential transparency, 
  for one.  For any set of arguments to a given function, that function will always 
  return the same value.  The function isn't modifying some persistent state that will 
  make it behave differently, depending.  The advantage is that you can employ the 
  function in any context and rely on its results.  It not only makes understanding the 
  code easier, but it also facilitates moving things around without breaking them.
  
  これらの制限の中で、あなたが関心を持つのはどれですか?ある人にとっては referential 
  transparency (参照透過性)と呼ばれる little thing です。任意の引数の集合が関数に与えら
  れたとき、(同じ引数に対しては) 関数は常に同じ値を返します。その関数は関数の動作を変え
  てしまうようななんらかの永続的な状態 (persistent state) を変更したりしませんその利点は 
  in any context and rely on its results で関数を手に入れることができるということです。
  それはコードを理解しやすくするだけでなく
  but it also facilitates moving things around without breaking them.
  
  
  As you might expect, avoiding program state changes makes looping difficult.  
  Functional languages tend to use recursion instead.  For instance, to count from 1 to 
  10 in Lisp:
  
  すでに気がついているかもしれませんが、プログラムの状態を変更することを排除することがル
  ープを難しいものにしてしまいます。関数型言語ではループの代わりに再帰を使う傾向があり
  ます。たとえば Lisp で 1 から 10 まで数えるには:
  
  (defun count (start end)
    (cond ((< start end) (cons start (count (+ 1 start) end)))
          (t (list start)))
  )
  
  (count 1 10)
  
  The function “count” defines counting from start to end as a list composed of start 
  followed by counting from start+1 to end － unless start is not less than end, in which 
  case it's just a list composed of start.  This function recurses until start and end 
  are equal, then concatenates the list in reverse order as it unwinds (We could have 
  included a case to handle if start is greater than end, but we're keeping the example 
  simple here.  As it stands, that case would simply return a list containing only start). 
  In case you're not used to Lisp, let's translate that logic into JavaScript:
  
  この “count”関数では start に続き start+1 から end までの数え上げが続いているリストを対
  象とする start から end までの数え上げ (counting) を行う関数を定義しています。start が 
  end よりも小さくないということがない限りこの関数は start と endが等しくなるまで再帰し
  ていって、再帰の巻き戻しとして逆順でリストを連結していきます(start が end よりも大きか
  った場合の対処を含めることも可能でしたがここでは例を単純にするためにそれをしていません。
  仮にそのようなことになった場合には start だけを含むリストがただ単に返されます)。もしあ
  なたが Lisp に慣れ親しんでいないのであればこのロジックを JavaScriptに移植してみてくだ
  さい:
  
  function count(start, end) {
    if (start < end)
      return start + ' ' + count(start+1, end);
  return start.toString();
  }
  
  alert(count(1,10));
  
  Using this approach instead of a “for” loop means never having to worry if someone 
  reuses the variable “i”.  On the other hand, languages that don't optimize recursion 
  well can quickly degrade in performance when this technique is overused.
  
  “for” ループの代わりにこのアプローチを使うことで誰かが“i”という変数を再利用してい
  ないか心配しないで済むようになります。その一方で、それほど再帰を最適化できないような言
  語はこの手法が使われすぎたときにすぐに性能が劣化してしまう可能性があります。
  
  Another feature of functional languages is the ability to pass functions as arguments 
  to functions, and call those function arguments as needed (known as “lazy 
  evaluation”).  In many languages, whenever you encounter a function reference, the 
  function is evaluated and the result is returned in its place before anything else 
  happens.  But in a language that supports higher-order functions and lazy evaluation, 
  the function is not evaluated until the function to which it is being passed decides 
  to do so.  This is most useful for passing callbacks to handle special cases and 
  events.  In many languages, you have the option of doing either one.  For instance, in 
  JavaScript:
  
  関数型言語のもう一つの機能が、関数の引数として関数を渡しておいて、必要なときに引数で渡さ
  れたその関数の呼び出しを行えるというものです (これは遅延評価 “lazy evaluation” として
  知られています)。多くの言語では関数のリファレンスに遭遇したときは常にその関数は評価さ
  れ、返されたその評価結果を呼び出しが行われた場所に(関数呼び出しに代えて)置きます。しか
  し高階関数と遅延評価をサポートしている言語では引数として渡されたその関数が実行されるこ
  とが決定するまで評価は実行されません。これは特別なケースやイベントをハンドルするために
  コールバックを渡すのに最も有用です多くの言語では、これを行うかどうかの選択の余地があり
  ます。たとえば JavaScript では:
  
  function doit() { alert("ya!"); return null;}
  
  function test(arg) {
    alert("in test!");
    if (arg != null)
      arg();
  }
  
  test(doit());    // Eager evaluation
  test(doit);     // Lazy evaluation (遅延評価)
  
  The first call to test executes doit beforehand, while the second call doesn't execute 
  doit until the third line of the test function.  Thus, the order of alerts in the code 
  above is “ya!”, “in test!”, then “in test!”, “ya!”.  The parentheses on the 
  function argument (or not) indicates whether to invoke the function immediately or 
  simply pass a reference to it.
  
  test の最初の呼び出しは test の前に doit を実行します。一方、二番目の呼び出しでは test 
  関数の三行目になるまでは doit を実行しません。したがって、上記のコードで alert される
  順番はまず“ya!”, “in test!”, が出力され、続いて “in test!”, “ya!”が出力されりま
  す。関数の引数である doit についていたりついていなかったりしているカッコはその関数が即
  座に実行されるのか、ただ単に関数への参照を渡しているだけなのかを示しています。
  
  Lisp is the first language to be based on the lambda calculus, and it was first 
  specified in 1958.  It boggles the mind to realize how much more advanced Lisp was 
  (and still is) than its contemporaries, especially back in the days of Fortran and 
  COBOL.  Programming languages ever since have learned from Lisp, especially as 
  functional languages have become more popular.
  
  Lisp はλ算法 (lambda caluclus) にその基礎を置いた最初の言語で、1958年に最初に 
  specifiy されました。Lisp が同時代の言語、特に Fortran と COBOL に対してどれほどより先
  進的であったか (かつ今も先進的であるか)を考えると驚くべきものがあります。特に関数型言
  語がより一般的になってきているので、プログラミング言語は今もなお Lisp から学ぶものがあ
  ります。
  
  But Lisp is not a purely functional language.  It supports multiple programming 
  paradigms, and it allows you to create side-effects, like modifying program variables 
  during the execution of a function.  A couple of pure functional languages are gaining 
  in popularity: Haskell and Erlang.  Most other languages that support functional 
  programming are actually multi-paradigmatic, providing imperative and object-oriented 
  features as well.  These include (but are by no means limited to) Scheme and Clojure 
  (more functional Lisp dialects), OCaml, F# (pretty much OCaml for .NET), Ruby, Python, 
  JavaScript, and Perl.   Even C# and Java have added some functional support, notably 
  lambdas.
  
  しかし Lisp は純粋な関数型言語ではありません。Lisp は複数のプログラミングパラダイムを
  サポートしていて、関数の実行時にプログラムの変数の値を変更してしまうような副作用も許し
  ています。Haskell と Erlang という二つの関数型言語が popularity を獲得しつつあります。
  この他のほとんどの関数型プログラミングをサポートする言語は実際にはマルチパラダイム的な
  もの (multi-paradigmatic) であり命令型プログラミングの機能やオブジェクト指向プログラミ
  ングの機能も同じように提供しています。そういった言語にはScheme や Clojure (より関数型
  的な Lisp の変種), OCaml, F# (.NET 向けの OCaml にとてもよく似たもの), Ruby, Python, 
  JavaScript, Perlといったものがあります(ただしこれしかないわけではありません) C# や 
  Java でさえ lambda のような関数言語的なサポートを幾つか追加されています。
  
  It's also possible to use a functional style in some languages that don't specifically 
  provide support for FP. For instance, even in C you can compose an application 
  entirely from functions, avoid creating side-effects within them, and pass functions 
  as arguments with lazy evaluation (using function pointers).
  
  関数プログラミングを特にサポートしていないような言語を使っても関数型スタイルを行うこと
  も可能です。たとえば C でさえ、副作用を排除した関数とからアプリケーション全体を 
  compose することができますし、引数として関数を渡す(関数ポインターを使って)ことで遅延評
  価を行えます。
  
  There are many other features generally associated with functional programming that we 
  don't have space to cover here － for instance, lexical closures and continuations.  
  While not strictly required to qualify a language as supporting FP, they certainly 
  make the functional programming paradigm more powerful.
  
  そのほかにも一般的に関数プログラミングに結び付けられている多くの機能があります。たとえば
  ここではスペースの関係で触れなかったレキシカルクロージャやコルーチンがそれです。言語が
  関数プログラミングのサポートを strictly に要求されなかった間に、そういったものが関数プ
  ログラミングというパラダイムをより強力なものにしていったのです。
  
  How does functional programming relate to object-oriented programming?  OOP 
  concentrates on modeling the actors in an application, and using methods to describe 
  the functions that each one can perform.  FP starts instead from the overall process, 
  and includes objects only as needed.  Sometimes one paradigm works better, sometimes 
  the other.  For instance, objects are useful when describing complex systems with many 
  parts, like an ERP application.  Mathematical computations and document composition, 
  on the other hand, are processes that often really don't need any discussion of the 
  actors involved.  The reason so many so-called functional languages actually support 
  both paradigms is because both are useful in different situations, and often in 
  combination.
  
  関数プログラミングはオブジェクト指向プログラミングとどのように関係しているのでしょうか? 
  OOP (オブジェクト指向プログラミング) はアプリケーションにおけるアクターのモデリング 
  (modeling the actors) に集中していて、メソッドをそれぞれが perform 可能な機能を記述す
  るために使っていますFP (関数プログラミング) はプロセス丸ごとではなくて必要な分だけオブ
  ジェクトを取り込むことから始めますたとえばERP アプリケーションのような多くのパーツを持
  った複雑なシステムを記述するときにオブジェクトは有用です一方で、アクターを inviolve す
  るようなディスカッションを一切必要としないことがしばしばあるプロセスです。その理由は関
  数型言語と呼ばれるものの多くが、異なる状況において両方ともがそれぞれ有用な局面が存在し
  組み合わされることが頻繁にあるために実際には両方のパラダイムをサポートしているからです
  
  
  This post is part 5 in a series on the history of programming languages.  Here are 
  links to parts 1 through 4:
  
     1. The Early History of Programming Languages
     2. An introduction to object oriented languages
     3. The ascent of scripting languages
     4. Scripting Languages and the Web
  
  

  • Reading Gauche/04.項目列挙/VMインストラクション - Mona OS developers Wiki
  • Reading Gauche VM インストラクション全制覇 - ひげぽん OSとか作っちゃうかMona-
  • 仕事が面白く感じる心理状態～フローな状態について － ＠IT自分戦略研究所
  • はてなのインフラを支える「ビジョン」と「数値化」 － ＠IT自分戦略研究所
  • 日本のセキュリティチーム (Japan Security Team) : セキュリティ インテリジェンス レポート 第7版(2009年上半期)
  • 秋の新プリンターは無線LAN対応が標準に：IT羅針盤
  • 脆弱性検査は“黒”から“白”へ（その1）：三輪信雄「ここが変だよみんなの対策」
  • Windowsの歴史 Windows Server 2003 R2編：安定性と先進性の両立目指す「R2」の先駆けとなったOS - builder by ZDNet Japan 「R2」（リリースアップデート2）だ。そうだったのか＞R2
  • [Lua]関数と変数は装備しないと意味ない以上でわかるとおり、グローバル変数のfoo, hoo に関数の内容を代入するためにスクリプト全体を実行する必要があるのです。
  • (6)夜勤だけでない？当直の仕組み - データセンターの舞台裏：ITproと言いながら，私はENTERキーを軽い気持ちで押そうとしたときに，隣に座っていた先輩から怒鳴られた。 　「なんだ，そのへっぴり腰なキー入力の仕方は！」
  • 『PageRankの数理』 » val it: α → α = fun -もっとも、基本的には数学で語られるので(たまにMATLABのサンプルコードが載っているが、MATLABというあたりに著者のお里が知れるよな)、
    MATLAB 使うとなにかいけないことがあるのでしょうか?
    このあと「脅し」が入ってるけどせっかくの向井さんのオススメだから読んでみるかなあ
  • Paste number 89718: Multiple Common Lisp Implementations on Win32 + ASDF setup HOWTO

  ■_ とらんすふぉーむ!

  FORTRAN Ⅳ [chaika]
  662 デフォルトの名無しさん [sage] 2009/11/04(水) 04:25:42 ID: Be:
      フォートランって
      フォーミュラ・トランスフォーマー
      っていうくらいだから、
      科学計算以外には向いていないのか？ 
  
  663 デフォルトの名無しさん [sage] 2009/11/04(水) 07:40:31 ID: Be:
      大昔は、他に言語がなかったから、なんでもFortranで書いてた。
  
      現在では、向いてる向いてない以前に、言語として古い。 
  
  664 デフォルトの名無しさん [] 2009/11/04(水) 12:39:17 ID: Be:
      そういえばなんでトランスフォーマーなんだろう
  
      数式を変形せずになるべくそのままの書き方でコードにできるのが
      Fortranのメリットだったはずなのに。
      今では使っちゃいけないとされる文関数なんてモロその名残だよね。 
  
  665 デフォルトの名無しさん [sage] 2009/11/04(水) 12:56:16 ID: Be:
      >>663
      古いゆえにコンパイラもライブラリも枯れていて、まずバグはない
      最適化も一番今の所進んでいる
  
      というわけで信頼性と速度が要求される局面で現在も使われているわけだ 
  
  666 デフォルトの名無しさん [sage] 2009/11/04(水) 13:02:36 ID: Be:
      トランスフォーマーじゃなくてトランスレータだぜ。
      FORTRAN以前は演算式もアセンブリで書かなければならなかった、
      数式そのものでプログラムを記述出来る事は画期的だったんだよ。 
  
  667 デフォルトの名無しさん [sage] 2009/11/04(水) 13:47:03 ID: Be:
      = で代入、という規則をプログラミングの世界に普及させてしまった
      張本人でもあるな。 
  
  

  Permalink  |  View Entire Page

Search the Site

Custom Search