  |
はてなキーワード: 機械語とは
たとえばユークリッド幾何学での直線は「幅をもたず、両側に方向に無限にのびたまっすぐな線」だそうですが、これも「幅」とは？「(幅を)持つ」とは？両側とは？「方向」の定義は？「無限(限りが無く)」とは？そもそも「限り」って何？「のびる」とは？「まっすぐ」とは？「線」と結論づけるのは循環論法じゃないの？
と突っ込む人にとっては厳密ではなくなっていませんか？
ここで、これらの言葉の意味は、国語辞典に載っている意味と同じものだよなどといおうものなら、それこそ数学の厳密性を否定したようなものになってしまっていると思います。
たとえば「方向」を調べたら「向くこと」とでます。これを調べると「物がある方向を指す」というふうに出ます。これは循環論法に陥ってますし、「物の正面があるものに面する位置にある」という別の語釈もありますが、物とは？正面とは？面するとは？位置とは？となります。これを繰り返せば結局どこかで循環論法に行きつくでしょう。
そもそも数学の根幹部分を支える論理学の重要な概念である「否定(そうでないこと)」にしても、厳密に定義することは可能なのかと思います。
「～でない」というのは、そうであることがないということ、と言ってみたところで循環論法。
そうであるのになぜ上記のような定義や公理が厳密なものと認識されているかといえば、「さすがにここまで平易な単語の組み合わせで書けば、これらの単語については私が常識として理解してる意味と同じ常識を、相手も持ってるはずだから同じ理解をするよね？」みたいな態度に立っているんだと思います。
結局相手も同じ常識を持っているという不確かな信念によりかかっている、甘えている点で、数学の記述もまた完全に厳密で一意というわけではないのかなという気がしてくるのです。
そもそも「方向」なんていうような概念は、言語によって定義されたものを知っているというよりは、幼少期に言語を習得していく過程で、それが話されるシチュエーション、つまり五感などあらゆる感覚の総体とセットでそうした言葉が使われているという環境に身を置いているなかで理解しているにすぎません。理解内容が各個人で全く同じである保証はどこにもないと思います。
どんなに高度な数学の表現も究極的には自然言語に還元されるはずで(どんな高級言語も機械語に置き換えられて処理されるように)、自然言語の各単語に対する人々の理解は原理的には五感に根差した感覚的なものなのだから、数学の記述が厳密で一意というのは、結局はほかの記述の仕方に比べた程度問題(つまりは誇張表現)なのかなと思うのです。
感覚によらない「証明」をすることに価値を見出す人が数学をありがたがることがありますが、数学もまた根源的には感覚ありきの理解に基づいていると思うわけです。
この考えは間違っているでしょうか？そうであればどうして間違いなのか、どこがどう理解を誤っているのか知りたいので教えてください。
ちなみにたとえば「否定」というのは、根本的には、やはり言語で理解が完結しているものではなく、現実の状況としての存在非存在にそれぞれ直面して、それぞれに対して「○○がある」「○○がない(なくなってる)」と言われてる場面を経験したうえで、その状況から理解した内容のさらなるアナロジーとして理解してるに過ぎないと思います(理解のあり方が、言語的ではなく、観念的直観的)。
数学が他よりも他者と厳密に同一な合意が常に成り立つ、その工夫として、抽象度を高くしているのがその工夫にあたるのではないかという人がいました。↓
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14293524459
しかし抽象度を高くすることは、合意内容のずれを減らすという点で「有効でもあり逆効果でもある」のではないかと思いました。つまり諸刃の剣なわけです。
有効である理由はリンク先に書かれているのでそこに説明を譲るとして、逆効果であると思う私の説明を書きます。
つまり、抽象度が高い概念は、抽象度が低い概念や直接的な事物に比べて理解が難しい傾向があるのがまずあるわけです。
また定義者の提起する定義をそれを発信される側が期待通りに理解しているかを確認するのも、抽象度が高い概念ほど困難な傾向はあると思います。
これ自体ある意味で抽象そのものなのでたとえが悪いですが、たとえば「左を向いて」という発言に対して、「左」を向く反応をすることで、この人は左について正しく理解してそうだなという確認(いや原理的には推定というべき)することができます。
抽象度が高くなるほど具象と結びつけたこのような正しく理解してるかの評価、確認テストをすることが難しくなるでしょう。
といってもそもそもわれわれは相手が自分の言ったことを期待することと厳密に一致した内容で理解してるか確認することは原理的に不可能です。
頭をパカっと割って理解内容を覗きみるということはできないですから。
対象となる言葉に関連したその人の発言や反応をみて、理解の結果としての発言や反応として、その人がある部分で正しく(定義者の期待通りに)理解してるだろうということを推定するしかありません。
しかも全体ではなく一部だけの理解が正しくても、発言や反応には異常が見られないということもあるでしょう。
反応や発言をいくら調べても、概念全体を期待通りに理解してるかのテストには無限通りのパターンが必要と思われ、原理上不可能と思います。
哲学的ゾンビにも通じそうな話ですが、日常の範囲内で「理解に齟齬があるような反応が返ってこないなら」そんな「理解が完全同一でないかもしれない」という可能性上の話を心配する必要はないというのはその通りでしょう。
ただ場合によってはそれが表出したように見える一例が、あれの原因がこれだとは言いませんが、望月新一がＡＢＣ予想を証明したという論文での紛糾みたいなことが起こる一因にはなりえると思います。
あれだけ理論として抽象的な概念を積み重ねた先には、定義者とそれ以外のその定義を見た人とでの理解のずれは、反応や発言として顕在化してくるほどになっても不思議ではありません。(定義者の解釈が正しいという優劣の問題ではなく)
とはいいますが、そもそも「矛盾」とは何か？「論理」とは？「範囲」とは？とは、といくらでも曖昧でしょう。
たとえ矛盾を記号論理の表現で記述して定義した気になったところで、じゃあその記号の定義ないし意味は？とどこまで突っ込まれても感覚に頼らない定義が可能なんですかね？と思います。
数学に限らない話じゃんっていうのはまあその通り。
でも定義について「厳密で一意」であることを(得意げに？)標榜してるのは数学(＋論理学)とそれベースの客観的であろうとする学問ぐらいだから、別にエントリ名詐欺じゃないよね？
a＝b、aはbだ。「は」って何？「だ」って何？「英語的にはどっちもisという語に集約されてるけど、じゃあisってなんだよ」ってところから概念の共有をしてない前提に立った時、その概念を非感覚的で厳密に共有することは可能なのか、それが「完全に」できたと確かめるのにはどうすりゃいいって話よ。
言葉という形式が従で、それに乗るべき内容が主であることは百も承知だが、形式言い換えれば入れ
物抜きに内容を厳密に伝えられるのか、入れ物の存在に無関係な、内容の厳密な伝達というテレパシーじみたものを考えることはそれこそ論理的に正しいのかという話でもある。
非言語的なテレパシーは論理的に矛盾してるので存在しえないのではないかとは思っている。
イデア論かな哲学書読めばってブコメついたけど、順序が逆なんだよね。
イデア論とか学校で習って本読んだりして教養として知ってるからこそ、改めてその考え方を自分なりの具体的な考察対象にあてはめて思索したくなるわけよね。
先達の哲学者たちがいなかったら俺はいまだにブルアカで抜くだけの毎日だわ。むしろ哲学者リスペクト100パーセントなんだよね。
語彙力ないので語弊ありそうなのは百も承知だが、哲学って考え方の基幹部分のオリジナリティーはそんな求められてないんだよ。
むしろ先人から受け継いだ考え方をどう今の時代の具体的な問題に適用して考察を広げるかが大事なので、ちょっと哲学かじったような素人目には過去の論文の焼き増しに見えてその存在意義が理解できないような論文はごまんとあるんだよね。
ああいうブコメつける人って「方向性とかみたいな意味でベクトルという言葉を使ってる人は横文字使いたがりの格好つけ」と言ってる人みたいな人を性悪説的にとらえるクレーマー気質が高い人間に感じる。
ちなみに俺はベクトルという言葉を使う人は「周りがベクトルという言葉を使ってるから、リアルタイム性を要求される会話でとっさに出てくる言葉がベクトルだから、それをそのまま使ってる」ってだけだと思う。
プログラミング言語側に組み込まれている「型」だけでなく、プログラマーが独自に「型」を定義する方法も用意されています。
struct、class、interface、type, enumなどを使って独自の「型」を定義します。
開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります。
多数の「型」を分類し、組織化するために名前空間を利用します。
近年「クラス」が「型」の定義であるという基本概念を理解していないエンジニアが増えているので、エンジニアを採用する際には注意しましょう。
ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています。
例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。
業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります。
これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます。
CPUは機械語しか理解できません。一方で人間は機械語でプログラミングすることは困難です。
人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。
CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまいます。
そこで、人間にとってプログラムを読みやすくすることと、CPUに意図しない演算をさせないために、データの種類を表す「型」という概念がプログラミング言語に用意されるようになりました。
金融やECサイトなどのお金の計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。
メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります。
例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。
オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。
よく知らないんだけどプログラミング言語？ ってやつかな
プログラマなら同意してくれると思うけど、Rust や Go で書ける時代にアセンブリや機械語を書く人間はいない、相当な趣味人とか特殊な例外だけだ。
お気の毒です。
イラストレーターで食える人は居なくなるだろう。
…
人工知能はスピードと品質の両面で人間のクリエイティビティを凌駕しつつある。
プログラマなら同意してくれると思うけど、Rust や Go で書ける時代にアセンブリや機械語を書く人間はいない、相当な趣味人とか特殊な例外だけだ。
…
どうすればいい？ イラストを禁止するのは、俺がゲームを禁止された果てにゲームジャンキーになったのと同じように逆効果にしかならないだろうな…。
これは聞いたことがあります。確かに禁止するのはリバウンドを招くので良くはない。
毎回ゲームをプレイするたびに感想文を書かせるのが、ゲームをやめさせるのに効果的な方法らしいです。
おそらく、読書感想文さえ億劫な子どもにとって、いちいち文章を書く面倒くささは足枷になり、
慣れてくるとプレイ中に感想を考えながらゲームするようになるのでしょう。
そしてそれがパフィーマンスを損なうので、成長が止まり、飽きやすくなるのだと思います。
小説やアニメなどを友人にオススメされると逆に読みたくなくなってしまう現象があります。
私見ですが、それも同種類の心理効果があるのだと思っています。
「将来はイラストレーターになりたい」
らしい。
うわあああああああ………。
プログラマの俺としては、なんとか芽吹いた夢が若い内に摘まなきゃならない。
イラストレーターで食える人は居なくなるだろう。
本当の意味でのトッププロと、声や生活などを釣り餌にするアイドル絵師だけが生き残る。
あとは今のアニメの奴隷労働のようなレッドオーシャンの過酷さしか残らない。
人工知能はスピードと品質の両面で人間のクリエイティビティを凌駕しつつある。
プログラマなら同意してくれると思うけど、Rust や Go で書ける時代にアセンブリや機械語を書く人間はいない、相当な趣味人とか特殊な例外だけだ。
こんな事態になるとは思わなかった、こんな辛い役割を担いたくはなかった。
どうすればいい？ イラストを禁止するのは、俺がゲームを禁止された果てにゲームジャンキーになったのと同じように逆効果にしかならないだろうな…。
初心者がプログラミングを身に着けるのに、LinuxとCLIは必須とか言い出すのが意味不明。
しかもUbuntuのインストールとかじゃなくWSL2入れて覚えろとか、駆け出しの開発者にそんな難しいことできるわけねーだろっていう。
そりゃ「Web系の」プログラミングだったら、そこら辺のノウハウが必要なのはそうだろう。
でもプログラミングはWeb系だけじゃないし、Web系がほとんどなわけでもないからな！
組み込みやモバイルだったらLinuxをCLIで触る機会なんてまず皆無なので、最初から学ぶのは時間の無駄だし、もっと優先して覚えるべきことはいくらでもある。
それこそWeb系だろうなんだろうが、プログラマなら機械語やラインエディタくらい覚えろ当然だろ？ってレベルで意味のない勉強だったりするわけで。
こういうこと書くと
とか言い出すバカがいるんだが、POSIX原理主義のほうが世界が狭いことにいい加減気づけっての。
過去に遡れば、薄っぺらい機械でしかなかったPCにすら日本語処理で大きく劣っていたくせに「UNIXは美しい」とかほざくアホがいた頃から、何も変わってないのな。
しかも今でこそ猫も杓子もLinux推しなのに、Linuxが出た頃は「ワナビーのクソガキが使うおもちゃ」として嘲笑しつつ*BSDが最高とか言ってたのは誰だったっけ？
差別主義者どもが恥を知れ。
そもそも高い賃金が欲しくてプログラマーになったようなやつは勘違いしているようだけど
なぜなら経済として会社を支えているのはどんなときでも営業だからだ
現に9割9分の会社は技術などないが営業が優秀なので存続している
（ちなみにここでいう営業というのはプロモーションや戦略系も含まれる）
例えば流行の機械学習を生業としているようなベンチャー企業であっても
最新のトレーニング手法やパラメータ定義なんかを使っても得られる利益はほとんど無いのだ
Web系でもAngularだろうがReactだろうがVueだろうがどうでもよくて
とにかくデザイナーの出したものを忠実、もしくはそれ以上のものを生み出せれば技術などどうでも良いのである
という人もいるが、残念ながら全ての技術は5年後に負債になっている可能性が等しくあるということを理解していただきたい
そんな中で日本での人材流動性の高まりであるとかプログラマー育成問題なんかもあって
技術系（プログラマー）の市場価値が高まり、たまたま今だけ高給になっているわけである
卵が少なくなって卵の値段が上がったとしても
その卵が美味しいかと言われるとそんなわけはないのだ
どちらかと言うと腐った卵まで流通するのが恐ろしいところである
私が見てきたベンチャーの腐った卵には下記のようなジャンルがある
メガベンチャーや伸び盛りのベンチャー系に多く、特に旧帝大出身（特に東大）に多いのがこのパワハラ系
とにかく（自分の）理論が正しいということを前提に自覚無くパワハラを繰り返す
これが雇われ社員ならそれほど問題でもないのだが、経営者側のCTOなどだった場合は目も当てられない
テックだろうがベンチャーだろうが雇用主と雇用者という関係性は変わらないのに平気でゴリゴリパワハラを行う
雇用主側に主張されると組合も無い弱い立場の雇用者は何も言えない
その状況を理解していないのか雇用主側のパワハラはエスカレートしていく傾向にあり
社員は退職するが新しい人材は集まらずたいていの場合は逆に雇用主側が病む
この手のテックマウントパワハラ系の特徴は、ドメイン駆動や過度の抽象化、もしくは無駄な高速化や機械語への執念などが挙げられる
例示するのは難しいが、PRを上げてきた新人社員をSlack上で公開にボコボコに論破した上に
「社会人としてできて当たり前」
みたいなことまで説教を始める人を何人か知ってる
小さめで大きくなってきているベンチャーに多いのが、この結局全部自分でやる系
締め切りの前日もしくは当日、もしくは過ぎた後に自分で全部やり直す人
それまで部下や関係者が相談しつつ進めていても結局は全部ぶち壊して全部自分でやる
などというのは完全な素人で、単に他者に業務依頼できない人である
「言ってくれればもっと早く出来たのに」
ということしかない
そんな調子で依頼することができないので結局は自分で実装を繰り返し更に時間がなくなる
「俺ほどの技術力を持った人がいなくて困る」
みたいな自己肯定感を醸成しているのでそのうち上のパワハラ系へと移行していく
特徴としてはSlackにしろPRにしろ話が抽象的すぎて文章力が無い人である
「1を聞いたら10を知るのが当たり前だろ！」
と言う人が多く（1と10から100は分かるけど1だけで10を知ったら変態ですよ）
ヒドイ人になるとIssueやPRの管理も全然できず、ブランチも規則無く乱立してしまっていて
新しく入った人もいったい何をどうすればいいのかさっぱり分からない状況で放置してしまう
これも例示すると、新サービスの仕様だけは決まっていてページレイアウトが無い状態で
デザイナーの配属が難しいので実装側が考える、ということになったとき（割とある）
と言っても音信不通で渋々とこれまでのレイアウトを踏襲して3人できっちり作ったところ
リリース前日になってCTOが徹夜で全部作り直す、ということがあった
レイアウトも全然変わっていて、実はニュースリリースの段階から新規テーマになることが決まっていたらしく
それに合わせて全部作り替えたそうだ
新規テーマは1ヶ月も前から決まっていたのだから共有さえしてくれればそれに合わせて作ったのになぁ、という話をした
余談だがこういうときにこの手の人が「デザイン共有できず申し訳なかった」というような一言はほとんど無い
そういうコミュニケーションが取れる人は最初から業務依頼ができるのだ
最後が最近一番多いのだが、単に技術力が無くて頑張ってるだけの技術者
JavaScriptでリストの中に'apple'があるかどうかを調べる時に array.includes('apple')と書くとして、
10個のフルーツのリストがあってそれらが含まれているかを調べる時に10個のincludesを書いてしまうような人である
「せめてfor文で書こう」「そもそもデータ構造がおかしい」「というか本当にやりたい処理は？」
などなど様々な疑問が出てくるが、不思議なことにこれらを指摘しても絶対に直ることは無く、全く同じことを何度もやる
他にも例えば男性か女性かでメッセージを変えて出力しているコードがあったとする
if( gender === 'male') { ... } else { ... }
これに、20歳以下の場合は男女共通で違うメッセージを出す場合に
if( gender === 'male') { if ( age ＜= 20 ) { ... } else { ... } } else { if ( age ＜= 20 ) { ... } else { ... } }
みたいなコードを書いてしまう（20歳以下の部分は同じコードのコピペ）
メッセージ表示させるだけなら大したことないが、実際にはもっと複雑な処理をコピペで貼り付けるのである
そのため
「20歳以下の表示部分のバグについて、男性の場合は直ってるけど女性の場合に直ってない」
if ( gender === 'female' && age ＜=20 ) { ... }
これでもだいぶオブラートに包んでいて、実際にはもっと複雑なロジックをぐちゃぐちゃのまま整理せずに追加するのでとてもじゃないがメンテできない
（最近だとそういう部分はまとめてChatGPTに放り込むと綺麗にしてくれるので非常に助かっている）
こういう低レベルな技術者は結構いるのだが、大企業だと時間をかけて成長していくのに対して
ベンチャーになると自己肯定感が高いのか成長せずに偉そうである
「動いてるものは触らないで欲しい」
「Javaだとこういう書き方するんだよね」（そんなことはない）
みたいなことを言って、とにかく学習しない
曲がりなりにもそういう職に一度就いてしまうと指摘されることもないので学習しないんだと思う
特にCTOだとあくまで雇用主側の立場なので雇用者側から指摘されることも少ないし
同業他社のレビューなんてのもないからそこで時間が止まってしまうんだろうな、という感じ
こういう技術者のコードでも、見た目は動いているので営業側から見ると売るには問題ないのだ
なので営業が優秀だと下手に売れてしまって成功体験からますます自己肯定感が増して手が付けられないモンスターCTOの誕生である
「成功してから伸び悩んで大手企業が買収したけど技術的負債が凄まじ過ぎてリファクタリングだけで一大プロジェクトになる」
「リファクタリングが上手く行かずに仕様変更することになって『大手企業に買収されてダメになった』というレッテルが貼られる」
「当時のCTOは別の会社で新しい事業のCTOとして活躍している」
という流れはこうして生まれている
プログラミング言語に翻訳できるプロンプト言語？ができたらそうなるだろうけど
今のAIはプロンプトに一意な回答を出さないしそれが本当に合ってるか分からないから結局プログラミング言語の知識要るでしょ
A:はい、私はアセンブリ言語のコードを記述することができます。アセンブリ言語は、コンピュータのプロセッサが理解できる低水準の機械語命令に直接対応するプログラム言語であり、CPUの命令セットアーキテクチャに依存するため、異なるCPUアーキテクチャに対して異なるコードが必要です。
以下は、x86アーキテクチャ向けの単純なアセンブリ言語の例です。これは、メモリの特定の場所にある2つの数値を加算して、結果をレジスタに格納するプログラムです。
Copy code
section .data
num1 dd 10 ; Define num1 as a double word (32-bit integer) and set its initial value to 10
num2 dd 20 ; Define num2 as a double word and set its initial value to 20
section .text
global _start ; Declare the entry point for the program
_start:
mov eax, [num1] ; Move the value of num1 into the eax register
add eax, [num2] ; Add the value of num2 to the eax register
mov [result], eax ; Move the value in eax to the memory location "result"
section .data
result dd 0 ; Define result as a double word and set its initial value to 0
このプログラムは、num1の値をeaxレジスタに移動し、num2の値をeaxレジスタに加算し、最後にeaxレジスタの値をresultメモリアドレスに保存します。
↑を書いた元増田ですが、VBの話から派生した話で、やたらコマンドライン(以下CLI)を使った開発に否定的な人間がいて閉口した件。
そりゃ一口に開発と言っても色々なので、本当に統合開発環境(以下IDE)だけで開発するケースもあるのは、こっちも知ってるんだよ。
だから学習者の中で「何をやりたいか」が既に決まっているなら、CLIを全く触らずプログラミングを学ぶケースもアリということなのだろう。
1つ目は、そもそも「プログラムって何？」というレベルの人が「何をやりたいか」なんて決まっているわけがないので、最初から「何をやるか」を決めてかかるのはナンセンスという話。
むしろどういう開発に進んでもいいように、「等号は代入を意味する」辺りから始まって、どんなプログラミングでも基礎の基礎になる、データ構造とアルゴリズムを意識させることに集中させたい。
そのためには難易度低めで比較的潰しが効く言語を、できるだけシンプルな手順で作業できる開発環境で学べる方がいい。
そしたらPythonの実行環境とそこそこ以上の機能を持つテキストエディタを入れて、コマンドプロンプトとかPowerShellとかのCLIから"Helllo, world"が取っ掛かりだと思うわけ。
もしLinuxの環境が用意できるなら同じことをLinuxでも試してもらって、プラットフォームに依存しない開発の入り口くらいを知っておければベター。
いずれにせよ何かを実行する方法が1つではないという重要な知見は、できれば基礎のうちに知ってもらいたいことの1つだし、それはWindowsとLinuxとかCLIとIDEという対比がうってつけかなーと。
ちなみにIDEは、Pythonによる手続き型プログラミングに慣れた後のタイミングで学べばいいと思う。
そこまで行ったら変数の型や、クラスとオブジェクトとかの難しい話をGo言語で学んでおくことで、現場で使われているJava、C#、swiftへの移行もスムーズになりそうだし。
ちなみに「初心者コース」の最後、もし可能ならRustでポインタとメモリの話の触りくらいを体験してもらえると、組み込みに進む際のハードルが少しは下がるんじゃないかな。
もう1つは、いくら現場によってはIDEだけで開発する現実があっても、CLIを使った開発がどういうものかくらい、プログラマにとっては知ってて当たり前じゃねーの？という話。
もちろん「プログラマが何を知ってて当たり前なのか」は、時代の移り変わりとともにどんどん変わる。
大昔ならおそらく機械語とかが必須だっただろうけど、今なら機械語よりはHTMLを読めるほうが遥かに重要なわけで。
あと、UNIX系OSをパーティションごとに主要なディレクトリを分割してインストールしていた時代であれば、edエディタの使い方は必須だったと聞く。
(/binに入るエディタがedのみだったため、もし使えないとシステムクラッシュして/以外マウントできなくなったときに詰む)
でも今やそんなの完全に過去の話どころか、viとemacsの論争ですら多分古い方の問題になるだろう。
そういう過去の諸々も踏まえるとCLIが未来永劫、プログラマにとって常識的なナレッジだとは自分も思っていない。
でも今はまだ、プログラマを名乗るならCLIからコンパイルだ実行だくらいの基礎は知ってて当然だと思うんだが。
例えばJavaScriptでリストをコピーするとき
const newList = list.slice();
しかし、
「なんで const newList = listじゃダメなんですか？」
と聞かれると非常に困る。
例えばconst a = 123と入っているときに、bにコピーしたかったらconst b=aで良い。
プリミティブと配列の違いとして覚えてもらう、という方法もあるけれど
じゃぁ文字列はどうなんですか？となると非常に困る。
JavaScriptだけを教えるならそれでも問題ないかもしれないが、Pythonも一緒に教えるとかなるとカオスになる。
結局のところ、コンピュータの仕組みを理解してもらって、メモリのアドレスとかポインタを知ってもらい
それからプリミティブや配列の話をしないと根本的には説明できない。
単純なプログラミング教育ってこの辺が破綻してると思っているので、結局はPCの構造と機械語・アセンブリ言語・C言語と順番に教える必要があると思っている。
スキルというか"プログラミング"についての理解が足りてないだけだと。
適材適所。スキルレベルも含めて、そのとき一番"自分に"いい(楽とかスキルアップ)と思うものを選べばいいのでは？
なければ自分でやる。そもそも連携可能でなければ出てこないし、労力に見合わなければやらない。
Pythonからエクセルを動かすのは、試してみたが、VBAマクロの方が楽に感じる。操作を記録する機能はあるし、そこから不要部分削ったりすればよく、Pythonでエクセル動かそうとすると読みにくいし何やってるか結局わからない。
汎用型か、特化型か。Pythonで楽になるならVBAマクロはいらない。汎用性無双ならアセンブラか機械語でプログラミング言語は止まってる。
プログラマーの人はエクセルなどを嫌うけれど、matplotlibを細かい調整しようとすると調べて描画し直してを繰り返さないとならず、GUIでポチポチ調整する方が楽に感じてしまう。
エクセル含め便利なツールはがっつり使う。楽だから。エクセルで辛くなったら、GUI=>VBAマクロ=>自作ツール。GUIで楽なら無駄に自作ツールなんか作らない。楽になりたい時だけ
個人でGUIを作るとして、ボタンやプルダウンは簡単だけど、マウスを使ってインタラクティブになるとググってもすぐ出てこない。
Python使いじゃないのでなんともだけど、PythonオンリーならDjangoとか？
PythonはGUIが得意な印象がないので、自分ならJS(TS)+Pythonで。Python部分は必要最小限にして、Node.jsで呼び出しか、ReactでAPIコール。
