「処理系」を含む日記 RSS

はてなキーワード: 処理系とは

2019-02-23

anond:20190223045232

perlでは連想配列

しかし、この話を読んでJavaだけ違うよなって思ってしまった。他のはみんな実装言語処理系にお任せだけれど、JavaだけはMapは単なるインタフェースで、どの実装にするかはお前が選べってところがねぇ。こいつだけはGenericsを使って、keyvalueの型を指定するのも違う。

Javascriptはプロトタイプベースオブジェクト指向言語から、こいつもこいつで思想が他のと違うんじゃないかとも思えてきた。

2019-02-08

anond:20190208123102

ある程度新しい処理系だったらだいたいマルチバイト対応しているので、ギリシャ文字くらいなら普通に使えると思うよ。

2019-02-05

COBOLer、人を呪わば穴2つ

リーナスですら自身攻撃発言自戒するこの時代、本邦の好戦的技術者を見てげんなりした話。

 

COBOLは難しいか、記者が試しにコードを書いてみた 」という記事日経XTECHに掲載された。はてブでも賑わいを見せている。

この記事では COBOL体験記者が OpenCOBOL という処理系FizzBuzz 問題を書き、それを踏まえて COBOL への評価と雑感が示されている。

これに対して、反論記事を見つけた。

 ま た 大 森 敏 行 か

タイトルからし技術批判というより個人攻撃主題にあり、すでに怪しげな雰囲気が出ている。

そんな雰囲気を交わしつつ途中までは「なるほど、COBOL特性データ構造にあり、件の記事では COBOL の特徴を捉えきれていないので結論勇み足だし的外れなのか…」と思っていた(私はCOBOL経験)。

けど、結語まで読んでげんなりしてしまう。

日経BPの記者ふぜいがgdgd言ったところでCOBOLはなくならない。それでいてこのようなFUD技術者敬遠させる効果はある。なくなりもしないのに技術者敬遠したら何が起きるか、わからない記者腹を切って死ぬべきである

日経記事的外れなのは分かったが、ここまでくると読んでて辛い(腹を切って云々はネットスラングだとしてもなんだかな)。

しかも、この人自身過去日経で連載を持っていて、それをプロフィールに書いている(!)のに個人宛じゃなくて日経BP記者ふぜいとか言っちゃうのか…。さら企業社長とのこと……

 

かなり本気で思ってるんで、日経ネットワークの当該記者コンタクト取って欲しいんだけど。 (「悪い大人」より)

あの語調で返されたらコンタクトを取りたがる人はあまりいないんじゃないかなぁー

 

この方、以前にはこんなことも言っていた(この際の批判対象の記事は私も問題があると思うが)。

まさにこれだった。いつの間にか、「オープンソース界」は英語hackマウンティングする奴等が力を持つようになってしまって、陳腐hacker集団に成り下がってしまったようだが。

まさに人を呪わば穴2つ。

 

---

ちなみに批判記事にある「(真の)グローバル変数」の話ですけど、へぇ勉強にはなった。

これは私が不安になったので確認ですけど、一般には「コンパイル単位内でのみグローバルな変数」もグローバル変数って呼びますよね?(ですよね?)

 

あと、"DATA DIVISION" の箇所についても「鶏を裂くに牛刀を持ち出す」という喩えを使うのにもなんか違和感がある。

というか COBOL では問題がなんであれ "DATA DIVISION" を使わざるえないのだったら、「鶏を裂くにも牛刀を持ち出さざるを得ない(だから鶏を捌くな)」のほうが適切なのでは…

COBOLer からすると前者の喩えで膝を打つ感じなんでしょうか?)

その後の「丸木橋経験本四架橋を論じる」の喩えはよくわかる。

2018-12-21

[]コンピューターで発生する技術面の問題

1999年問題

1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコード例外値として扱っている物があったとされ、そのようなシステムでは1999年になった途端に正当な1999年エラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日エラーが発生することも懸念された。

1999年8月21日問題

GPSは内部処理で週数を10ビット管理しており、起点である1980年1月6日から1024週後にあふれて0に戻る。

2000年問題(Y2K)

年数を下2桁だけで処理していたシステムや、2000年平年(閏年ではない)と誤解したシステム問題が起こる。

2001年9月9日問題

1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。

2008年問題

2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperl作成されたネットゲーム誤作動が発生した事例がある。

2010年問題

潜在的バグが発覚した。シチズン電波時計ソニーゲーム機プレイステーション3」(閏年処理)、オーストラリアクイーンズランド銀行でのシステム動作ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現西暦下2桁のBCDを使っていた。

2019年4月7日問題

GPSは内部処理で週数を10ビット管理しており、起点である1980年1月6日から2048週後にあふれて0に戻る。(10ビットでは2回目)

2030年問題

1930年 - 2029年を下2桁で表現しているシステム問題が起こる。同様のもの2050年問題や2070年問題などがある。

2036年問題

1900年1月1日0時からの秒数が32ビットからあふれ、NTP問題が起こる。

2038年問題

Unixなど。1970年1月1日0時(Unix epoch)からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステム問題が起こる。

2038年11月21日問題

GPSは内部処理で週数を10ビット管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。(10ビットでは3回目)

2040年問題

HFSのタイムスタンプ2040年2月6日までしか取り扱えない。

2042年問題

System zのSTCK命令で取得する64ビットTODクロック2042年9月17日中にオーバーフローする。

2048年問題

2038年問題1980年起点版。FATファイルシステムタイムスタンプなどが1980年起点である

2050年問題

1950年 - 2049年を下2桁で表現しているシステム問題が起こる。同様のもの2030年問題や2070年問題などがある。

2053年問題

2038年問題1985年起点版。TRONなど。

2070年問題

1970年 - 2069年を下2桁で表現しているシステム問題が起こる。同様のもの2030年問題2050年問題などがある。

2079年問題

FATファイルシステムタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後(2079年12月31日)までしか正常動作しない。

2100年問題

2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステム問題が起こる。

2108年問題

FATファイルシステムタイムスタンプは2107年12月31日までしか取り扱えない。

2137年問題

更新されたGPSは内部処理で週数を13ビット管理しており、この頃にあふれて0に戻る(正確な日時は未定)。

2286年問題-2286年11月20日17時46分40秒に起こる。原因は、2001年問題と同じ。

3000年問題

Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。

10000年問題

西暦が5桁になる西暦10000年1月1日に起こる。

2018-11-25

やっぱCOBOLFORTRANだよな

事務処理系ならCOBOL

大学科学技術計算するならFORTRAN

両方兼ね備えたPL/Iとかもあるけど少数派

Cとかはまだ普及してないか10年後にはいいか

実行速度を要求される現場ならアセンブラやらないとね

2018-06-19

Go言語PHPに似ている

2018-05-26

anond:20180526173227

女心という処理系理解してないからだろ。

器用な奴は思い通りにコトバで女をプログラムしてんだろうな。

2018-05-25

anond:20180525103904

非同期処理がウリの処理系無意味に選ぶからだろ

おとなしくPythonRubyにすればいいのに

2018-05-01

anond:20180501102237

いまどきの高級言語なら定義済みかundefかってとこを1bitフィールド自体の値じゃなく処理系の方で管理してるんじゃないですかね

2018-03-23

anond:20180323131759

うわぁ。なんというか。。

そもそもそれどういう処理系で、金額は何の型に入れて計算してるの?

2018-03-21

プログラミングレベルってみんなどうやって自己評価してんの?

レベル5 : マスターレベル拡張ライブラリ記述できるだけでなく、言語の内部仕様処理系実装等についても明るい。

レベル4 : 問題なく日常的に利用できるレベル言語を使うだけでなく、その言語ライブラリを作ったり、フレームワークを作ることもできる。

レベル3 : リファレンスがなくても任意の処理が記述できるレベル

レベル2 : リファレンス本があれば利用できるレベル

レベル1 : 授業などで触れたことがある程度。日常的に利用できるわけではない。

問題なく日常的に利用できるけどリファレンス禁止は無理な私はレベル2なの?

というかどんなコードを書く前提なの?

競技プログラミング解くならリファレンスは要らんけどGUI絡んだりWEBとかだと絶対無理だけど?

スレッドとか普段使わないからどの言語でも調べないと無理ですけど?


そもそもこの判定基準考えたの誰だよ

コピペされすぎだろ

2017-10-29

はてなハードウェアエンジニアが少ない件

エンジニア一言で言っても星の数ほどのジャンルがあるが、その中でも代表的なのはハードウェアエンジニアソフトウェアエンジニアだと思う。

まりに広範囲区分けだが、敢えて定義はしないでおく。

さて、自分新米ハードウェアエンジニアで、ソフトウェア趣味人間である

はてなにはソフトウェア記事(及びブックマーク)が多く、日曜プログラマ自分にとって大変有益である

大抵の悩みは検索をかければ解決するし、自分では想像し得ないようなユニーク記事もあり毎日が発見連続だ。

特にユーザコメントが好きで、皆の関心が伺える“はてなはいくら見ていても飽きない。

ただ、ハードウェアに関する記事が少ないことが残念でならない。

エンジニアカテゴリを覗いても、ハードウェアに関する記事が上がっていることは稀である

たまにラズパイIoTキットに関する記事があるだけで、デジタル回路におけるインピーダンスシミュレーションとか、高速差動信号の放射電波対策とか、そういった踏み込んだ記事はほぼ無いと言っていい。

当然アナログ回路のGNDレイアウトに関する記事は皆無だし、ソフトウェア寄りと言えるRTLコーディング記事さえ見当たらない。

ハードウェアエンジニア守秘義務なのだろうか?

・・・・・・

・・・

ソフトウェア技術日進月歩

イマイチ盛り上がらないハードウェア業界比較して、ソフトウェア業界の隆盛は火を見るよりも明らかである

コーディング環境、つまりPCがあればその先には広大な世界が広がっている。

語弊を恐れず言うが、アイディア次第ではその日のうちにスターダムにのし上がることも可能かもしれない。

当然、アマチュアを含めたエンジニア人口を見るとソフトウェアエンジニア人口は突出しているだろう。

なので記事数の多さは人間性質に依るものではなく、単純に人口の違いだろう。

ハードウェア面白いのに、何故手を出す人が少ないのだろうか。

ロボコンなんか見ていると、胸に込み上がるものがあると思う。

ハードウェア自然界の物理法則の下で成り立っているため、主に電磁気学電気回路電子回路勉強するだけでいくらでも応用が効く。

言うなればソフトウェアよりも参入障壁は低いはずで、高校物理で習ってきたこである程度の回路が組める。

FPGAなりでハードウェアアクセラレータ自作し始めると計算機科学知識必要になるが、ここはむしろソフトウェアエンジニアの方が得意な領域だ。

・・・・・・

・・・

こんなことを言っておいて、自分ハードウェアを始めたのは社会人になってからである

学部修士時代の専攻は材料物理学だったため、工学とは全く縁が無かった。

ここから自分ハードウェアの道に進んだきっかけを書こうと思う。

新人研修の昼休み、あるフラクタル図形を高速描画するハードウェア記事が目に留まった。

当時の自分にはその偉大さが理解できなかったが、2年もの間寝食を忘れて没頭できるその世界に心が惹かれた。

人生を変えることになる出会いだった。2012年の春である

早速オームの法則から復習し、使ったこともない半田ごてやテスターを買ってきて4bit CPU製作に取り掛かった。

ALU(算術論理演算回路)以外はディスクリート部品で組んだため、デバッグ含めて完成までに6ヶ月も掛かってしまった。

その後FPGA存在を知り、8bit CPUを載せてみた。

機械語勉強し、命令デコーダ設計して1年後、自分の考えたプログラム動作したときは嬉しかった。

上述した記事追体験しているようで、仕事を忘れて没頭していた。

続いてFPGAマイコン+汎用ROMの組み合わせでプリント基板を起こしてみた。

目的は勿論、あるフラクタル図形の高速描画である

ここでレベル変換やリセットシーケンスなど、デジタル回路の基礎を身に付けることができた。

基板レイアウトの考え方は専門的であるものWEB簡単情報が手に入ったし、殆ど電磁気学世界なので理不尽ものは無かった。

苦労したのがマイコンプログラムだった。

機械語論理的な手順をコード化するだけだったが、組み込みC言語はそのルールが難解だった。

言い方は悪いかもしれないが、人間の考えたルールだろうと理不尽に思える理論もその設計思想を調べもせず暗記で済ましていた。

メモリリークが発生した場合ハードウェアのように現象を観察して仮説検証することが難しく、ダンプなどのデバッグ手法も知らなかった。

そんなとき、社内でセキュアプログラミングなる研修があったため同期と潜り込んでみた。

参加資格の無い自分が参加できたのは、配線だらけの汚い自作CPU子供のような目で見てくれた上司の厚意だった。

そして1年後、自分モニタの中で鮮やかに描画されるフラクタル図形を眺めていた。

上述した研修講師に1年間師事し、半ばマンツーマン計算機科学を教えて頂いていた。

大学講師の方だったため、C言語ルールではなく命令処理系としての働き、ハードウェアとの関連を核にして叩き込んでもらった。

・・・・・・

・・・

紆余曲折を経て、ハードウェアエンジニアとして働いている。

こういう部署では多少なりともソフトウェアができると光るものである

ただ組み込みC言語以外はサッパリのため、日々独学の毎日だった。

そこで出会ったのが“はてな”だった。

そこにある記事はどれも眩しくて、「ある疑問の解決法」を検索するだけでは決して出会えない珠玉記事の宝庫だった。

きっとハードウェア世界にも、自分では想像し得ないような発見があるはずだ。

それこそあのフラクタル図形のような驚きが。

・・・・・・

・・・

今は仕事の傍ら、奇しくもプロになってしまった自分義務として細々とハードウェア記事を書いている。

残念ながら驚くような技術ではないが、誰かにとって小さな発見があれば嬉しい。

これを読んだ人がハードウェアに興味を持ってくれたらと思う。

2017-04-12

IT業界全然進歩してなくて笑えてくるw

業界20年目だけど、まるで成長してない(安西先生)って感じる事ばかり

20年もこんなマッチポンプに付き合わされればそりゃ愛想も付きます

なにか目的があって、それを機械解決してほしいだけなのよ

一部のプログラミング大好きサーバー大好きっ子はその手の仕事が好きなのかもしんないけどこっちはそんなことしたくねーよ

だって本質じゃないだろ?

なんでプログラミング言語処理系ケアまでなんでこっちがしなきゃいけないの?アップデートに付き合わされなきゃいけないの?

自分要望目的をしたいことリストアップ言語かなんかに書いておいて、実現する技術はその時々で最適なものを選定してくれませんか?

したい事は変わらないのにプログラミング言語やらOSアップデートされたので開発をやり直します!ってあきれて物も言えないわww

最近流行りのAI技術とやらで、ここら辺解決してくれませんかね?

2017-02-22

カルドセプト乱数問題

当時ドヤ顔で、標準関数rand()を使ってるからって指摘してる連中多かったな。

大昔に書かれたC FAQってドキュメントに、rand()は質が悪いって書かれてる影響でだろう。

でもカルドセプト事件が起きたときにはすでに21世紀でそんなrand()の質の悪い処理系なんてなかったはず。

しろrand()を使わずに、自作たから失敗したんだろ。

あとだいぶ前に2chプログラム板を見てたけど、初心者乱数関係質問をするたびに、乱数の質が悪いから加工して使えとか、メルセンヌ云々でとか言う連中が常駐してたな。

でもその初心者に教えてる乱数を加工するコードバグってたりするの。

初心者が作るゲームに使う乱数なんてrand()で十分だろって言っても、ぜんぜん通じなかったな。

この前のtoto乱数の件で思い出したから書いた。

2016-07-19

おカタい文章の中に出てくる独特な言い回しが興味深くて面白い

法律とか契約書みたいなおカタい文章を読んでいると,

「A、B、Cについては、○○の場合においてこれを実施することができる。」

みたいな言い回しをよく見かけるけれど, 日常のやりとりではまず出てこないような独特な言い回しだよなーと大変興味深い. (「これ」という言葉の使い方とか)

おそらく, この手の文章はできるだけ解釈が一意に定まる (読み方によって解釈がブレない) 表現必要なので, そのための工夫としてこういう形になったんだろうな~.

解釈が一意に定まる」ことの重要性はプログラミング言語でも同様で, 処理系実装する場合にもポイントになってくるわけだけど, そういえばこの表現ってプログラミングにおける foreach 文だよなとふと思った.

「A、B、Cについては」という語句言及している各項目を、「これ」という変数バインドしている感じ. Javascript 的に書くと

[A, B, C].forEach(これ => { if (○○の場合) 「これ」を実施; });

こういう風に解釈すると, この手の文章を読んでいてなるほどなーと思える.

2016-05-20

http://anond.hatelabo.jp/20160520152449

私も専門家ではありませんがkenokabeさんよりはFRPもよく知っていると思いますし、

kenokabeさんのいうFRP普通世界でいうFRPとは全く違うこと、そして

kenokabeさんが決してそれを認めようとしないことはとてもよくわかりました。

ありがとうございます

言うだけ言うのはただだよねw なんもできてないし。

あの、処理系で「現在時刻が」って言いたかっただけのアホな人?

その俺的FRPコード出したの?nonstarterの偽物のやつじゃなくて。

http://anond.hatelabo.jp/20160520144913

違うわアホ

同じ一つの変数の値が「処理系評価する時刻」によって変わるのであれば、

それは命令プログラムですね。

同じ一つの変数.ではなく定数というのは、

__x という、時間ストリームであり、

その__x上の分布は、「処理系評価する時刻」に従って広がっている。

このイミュータブルな世界観理解できず、命令型だとしか見られないのは、ライブラリ設計者の問題ではなくて、

おまえの脳の問題。つまりアホなんだわ。

http://anond.hatelabo.jp/20160520144213

同じ一つの変数の値が「処理系評価する時刻」によって変わるのであれば、

それは命令プログラムですね。

http://anond.hatelabo.jp/20160520143122

方程式の左右の評価時間が違う処理系

やっぱり「処理系」という言葉意味理解していないことがよくわかったので、ありがとうございました

わかってるよ。そんな難しい言葉だと思ってるのか?

方程式の左右の評価時間が異なる命令型の文脈を「おまえ」が「わざと」作っているか・・・

という説明理解できたの?やっぱ無理か?真性の馬鹿だな。

http://anond.hatelabo.jp/20160520141703

「kenokabeのGUIプログラムも、イベントが起こるたびに変数の値を繰り返し更新してる。」はスルー

もしくは「岡部さんの哲学理解していない」ですか。まあそうですよね。

方程式の左右の評価時間が違う処理系

やっぱり「処理系」という言葉意味理解していないことがよくわかったので、ありがとうございました。

http://anond.hatelabo.jp/20160520142159

無限ループなのはおまえだろ。

もう一回だけまとめると、__x.t=__x.t+1のような単純な例はもちろん、

その「おまえが書いた命令コード」について、

処理系が、右辺を先に評価して、左辺に代入する

解釈してやった場合

岡部氏のライブラリは、右辺の評価時間におけるxの値を、左辺の評価時間におけるxの値としてイミュータブルなストリーム上に分布する、という説明になるんだろ?

馬鹿から理解できない?

kenokabe氏のGUIコードイベントのたびに同じ変数t(実体はvalOnT)の値を更新しており、

ライブラリの内部的にはな。まだ内部で破壊的代入してるってゴネてるの?精神病

timeengineはライブラリの内部実装だけでなくユーザから見ても関数型ではなく命令型。

ユーザが見ても関数型だが、おまえみたいに命令型のコードかけば、その文脈でも関数型の値が帰ってきたり、定義することができる。

それだけだが、馬鹿から理解できないか

これは過去の値が別の場所に保存されていようが無関係

お前自身がすすんで命令型のコード書いてるんだから、その評価時間のズレで「過去時間」ってのが発生するんだが、命令コード意味しってるかい

http://anond.hatelabo.jp/20160520140758

言い訳してるのはおまえ。

関数ライブラリつかって、あからさまな命令型を書いて、命令型だ!って言われてもな。馬鹿だろ?

方程式の左右の評価時間が違う処理系ならば、岡部氏の説明するとおり、その異なる時間FRPライブラリ挙動するだけ。

そんなことも理解できないの?

http://anond.hatelabo.jp/20160520135548

一応説明すると、Elliottの元記事

HaskellのIOモナドが「IOアクションを生成する純粋関数プログラム」なのと同様、

Cのプリプロセッサは「Cプログラムを生成する純粋関数プログラム」って言ってるのね。

から「cpp + C言語処理系」は「Haskell + 処理系」と同じく純粋関数型だと:-)

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん