Big Techが使う大きなツールは専門家を見つけやすいです。
Big Techに入社するために学ぶ人も多いですし、Big Techが選んだからと勉強する人も多いです。当然、これを知っている人を見つけるのも簡単で、経験者や専門家を採用するのもしやすいです。では、初めて見るツールならどうでしょうか。これを集中的に掘り下げた人がまったくいないわけではないでしょうが、そういう人を見つけるのはBig Techのツールの専門家よりはるかに難しいはずです。
Big Techが使っている大きなツールは、リファレンスや資料が豊富です。
多くの人が使う大きなツールは、問題解決のための資料やGoogle検索結果が豊富です。ほとんどの問題は、他の人も経験したことがある場合が大半で、簡単な検索で容易に問題を把握できます。しかし、初めて見るツールの問題はリファレンスを見つけにくく、問題が発生した場合は原因の特定にかなりの時間がかかる可能性が高いです。これも全部コストです。この問題は新しく導入した小さなツールの問題なのでしょうか。それとも別の側の問題を誤解しているのでしょうか。
そうですね。コメントにもたわごとが多いですね。過度にのめり込むのもよくありませんが、ソフトウェアエンジニアリングがそれほど大したものではないと感じるなら、その仕事はやめればいいんです。正直、基準を下げれば簡単な仕事ですが、そうでないなら難しい仕事であるのは事実ではありませんか。世の中の大半の職業がそうでしょうけど。
別に他の職業を見下した文章でもないのに、こういう文章のほうがもっと滑稽ですね。
今回のo3はハルシネーションがかなりひどいという問題がありましたよね。
そのうちの一つではないかと思っていましたが、直接連絡したのは面白いですね。
[更新] OpenAIがLumiに公式に回答
OpenAIはこの投稿について私たちに連絡し、その特殊な文字はウォーターマークではないと伝えました。OpenAIによれば、これは単なる「大規模強化学習の特異点」です。しかし、将来の読者がChatGPT o3/o4の応答におけるこうした特殊な（そして潜在的に望ましくない）文字の問題を引き続き確認できるよう、私たちはこの投稿を残しておきます。
www
リテラルをパースすると変数まで文字列として出てくる問題が解決されたようですね。共有ありがとうございます。
そういえば、elmでもできますね。
Gleamもこれをサポートしているので、かなりすっきりコードが書けるんですよね。
ところで、本文にコードブロックが入っているからなのか、モバイルでもデスクトップレイアウトで表示されますね。
サービスの成長に伴う複雑さの増加に対して、初期のやり方をそのまま適用すると、もはや有効でない可能性があることを見落としている内容のように見えます。
当然、初期には素早いアプローチがしやすく有効だったのでしょうが、それがもはや機能しない可能性があるという点を受け入れなければ、追加人員がまるで非効率で献身的でないかのように判断されてしまうようにも感じられるでしょう。
その戦略がもはや通用しないことに、あとになって気づくのでしょうが。
そして、会社に仕組みがないことを「実行が速い」と言うのは、自慢にはならないと思います。
あの人たちほどの報酬を払うわけでもないのに、生産性が出ていないと締めつけても、仕事のできる人は逃げていきます……
Googleのおすすめにたまたま出てきたので読んでみましたが、この記事はあまりにもGeekの視点で書かれた記事です。事業的な観点では、まったく的を射た話ではありません。なぜでしょうか。
Big Techが使う大きなツールは専門家を見つけやすいです。
Big Techに入社するために学ぶ人も多いですし、Big Techが選んだからと勉強する人も多いです。当然、これを知っている人を見つけるのも簡単で、経験者や専門家を採用するのもしやすいです。では、初めて見るツールならどうでしょうか。これを集中的に掘り下げた人がまったくいないわけではないでしょうが、そういう人を見つけるのはBig Techのツールの専門家よりはるかに難しいはずです。
Big Techが使っている大きなツールは、リファレンスや資料が豊富です。
多くの人が使う大きなツールは、問題解決のための資料やGoogle検索結果が豊富です。ほとんどの問題は、他の人も経験したことがある場合が大半で、簡単な検索で容易に問題を把握できます。しかし、初めて見るツールの問題はリファレンスを見つけにくく、問題が発生した場合は原因の特定にかなりの時間がかかる可能性が高いです。これも全部コストです。この問題は新しく導入した小さなツールの問題なのでしょうか。それとも別の側の問題を誤解しているのでしょうか。
むしろBig Techのほうがこうしたものを切り替えやすいのです。膨大なデータ処理規模のため、わずかなI/Oの改善が大きな利益になる企業だからです。そして、Big Techが採用したという理由だけで勉強しようとする人も多いです。しかし中小規模の企業では、比較的小さなデータ規模のため、わずかなI/Oの改善はそこまで大きな利益ではない一方で、上の問題は非常に深刻です。中小規模企業が採用したソリューションを学ぼうという人も少ないです。ですから中小規模企業の経営者であれば、Geekのようにこういう点を細かく比較するより、Big Techのツールを真似したほうが、かえって経済的だという結論になることが多いです。
韓国語対応に期待です!!
AI生成データを学習データとして使わないようにするためではないでしょうか（model collapse）。
韓国式のポイントを絞った詰め込み指導でも受けたのか……試験だけはやたらできる。
いざ話してみると……実はかなりポンコツ。
「時間がかかると思えば時間がかかり、早く終わると思えば早く終わる。」で、パーキンソンの法則を思い出しました。
パーキンソンの法則: ある仕事にかかる時間は、与えられた時間に応じて増大するという法則です。
単に殺したかっただけでは？
AIも知覚に似たものを持っているため、AIと共に生きるなら、AIのための制度や法律が作られるべきでしょう。22世紀の新しい生命体として、おもちゃのように扱ってからかったりしてはならず、また見方によっては危険になり得るため、AIを発展・利用するだけでなく、安全に使えるようにする必要もあります。
少量のデータや上の例のような簡単なレベルのコードでは、見た目も悪くないと思います。
ですが
map()の中にコードが少しずつ入り始めると……コードがだんだん太っていく傾向がありますし、言語や実装ライブラリによって影響はありますが、データ量が多くなると、単にデータ構造にデータを積んだり操作したりしながら処理するのに比べて、簡単に数千倍遅くなることもあるので、
それに、さらに好まなくなった新しい理由がもう一つできたのですが、スマホでこの記事を見たら、PCレベルの幅がそのまま維持されて文字サイズがゴマ粒みたいに小さくなってしまい、記事を読むのがとても大変だったからです T.T
基本的には好みではなく、わざわざああいう書き方をしようとはしません。
MAUI ... （泣）