Visual Studio Codeが天下統一へ

2021年7月27日 13:03

あるAnonymous Coward 曰く、

戦国時代だったテキストエディタ界をVisual Studio Codeが天下統一しつつあるそうだ。

Stack Overflowの調査によると、Visual Studio Codeの人気は2018年の35%から2019年には51%に達し、他のエディタが越えられれなかった40%のラインをオーバーしてきたとのこと。また、記事ではVisual Studio Codeを「テキストエディタの進化の最終地点」と評価している。

エディタ戦争というと長らくEmacs vs VI (最近はvim)が語られていたが、これらの「初期のエディタ」は「コピーやペースト、アンドゥなどの機能を利用するのに独自の方法を使うなど、新たに使い始めるにはハードルが高い」と評価している。人気度もEmacsが4～5%、vimが25%程度とVisual Studio Codeには及んでいない。

スラド
GitHub、関数名やコメントからコードを生成・提案する「GitHub Copilot」を発表 2021年7月2日 18:45

GitHub、関数名やコメントからコードを生成・提案する「GitHub Copilot」を発表

スラド

著者: nagazou

2021年7月2日 18:45

GitHubは6月29日、開発者のコード作成を支援するためのAIプログラミング機能「GitHub Copilot」を発表した。開発者の生産性を向上させる目的のもので、関数名とコメントから関数のコードを丸ごと自動補完するなどの提案も行えるという。Microsoftの「Visual Studio Code」および「GitHub Codespaces」向けの拡張機能として提供されるとしている。登録を行うとテクニカルプレビュー版の招待が受けられるようになるとしている（CNBC、ITmedia、TechCrunch）。

GitHub CopilotはOpen AIと提携してこのツールを開発したという。このAIは何十億行ものコードを使って訓練を受けており、コードを書き進めていくと途中でGitHub Copilotからコードの提案が行われるという。開発者はそうした提案を受け入れたり拒否したりできるとしている。

一方でこのOpen AIの学習にはGitHub上にあるGPLコードも使われていると見られ、GitHub Copilotがプロプライエタリコードを利用している扱いとなり、GPLに違反する可能性もあるのではないかとする指摘も出ている模様（eevee氏のツイート）。

あるAnonymous Coward 曰く、

現在はテクニカルプレビューだが、将来的にはこの機能をベースにした商用製品の発売を予定しているという。ただし関数名やコメントは「平易な英語で」記述する必要があるため、日本人プログラマーが活用するのにはまだ難しいだろう。

スラド
プログラミング言語を一つ学んだら別の言語も簡単に習得できるという考えは正しいのか？ 2021年6月29日 15:03

プログラミング言語を一つ学んだら別の言語も簡単に習得できるという考えは正しいのか？

スラド

著者: nagazou

2021年6月29日 15:03

ミシガン大学教授のMark Guzdial氏は、同業のコンピューターサイエンス（CS）の教育者二人から、最初のコースでプログラミング言語を気にする必要はない。学生が概念をしっかり学んでいれば、次に学ぶ言語では最初に学習した言語の知識を応用できるとする意見を聞いたという。しかし、Mark Guzdial氏本人は、過去の経験などから二つ目の言語習得はそう簡単ではないとして、先の二人とは異なる考えを持っている（Mark Guzdial氏のブログ、GIGAZINE）。

LISPやMICRO-PLANNERのように、基本的な概念が全く異なる第二言語の学習は、第一言語の学習と同等かそれ以上に難しい可能性が高い。学生がデータサイエンティストになりたいのであれば、C言語を学ぶよりもRやPythonを学ぶ方が合理的だ。こうしたことから、Mark Guzdial氏は、「なぜ最初に学ぶプログラミング言語は重要ではない」という考え方が定着しているのか考えるようになったそうだ。同氏の考えとしては、1960年代後半にCSカリキュラムが定義されたとき、プログラミングの数学的基盤に重点が置かれていた。このため、現在教育者になってるような人は、現代の学生と比較すると数学的に強い基盤を持っている。このため、言語の違いは表記法の違いに過ぎないと考えているのではないかとしている。

スラド
証明支援システムCoq、新しい名称を検討中 2021年6月17日 18:04

証明支援システムCoq、新しい名称を検討中

スラド

著者: nagazou

2021年6月17日 18:04

headless 曰く、

証明支援システムのCoqが新しい名称の検討を4月から進めているそうだ(The Registerの記事、 GitHubのプロジェクトページ)。

Coqという名称はフランス語の雄鶏や料理人を指す単語のほか、CoC(Calculus of Constructions)や最初の開発者の一人であるThierry Coquand氏からとったものだ。英語で雄鶏を示す単語「cock」と発音も同様だが、この単語が男性器を指す言葉としても使われることから、ユーザーが気まずい思いをすることもあるようだ。

現在のところ、Coqの名称はそのままに発音を変える(シーオーキュー/コーク/クック)ものや、フランス語であることを強調(Le Coqなど)するもの、文字を追加して長くする(Coqpit/PeaCoq/Coquandなど)もの、鶏や開発者にちなんだCoqとは異なる名称(Gallo/Poussin/Thierryなど)が代替案として検討されている。

ただし、発音の変更やCoqを含む長い名前の場合、結局「Coq」と呼ばれ続けてしまう可能性もある。また、Coqをフランス語でスペルアウトした発音(セオキュ)があまりよくないことや、「Le」がミームなどで非フランス語話者がフランス語風の表現を作るステレオタイプ的表現である点も指摘されている。

なお、プロジェクトは引き続き代替案や意見を募集しているが、今回The Registerの記事でCoqを初めて知った人の意見は役に立たないので口を出さないでほしいとのこと。スラドは特にそのような制約はないので、自由にコメントしてほしい。

スラド
MicrosoftのC#コーディング規約に「privateフィールドにはプレフィックス」と追記されて混乱を呼ぶ 2021年5月16日 18:08

MicrosoftのC#コーディング規約に「privateフィールドにはプレフィックス」と追記されて混乱を呼ぶ

スラド

著者: headless

2021年5月16日 18:08

あるAnonymous Coward 曰く、

C#のコーディング規約として一番権威あるのは本家Microsoftのものだと思われるが、そのページに、いつの間にか「private/internalフィールドには _ プレフィックス」「private/internalなstaticフィールドには s_ プレフィックス」「ThreadStaticの場合は t_ プレフィックス」を付ける必要がある(should)という項目が追加され、C#er達が大混乱に陥っている(C#のコーディング規則、発端となったツイート）。

C#においては、後発のUnityがプレフィックスを付ける文化を持っている一方、本家のC#においては、プレフィックスを付けずに this. で参照する文化があり、StyleCop.Analyzersなどのスタイルチェックもこれをデフォルトとしている。また、2010年頃のプログラミング書籍では「メンバー変数にプレフィックスを付けるのはIDEが未発達の頃の名残で、IDEが発達した現代では不要」としてプレフィックスを付けないことが推奨されていたと記憶している。

今回の記述はそうしたこれまでの流れと真っ向から対立するもので、Twitter上ではアンダースコア派が歓喜する一方、this派からは大ブーイングが起こっているようだ。ただし、この規約が書かれたのは6年前でそれが今になって反映されただけといったコメントもあるなど、なんでこうなったかはよく分からない。

元となったコーディング規約はオープンソースの.NETランタイム貢献者向けに書かれたものであり、C#開発者一般に向けたものではない。日本語版にはまだ反映されていないが、英語版には「.NET Runtime, C# Coding Style」から取り入れられたものであることが明記され、使いたければ使えばいいという感じになっている。「s_」「t_」の使用はハンガリアン記法を使用しないよう求める.NETの一般的な名前付け規則に反するが、この点は解決されていない。

なお、元のコーディング規約では「this.」について、「どうしても必要な場合を除いて避ける」と記載されている。

スラド
プログラミングはキー2つだけあればよい？ 2021年4月30日 14:31

プログラミングはキー2つだけあればよい？

スラド

著者: nagazou

2021年4月30日 14:31

Holy Cater氏の作成した究極のプラグラミングツール（自称）がバズっている。リンク先の画像を見ていただければ、一発で何か分かるネタなのだが、SimPad Nanoという小型キーパッドを利用して作成したコピー・ペーストの専用キーボードとなっている。キートップにデカデカと貼られた「コピ」＋「ペ」の文字のインパクトが強烈だ。左のキーにコピー(Ctrl+C)、右のキーにペースト(Ctrl+V)が割り当てられており、プログラミング時に必要不可欠なコピー＆ペーストが手早く行えるのが特徴となっている（Holy Cater氏のツイート、PC Watch）。

スラド
Qiitaが「今後はプログラマのことをエンジニアと呼称する」と宣言 2021年4月19日 18:11

Qiitaが「今後はプログラマのことをエンジニアと呼称する」と宣言

スラド

著者: nagazou

2021年4月19日 18:11

あるAnonymous Coward 曰く、

たまに燃えることのある「エンジニア」と「プログラマ」の呼称を巡る問題だが、プログラマのための情報共有サイトであったQiitaがガイドラインを改訂し、今後は「プログラマ」のことは「エンジニア」と呼ぶと宣言してまたちょっと燃えているようだ（Qiitaの発表, はてなブックマークのコメント）。

一般的には、プログラミングをする人が全て「プログラマ」である一方、「エンジニア」は機械エンジニアや航空エンジニアなども含めた技術者全般を指す言葉で、特にプログラミングをする人を指す言葉では無いと思うが、Qiitaでは「世の中のエンジニアの定義とは少しずれた定義とはなってしまいますが」と断った上で、同サイトにおいて以後エンジニアを「プログラミングの知識と経験を活用している人」に変更して、今後はこの定義を用いていくとしている。

昨今では未経験者が経緯を知らずにエンジニアを使っている例は非常に多くなったが、だからと言って世の定義と間違っていることを承知で間違った定義に改める理由はないと思うのだが、スラド諸氏の見解は如何に？

情報元へのリンク

すべて読む | デベロッパーセクション | プログラミング | デベロッパー |

スラド
超一流プログラマーになるには3万時間のプログラミングが必要 2021年4月8日 18:05

超一流プログラマーになるには3万時間のプログラミングが必要

スラド

著者: nagazou

2021年4月8日 18:05

あるAnonymous Coward 曰く、

https://gigazine.net/news/20210404-5-programmers-30000-hours/

プロになるには1万時間の練習が必要という1万時間の法則というのがあるが、ドナルド・クヌース（The Art of Computer Programmingの著者）やスティーブン・ウルフラム（Mathematicaの作者）クラスになるには、3万時間超のプログラミングが必要なようだ。

情報元へのリンク

何事も一流のスキルを身につけるには1万時間の練習が必要とする「1万時間の法則」なるものがマルコム・グラッドウェルによって提案されている。この法則の自体の是非はさておき、プログラマーのBreck yunits氏は、実際に1万時間プログラミングしてみて、実際にその効果に自信を持てなかったそうだ。そこで自身が尊敬する著名なプログラマー25人にプログラミングに費やした時間を問い合わせたという。そのうち返答は5人あり、その結果をGitHub上で公開したという（GitHub、GIGAZINE）。

なお返答のあった5人は以下の通り。

Donald Knuth　56000時間
Rob Pike　30000時間
Peter Norvig　30000時間
Stephen Wolfram　50000時間
Lars Bak　30000時間

いずれも3万時間以上プログラミングに時間を費やしており、yunits氏は次は3万時間を目指すとしている。

スラド
プログラミング言語「Julia」1.6.0が公開 2021年3月30日 06:02

プログラミング言語「Julia」1.6.0が公開

スラド

著者: nagazou

2021年3月30日 06:02

数値処理向けプログラミング言語Juliaの開発チームは24日、最新版となる「Julia 1.6」をリリースしたと発表した。同時にマニュアル「The Julia Languageも公開した。プリコンパイルを並列化することでさらに高速化したほか、コンパイル時間を計測するタイミングマクロが追加されているとしている。Julia 1.6は次期LTSになる可能性があるが、フィールドテスト後のv1.7が提供されることに決定するとのこと（Julia公式ブログ、CodeZine、TECH+）。

すべて読む | デベロッパーセクション | プログラミング | デベロッパー |

スラド
プログラミング言語「Go」がM1チップ搭載Macに対応 2021年2月19日 14:22

プログラミング言語「Go」がM1チップ搭載Macに対応

スラド

著者: nagazou

2021年2月19日 14:22

16日にリリースされたプログラミング言語「Go」のv1.16で、macOS ARM64がサポートされたそうだ。これによりApple Silicon（M1チップ）でもネイティブ動作するようになったという。パフォーマンスや安定性の向上、ビルドに必要な時間が最大25％高速化されたほか、使用メモリは最大15％削減されたとしている（The Go Blog、窓の杜）。

すべて読む | デベロッパーセクション | プログラミング | デベロッパー |

スラド
GitHubのページをオンラインVSCode版で表示可能な「GitHub1s」 2021年2月12日 15:28

GitHubのページをオンラインVSCode版で表示可能な「GitHub1s」

スラド

著者: nagazou

2021年2月12日 15:28

オンラインバージョンのVSCodeで、GitHubの任意のコードを表示できる「GitHub1s」というサービスが始まったそうだ。使用方法は簡単でURLのhttp://github.comをhttp://github1s.comに変更するだけでいいという。これによりgithubにあるファイルをオンライン版VS Codeに読み込んでくれる（kabukawaさんのツイート、GitHub1sプロジェクトアドレス、tproger.ru、Sina.com）。

統合用WebIDE「Gitpod」のようなより高機能なものも存在しているが、こちらは読み込みに数分を必要とすることもある。一方でGitHub1sは読み込み時間は数秒程度と非常に高速。またChromeユーザーの場合は、GitHub1sに対応した専用の拡張機能も用意されている。この拡張機能を追加すると、GitHubインターフェースに[Open withGitHub1s]ボタンが表示される。それを押せば、URLが追加されてVSCodeのオンラインバージョンでリポジトリを開くことができるそうだ（ITnews）。

すべて読む | オープンソースセクション | オープンソース | プログラミング |

関連ストーリー：
VSCodeの対抗馬というIDE「Eclipse Theia」登場 2020年04月08日
GitHubのリポジトリ数が1億件に到達 2018年11月12日
Windows標準アプリに対する要望募集、メモ帳に人気が集まる 2018年09月22日

「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？」という海外の分析

スラド

著者: nagazou

2021年2月3日 08:01

あるAnonymous Coward 曰く、

元ネタが投稿されたのは1年ほど前のようだが、「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？」(Why doesn’t Japan excel in software as they did in hardware?) というQuora記事の翻訳が話題になっていたので共有したい（Quoraの英語記事, Qiitaの翻訳）。

この記事では複数の仮説が挙げられているが、要約すると
1. 「日本人の職人気質や完璧主義が、ソフトウェア開発のパレートの法則やアジャイル文化と合っていない」
2. 「ソフトウェア開発職を他の技術職と同じように新卒一括採用や専門軽視で採用している」
3. 「英語が話せず、海外では古くなった技術や開発スタイルが今も跋扈している」
4. 「国際標準との互換性を軽視する」
となっている。

日本の中から見ていると分かる部分分からない部分もあるだろうが、スラド諸氏はこの分析、どう感じるだろうか？

情報元へのリンク

スラド
Ruby 2の3倍高速化を図った「Ruby 3.0.0」が登場 2021年1月4日 17:01

Ruby 2の3倍高速化を図った「Ruby 3.0.0」が登場

スラド

著者: nagazou

2021年1月4日 17:01

12月25日、Rubyのメジャーバージョンアップ版である「Ruby 3.0.0」が発表された（Ruby 3.0.0 リリース、OSDN Magazine）。開発には2016年にRuby 3x3という目標が設定され、OptcarrotベンチマークでRuby2の3倍高速化を達成することを目指したという。主にパフォーマンス、並行処理、静的解析に注力して開発されたとしている。

あるAnonymous Coward 曰く、

Ruby 3.0は2013年に最初のバージョンが公開された2系に続くメジャーリリースとなる。
RakuになるのかPython3になるのか。

情報元へのリンク

すべて読む | デベロッパーセクション | プログラミング |

スラド
プログラミングをすると変な夢を見る 2020年12月29日 07:03

プログラミングをすると変な夢を見る

スラド

著者: nagazou

2020年12月29日 07:03

プログラムに限らず、似たような経験は誰しもあると思うが、見返すかもしれないメモさんの記事によれば、プログラミングをした後に寝ると変な夢を見るのだそうだ。曰く、

isLoading というbooleanの変数を作っていた。（ここまで現実）その言語のboolean型はいくらの寿司で、いくらをシャリのどちらの端に固めるかによって、スイッチのようにtrue/falseを表現するようになっていた。いくらの場所が中途半端だったら、trueなのかfalseなのかわかりにくくて困るだろうなと思った。

という具合らしい。寝る直前にしていた作業の続きを夢に見てしまうことはあるが、寝ている間にコードを書いてしまう経験をした人はどれくらいいるのだろうか。

スラド
プログラム言語を処理するとき使う脳部位は言語野ではなかった 2020年12月23日 08:06

プログラム言語を処理するとき使う脳部位は言語野ではなかった

スラド

著者: nagazou

2020年12月23日 08:06

プログラム言語で書かれているコードは、人間の脳の言語処理を行うブローカ野（言語野）で処理されていると思われがちだ。しかし、米マサチューセッツ工科大学の神経科学者らの研究チームが、プログラムのコードを読む人の脳をfMRIでスキャンしてみたところ、コードを読む時に活性化する脳の部位は、ブローカ野と異なる部分だったそうだ（eLife、Massachusetts Institute of Technology、GIGAZINE）。

研究ではfMRIで2カ所の脳の部位を調査した。一つは数学の問題やクロスワードパズルの解決などの解決などに使われる分散ネットワーク（multiple demand network：MD）で、もう一つは言語処理に使われるブローカ野。実験では、テキストベースのプログラミング言語であるPythonとグラフィカルプログラミング言語であるScratchJr記述されたコードの2種類を読み込んだときの応答を調べたそうだ。

結果、MDシステムは両方の言語ともに反応したという。一方で言語システムは文の解析には強く反応したものの、コードの問題を処理するときには弱いもしくは無反応だったとのこと。

すべて読む | デベロッパーセクション | プログラミング | サイエンス |

スラド
Microsoft曰く、Excelの数式は世界で最も広く使われているプログラミング言語 2020年12月8日 14:03

Microsoft曰く、Excelの数式は世界で最も広く使われているプログラミング言語

スラド

著者: nagazou

2020年12月8日 14:03

headless 曰く、

Microsoftによれば、Excelの数式は世界で最も広く使われているプログラミング言語だという(Excel Blogの記事、 The Registerの記事、 BetaNewsの記事、 Neowinの記事)。

しかしExcelの数式言語には再利用可能な独自の関数を定義するというプログラミングにおける基本的な要素が欠けており、それを補うため新たに「LAMBDA」関数を導入するそうだ。Excelでは既にJavaScriptやTypeScriptを用いてカスタム関数を定義できるようになっているが、LAMBDA関数を用いれば数式言語のみでカスタム関数を定義可能となる。カスタム関数は他のカスタム関数を呼び出すことが可能であり、カスタム関数を再帰的に実行することも可能だ。これにより、Excelの数式言語がチューリング完全になるとのこと。

LAMBDA関数は現在、Office Insiderプログラムのベータ版チャネルでWindows版およびMac版Excelに提供されており、リボンの「数式」→「名前の管理」でLAMBDA関数を参照する新しい名前(カスタム関数名)を追加すればカスタム関数が利用可能になる。LAMBDA関数の書式は「=LAMBDA(引数, 数式)」というもので、カスタム関数作成後は「=カスタム関数名(引数)」のように入力することで引数が数式に渡されて演算結果が得られる。「=LAMBDA(引数1, 引数2 [, 引数3 ...], 数式)」のように複数の引数を指定することも可能だが、引数がいくつまで指定できるかは説明されていない。また、LAMBDA関数を直接呼び出して使用することも可能とのことだ。

スラド
ライフゲームでコンピュータを構築 2020年11月26日 07:01

ライフゲームでコンピュータを構築

スラド

著者: nagazou

2020年11月26日 07:01

あるAnonymous Coward 曰く、

みんな大好きコンウェイのライフゲームでコンピュータを構築する試みが公開されている。グライダー銃などを組み合わせて基本的な論理回路を作っている（Nicolas Loizeau - GOL computer）。

すべて読む | デベロッパーセクション | プログラミング |

スラド
Excelでドラクエ3を再現。VBAなし縛りでも高い再現度 2020年11月6日 13:04

Excelでドラクエ3を再現。VBAなし縛りでも高い再現度

スラド

著者: nagazou

2020年11月6日 13:04

Excelでドラクエを再現した人がいるそうだ。しかもVBAを使用しない状態で。再現度に関しては動画（音声はなし）を見てもらう方が早いが、かなりの再現度になっている（パパセンセイ365）。

VBAなしという縛りで再現するため、図やモンスターは散布図で表示、循環参照を使ってカウンタを作りF9を押しっぱなしにする、循環参照を使ってセル上で疑似的にプログラミングを作る方法を開発したという。マップ上でキャラクターを自動で移動させたり、戦闘シーンに入る部分などをVBAを使わない状態で再現するのに苦労したようだ。具体的な手法については元サイトで詳細に解説されている。

すべて読む | デベロッパーセクション | プログラミング | デベロッパー |

スラド
なでしこが教科書に採用されたことで日本語でプログラミングができる意味を考える 2020年11月2日 18:03

なでしこが教科書に採用されたことで日本語でプログラミングができる意味を考える

スラド

著者: nagazou

2020年11月2日 18:03

あるAnonymous Coward 曰く、

以前、日本語プログラミング言語「なでしこ」が中学校の教科書に採用されたという話があったが、なでしこ開発者である酒徳峰章氏と知人だという柳井政和(めもりーくりーなーの作者)氏が「なでしこ」の開発経緯とその意味に関してのコラムをまとめている(HARBOR BUSINESS Online)。

コラムなのでニュース性があるわけではないが、よくある教科書に載せるなら現場で使われている言語の方が良いのでは、という意見については、
学校でプログラムを学ぶ全員が、開発者になるのではない。普段見慣れた言葉でプログラムが書いてあるだけで、ずいぶんと気持ちが楽になる人も多いはずだ。母国語でプログラムを学べるのは有意義なことだと思う。
と返している。似たような意見はスラドにもあったが、これに関してはもっともだと感じる。なおこのコラムによれば、なでしこ利用者のうち仕事に使っている人は43％ほどいるそうだ。

この利用者数の数字は「なでしこ」公式サイトが15周年時に行ったアンケートによるもの。それによれば、利用年齢層は40代が38％、30代が25％、60代と10代が13％となっている。利用場所は趣味と仕事が43％で同率。タレコミの元記事によれば、日常の自動化処理などに使われている模様（１５周年日本語プログラミング言語なでしこ）。

すべて読む | デベロッパーセクション | プログラミング | デベロッパー |

スラド
プログラミング言語とエネルギー効率 2020年10月22日 16:05

プログラミング言語とエネルギー効率

スラド

著者: nagazou

2020年10月22日 16:05

ポルトガルの大学に所属する6人の研究者が「プログラミング言語全体のエネルギー効率[PDF]」というタイトルの論文を発表したそうだ。研究者たちは、27種類の異なる言語で書かれた10個のプログラミング実行し、実行時の速度と消費電力、そしてメモリ使用量を計測した。テスト用の10個のプログラムには"Computer Language Benchmarks Gameが使用されたという（The New Stack、ブログ: 最も電力を使わないプログラミング言語は？）。

この論文では、より高速なプログラムは総合的なエネルギー消費は少ないという考えは見直されるべきだと指摘している。プログラム実行中は電力が一定の割合で消費されているわけではないためだという。例えば、実験で使われたベンチマークテストの中の一つでは、Chapel言語で記述されたものは、Pascalで記述された同等のプログラムより55％実行時間は短縮されたが、エネルギー使用量はPascalで書かれたものの方が10％少なかった。

確かにエネルギー効率が最も高い上位5つの言語は、エネルギー効率は実行時間の短い順で高い。しかし、これを24言語にまで広げた場合は、OCaml、Haskel、Racket、Pythonに関しては、エネルギー効率と実行時間の短さが一致するものの、ほかの言語は条件によっては全く一致しなかったとしている。

すべて読む | デベロッパーセクション | プログラミング | デベロッパー |

ノーマルビュー