アカウント名:
パスワード:
Python使えるのは掃いて捨てるほど居るとな。Python使えるのはいいんだが、そのライブラリを作れるのはそのうち何人だろう。潰しが効くのはCとアセンブラ、この2つができれば食いっぱぐれることはないと勝手に思っている
COBOLですら仕事があるというか帳票作った人を墓地から再生したいぐらいなのに、むしろ食いっぱぐれる言語って何さ!
Rubyは衰退具合が激しい。時間の問題じゃないかな。
java
今凄い需要あるじゃないですか
脆弱性量産言語w
一度でも特定分野の天下を取った言語はどんなにマイナーになっても仕事には困らんが、2番手は食いっぱぐれる。
たとえばクソース満載で悪名を轟かせてしまってるVBA+Excelはオフィス分野で天下を取ったので(おそらく)永遠に仕事には困らない。一方でAccessで頑張った奴がSQL覚えられなかったら、いずれ仕事を失う。
そうか、JAVAは滅びることはないんだな…
JavaはともかくJAVAは滅べ
JAVASCRIPTとかJAVA SCRIPTも滅べ
これ、日本ローカルな話で、しかも学生だからなぁ。
ヨーロッパでは一般層にはJavaが圧倒的に強くて、その理由も公共教育で採用されてるからなんだけど、実際に世の中に出回るソフトはJavaScriptやC++が多くて、そりゃ、業務に合わせていけばそうなるよな、って話だと思う。
大学でFORTRAN教わった人は多いと思うけど、それが覇権取ってないんだから……
Stack Overflowの全世界サーベイでもPythonはJavascriptとHTML/CSSに次いで3位。エンジニアの学生の言語ということを考えると、Python首位というのは別に日本ローカルだと片付けられるような話でもないのでは。
https://kotamorishita.com/stack-overflow-developer-survey-2021/ [kotamorishita.com]
ヨーロッパローカルの話なんでしょう。興味ないけど。
こいつひろゆき好きそう
潰しが効くのはCとアセンブラ、この2つができれば食いっぱぐれることはないと勝手に思っている
組み込み系か、ドライバ書きか、その他の用途かで全然、勝手が違う。その違いを理解せずに「Cとアセンブラ」とか漠然と言ってる奴はいらん。
アセンブラって命令セットの数だけあるのでは。下手するとプロセッサの数だけ?
プロセッサが同じでも複数の処理系があるのでは。昔々、8080用とかZ80用アセンブラって10以上は見かけたと思う。あと、ICEベンダは結構独自のを持ってたようだし(デバッグ機能と連携するため?)。
アセンブリ語が分かるというのは、特定のプロセッサの特定のアセンブラでコードが書けるってな低レベルな話では無いだろうな。プロセッサの内部構造を理解しているとか、複数のプロセッサでの相違点や類似点が分かるとか。そのレベルに到達していれば、別のプロセッサ、別のアセンブラでも開発は行える。最初はちょっと戸惑う事はあったとしても。
Cなんかのプログラミングも、確かに組み込み系とかの畑はあるんだけど、他の畑の知識が全く通用しないほどの差異は無いね。もし他の畑で通用しないとすれば、それはやっぱりレベルが低すぎるんだと思う。
逆に特定の畑だけやってる人は、引き出しが少なすぎて、その畑の仕事ですら変な事をやっているのに気が付かない場合がある。あるデバイスの機能不全の調査をしたら、その原因がワッチドッグタイマのリセット実装だった事がある。開発者のベテランの人にその実装方法を採用した理由を聞いたら、組み込みの世界ではそれが普通との事。ネットで検索すると、その問題を起こした実装方法がまだ紹介されている。そんな事もあるんだよね。
アセンブラを書ける人を採用する側って「組み込み系」と「ドライバ書き」を区別するほど余裕あるの?
そんな人材少ないと思うんだけど
Cが使えるのもはいてすてるほどいるよ。でも自称使えるだけでまともにプログラミングできるのはほぼいない。phthonも同じくまともにプログラミングできるのはいないんだけど、プログラミングの技量低くてもpythonでAIデータ処理できるってだけで今はひっぱりだこだし年収も多くとれる
> でも自称使えるだけでまともにプログラミングできるのはほぼいない。
C99やC++14以前でそういう人多そうな雰囲気。俺のことだけど。 # 前世紀のC, C++の知識じゃ役に立たんよね。
C/C++で重要なのは言語以外の知識だな。PythonなどはOSの知識なくても言語だけ知ってればプログラミングできるけど、C/C++はできない。OSや場合によってはハードの知識が必要になる。
えー、CやC++の規格票読んでます?言語以外に必要な環境の知識はPythonも大差ないでしょ。
> 潰しが効くのはCとアセンブラ、この2つができれば食いっぱぐれることはないと勝手に思っている
食いっぱぐれはしないけど、AIとかデータ分析の仕事は回ってこないよ
Cは今はまだ生きてるけど、古い物の保守だけ残って、新しいものはRustやGoに食われてなくなって行くんじゃないかな?Cを選んでも危険なだけで、これらの新しく安全な言語に対してメリットがない。
ベアメタルの組み込みだといまだにC89のコンパイラしか使えない場合がある。特殊用途向けのCPUだと代替コンパイラもない。
その新しいものがCの古い物より長生きする保証なんてないからな。Rustで実装された実用的なカーネルが現実的になってから考えるわ。
がなくなると?
もちろん、永遠に稼働しつづけるわけはありませんが。
無くなりはしないが、新しい機能はRustにしようという動きはありますね。
8086アセンブラなら使える(た?)けど、今時役に立つ気が全くしない。ただ、他言語やるときメモリとかポインタとかで苦労することないというのはあるのかな?
どんなCPUでもいいので、1種類だけでもアセンブラやってれば他のも読めるでしょ。コンパイラが吐くコードを読めるのは強いし、それを意識して書けないと最適化はできない。もっと高度な最適化したいなら、HDLも触ったことあると強いですね。
まともなコンパイラで最適化オプションを適切に振ってやれば、自前でアセンブラ書くほどではないですが、最適化した結果うまく動かなくなったとか、リリースビルドした実行イメージが落ちたなどのデバッグでは、アセンブラやCとのミックスで読めないと確かに仕事にならないですね。
あと画像処理の最適化などで、ARM-NEONとかのような高速化命令を使う場合はアセンブラで書きます。より有効に働くように処理粒度や処理手順を組み替えたり必要があるので。
ただその手の分野だと、CPU固有の高速化命令だけじゃなくGPGPU活用やFPGA化まで選択肢はあるし、その場合はハード間のデータバスやキャッシュヒットなども考慮した検討になるんで、アセンブラ読めるだけの知識だけではあまり意味がないですが。
アセンブラが時に必要になるデバイスドライバやOSのブートコードなども同様に、ハード周りの知識が前提となるので、一般的なアセンブラが読める・書けるだけでは使い道がなさそう...
HDLなんてソフトの最適化と全然関係ないです。
俺もそう思った、ソフトの最適化とHDLの経験は全く無関係だなしかし、HDLというかFPGAをやるとマイコンのペリフェラルモジュールの気持ちが分かるようにはなる
一昔前の「NASA」(NASA通信社でなく米航空宇宙局)なら、8086アセンブラ・マシン語の仕事があったらしい。パチンコ機・パチスロ機なら今でも?
パチンコなどの遊戯機はZ80だったような。(不正コードが混じってないかを読む検査官がZ80しか読めないおじいちゃん説)
内蔵ROMプロテクトでお上的なセキュリティが強いと言われるZ80コア使用のCPUですROMは8KB、RAMは512Bこれで\3000もするのを買わされる
asmコードのリロケータブルリンクは禁止ORGのアドレス指定で書かねばならん
むしろCとアセンブラ以外のポインターで苦労する言語 is 何それしか知らないから認知が偏っているのでは
多くの言語でポインタ使ってない?Cみたいにポインタで演算できちゃうのは少ないとは思うけど#俺もやらないようにしてる
他にはRubyしか使えないのでRubyで例書くけどfoo = ["hoge", "fuga"]bar = foofoo ["hoge", "fuga", "piyo"]このあたりの挙動ってポインタの知識そのものかと
後から見直したらrubyの部分化けてるなぁ<<がの行が消えてるっぽい。<ecode>使わないとだめなのね
foo = ["hoge", "fuga"]bar = foofoo << "piyo"p "bar" # => ["hoge", "fuga", "piyo"]
って書いたつもり
イマドキの言語では「ポインタ」ではなく「参照型」を使うし、そっちの概念で考えるのでは。C言語のポインタ (や配列に関してのsyntax sugarなど)はデータアクセスの抽象化が未熟な頃の仕様では。実行時にメモリイメージを想起しやすいというメリットはあるけど、そんなメリットを求めるのって組み込み屋さんとかくらいだし。
あなたが書いてるのも別に「ポインタの知識」じゃないよね。どちらかというとメモリアドレスやその演算を意識した例じゃないとポインタっぽくないのでは。
メモリアドレスやその演算を意識した実装なんて、脆弱性の臭いがプンプンする悪しき風習ですね。
8086のセグメントアドレス方式を意識したポインタ操作ができる高級言語はあっただろうか
それもポインタだけどポインタ知らなくても誰でも使える程度のものだから・・・
CASLの達人は?
CASLはさっぱりわからんかったCASLが一番簡単だって聞いてたんだけども結局COBOLで取ったわ
ExcelでVLOOKUP使って1時間とかかかる作業をしている所は意外と多いらしいしAccessでも何でもいいので適当なDBにデータ突っ込んで複数のテーブルをJOINしてSELECTする程度のSQLが書くことが出来れば非IT企業なら多分食いぱぐれることは無いんじゃないかな
VB6.0やVBScriptが出来ればなんだかんだ言いつつ10年くらいは食べていけそう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
逆に言えば (スコア:0)
Python使えるのは掃いて捨てるほど居るとな。
Python使えるのはいいんだが、そのライブラリを作れるのはそのうち何人だろう。
潰しが効くのはCとアセンブラ、この2つができれば食いっぱぐれることはないと勝手に思っている
Re:逆に言えば (スコア:1)
COBOLですら仕事があるというか帳票作った人を墓地から再生したいぐらいなのに、むしろ食いっぱぐれる言語って何さ!
Re: (スコア:0)
Rubyは衰退具合が激しい。
時間の問題じゃないかな。
Re: (スコア:0)
java
Re: (スコア:0)
今凄い需要あるじゃないですか
Re: (スコア:0)
脆弱性量産言語w
Re: (スコア:0)
一度でも特定分野の天下を取った言語はどんなにマイナーになっても仕事には困らんが、2番手は食いっぱぐれる。
たとえばクソース満載で悪名を轟かせてしまってるVBA+Excelはオフィス分野で天下を取ったので(おそらく)永遠に仕事には困らない。
一方でAccessで頑張った奴がSQL覚えられなかったら、いずれ仕事を失う。
Re: (スコア:0)
実際にそこから標準のSQLも調べて後に繋いだし
Re: (スコア:0)
そうか、JAVAは滅びることはないんだな…
Re: (スコア:0)
JavaはともかくJAVAは滅べ
Re: (スコア:0)
JAVASCRIPTとかJAVA SCRIPTも滅べ
Re:逆に言えば (スコア:1)
これ、日本ローカルな話で、しかも学生だからなぁ。
ヨーロッパでは一般層にはJavaが圧倒的に強くて、その理由も公共教育で採用されてるからなんだけど、実際に世の中に出回るソフトはJavaScriptやC++が多くて、そりゃ、業務に合わせていけばそうなるよな、って話だと思う。
大学でFORTRAN教わった人は多いと思うけど、それが覇権取ってないんだから……
Re: (スコア:0)
Stack Overflowの全世界サーベイでもPythonはJavascriptとHTML/CSSに次いで3位。エンジニアの学生の言語ということを考えると、Python首位というのは別に日本ローカルだと片付けられるような話でもないのでは。
https://kotamorishita.com/stack-overflow-developer-survey-2021/ [kotamorishita.com]
Re: (スコア:0)
ヨーロッパローカルの話なんでしょう。興味ないけど。
Re: (スコア:0)
こいつひろゆき好きそう
Re: (スコア:0)
潰しが効くのはCとアセンブラ、この2つができれば食いっぱぐれることはないと勝手に思っている
組み込み系か、ドライバ書きか、その他の用途かで全然、勝手が違う。
その違いを理解せずに「Cとアセンブラ」とか漠然と言ってる奴はいらん。
Re: (スコア:0)
アセンブラって命令セットの数だけあるのでは。下手するとプロセッサの数だけ?
Re: (スコア:0)
プロセッサが同じでも複数の処理系があるのでは。
昔々、8080用とかZ80用アセンブラって10以上は見かけたと思う。
あと、ICEベンダは結構独自のを持ってたようだし(デバッグ機能と連携するため?)。
Re: (スコア:0)
アセンブリ語が分かるというのは、特定のプロセッサの特定のアセンブラでコードが書けるってな低レベルな話では無いだろうな。プロセッサの内部構造を理解しているとか、複数のプロセッサでの相違点や類似点が分かるとか。そのレベルに到達していれば、別のプロセッサ、別のアセンブラでも開発は行える。最初はちょっと戸惑う事はあったとしても。
Cなんかのプログラミングも、確かに組み込み系とかの畑はあるんだけど、他の畑の知識が全く通用しないほどの差異は無いね。もし他の畑で通用しないとすれば、それはやっぱりレベルが低すぎるんだと思う。
逆に特定の畑だけやってる人は、引き出しが少なすぎて、その畑の仕事ですら変な事をやっているのに気が付かない場合がある。あるデバイスの機能不全の調査をしたら、その原因がワッチドッグタイマのリセット実装だった事がある。開発者のベテランの人にその実装方法を採用した理由を聞いたら、組み込みの世界ではそれが普通との事。ネットで検索すると、その問題を起こした実装方法がまだ紹介されている。そんな事もあるんだよね。
Re: (スコア:0)
アセンブラを書ける人を採用する側って
「組み込み系」と「ドライバ書き」を区別するほど余裕あるの?
そんな人材少ないと思うんだけど
Re: (スコア:0)
Cが使えるのもはいてすてるほどいるよ。
でも自称使えるだけでまともにプログラミングできるのはほぼいない。
phthonも同じくまともにプログラミングできるのはいないんだけど、プログラミングの技量低くてもpythonでAIデータ処理できるってだけで今はひっぱりだこだし年収も多くとれる
Re: (スコア:0)
> でも自称使えるだけでまともにプログラミングできるのはほぼいない。
C99やC++14以前でそういう人多そうな雰囲気。
俺のことだけど。
# 前世紀のC, C++の知識じゃ役に立たんよね。
Re: (スコア:0)
C/C++で重要なのは言語以外の知識だな。PythonなどはOSの知識なくても言語だけ知ってればプログラミングできるけど、C/C++はできない。OSや場合によってはハードの知識が必要になる。
Re: (スコア:0)
えー、CやC++の規格票読んでます?
言語以外に必要な環境の知識はPythonも大差ないでしょ。
Re: (スコア:0)
> 潰しが効くのはCとアセンブラ、この2つができれば食いっぱぐれることはないと勝手に思っている
食いっぱぐれはしないけど、AIとかデータ分析の仕事は回ってこないよ
Re: (スコア:0)
Cは今はまだ生きてるけど、古い物の保守だけ残って、新しいものはRustやGoに食われてなくなって行くんじゃないかな?
Cを選んでも危険なだけで、これらの新しく安全な言語に対してメリットがない。
Re: (スコア:0)
ベアメタルの組み込みだといまだにC89のコンパイラしか使えない場合がある。
特殊用途向けのCPUだと代替コンパイラもない。
Re: (スコア:0)
その新しいものがCの古い物より長生きする保証なんてないからな。
Rustで実装された実用的なカーネルが現実的になってから考えるわ。
Linuxカーネル (スコア:0)
がなくなると?
もちろん、永遠に稼働しつづけるわけはありませんが。
Re: (スコア:0)
無くなりはしないが、新しい機能はRustにしようという動きはありますね。
Re: (スコア:0)
8086アセンブラなら使える(た?)けど、今時役に立つ気が全くしない。
ただ、他言語やるときメモリとかポインタとかで苦労することないというのはあるのかな?
Re:逆に言えば (スコア:1)
どんなCPUでもいいので、1種類だけでもアセンブラやってれば他のも読めるでしょ。
コンパイラが吐くコードを読めるのは強いし、それを意識して書けないと最適化はできない。
もっと高度な最適化したいなら、HDLも触ったことあると強いですね。
Re:逆に言えば (スコア:2)
まともなコンパイラで最適化オプションを適切に振ってやれば、自前でアセンブラ書くほどではないですが、
最適化した結果うまく動かなくなったとか、リリースビルドした実行イメージが落ちたなどのデバッグでは、
アセンブラやCとのミックスで読めないと確かに仕事にならないですね。
あと画像処理の最適化などで、ARM-NEONとかのような高速化命令を使う場合はアセンブラで書きます。
より有効に働くように処理粒度や処理手順を組み替えたり必要があるので。
ただその手の分野だと、CPU固有の高速化命令だけじゃなくGPGPU活用やFPGA化まで選択肢はあるし、
その場合はハード間のデータバスやキャッシュヒットなども考慮した検討になるんで、
アセンブラ読めるだけの知識だけではあまり意味がないですが。
アセンブラが時に必要になるデバイスドライバやOSのブートコードなども同様に、
ハード周りの知識が前提となるので、一般的なアセンブラが読める・書けるだけでは使い道がなさそう...
Re: (スコア:0)
HDLなんてソフトの最適化と全然関係ないです。
Re: (スコア:0)
俺もそう思った、ソフトの最適化とHDLの経験は全く無関係だな
しかし、HDLというかFPGAをやるとマイコンのペリフェラルモジュールの気持ちが分かるようにはなる
Re:逆に言えば (スコア:1)
一昔前の「NASA」(NASA通信社でなく米航空宇宙局)なら、8086アセンブラ・マシン語の仕事があったらしい。
パチンコ機・パチスロ機なら今でも?
Re: (スコア:0)
パチンコなどの遊戯機はZ80だったような。
(不正コードが混じってないかを読む検査官がZ80しか読めないおじいちゃん説)
Re: (スコア:0)
内蔵ROMプロテクトでお上的なセキュリティが強いと言われるZ80コア使用のCPUです
ROMは8KB、RAMは512B
これで\3000もするのを買わされる
asmコードのリロケータブルリンクは禁止
ORGのアドレス指定で書かねばならん
Re: (スコア:0)
むしろCとアセンブラ以外のポインターで苦労する言語 is 何
それしか知らないから認知が偏っているのでは
Re:逆に言えば (スコア:2)
多くの言語でポインタ使ってない?
Cみたいにポインタで演算できちゃうのは少ないとは思うけど
#俺もやらないようにしてる
他にはRubyしか使えないのでRubyで例書くけど
foo = ["hoge", "fuga"]
bar = foo
foo ["hoge", "fuga", "piyo"]
このあたりの挙動ってポインタの知識そのものかと
Re:逆に言えば (スコア:1)
後から見直したらrubyの部分化けてるなぁ
<<がの行が消えてるっぽい。<ecode>使わないとだめなのね
って書いたつもり
Re: (スコア:0)
イマドキの言語では「ポインタ」ではなく「参照型」を使うし、そっちの概念で考えるのでは。
C言語のポインタ (や配列に関してのsyntax sugarなど)はデータアクセスの抽象化が未熟な頃の仕様では。
実行時にメモリイメージを想起しやすいというメリットはあるけど、
そんなメリットを求めるのって組み込み屋さんとかくらいだし。
あなたが書いてるのも別に「ポインタの知識」じゃないよね。
どちらかというとメモリアドレスやその演算を意識した例じゃないとポインタっぽくないのでは。
Re: (スコア:0)
メモリアドレスやその演算を意識した実装なんて、脆弱性の臭いがプンプンする悪しき風習ですね。
Re: (スコア:0)
8086のセグメントアドレス方式を意識したポインタ操作ができる高級言語はあっただろうか
Re:逆に言えば (スコア:1)
Re: (スコア:0)
それもポインタだけどポインタ知らなくても誰でも使える程度のものだから・・・
Re: (スコア:0)
CASLの達人は?
Re: (スコア:0)
周囲が皆CASLを苦手にしているのがよくわからんかった
Re: (スコア:0)
CASLはさっぱりわからんかった
CASLが一番簡単だって聞いてたんだけども結局COBOLで取ったわ
Re: (スコア:0)
ExcelでVLOOKUP使って1時間とかかかる作業をしている所は意外と多いらしいし
Accessでも何でもいいので適当なDBにデータ突っ込んで複数のテーブルをJOINしてSELECTする程度のSQLが書くことが出来れば
非IT企業なら多分食いぱぐれることは無いんじゃないかな
VB6.0やVBScriptが出来ればなんだかんだ言いつつ10年くらいは食べていけそう