Java厨は脳が足りない

うちの会社もJavaしか出来ない馬鹿が多くて困ってる

本当にJavaが使えてるのならまだマシ

適性のない人間を無理やり使ってるんだからしょうがない。
それともおまえ、そいつら無しでやるのか？

C++よりはマシ

>>3
ぶっちゃけ、いらん

Javaは簡単すぎる
７歳の娘にJavaを教えたら１日で概要を理解してた
２日でサーブレットやJSPも覚えて
３日目には座席予約プログラムとか１人で書いてたよ

それある意味すごいな

そういえば長門さんって何歳なんだっけ

C++挫折者の巣窟

デジャブーな予感

>>1
C/C++しか出来ない、VB/C#しか出来ないより、よほど役に立つわけだが。

成長しないのはJava厨だけだから
他の言語しか出来ない奴の方がマシ

脳内妄想乙。
使い道の無い言語覚えて何が楽しいの？

Java(笑)

>>11
典型的な脳が足りてないJava厨だな。
C/C++の有用性はいまさら語るまでもないし、
VB使えりゃWSHやExcelのマクロを弄れるし、VBはなにげお得。
C#は...えっと、その、まぁなんだ、きっとなにかの役に立つよ。

java は GC が致命的

>>16
否、Javaは起動時間が致命的。

>>17
昔ほど、ストレスは感じなくなった。それほど待たずに使えるよ。

>>18
Javaのフォローをしてるようで全然フォローになってなくてワラタ。

プニルの起動時間に待てればV2Cはぜんぜん快適

>>8
3歳。でもJavaは触ったこと無いと思う。やったとすればいきなり機械語だろ。

>>20
V2Cは十分快適だよ。起動時間約2秒だった。

気持ちはわかるが、いちいちクソスレ立てる>>1の脳みそ量も疑わしいぞ。

Javaって使い道あるの？

>>24
それをいうまえにC#はどうなんだ？
Javaできりゃ、普通に考えてC#もできるだろ。

Java厨は一度、脳の検査を受けたほうがいい。

つーか、Javaスレ乱立させ杉。
おまいら余程Javaが好きなんだな。

>>27
うん、好きだ。

厨房ならJavaに限らず脳みそたりなくね？

そっか、C++で挫折するとJavaにたどり着くのか。どうりで。

で、逆恨み的にC++を馬鹿にしだす

あんなの知らなくても生きていけるもーん。わーん(泣)

言語ってなんにせよシステムありきでおぼえていくもんじゃねーの？
漏れの場合は、C→RPG→PL/1→アセンブラ→COBOL→VB→Javaって感じなんだが。
○○しか出来ないのはそれらを使う業務と縁がないと仕方ないと思うんだが。

漏れは基礎としてCがあるから、どんな言語でもあまり苦労しないけど、
宗教論っぽい排他意見を出す人は多分単一言語しか経験ないとｵﾓ。

>>33
うんにゃ。例えばおまえの場合だとLispやHaskellあたりをやって、初めて基礎が完成ってところか。
そしたらJavaやC++のコードの書き方も変わってくるぞ。

ﾜﾛｽ

>>34
LispやHaskellってどういう業務でつかってんの？
漏れは保険、金融、物流のシステムやった事あるけど、
Lispの出番はさすがになかった様な気がするんだが。

基礎を完成させるのは遠いでつなｗ

Haskell・・・コンピュータサイエンス課程の教育/研究用言語
Lisp・・・・・・非コンピュータサイエンス課程の学生自習用言語

>>3
了解しますた。
多分縁がない、と言うかHaskell辺りはもうちょっと普及が進めば
もしかして機会があるのかもしれんけど、Lispは徹底的に縁がなさそうっす。

うちの職場はLispを開発には使ってないけど、技術のある人は
教養としてほぼ間違いなく知っている。

業務に関連とかしてたらLispとかも覚えてもいいかな？とは思うんだけど、
単純なテキスト整形とかだとperlとかsed,awk辺りで済むし、
テストデータとかを準備するのもSQLとかで出来ちゃうので、
Lispがどう適材適所になるのかよーわからん。

金融、保険の仕事した時に確かに面倒な計算とかはやるんだけど、
Lispでやると便利って風にはLispの仕様をみて感じないのは
漏れが基礎が出来てないからか？

んだ。手続き型言語(JavaやC++含む)を主として使う奴も、
「教養」としてLispは押さえておくほうがいいってこと。
どっかでCとLispはプログラミングの基礎の両輪、みたいな
文章を読んだことあるけど、まさにそれだとおもう

あー、確かに自分の思考パターンがC寄りではあると思う。
まだまだ修行不足なんだろうなぁ。

絵に描いたような自作自演だなｗ

Java厨を叩かないと鬱憤が晴れない
可哀相な人　乙

Lispについてはとりあえず有名どころで

ESRの「ハッカーになろう」
http://cruel.org/freeware/hacker.html

↑をふまえて、ポール・グレアムの「普通の奴らの上を行け」
http://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.html

まあ、コンピュータサイエンスなんて見下してたおいらは、
自分の専門課程の他に>>37 の両方やった上で
Symbolics Macsyma弄ったり
数式処理システムやSmalltalk class kernelの試作してたけど、ね。

>>6
将来Javaでしか会話できない子になるぞ。

なんかさぁ、>>44のコンプレックスが手に取るように見えちゃうんだ。
結局おまえは まっとうな関数型言語 (SML/NJ, Haskell 等)に
コンプレックス持ってるから、Lisp自慢始めちゃうんだろ？
お前よりよっぽどその分野を深くやってるんだよ実際。

>>47
その分野ってなあに？

やっぱさぁ、ホンモノのスーパープログラマと
Java厨やJava叩き厨と差別化するには
下に挙げるGuy L. Steel Jr.の仕事のうち幾つかは押さえてないと
まずいんじゃない？

・CLtL1, CLtL2
・C*
・HPF
・Java

俺は上のうち三つだけだ（ｗ

>>44
ハッカーの理念は共感できる部分があるのだが、
漏れの場合はガキの頃、「ゲームを作りたい」ってノリで
Cやアセンブラを自発的に習得して、他の言語は
仕事で必要だったから覚えた。ってスタンスだから、
学術とか研究とかハッカー精神とかにつながらないんだよな。

知識の収集欲みたいなのはあるののだけども、
普通と違う事をステータスにしたり、人より上とか下とか
どーでもいいってのはある。

そういう意味では純粋に機械が好きってタイプでないんだろう。

おまえ相変わらず他人と会話ろくすっぽできねぇんだな

>>49
The Jargon Fileはだめでつか。

>>52
あい。認めまつ。

ところで>>1よ、
お前自身はプログラムはできるのか？
基礎教養と称する言語は扱えるのか？

>>34よ
お前はどうなんだ？

しょうもない見栄張り厨房だったな >>1, >>33

こっちは(大体のところは)正直ベースで申告してｗ
楽しい会話を期待しているのに、
お前は他人に自分の趣味を押し付けて、
自分の程度が問題になるとケツまくって
スタコラホイサッサと逃げ出すんだよな

そんなしょうもない見栄を
いったい何回繰り返したら気が済むんだ？

自分に自信がなくても、自分を率直に出す
そういった人間としての基本姿勢に問題があるんじゃねぇのか、おまえは

なにこれ自作自演？

はいはい、お前が書いた部分は全部ｼﾞｻｸｼﾞｴﾝ

俺はお前のｼﾞｻｸｼﾞｴﾝに突っ込んでるところ。

どうだ、俺のブツの具合は？

>>34
Haskellにはショックを受けたよ、こんな言語があるのかって
手続き言語（C/C++、java)だけしか扱ったことのない香具師は、遊びでいいから触ってみるといいと思う。
ただ、Haskell自体、SmallTalkみたいになる可能性が有りそうな感じがするんだよな。
Haskellがそうなっても、関数型言語の考えは将来メジャー言語に取り込まれると思う。

既にラムダ式やクロージャなど関数型言語でよく使われるものが
手続き型だった言語にも取り入れられつつある。

>>59
　>>37
関数言語の可能性は、80年代末〜90年代位にコンピュータサイエンスで SML, Haskellをマジメにやった人ならとっくに気付いている。
その状況は、あたかも教育/研究機関で使われていたインターネットが90年代に一般利用開始されて世の中に大きな変化をもたらしたのと同じだ。

>>59
> Haskellがそうなっても、関数型言語の考えは将来メジャー言語に取り込まれると思う。

つC# 3.0

MLは元々、定理証明系の記述言語として作られた。
その後、他の言語の機能(型推論等)が取り入れられて
より一般的用途に使える関数型言語としてSML他が作られた。

また90年代前半には副作用のない純関数型言語の標準として
Haskellが作られた。

欧米(MIT等)ではかつて、教育用言語としてScheme、Lisp等が
使われていたが、それらは「コンピュータサイエンスで扱う概念を
示したり研究する土台」としては不十分※1なものだった。
(※1; 副作用の大きな関数風手続き言語に過ぎない、という意味で)
SML、Haskellの登場に伴い、大学院での研究にも使える
教育用言語として、学部で最初に扱う教育用言語として
SML, Haskell を使う大学が増えた。

その影響を受け、国内でも80年代後半〜90年代前半にかけ
MLやHakellを扱う大学が増え、現在の関数型言語ブームの
下地ができた。

現在メジャーな言語の設計に、関数型言語の機能が次々と入り込んでいる
のは、そのような下地の上で、当時のコアな研究者がメジャーな言語の開発に
影響力を及ぼしている事による。
例えば MSリサーチは、関数型言語の研究者を多数抱えている。

結局 Java叩き厨ってのは
・学校で普通に習ったこと
・２ちゃんで聞きかじった話 (僭越ながら俺も何度もその類の話を書いてやった)
を根拠に叩くだけじゃん。
そんな基礎体力の低さじゃせせら笑われるよ

Ruby, Python といった関数型言語のフレーバを取り込んだ
スクリプト言語の登場もまた然りだ。
これら言語の作者達も、俺と同時期に関数型言語の新潮流
を知った人なのだと思うが、
彼らの場合はより簡単に扱え、また現場に入り込み易い
「スクリプト言語」の形でさっさと実装を済ませ、普及を図った
そんな意味で彼らにはかなわねぇな、と心の奥底からおもう。

ってゆーよーな背景かかえながら、JavaやったりC++やってるわけよ、
世の中のスーパープログラマってのは。

たかひろ、お前は今更そんな話して、一体何を言いたいの？

これからのＪａｖａ考えると、脳足りなかったらできねーような気がするぞ。ドルフィン？あれなったら色々面倒なの導入されて何でもありなっちゃうんだろ？もースクリプト言語もＣ＋＋も淘汰されてっちゃうんじゃね？いや、わからんけど

C++はtemplateが関数型言語に似てるからな。
Boostじゃラムダ計算や無名関数なんかも取り入れてるし。
Cとの親和性と関数型の拡張なんかを考えるとjavaより生き残るのは確実だろう。

この先生きのこる？きのこる厨房と死滅厨房かよ
ﾜﾛｽ

C++にも処理系非依存のリフレクションがあったらなぁとたまに思う。

>>66
今度は関数型言語で名前を売ろうかななんて思るよ。
お舞には、無理だろうが

OpenC++あたりから情報たどれよ

時代遅れの夢見過ぎだよ
たかひろ
お前の設計見た連中がせせら笑ってるぞ

たかひろの話は常に２０年遅れ

で、たかひろって誰？

m9(^Д^) お前だよ、喪前、プッ

意味わからん。なんかばっちぃものに触ったようだ。

この先生きのこる
キノコ厨房スレ

キノコは菌類だからばっちくて当然

泥落とすのは別として、キノコってふつう洗わずに料理するよな。
風味が落ちるのかね。

結局たかひろから学ぶべきものは
何も無かったな
反面教師というただ一点を除いては

相手を叩き相手から情報を引き出すだけで、
相手と何かを分かち合う、そんな姿勢が微塵もない。
そして別の所へ行っては初心者相手に耳知識自慢を始める。

そんな物乞い姿勢だからｃ野も呆れ返っているんだろう。
いい加減ビジネスやめて山にこもれ。

「うぬぼれというより、勘違いだと思う。
　まぁちいさな企業だったら、本を読んだ知識でごまかせると思う。
　だから、たかひろに限らず、リタイアした業務コンサルを集めて
　会社をつくるわけですよね。
　年齢というパワープレイをする人ほど、経験を軽視するような気もしている。 」

関数型言語面白そうなんだけど手続き型言語に置き換わるような気はしないなぁ
マルチパラダイムにするのもいいけど必要以上に複雑になるのは嫌だし
もう少しいい妥協点はないかなあと思わなくはない

以前キミがやろうとしていた事は概略以下の通りだと思う。

目的：ＯＯできない技術者にＯＯの真似事をさせる
前提：業務分析とドメインモデリングをしない
　　　　画面中心設計、ＤＢ中心設計、構造化プログラミングを温存
方針：業務アプリを、次の要素で記述する。
　　　　・画面中心設計 (画面と処理、データを適切に分離しない)
　　　　・DBエンティティをマッピングした
　　　　　静的なドメイン・オブジェクト
　　　　・アドホックなドメインスクリプトで処理を記述
結果：・不適切な設計方針により、画面に強く型依存した
　　　　　大量のデータオブジェクト、処理オブジェクトが発生し
　　　　　再利用や共通化の支障となった
　　　　・マルチスレッド処理を考慮しなかったため
　　　　　問題点の抽出と手直しに時間がかかった

強い型付けを持つ言語から学ぶべきポイント
・型の依存関係について、適切な見通しを立てる能力が身につく。
・この結果、クラスを型でがんじがらめにせず、
　適切に疎結合を導入する必要性や、
　総称的プログラミング手法で逃げるべきポイント
　を理解できるようになる。

純関数型言語から学ぶべきポイント
・処理の副作用を除去する事で、
　関数プログラミングは極めて見通しが良くなる。
・逆に副作用を持つ言語では、
　副作用(内部状態等)を持つ範囲を限定する事で、
　見通しの良いプログラミングが可能になる。
・それはマルチスレッドを含む分散トランザクション処理を
　記述する上で重要なスキルとなる。

版画はいつから神になったんだ？ん？

邪教の狂信者が大口を叩くな

キミのやっていた事を、別の言葉で表現してやろう。

下僕よ、お前は「ＤＳＬ(ドメイン特化言語)」は理解できているか？
お前が構築したパターン体系は、
「ＤＢ処理＆構造化プログラミングのためのドメイン特化パターン言語」
とでも呼ぶべき代物だ。
その構成要素は、構造化プログラミング言語の手続きとモジュールを
クラスで置き換えただけのものに過ぎない。
そんな暇な事をやるくらいなら、構造化スクリプト言語でも設計しる。

愚かで性根の捩くれた者を罰するのは簡単だ。
常に正解だけを語っておけば良い。
そうすれば、性根の捩くれた者は勝手に正解とは逆方向へ飛んでいく。
自らの心の捩れが、目を曇らせているのだとは気付かずに・・・。

>>神

またまたそういう惑わす事言ってｗ
ほんと性悪なんだからｗ

愚か者に遠隔から天罰を与える事ができる
インターネットってチョー便利だな

ｃ野氏： 大手クライアントを抱えながら新しい技術に貪欲に取り組む
豆腐：　 20年前の技術すら良く理解できていない

これだけ差がありゃ、まともに相手にされないのも当然だなｗ

豆腐は相変わらずアフォだな。
今度はどんな妄想と戯れているのだろう。

妄想をうんこみてえに垂れ流してんのはアンタ＝版画
んなとこでいきがってねえでpyスレこいやザコｗ

【次スレ】
http://pc11.2ch.net/test/read.cgi/tech/1176033534/

× ・アドホックなドメインスクリプトで処理を記述
○ ・アドホックなトランザクション・スクリプトで処理を記述

プログラマは頑固なのが多いから困る。

豆腐メソッドとくーすを比較すると、
両者が類似した土壌に育った手法であるにも関わらず、
決定的に異なる点が見つかる。

Fランク大出身の豆腐にとって、
そこは認めることのできない一線なのだろう。
合掌

とりあえず(俺には同意できない意見も含めて)
・類似ポイントが一点
・相違ポイントが二点
かな。

いやーﾜﾛﾀ

いまだに３年前のひがちゃん以下のレベルを彷徨っているんだな、豆腐

オブジェクト指向がわからない馬鹿ｗｗｗｗ　哀れｗ

哀れだな、関数型言語からも業務OO設計を学べなかった狂信者は

ひがちゃんが業務APという全く別のジャンルで
>>85後半部と同様な意見にたどりついたのは興味深い。

業務AP屋にも、豆腐みたいな狂信的キチガイばかりではなく
中にはまともな方も居るんだなぁ〜（数年前から知ってるけどｗ)

GoFデザパタ命の焼き豆腐が
Interpreterパターン→LLパーサ→パーサコンビネータ
という奇妙な連想でコンビネータ理論を齧り始めたのには
ﾜﾛﾀ

BNFモドキの文法定義を書けば、それがそのまま構文解析系になって
インタープリタやコンパイラのフロントエンド代わりに使える、なんて話は
prologのDCG (Definite Clause Grammer) の当時から既出。

だが、文を構成する文法要素の階層を、
コンビネータのような高階関数で再帰的に処理する手法は面白い。

バカだからこそオブジェクト指向使うんだろ？

バカの大将＝豆蔵創設者

バカには理解できないオブジェクト指向ｗｗｗ　ﾀﾞｯｻ

そういったウンコ臭い嫌悪感は腐れ豆に直接ぶつけろｗ

出現当時は全然ピンとこなかったのだけど
業務系のOO適用で出てくる齟齬って
Subject Oriented の用語で語られてた話だったんだね。
最近Subject Orientedの話を読み直して妙に納得。