  |
はてなキーワード: javaとは
そうは言ってもOracleがSunを買収したのはAndroidにjavaが採用された後の話だからなあ
GoogleがGoを作るよりももっとずっと前から採用している言語は主にC++, python, そしてjavaだが、javaのパートが一番問題だ。
Android関連の開発で有用であるという点でjavaは使われるが、ロイヤリティを支払うことになっている。
このことについて昔から訴訟問題が起きてきたようで、javaがクソである言われる一つの要因となっている。
JVMはいいんだよ。マジで素晴らしい。Javaはあまりにもクソ過ぎる。
不完全な型推論、あまりにも冗長すぎるモジュール機構、ファーストクラスじゃない関数、なんでもクラス、ザコみたいな型システムに由来したあまりにも乏しい表現力。
あげてもキリがないほどのクソofクソ。このそびえたつクソに燦然と輝く究極のゴミ、そう我らが springframework。
マジでイカれてるよ。直近のJDK21で導入されたJavaの言語仕様としては instanceof 以外で正気を疑う進歩のなさ。どうしてこんなゴミがのさばってるんだよ。
まじで新規案件はKotlinかScalaにしろ！！！！！！(Scalaをまともに使える能力も判断力もない人間がなんとなくJavaを使うんだろうなあ)
たとえばulをフレックスコンテナとして、その子要素liの子要素imgに対してmax-width:100%をかけていたとします。
デフォルトだと、imgを内包したliがulの中で横並びになり、さらにliの横幅は自動的に親要素の横幅をliの個数で割った分だけ縮小されますが、ここでflex-wrapにwrapをかけると、imgで表示する画像のサイズがある程度大きいと、wrapとしないときよりもliごと大きく表示されます。
しかしliの横幅はそもそも指定していなくて、しかもその子要素のimgに対してmax-width:100%をかけているということは、そのcssの指定の意味を論理的な日本語で表すならば、imgはliの大きさを基準にその100パーセント分の大きさで表示しろという意味の指定になると思います。
しかしその基準であるliの大きさを定めていないのだから、imgの大きさも定まりようがないというのが論理的な解釈だと思います。
それでも実際はwrapをかけるかかけないかでそれぞれ一意的にある大きさでimgが表示されるわけです。
ようするにcssはそこに記述されているプロパティの兼ね合いで最終的にある要素がどういう風に表示されるのか、その挙動を理詰めで予測するのが困難な部分があって、それはプログラミング言語よりもある種厄介な癖として立ちはだかっているように思います。
上記の例の場合も理詰めで挙動を予測するには、プロパティの性質に関する論理的な情報が不足しているように感じます。「imgはliの大きさを基準にその100パーセント分の大きさで表示しろ」という情報から、実際どのような大きさでliやimgが表示されるのかはっきり言って予測しようがないと思います。
多くの参考書にもどう挙動するのか一意的な推測を可能とするだけの情報は書かれていません。
もしかしたらcssの公式の仕様を端から端まで参照することで過不足なく挙動を把握するための情報が手に入るのかもしれませんが、仕様のどこか今の自分の仕事にとって必要な情報なのか見極めるのにはなかなか困難なところがあるという意味で、情報に対するアクセスの困難性があると思います。
私はjavaも学習しました。極めたというところには全く到達していませんが、それでもああいった言語は書いた通りに動くものであるということを実感しています。つまり自分が今書いた、書こうとしているコードがどのような動きをするのかを予測するための、各記法や関数に関する文法が情報として過不足なく学習者に提供されているように思います。
cssにも事実上として「文法」なるものはあることは前述の例からも疑いの余地がない(先に書いた解釈以上に要素の表示を決定づけるための文法がないなら、要素の大きさは決定不能ということになる)のに、その情報がいまいち曖昧に提供されているきらいがあるように感じます。
https://coliss.com/articles/build-websites/operation/css/about-css-layout-algorithms.html
↑このような「レイアウトアルゴリズム」と語るサイトも見つけはしましたが、私の言っている文法、すなわち、要素の表示のされ方を決定づけるための処理のフローと、概念的に同質なのかはいまいち不明です。
他の端的な例としては隣接する要素同士がネガティブマージンなので重なった場合、z-indexを指定してない場合はどういう法則でどちらの要素が上にくるのかとかも、本来は明確なアルゴリズム、文法に則って決定されているはずなのに、多くの初学者あるいは中級以上の方でさえも当て推量とセンスと試行錯誤で、なんとか自分の意図通りの表示になるように調整を繰り返すことを余儀なくされているかもしれません(意外と単純で要素の名前について辞書順ベースでどちらが上にくるか決定されてる？)。理詰めで考えさえて設計しさえすれば一発で自分で思い通りの挙動(表示)をさせる、ということが困難な言語がCSSの癖として立ちはだかっているように思います。それはある種プログラミング言語が持つそれよりも厄介な癖だと思います。プログラミング言語の方がある意味で「素直」に挙動してくれると私は思います。
同じように感じた人は教えてください。またそういう感覚を卒業してCSSの挙動が論理的に手に取るようににわかるぞという方は今後の学習に関するアドバイスをしていただけると助かります。
身長：180cm
体重：70kg
過眠症が悩みで１日１２時間寝ないと日常生活に支障をきたし、今は時短勤務で派遣社員をしてます。
食にこだわりはなく、食費もかからず毎月自炊で月２万程に抑えています。
乗り物の運転はそつなくこなせます。必要であればバイクでも乗ります。
炊事は人並みですが、家事は掃除から家の簡単な電気工事、水回りの一次対応、換気扇のオーバーホール、害虫防除まで色々こなせます。
綺麗好きであまりものを持ちたくないので、買い物好きで物を捨てられない人とは相性が悪いです。
以下、所有資格
・全経簿記２級
・危険物取扱者乙種第4類
・ボイラー技士２級
・Oracle Certified Java Programmer, Silver SE 8
・極真空手初段
ベテランじゃねえけど
＞ Masterクラス的なクラスが持ったHelperの処理を呼び出したい
Masterが持ってるインスタンスの情報を参照した上でHelperの処理呼びたいならMasterに窓口になるメソッド作ったほうがいいんじゃない？
別に関係ないならHelperのStatic関数で呼べばいいのでは。
ただ
＞ Master.Helper.処理()
こう書いてるからHelperの関数だけ直接呼びたいっぽいので
それなら普通にStaticで定義してHelper.処理()で呼んでしまえばいいんでねーの
JavaScriptはJavaにあやかって名付けられたけど、インドネシアもインドにあやかってんのかな。
と思って調べてみたら、
という流れのようなので、どっちかというとC++とObjective-Cみたいな感じか。
JavaScriptの名前に「Java」がついている理由は、この言語を開発したネットスケープ社が、もともとLiveScriptと名付けていたものを、Javaを開発したサン・マイクロシステムズ社と提携していたことから「JavaScript」という名前に変更したからです。
しかし、JavaとJavaScriptは全く別の言語で、それぞれ異なる目的と特性を持っています。
なお、Javaは中間コードでのインタプリタであり、JavaScriptはスクリプト言語です。
JavaScriptってJavaの簡易版みたいなもの？ WEBで使うのがJavaScriptでプログラムがJavaってことでいいのかな
プログラマーってだけでシステムエンジニアと対比されて軽んじられる風潮あるけどあれっってどうなんだろ。
まるでウェブデザイナーの下にコーダーがいるかのごとく…しかしこの構造をそのままseとプログラマーの間に当てはめるのは筋違いじゃないのか。
天才プログラマーとか天才ハッカーという言い方はあるが天才システムエンジニアという言い方はこなれていない。
プログラミングはその道を極めれば天才と呼ばれうる奥の深い行為だが、システムエンジニアの業務はそうではないということではないか。
天才ハッカー、クラッカーという言い方があるのは、彼らの目的の達成を左右するのがその奥の深いプログラミングの技量如何だからだろう。
不正アクセス全般、アイフォンの脱獄、ゲームハード界隈のcfw…これらの方法の確立やそれに必要なソフトウェアの開発をするのに一体どんなプログラミング知識がいるのかJavaを齧った程度の私には想像もつかない。まごうことなき天才だ。
大は小を兼ねるというが、それなりにプログラミングができてそれなりにプロジェクト管理とかネットワーク構築ができるseは果たしてトッププレーヤーになれるか、彼らから数100億が動くような製品が生まれるのか。
配下に天才プログラマーがいること無しのはそんな製品できっこないだろうし、トッププレーヤーとなるのもそも配下の方だろう。
別にシステムエンジニアが軽んじられるべきとか奥が深きないとか言ってるわけではない。
コーダーとウェブデザイナーと関係とは明らかに違って、プログラマーとシステムエンジニアはどちらもその内部に底の見えない奥の深さを有し、その立場は対等だろうということだ。
