「プログラミング言語」を含む日記 RSS

はてなキーワード: プログラミング言語とは

2024-03-11

anond:20240311133554

いうても、html5フローだのエンデベッドだの、どのタグにどのタグ入れ子にするのが許されるのかとか、cssならどんなコードを読んでもその挙動を正しく予測できる、みたいな人は逆に高尚なプログラミング言語習得してる人でもまれじゃないかね。

プログラミング言語の基礎については難度の高低はあって、そこでマウントとる人もいるんだろうが、そんなレベル基準マウントとるのはおろかというか、道を究めた人ならどの言語でも貴重というか。

anond:20240311132927

htmlcssプログラミング言語ってニートの中でも最下層のやつだわな

中学生がイキってるならまだ微笑ましいけど

haskellやってるというといかにも理系学部卒っぽい。

htmlcss高卒か専門か職安の訓練受けた雑魚って感じ。

明らかに習得プログラミング言語が与える印象、高尚さの違いってあるよな。

2024-03-04

どのプログラミング言語を使ってるかなんて関係なくなる

日本語仕様を書ける能力重要になる

2024-03-02

エクセルマクロのお作法計算用シートという諸悪の根源について)

前置き

この日記の内容は、会社の後輩から最近エクセルマクロ勉強し始めて(キラキラ)」という話を聞いて、先輩ムーブかますために話した内容になります

とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。

ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。

増田の経歴

この記事趣旨

エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。

3行でまとめます

〇 エクセルシートはユーザーインターフェースインプット)か出力結果(アウトプット)のためのものとすべき

〇 データ加工をする場合には、原則配列辞書配列連想配列)に格納して加工を行い、最後の結果だけシートに出力するべき

〇 何事にも例外はある。

計算用シートとは

この記事では、エクセルシートを下記の通り分類します。

エクセルマクロにも色々あると思いますが、今回は下記を想定します。

日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータ入力された値を基に加工し、加工後のデータをシートに出力する

この場合入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。

(もちろん、ユーザーインターフェースの別の欄(セル)に出力する場合もあるし、その場合ユーザーインターフェース出力結果が一体のものとみなします。)

また、データ用シートは同じエクセルファイル内に基となるデータが含まれ場合を想定します。

(これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…)

ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。

例えばイメージするのはこんなマクロです。

1.元となるcsvファイルエクセルに読み出してシートに格納

2.そのデータは日付が数値型になっているので、日付(数値型)の入った列を文字列に変換した日付(文字列型)列を新たに作成

3.その列をキーとして対象となるデータを取り出すvlookup関数を各行に格納した列を新たに作成

4.その列で特定された列をさらに加工した列を新たに作成し、…

これは極端な例ですが、とにかく変数配列定義せず(あるいはエクセルセルオブジェクト変数のように扱い)、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。

その舞台となるのが、計算用シートです。

なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。

ある程度マクロに慣れた気の利く人なら、このシートはロック非表示にして、ユーザーから触れないようにするでしょう。

・・・これ、やめたほうが良くないですか?

こいつが日本生産性を落とす諸悪の根源だと思います

駄目な理由

ある程度詳しい人なら同意してくれると思いますが、このやり方でダメ理由はいっぱいあります

後で説明する配列辞書配列連想配列)と比べると格段に処理が遅いです。

わざわざエクセル操作しているから当然ですね。

ちょっと詳しい人が知っている「画面更新非表示」を駆使しても、配列を使った処理からみれば止まったハエです。

(参考)VBAで作ったマクロの高速化① 配列を使う

  • 可読性が下がる

いったんエクセルシートにデータを格納して加工しているので、コードエクセルシートを両方見る必要があり、とても読みにくいです。

変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります

計算用シートを事前に用意して、別のセル関数を格納しておき、マクロ関数を使ってデータ加工をするものも見たことがあります

これは懲役刑に処したほうがいいと思います

まり知られていませんが、セルの最大文字数は32,767 文字です。

セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります

他にもエクセルの数値を丸め自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます

できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているか日本GDPは上がらないんだと思います

他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまリスクがある、などいくらでも理由は上げられます

(逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・

じゃあどうするの

配列を使いましょう。

配列とは何ぞや、という人はググってください。

配列データを入れて、データ加工は配列変数に対して行い、一番最後の出力だけセルに値を格納する。

他のプログラミング言語なら普通にやっていることです。

個人的オススメしたいのは辞書配列連想配列)で、うまく使うとデータ管理簡単になり、処理も爆速になります

(参考)【VBA】大量データから高速で値を検索【Dictionaryを使う】

csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。

直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。

エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ますエクセル開くと処理もめちゃ不安定です。

(参考)Excel VBAでCSVオープンするときのパフォーマンス比較

いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分コードを書き始めたころは全部シート上で操作していました。

冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロやらせる、というマクロ本来趣旨にはあっていますし。

途中の計算過程もすべて目の前で展開されるから分かりやすいです。

ただ、それではダメなんです。。。処理は遅いし挙動不安定だし後で改修・保守する人が死にます

あと、エクセルシートやセルは当然エクセルしかないので、エクセルマクロVBAから他の言語に移れなくなります

自分エクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列辞書配列連想配列)のスキルはそのまま他の言語に活かすことができました。

配列の中身を見る方法別にある(ローカルウィンドウやDebug.printを使うなど)ので、リハビリに取り組んでほしいです。

(参考)VBA デバッグの仕方

もちろん例外もあります

計算用シートを許容できる、使うべきケースもあると思います。。

個人的には、

最後のは、なんでも自分確認しないと気が済まない上司発注で、意味不明と思いましたしたがしぶしぶやりました。)

などの場合計算用シートを使ってもよいと思います

この場合インプットエクセルシートに直接加工するのは論外なので、計算用(加工用)のシートを用意してそこで操作を行うことは必要だと思います

他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。

最後

そもそもツッコミとして、「データ加工するならエクセルマクロを使わずpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。

ただ、個人的にはエクセルマクロVBA)は大好きですし、初心者にもおすすめしたいです。

自分のような非エンジニアだと、セキュリティ関係などでPythonの開発環境とかすごく用意しにくいんですよね。

(あと、コマンドプロンプトの真っ黒な画面が怖かった)

その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セル挙動を追えば視覚的にプログラム理解できるし、初心者に優しいです。

(そのやさしさが上述したとおり悪魔の罠なわけですが。)

最初計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。

さらに本格的なデータ処理を行うために、PythonやRなど別の言語習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います

2024-03-01

数学必然性は実は人間言語分析能力によるものなので、言語能力が異なる宇宙人とは、数学的語彙が共有できない可能性があるんですよね~


なぜ数学言語能力関係するんだ?と思う人は、以下のノーム・チョムスキーの有名な、無意味な二種の文を見ればわかってもらえるかもしれませんね~

・“Colorless green ideas sleep furiously.”(「無色の緑の考えが猛烈に眠る。」)

・“Furiously sleep ideas green colorless”(「猛烈に」「眠る」「アイデア」「緑色」「無色」)

前者は文法的には正しいが意味が無い文で、後者文法的に正しくないか意味がない文、ということはわかっていただけるかと思います

しかし、上記二種の文は、両方とも経験的には何も想起させないがゆえに、経験的には同様に意味の無い文です。

ということは、経験こそが認識の基礎、基底である考える人にとっては、二種の文の違いを説明することができないのですよね~。

なぜならそのどちらも経験することができず、経験による理解が基底であると主張するのだから経験的基底において違いのない(意味のなさ、指示対象存在しないという点において同質という意味)上記二種の文の本質的差異(基底的差異)を指摘することができないのですね~


現代言語哲学、そして現代論理学の基礎を作ってきた哲学者たちは、数学必然性がどこから来るのかという問題について、

文の経験理解よりもに、文の文法的分析が先に行われる(そして数学必然性は、文法分析に基づく理解のものから正当化可能である)ことを示すことによって、

経験的(アプリオリ)論理数学必然性正当化可能であることを証明してきたんですね~

例えば上記二種の前者の文でいえば、経験できないにもかかわらず文法的に正しいことが理解できるのは、まず文法分析が先に行われ、その後意味解釈に失敗するから無意味なのであって、その逆ではないのですね~

そして数学で扱われる文、例えば2+2=4は、なんらかの経験を前提せずとも、形式的理解(つまり文法的理解)から正当化可能であるがゆえに必然的(=非偶然的、または前経験的)なのですね~

そして例えば上記二種の文とは別の有意味である文「無職緑色ジャージを着た男性が猛烈に眠る」であったとしても、まず文法的理解が先に行われたあと、その意味解釈を行うことができるがゆえに有意味なのですね~

プログラミング言語だって、まずどれが変数で、その変数に何が割り当てられているかといったセマンティクスよりも先に、シンタックス分析が行われますよね~


から数学必然性は実は人間の前経験的な言語分析能力によるものなので、言語能力が異なる地球外生命体と遭遇した時、数学的語彙が共有できない可能ももしかしたらあるのかもしれませんね~

なぜなら我々の理解する必然性とは、我々の言語分析能力に基づくものであって、よそから来た宇宙人にそれが期待される理由がないからですね~

2024-02-17

anond:20240217074909

ってかプログラミング言語統一されてない意味分からん

自然発生じゃなく人工的に作った言語が一つにまとめられないの何なの。

ハードウェアUSBは規格統一できたのに。

技術的に不可能じゃないよね。

Rustだけでいいやん。

anond:20240217003758

うーん、シェルスクリプトは確かに扱いやすいが、最初に覚える本格的なプログラミング言語として適格かというと???・・・ 型もないし。

anond:20240216234130

そうか、その考えはなかった。

自転車置き場の議論として最初に教えるプログラミング言語は何にすべき?

ってのがある。オレの大学ではPascalだった。Cよりはマシだろう。あるいはPythonとかもあり得るかもな。

だが、最初に触れるパソコンLinuxなら、POSIX shホーム言語にできるわけか。。。

そりゃ結構面白いな。

2024-02-03

[]2月2日

ご飯

朝:サンドイッチ。昼:サラダどら焼き。夜:ワインポテト生ハムチーズドリアピザ。間食:アイス

調子

むきゅーはややー。おしごとは大変。来週からは忙しくなりそう。

今まではC#というプログラミング言語お仕事してたんだけど、来週からPythonという別の言語も使ってお仕事をしないといけない。

勉強もしないといけないし大変だ。

がんばるぞー。

グランブルーファンタジー

コスモスHLわからん

勉強しないとだ。

2024-01-26

各位、久々の大型新人の予感がするので可愛がってください

https://twitter.com/shims_ag/status/1749925004236779961

午前7:40 · 2024年1月24日

「型」という概念存在しないプログラミング言語存在しません。

https://twitter.com/shims_ag/status/1750300836113342567

午前8:33 · 2024年1月25日

メモリ上のデータの種類を表す情報が「型」(type)です。

プログラミング言語側に組み込まれている「型」だけでなく、プログラマー独自に「型」を定義する方法も用意されています

struct、classinterface、type, enumなどを使って独自の「型」を定義します。

開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります

多数の「型」を分類し、組織化するために名前空間を利用します。

近年「クラス」が「型」の定義であるという基本概念理解していないエンジニアが増えているので、エンジニア採用する際には注意しましょう。

https://twitter.com/shims_ag/status/1750346589431042157

午前11:35 · 2024年1月25日

ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています

例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。

業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります

上記の「型」は、構造体やクラスを使って定義します。

これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます

現代ほとんどの言語にはis-a関係を明確にする方法が用意されています

上記のような「型」の知識プログラミングの基礎です。

https://twitter.com/shims_ag/status/1750014081648779450

午後1:34 · 2024年1月24日

CPU機械語しか理解できません。一方で人間機械語プログラミングすることは困難です。

人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。

CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまます

そこで、人間にとってプログラムを読みやすくすることと、CPU意図しない演算をさせないために、データの種類を表す「型」という概念プログラミング言語に用意されるようになりました。

金融ECサイトなどのお金計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。

まとめると、可読性向上と、プログラムの誤動作防止のために「型」が不可欠な概念になりました。


https://twitter.com/shims_ag/status/1750507533536760000

午後10:14 · 2024年1月25日

プログラミング初心者は、

プログラミングを以下のようにシンプルに考えましょう。

(1) データメモリ記憶する命令プログラミングする。

変数配列構造体、クラスなどを使って、メモリ上にデータ記憶させる命令設計し、コーディングする。

(2) データ操作する命令プログラミングする。

上記(1)でメモリ記憶したデータに対して、計算、変換、表示、出力、保存などの命令設計し、コーディングする。

https://twitter.com/shims_ag/status/1750534515616059749

午前0:02 · 2024年1月26日

「型」という概念数学に由来しています

メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります

分かりやすく言えば、データの種類、分類の話です。

例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。

オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。

クラス」とは「型」の定義であり、メモリ上のデータの「分類」(class)です。

is-a関係」ではないのに継承すると、当然破綻します。

逆に、明らかにis-a関係」なのに、継承せずに委譲すると、スパゲッティコード化を誘発します。

2024-01-16

最初プログラミング言語問題

子ども最初に教えるプログラミング言語は何がいいのか。

C++ なんて教えても罠にハマって時間を潰すだけだし

それなら適当クラスメイト恋愛でもしてた方が、人生初動の貴重な時間有効に使える。

ならば、 Ruby か。

2024-01-15

技術イベント行ったらネットに顔晒されるのヤバない?

ちょっと疑問があるので、意識調査じゃないけど、意見を聞きたい。

技術系のイベントの会場内の写真カジュアルTwitterかに載せてる人いるけど、あれってヤバくないの? 問題に思う人いないの?

漫画アニメ同人系のイベントとかだと、運営がわりと厳しく「会場内撮影禁止」ってアナウンスなり指導なりしている印象あったから、技術系のイベント撮影された人が映り込んでる写真を鍵垢でもないTwitterで流しているの見て、大丈夫なのかと心配になった。

私が見て覚えてるものだと、自作キーボードイベントとか、プログラミング言語系の勉強会なんだけど…

事前に「会場内の写真SNSなどに公開します。顔が映り込むことがあります」みたいに、イベント詳細に書いてあったりするんかね?

イベントに不慣れな一般参加者が撮ってアップしちゃうとかなら、まだ分からんでもないけど、まれ主催側や登壇する側が「こんなに集まりました、盛り上がりました」みたいに無邪気に上げてたりするのも見るし。

もしかして、そういう技術系のイベントって、同人系のイベントとは違って写真撮ったり撮られたりするの、みんな何とも思わない?

その場にいることがバレたくない人とか、そもそも写真に写るのが嫌って人とか、いそうな気がするんだけど、どうなんだろ。

まじめな勉強会やらカンファレンスとかならいいけど、懇親会でハメ外してるところ見られると、会社とかパートナーに怒られる!とか無いのかな?

↑なんかは想像やす可愛い例だけど、特定イベントに来ていることが記録に残ると困るって人も少なからずいると思うんだよな。

2023-12-26

プログラミング言語で一度書いたことを、もう一度自然言語で言ったからといって、正しさが増すなどということはありません

英語マウンティング

2023-12-24

なぜエンジニアは「浅い」記事しか書かないのか?

浅薄記事ばかり書くな

タイトルや以下における「エンジニア」とはソフトウェアエンジニア的なものを指すとする。

この時期に各種アドベントカレンダーで見かけるような、あるいは平時でもはてブの「テクノロジー」タブに上がってくるような記事は魂に訴えかけるものが皆無な浅い記事ばかりだ。マネジメントがどうのだとか、○○プログラミング言語で△△してみましただとか、無味乾燥なこと甚だしい。それはなぜかというと、そうした記述はいわば児戯を一生懸命やっているだけであって、社会世界のことをなんら考慮しておらずなんの影響も与えることができないものからだ。

そうした浅い記事が生まれ理由について考察してみた。

理由1: 採用転職ゼロサムゲームの1つのギミックから

求職側において、個人ブログ等で発信することでポートフォリオ代わりになり、転職活動に有利になるというインセンティブがある。求人から見ると、自社ドメイン技術ブログ等で発信することで採用市場におけるプレゼンスを高めたいという動機がある。この双方向の動きにおいては、情報を多く出したもん勝ちであるため、浅い記事が量産されるというわけだ。

求職者は人材会社陰謀に嵌められて義務的情報発信させられていることも多く、被害者だとも言える。しかし、求人側がこの動きに加担するのは非道徳的であるたか採用のために競合と人間認知許容量を巡るゼロサムゲームを繰り広げて貴重な人類知的エネルギーを浪費しているのは端的に反社売国奴である

理由2: ブルシットジョブから

IT業界は、火のない所に無理やり火をつけてからなるべく複雑な消火のソリューションをなるべく高値提供するというブルシットジョブの宝庫である。何社もの企業キラキラ業界ヅラして犇めいている分野においても、冷静に見るとその分野自体社会不要(それどころか有害であるということはよくある。自分が携わっている分野においては正常性バイアスでそう感じないかもしれないが、他分野を見たときには同じように感じる方は多いだろう。

そもそもがブルシットジョブなのだから、それについて何をどう語ったところで本質的伽藍堂なのである

理由3: 記号接地していないか

AI身体性を持たないため、記号記号としてしか処理できず、現実実体が持つ意味と結びつけられないという記号接地問題課題となっていた。特にサーバーレス環境において、エンジニアAIと同様な状況に陥っている。コードを書いてCDデプロイしてクラウドで動かすという開発のサイクルは現実物体との関わりがなく、自分の行いが現実においてどういう意味なすかという意識希薄になるからだ。そのような状況では空論を弄ぶことしかできなくなるのは当然の帰結だ。

記号接地問題解決する側にいるはずのエンジニア自身が同じ問題に囚われるとは、なんたる痛快事であろうか。

理由4: 馬鹿から

エンジニアというのは誰でもできる職業なのに高給取りだというイメージが付いており、思考停止しているくせに一発逆転を狙う馬鹿を呼び寄せている。

また、仕事それ自体によって、あるいは仕事で金を稼ぐことによって自己実現をしようと企むナイーブ価値観蔓延している。もともと馬鹿ならそのままぬくぬく馬鹿のまま育つし、大学一般教養を学び大学院でコンピュータサイエンスを学んだような本来は"頭の良い"人までそうした朱の馬鹿共に交わってより赤き馬鹿に成り下がってしま環境なのだ

まり、端的に馬鹿からそもそも浅い思考・浅い言論しかできないのだ。

2023-12-22

anond:20231222065623

純度100%お気持ちラッダイトじゃん。反AIってこんなんばっか。

時間が早いことが罪ならCopilotどころかプログラミング言語とか使わずに手で論理回路配線しろよ。

学習されない権利」「参考にされない権利」「解析されない権利」なんぞ著作権どころか歴史上どんな知財にも存在せんわ。

何でそんな異常すぎる特権が当然あるべきだと思い込めるんだ?

2023-12-19

anond:20231219191613

GoogleGoを作るよりももっとずっと前から採用している言語は主にC++, python, そしてjavaだが、javaパートが一番問題だ。

Android関連の開発で有用であるという点でjavaは使われるが、ロイヤリティを支払うことになっている。

このことについて昔から訴訟問題が起きてきたようで、javaがクソである言われる一つの要因となっている。

オラクルといった大企業管理するプログラミング言語はそういった理由で信用されていない。

2023-12-18

anond:20231218170959

いうてブラウザ自作するにはCSS仕様完璧に把握してこそdomとか解釈して表示する機能を実現できるわけで、それはプログラミング言語によるものなのだから、やっぱプログラミング言語マークアップ言語以上の難しさだろ

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