「プログラム」を含む日記 RSS

はてなキーワード: プログラムとは

2017-02-26

http://anond.hatelabo.jp/20170226200826

プランナーに限らない。

プログラマにはプログラミングで何ができて何ができないのか、

プログラムを作るにあたってどのような情報必要か、

一度決めたことは引き返せるのか引き返せないのか、といったことがわからない。

コミュニケーションカバーしようとしても、当のプログラマからの返答が的を得ないのでわからないしイライラする。



まり、「○○なプログラムを作って」とプログラマに依頼する際に

○○をどこまで詳しく追及しないといけないのかがお互いにわからない。

例えばプランナーが「ログインボーナス作って」と言ったとする。



プログラマログインって何?ボーナスって何?」

プランナーパズドラとかにあるやつだよ。ゲーム起動したらいろいろもらえるでしょ」

プログラマ「起動するたびにもらえるの?アプリ閉じてもう一回起動したらまたもらえる?あとそれと具体的に何がもらえるの?もらえるってどういうこと?なんとかボックス的なやつ?賞味期限ある?」



このあたりでプランナー思考停止して上の空になるパターンが多い。

このようなやり取りに辟易するのはゲームプランナーに限らない。ソフトウェアを作る仕事において常に発生する。

プログラマ仕事を依頼する際、プログラマの方でうまくやっといてくれというようなことに関して面白いほどプログラマはうまくやってくれない。

後になって不具合が発生すると「貴方がそうしろと言ったからだ」と責任を依頼者に転嫁しようとする。

http://anond.hatelabo.jp/20170226193408

AIにとってはプログラム通りで正しい事だけど、人間判断としては間違っている事、

例えば、生産性が上がらないか弱者は切り捨てようって判断を下したとき

AIが悪意や意思を持ったように錯覚する事はありそう。

anond:20170225195916

"Google翻訳オープンソースプロジェクトに使うのはダメなのか? " についての反論

いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。

GPLコンパイラの例

このGPLコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。

確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェア著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。

ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。

詳しくはGNUの書いた記事契約を元にしたライセンスを読むと良い。

https://www.gnu.org/philosophy/free-sw.html

ほとんどの自由ソフトウェアライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアライセンスは、契約を元にするもので、契約もっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。

わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンス利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由である結論づけるかもしれません。

また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフト保護されたソフトウェアでも、それによって作成された著作物GPLにならない(つまりコンパイラやパーサーのライセンス継承しない)ことを根拠考察しているようだが、実はbisonやGCCGPLにはライセンスに対する例外付属していることを考慮すべきである

GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアライセンスが影響しないことを確実にするためにこれらの例外規定しているのではないか

まり記事議論世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。

フェアユースについて

フェアユース規定は例えば日本では存在しない、

加えて言えば、たとえフェアユース規定が全世界的に利用できて、営利目的でなければ利用できたとしても、

フリーソフトウェア/オープンソース定義の中に

自由.0: どんな目的に対しても、プログラムを望むままに実行する自由

(i.e. オープンソース定義 6項 利用する分野に対する差別禁止)

がある限り、そのような制限ディストリビューションは受け入れられないだろう。

またOracle vs GoogleJavaAPI訴訟はケースとしてはかなり特例であり、

一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、

これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である

というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである

Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーコンピューター計算コントロール

つべであるという自由ソフトウェア思想と明らかに相容れないものである

また(例えば)Google翻訳翻訳処理の計算依存することにより、ユーザー入力Googleが常に把握することになる。

多くのFLOSSシステムディストリビューション自由ソフトウェアを主に入れるというガイドラインを持っている。

アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、

これは事実上妥協産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者異論を挟まないだろう。

例えばDebianはあるソフトウェアがDFSG(Debianフリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物依存する場合、contribというセクションに閉じ込めており、それは公式システムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)

Ubuntuコミュニティで作られた著作物コミュニティ哲学に反する物に依存するというのは、

かなり致命的である。たとえ奇跡が起こり例外的Google翻訳や一部のプロ翻訳ツールBSDライセンス(Launchpad上での翻訳ライセンス)での出力を許したとしても決して褒められたものではない。

Ubuntubug#1に"Ubuntuソフトウェア自由である。常にそうであったし、今後も常にそうである自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである

https://bugs.launchpad.net/ubuntu/+bug/1

この反論を読んだ読者の中にはあまりGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、

いわゆる"Linuxディストリビューション"の中には数多くの重要GNUソフトウェアシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)

またUbuntu派生元となったDebianの成立経緯にはやはりFSFが関わっている。

さらに言えば、システム保守を手伝う人の中にはシステムフリーからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)

のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。

2017-02-25

Google翻訳オープンソースプロジェクトに使うのはダメなのか?

免責: これは法律専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。

最近プログラマの間で

Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」

http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace

が、話題になってますね。

Ubuntu翻訳プロジェクトで発生したトラブルの話です。

この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSS翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます

ですが、プログラマの間で単にWeb翻訳OSSに使ってはいけないんだという認識が広まってるように見えます個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています

どういう話かというと、自分個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースライセンスで公開しています)



注意書き

念のため言っておきますが、これは元記事問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります

コミュニティ思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。



Google翻訳利用規約について

もとの記事のとおり、Excite翻訳利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。

ここでは、Google翻訳に焦点を当てた話をします。Google翻訳利用規約はどうか?というと、Google利用規約については翻訳結果の利用についての記載がありません。

https://www.google.com/intl/ja/policies/terms/

記載がないということは、使用してよいのか?使用してはいけないのか?いったいどちらなのでしょうか?



GPLコンパイラの例

機械翻訳権利問題と似た構造の話に、GPLGNU一般公衆ライセンス)で許諾されたコンパイラによってコンパイルした結果の利用があります

GPLの本文には、GPLプログラムの出力結果自体GPLのものを含む場合にのみその出力結果にGPL適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているか記載はありません。

これについては、コンパイラによるコンパイル結果に対して、コンパイラ著作者はなんら権利を持たないと考えるのが一般的です。

GNU自体もそういう見解を持っています

https://www.gnu.org/licenses/gpl-faq.ja.html#GPLOutput

著作権法は人々があなたプログラムとかれらのデータを使って作った出力結果の利用に関して、あなたに何の発言権も与えていません。

コンパイラ機械翻訳ツールとの違いが、対象が人工の言語であるか、自然言語かので違いしかないと考えるならば、Google翻訳の結果をOSSに利用することも問題ないということになります



ウィキメディア財団見解

ウィキメディア財団法務チームは、Google翻訳した文書ウィキペディア内での利用についての見解を公開しています

https://meta.wikimedia.org/wiki/Wikilegal/Copyright_for_Google_Translations

これはアメリカ法律に基づく話ですが、CC-BY-SA 3.0やそれに類似するライセンスコンテンツGoogle翻訳翻訳してウィキペディア使用してもGoogle著作権侵害する可能性はとても低い(very unlikely)と結論づけています

要点をまとめると以下の通りです。

ウィキメディア財団見解には含まれていませんがアメリカ法律でいえば、さらにもう一つ「フェアユース」にあたるのではという話があります。これはGoogle自体がよく知っている話かもしれません。



Oracle vs GoogleJava API訴訟

これはAndroidAPIJavaAPIが流用されていることについて、OracleGoogle訴訟したものです。

これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコ地裁では著作権使用料支払いの対象にはならないという判決が下っています

(この裁判自体はまだ続いているようです)

フェアユース」というのは、アメリカ著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権侵害とはしないと考えるものです。

Google翻訳結果のOSSでの利用をこれに当てはめると

ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidJava APIの流用と比べても、さらにフェアな利用であるように見えます

さて、ここまではアメリカ法律での話でした。

(ちなみにGoogle利用規約には、「カリフォルニア州抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州法律適用されます。」と書かれています)



文化庁見解

今度は日本法律に基づく話です。

著作権情報センターサイトに、 コンピュータ創作物についての文化庁報告書記載されています

http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html

この報告書は、機械翻訳ユーザー機械翻訳システム使用するために行う原文の編集や出力の編集創作的寄与となりうることを認めている一方で、機械翻訳開発者翻訳物の著作者になるということについては否定的です。

なお、原文解析等のプログラム作成者及び汎用的な辞書データベース作成者は、一般的翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。

これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳技術は大幅に進歩しましたが、創造個性表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます

これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者著作物機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間二次著作物になるということになりそうです。



白に近いグレー

これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているか説明してきました。

では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。



グレーなものを作ることの良し悪し

だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。

著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。

有名なところでいうと、Monoが思いつきますAndroidDalvikJavaAPIを真似したものであるのと同じように、MonoMicrosoft.NETフレームワークを真似しています。つまりMonoについても訴訟リスクはあっただろうということです。

しかし、OracleGoogle対立したのとは対照的な道をMonoはたどります

2016年Monoプロジェクト運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoMicrosoft公認プロジェクトになったというわけです。

権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。



Ubuntu日本語化プロジェクトでの良し悪し

すこし元の記事に話をもどします。冒頭にも書いた通り、Ubuntu日本語化プロジェクトに対してWeb翻訳の結果を突っ込むという行為は、批判されるべきだと思っています

まずは質の問題です。現在Google翻訳などは、UI翻訳に向いていません。UIほとんどは、意味合い文脈依存する単語や短文です。UI翻訳は、実際にその機能を動かしながら、動作にあった訳語を割り当てていくべきです。

Google翻訳などを使って一括で、訳語を割り当てても良いUI翻訳はできません。

UIにとっての良い訳については、元記事のいくやさんがとても良い話を書いています: https://github.com/ikunya/howtotranslatelibo/blob/master/howtotranslatelibo.md#ふさわしい翻訳の考え方 )

次に、白に近かろうがリスクのあるものを入れることになるということです。Ubuntu日本語化ローカライズであれば、すでに多くのユーザー使用しているでしょうし、そういうものについてリスクのあるものを後から入れることになります

そういったことを独断で黙ってやるというのは、歓迎されたものではありません。少なくとも、コミュニティに対して事前に方針を聞いたりすべきだったでしょう。

まりクオリティが低い上にリスクのあることを黙ってやったわけで、もちろん批判されるべきでしょう。



自分場合

はいえ、OSSには個々の事情があります。次は自分場合の話をしてみます

まずは質の話です。

自分プロジェクト場合Google翻訳を使ったのはドキュメントです。日本語で書いたドキュメントをあたらしいGoogle翻訳に入れてみたところ、そこそこのクオリティ翻訳が出力されており、自分ゼロから翻訳するよりも、原文を翻訳やす修正したり結果に対して修正を加えていったほうが質と速さの両面でよいと判断したので、Google翻訳使用しました。

次にリスクの話です。

OSS企業権利問題訴訟されるということはめったにありません。OSS公益性の高いものなので、むやみに訴えれば社会からの反感を買いますし、ほとんどの場合は訴えても大した金になりません。

訴えられるとすれば、そのOSSが十分に儲かっている場合です。もしOSS大金が儲かったらGoogleから訴えられてしまう!どうしよう!と考えるのは、宝くじに当たったら強盗におそわれてしまう!どうしよう!と考えるのに似ています

まず宝くじは当たらないですし、宝くじが当たったらそのお金対策を行えば良いだけの話です。

実際Linuxでは、特許周りの対策としてOpen Invention Network(OIN)を設立していますLinuxなどソフトウェアに対して特許を主張しないことに同意した企業から特許を買収して、そういった企業に対してロイヤルティー・フリーで許諾を行っている会社です。

これによって、Linux関連のソフトウェアに対して訴訟をしてきた、いわゆる「パテント・トロール」に対して訴訟をやり返すなどの対抗手段を得ているわけです。

別の視点でのリスク

それにOSSにまた別の角度のリスクがあります

権利問題訴訟されたことによって失敗に終わったOSSというのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業うんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます

そういったこともまた、OSSリスクなわけです。

結局のところ、自分場合Google翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Google翻訳改善するためのデータを得られます

わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。



Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか?というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェア翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。

質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります

OSS翻訳者コミュニティ機械翻訳の利用についてそのプロジェクトで使って良いか方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合コミュニティ方針確認した上でやっていくしかないんだろうなあと思うところです。

略語発音しているLispプログラマ諸君

プログラムと省略語でふと思ったけど、実にうらやましいなぁ。

だって堂々と合法的セックス!(ぴー)って言える。

オライリーの本にも大真面目に書いてあるもんね。s-expはsex peeと読めって。

というかコンスセルリストってムカデ人間じゃね?

マジでエロ言語だなLisp。もう舌とか唇とか使ってなんかする言語に見えてきた。おのれ81!

http://anond.hatelabo.jp/20170224152614

便乗

http://anond.hatelabo.jp/20170223234843

  

便乗。

当方プログラマー業界10前後

  

テスターなのにテストも満足にできないおじさん

協力会社から人材派遣者。45歳前後(当時)。

テストのやり方を理解できていない。

教えてもらっても半分くらいしかちゃんとできない。

自信がないならわかるまで質問しようね。

1週間くらいで元の会社に戻らされた。

  

職場を仕切るSE多重人格

45歳前後(当時)。

もちろん職場にはより上の役職の人がいるが、その人らを手玉にとる。

さらにいろんなプログラム管理しているので、不具合修正優先度を人質各部から毎朝挨拶にやって来る(ご機嫌取りに来る)。

経理資格ももっているらしく、経理から相談に来る。

裏で何やっているのか分からないようにいつもニコニコ

たまにドスを効かした声を発す。

安直修正コメントを全く書かない(死んで欲しい)。

VBAで年度コード計算無駄連続IF文で年を列挙して書いていた(クソコード)。

下記のように書けるのにね(笑)

 YearCode = intYear - iif(intMonth < 4, 1991, 1990)

SEの腕は3(5段階評価、以下同)。

プログラムの腕は2。

人生で死んで欲しい人5本の指に入る。

  

プログラムの書き方教えたら寝かけたやつ

島人。25歳前後(当時)。

基本、面白い人。

プロプログラマー思考の真髄を見せてやったのに寝かけた馬鹿野郎

でも憎めないところがあるのが魅力。

プログラマーは諦めたのか、テスターやなぜかSE的なことをやっているらしい。人伝いに聞いた。

  

社員旅行夜這いしてクビになるやつ

話は面白いけど、少しイキったやつ。30歳前後(当時)。

なぜか芸能界の裏の話を知っていて休み時間披露する。

要領は良い方。

だけど社員旅行女性夜這いをかけたのが女性本人から会社に告げ口をされクビに。

その女性知っているがそんなに可愛い方ではない(溜まってたのか?)。

私とは別会社なので私はまったく関係ない。

  

ヤンキー上がりの強面SE

リーゼントが似合う45歳前後(当時)。

凄んできたり、睨む癖が抜けきれてない。

一度相談したら睨まれた。凄く怖かった(ウソ)。

家族持ちなのにお盆時期に1週間無断欠勤

しかし何事もなかったかのように出社。

どう処理されたのか不明

人生で死んで欲しい人5本の指に入る。

  

太鼓持ちSE

上のヤンキーSE太鼓持ち40歳前(当時)。

良い高校を出たらしいが専門学校卒。

プログラムの腕は4。

ただ頼りない顔面で、喋りが下手。でも太鼓持ち

死ななくてもいいが、いつもヤンキーSEとつるんでるので気持ち悪い。

  

おねぇプログラマー

黙っていられない。おねぇ口調。35歳前後(当時)。

昔勤めてた会社の先輩。会社喧嘩してクビに。

残業ドロボー。人が終わる時間の3倍以上かかってた。しかバグ混入率高し。

プログラムの腕は1。喋りは5。

あと、貸した金返せよ!!!

現在生活保護を受けているらしい(たぶん抜けられない)。

  

クソ、馬鹿が口癖のやつ

四六時中まわりを馬鹿呼ばわり。50歳前後(当時)。

ハラスメントまりない。不快仕事邪魔

フケを撒き散らしていた。汚いのでやめてくれ。

職場に遊びに来ている気がしてならなかった。

職場学校じゃねえんだぞ!」と言ってやりたかった(ヘタレ)。

仕事はできるか不明

直接絡んでないので死ななくてもいいが、死んで欲しいと願っている人はいるんじゃないかな。

  

最初の人だけ派遣と書いたが、他にもいる。でも省略(プロパーとは限らないって事)。

まだいろんなキャラが居た気がするがとりあえずこのくらいで。

フェイク有り)

2017-02-22

http://anond.hatelabo.jp/20170222201147

でも実際にエンジニア面談とかすると「高校ときとかプログラムとかやってん?」みたいなことを聞かれるぜ。

ワイの高校のころってwin95時代やでって前提とか軽くスルーして。実際VBとかはやってたけどそんなん言えるような実績になっとらんっちゅーに。

みんないるはずもない化け物を探してるんやで。

http://anond.hatelabo.jp/20170222193043

高校プログラミングに強い(笑)先輩がrand()の質の悪さを説明するために点描するプログラム書いてくれたな。

ものの見事に濃淡が偏ってて、「ああ確かに質が悪いんだな」と思ったけど、今思うとどうなんだろうあれは。

カルドセプト乱数問題

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

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

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

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

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

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

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

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

2017-02-21

プログラムの触りにCから始めるのは止めにしませんか

Pythonが神だよ。読みやすいよ。

計算時間とか気にする人だけがC,C++を学べばいい


今時プログラムを学びたい人はなんかゲームみたいなの作れるんでしょとかwebアプリと書いてみたいって理由が多いでしょ

それならCじゃなくね。Pythonじゃね、jsじゃね。

2017-02-19

http://anond.hatelabo.jp/20170214233309

二桁の整数の和を返す


そんな曖昧仕様記述でちゃんとしたプログラムが書けるかよ、バーカ。

逆に、バグがあってもよいなら、プログラムはどんなことも実現できる。

2017-02-16

http://d.hatena.ne.jp/shi3z/20170216/1487200968

バグのないプログラムを書くことは理論上は可能である(http://d.hatena.ne.jp/shi3z/20170216/1487200968)

なにいってんだこの人は。ドヤ顔で知性があることをアピールでもしたいのか。

バグのないプログラムを書くことはできないのか?難しいかもしれないが、十分に気を付けていれば防げるのではないか?」

の問に如何に回答するかの話題なのに。

この人はプログラムの分からないおっさん

バグのないプログラムを書くことは理論上は可能である

そのためのツールノウハウもある。

それを定理証明支援言語と呼ぶ。」

かいいんだすんか。

http://anond.hatelabo.jp/20170215111309

個人的にはこの辺の話でコストと折り合いつけて、どのへんにしましょうかって話し合うのが正しいと思う。

理論上は可能とか、ツールもありますよとかいいだしたら、何でそれやらんのってなるじゃん。

んでやらない理由説明するじゃん。

じゃあ無理なんだねってなるじゃん(このときおっさんは無理な理由理解できない)。

でもそれって話を一旦発散させただけじゃん。

おっさんからしたらわけわからんこと言われて、結局なにも解決せず、ただ何もわからなかったが無理なのかってなるだけじゃん。

はっきりいうとこの人は仕事できないと思う。

少なくともプログラムの分からないおっさん定理証明支援言語かいい出すやつは仕事できない。

相手視点に立てていないし、落とし所も考えず、知識をひけらかしてるだけ。

http://anond.hatelabo.jp/20170214114736

 http://d.hatena.ne.jp/shi3z/20170216/1487200968

定理証明支援ができても――、

定理の間違いは正せない。

証明自体プログラムにはできない。

・それ以前に支援プログラム自体の間違いも正せない。

ASプレイ理想的な事を確かめられたとして、ゲームのものを作るのとは全く別、みたいな気がするんだけどどう?(笑)

 仮にAIを使った直感系を応用して定理プログラムのものを構築するとの主張だとしても、それはディープラーニングが100%ではないと自分エクスキューズしてるよね?

CoqもAgdaも前提となる定義存在した上で、そのコーディングや飽く迄も定義の上で成り立つ定理支援しか過ぎない。

 我々は必ず間違うし、間違えないものはそれを正す方法も決して学習しえない、なぁんて思うんだけどなぁ。

TASさんがプログラム開発するようです

http://anond.hatelabo.jp/20170214114736

理論上最速のゲームクリア」を目指すTASプログラマに例えて、「理論バグのないプログラム開発は可能」かどうか検証する思考実験

時をさかのぼ能力を持つプログラマ(以後TASさんと呼ぶ)が居ると仮定する。

プログラムリリース後、バグが発覚する度にTASさんがリリース前まで戻ってそのバグの原因を修正すれば、そのバグは無かったことにできる。

これを繰り返して、サポート期間に発生するすべてのバグを無かったことにできれば、「理論バグのないプログラム開発は可能」といえるのではないか

不可能と言えそうな根拠

・何度繰り返してもバグは無くならないよ→そうだろうか。システムが有限である以上、バグも有限ではないか

・直せないバグもあるよ→直せない理由にもよるが、ある程度仕様変更しないと直せないケースはありそう

・全部のバグ排除するための開発期間が足りないよ→これはありそう。納期変更できなければいつか限界がくる

他にもないだろうか。

図書館の貸出ランキング

某市立図書館のが公開されてて面白かったので貼る。


わりと普通っぽいジャンル

歴史・伝記・地理旅行


社会教育民俗学軍事


アフィブログタイトルみたいになってるジャンル

総記哲学心理宗教言語


工業コンピュータ医学


家庭・手芸料理育児


それ科学じゃなくて図鑑じゃん

自然科学動植物産業


偏りすぎ

芸術スポーツ趣味


子供の本

2017-02-15

バグが起こる仕組みを説明する

http://anond.hatelabo.jp/20170214114736

 

1.権威を使う

GoogleMSAppleでさえバグを生み出している

 

2.ハードウェアに喩える

車は完璧に近いように作られているが、整備なしに数年後きちんと動いているかどうかは保証できない

整備とはデバッグのことである

 

3.ユーザーを絡める

ユーザーの行動を全て網羅することはできない

いつだってユーザー破天荒な使い方をする

 

4.プラットフォーム説明する

プログラミングという道具を使っているが

道具が完璧である補償はない

我々が完璧仕事をこなしても、道具がミスを起こす可能性はある

 

5.量を説明する

プログラムは数万行、数十万行のコードでできているが

文字ミスするだけでバグ簡単に作れてしま

たとえば小説一冊を1文字の誤字もなく書き上げることはプロでも難しい

 

6.難しさの質を説明する

小説を1冊書き上げることはできるが、全て矛盾なく仕上げるのは非常に難しい

要素や登場人物時系列を複雑にするほどどんどん難しくなる

プログラムも同じだ

 

7.バグ定義

そもそもバグとはどこからどこまでをいうのか

解釈を広げるとどこまでもバグになってしま

 

8.プログラムとはどこまでか

コンパイラコードエラーを指摘してくれるが

仕様エラーを指摘する者はいない

仕様エラーを残すとそれはプログラムバグとなる

 

9.掃除に喩える

バグのないコードというのは、塵1つない部屋のようなものだ 

そのために努力はできるが、物理的に不可能

 

 

個人的には1が好き

考える必要がない

http://anond.hatelabo.jp/20170215165906

0.99999999999999999999............=1

これが成り立つ時点でバグのないプログラムとか無理だよな

http://anond.hatelabo.jp/20170215111309

そういや新聞とか本の場合は、書いた本人の目だけだと思い込みとかクセとかがあって万全を期すのはかなり難しいので、別人の目で校閲複数回通すけど、

プログラム仕事ってそういうのあんのかな?

2017-02-14

http://anond.hatelabo.jp/20170214114736

正しいでしょ。例えば、二桁の整数の和を返すプログラムなら簡単完璧に作れる。それが複雑になろうが原理的には可能

妄想オナニーをする。それは瞑想である

ここ数週間、妄想オナニーをしている。

それが当たり前の人もいるかもしれないが、ぼくはそうではなかった。

エロ画像エロ動画収集に一日の大半を費やし、プログラムを覚え、効率化してきた。

貯めてきた紳士データの量は2桁テラに及ぼうとしている。

だが、ぼくはこれらを捨てた。

そう、郭海皇がパワーを捨て、技術を身につけようとしたように、ぼくもまた、データ封印し、妄想力を鍛えようとしている。

妄想力は筋肉と同じように、繰り返し行うことでより強く、鮮明に、そして自在に操れるようになる。

妄想力を鍛えるメリットは様々だ。実践へのイメージトレーニングにもなるし、レストランでも電車の中でも鍛えることができるし、実戦時相手の戦力不足妄想で補ってやることもできる。

アフターセックス時に振り返りをすることで、予習をすることすら可能である

目を瞑り、外部からの刺激を遮断して、イメージを操ることは、瞑想と同じであるトランス状態に入るのはもはや当然だし、そうなれば瞑想だけでなく自己催眠の暗示をかけることもできる。

唯一のデメリットは、境地に達するまでの努力必要なことぐらいだろうか。

しかし、一度身につけた妄想力は中々衰えないし、性欲以外のことにも使えるようになったりする。

こうしてぼくは、今日妄想の力を鍛え、もう一段高みへと登っていく。

http://anond.hatelabo.jp/20170214164715

顧客「ウチが求めてるのはバグのないプログラムじゃなくて業務をそつなくこなすことができるシステムだよ? そんなことに拘るエンジニアさんは、要らないかな?」

http://anond.hatelabo.jp/20170214151240

PMバグのないプログラムを書くことはできないかもしれないが、バグバグじゃないように運用することはできるだろカス。そのためのフェイルオーバーさせるためのロジックを書けゆうとんのや」

http://anond.hatelabo.jp/20170214114736

バグのないプログラムを書くためには、すべての仕様プログラム全体を記憶したうえで、実際に起こり得る可能性を全て列挙できる必要があるんです。

膨大な仕様プログラム記憶し続けることは非常に困難で、自分の脳力では無理です

10日前の夕食のメニューをすぐに思い出せるくらいの記憶力が無いと無理です。


…とでもいうしかない。

ログイン ユーザー登録
ようこそ ゲスト さん