だめです！ HSP厨は絶対に犯罪です。

1 ：08/12/18 〜 最終レス ：11/12/26

早速警察に通報しました。

2 ：

1 ：大便 [] ：2008/12/18(木) 10:08:21
早速警察に通報しました。

3 ：

削除依頼出しておけよ

4 ：

>>1
この板を多くの人間が見ているんだぞ
お前なんか迷惑行為等防止条例違反でかーちゃんにいいつけるぞ

5 ：

>4
かあちゃんが警察官で>1逮捕、わかりません。

6 ：

だめ、絶対だめ

7 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

8 ：

アイちゃんどんだけ精力的なんだよｗｗｗｗ

9 ：

HSP≡
C#≡
Java＝タバコ
C++＝コーヒー
アセンブラ＝美味しいお米のごはん

10 ：

なるほど、Javaこそが最高最強高偏差値言語なのですね、わかります

11 ：

Delphiのこともたまには思い出してあげてください・・・

12 ：

Javaこそが正義なのです。

13 ：

他は嗜好品なのになぜ一つだけごはんなんだｗ

14 ：

アセンブリこそプログラマの主食

15 ：

guest guest

16 ：

でも、HSPってウィンドウ操作系のプログラムを組む場合に便利だよね。
それ以外はだけど。

17 ：

サワリがラクなだけで、まともなデータ構造欲しくなった途端に難儀するよな
HSPの利点って、オモチャ感覚でダウンロードしてきて
設定もなしに何も考えずにGUIモノを始められる所なんじゃないの

18 ：

良い意味でも悪い意味でもオモチャやね
すごく気軽だが、その程度のことしか出来ない

19 ：

つい最近まで浮動小数点が扱えなかったとか、もう言語の仕様が糞すぎて

20 ：

浮動小数点なんて何に使うんだよｗ
０と自然数だけでいいよ

21 ：

ウィンドウ操作系のプログラムが具体的にどんなのか知らんけど
最近のHSPはまともにウィンドウハンドル扱えるようになったりしたのか？

22 ：

>>20
>浮動小数点なんて何に使うんだよｗ
仮になんにも使えないんなら、なんで今時のCPU
みんなこぞって浮動小数点演算機能積んでんだよwww
まあでもHSPってコプロつかFPUとかがオプション扱いだった時代の
BASIC環境を意識してる品物に見えるし、3Dやらない場合は需要ないのかもな

23 ：

sin, cos も知らない厨房には必要ないだろ

24 ：

goto *>>1

25 ：

20 名前：デフォルトの名無しさん 投稿日：2008/12/23(火) 02:20:45
浮動小数点なんて何に使うんだよｗ
０と自然数だけでいいよ

26 ：

HSPがポインタ扱えるようになれば最強かもしれない。

27 ：

ポインタ実装だけで他もろもろの問題点まで改善しようがねえだろwww
ああポインタ実装に乗っかってライブラリ整理すれば、みたいな妄想かな？
でも言語が糞だから。構造化性がヘタレで命令体系もうまくやれてない
いや、まあHSPの言語設計のデタラメさを突っついても意味ないと思うけどね。
Win上にベーマガ世代の手軽さを求めた結果の成果物なんだろ。
それならアレで十分だろうし。
PHPと一緒で言語がクソでも必要充分なバランスを認知された「環境」なんだと思うよ。
でもHSPにポインタ実装されたところでどうにもならない

28 ：

元々はゲーム内に組み込む簡易スクリプトみたいなとこから始まったんだろHSPって
だから言語としての設計思想なんて最初から欠片もなく、ただ効率よく動けばいいや位の
文法しか備えていない（以前のHSPは演算優先順位すら存在しないというありえない仕様）
もっともその割り切り故に、一定の実用性とそれなりのユーザ数を獲得するに至った

29 ：

型無し言語は例外無く犯罪

30 ：

型無し言語なんてまず無いけどな

31 ：

>>22みたいな犯罪者予備軍をなんとかしてほしい。

32 ：

Ruby・・・

33 ：

なんで俺が犯罪者予備軍なん？

34 ：

1/2=0 でよろしければどうぞ
つ整数型

35 ：

1 / 2 が 0.5 になる言語も中にはある

36 ：

犯罪ｗｗｗｗ
まぁ、HSPだけしかやってないってのは悲しいかもね。
HSPだけに依存すると成長できん、就活にも使えないし

37 ：

>>35
次のPythonのことですね

38 ：

個人用途だからHSPとPHPだけで困ってないわ。

39 ：

>>38を言い換えると、
「俺が食うだけだからと汚水で困ってないわ」

40 ：

困ってないのは勝手だが、わざわざ人前で言うような事じゃない
という事か

41 ：

HSP > C++ という最高定理を否定するやつは俺がゆるさない！
悔しかったらHSPより少ないコード量でラーメンタイマー作ってみろ。

42 ：

LL系の方が相手に相応しいんじゃねえの
とりあえずpythonで汚く4行
import sys,time,string;s=string.atoi(raw_input("enter second:"))
while s:
print s,;sys.stdout.flush();time.sleep(1);s=s-1
print "finished."

43 ：

三行目冒頭、半角スペース消え失敬

44 ：

誰か>>41やってみてよ
ラーメンタイマぐらいでPC使うのもあれだからARMアーキテクチャあたりで

45 ：

LL許すとperlerとかruby使いはワンライナでやりそうだな

46 ：

じゃあ要件設定をば。
■勘定奉行程度のGUI機能をもつ
■ネット通信によるラーメンデータの交換機能

47 ：

サーバ要るのかよw
ラーメンタイマーにおけるラーメンデータってなんだ？
いつタイマー開始したか（作り始めたか）のタイムスタンプと
必要な定刻秒数はラーメンタイマー普通に取得できるけど
ラーメンタイマーの役割に於いて、それ以上の情報入力は
optionalじゃないと面倒だな
それ以上の情報（食ったラーメンの感想や価格、メーカー等）はnull許容でいいかな？
勘定奉行のUIを知らないのだけど、最低限コレ実装しろってラインをお伝え願えると助かるですよ。

48 ：

>>ラーメンタイマー
これがHSP厨の発想のレベル。
わざわざPC使わなくても普通のタイマー使えば良いところをわざわざPC使おうとする。
こうした非合理的な精神構造は非合理的な設計で作られた言語による洗脳の賜。
もしPCでラーメンタイマーを必要としている人がいるとすれば、
それはコードが最小のラーメンタイマーではなく、
ファイルサイズやPCへの負荷が最小のラーメンタイマー。
HSPをやっていると、
自分の楽さやコードの少なさに重点を置いた
利用者の立場を無視したソフトウェア設計が可能となる。
…ネット社会に対する嫌がらせ以外のなにものでもない。

49 ：

c:\>sleep 180 & echo ^G^G^G

50 ：

ほー　いいじゃないか
こういうのでいいんだよこういうので

51 ：

そりゃ、犯罪扱いされるわな

52 ：

HSPに足りないもの
- ポインタ性
- ウェブアプリ作れる性

53 ：

- 実装の一貫性
- 言語環境の一貫性
- 後方互換性の堅実さ
- データ構造の柔軟さ
- データストア関連の実装の十分さ
- プログラム構造の柔軟さ
- コード評価モデル柔軟さ
- メモリ設計効率の高さ
- ポータビリティ
- メタプログラミング性

54 ：

お前らHSPに多くを求め杉
例えるなら、をどう調理すれば美味しく食べられるかを議論するようなものだ

55 ：

なんだかんだいって、HSPの言語設計は悪くないよな。

56 ：

犯罪者予備軍現る！

57 ：

玉葱の作った言語=HSP

58 ：

hspは2009年に来なくていいよ^^

59 ：

HSPは言語設計自体は悪くないんだが、
一番のネックはコミュニティだと思うんだな。
GPLにしてそっち方面に解放すれば化ける気がする。

60 ：

それならHSPそのものの状況が変わるのを期待するより
HSPをもう少しブラッシュアップしたものをGPLで出せばいいんじゃね

61 ：

言語設計が悪くないとかたちの悪いジョークだ

62 ：

コミュニティつーか厨を一掃したいならそれこそ言語仕様を一新すればいい
厨どころかコミュニティ自体が消滅するけどな

63 ：

もともと必要ない子だったんですよ

64 ：

もともとTclに対するTkみたいなGUI構築用の組込スクリプトの立ち位置だったのに
はからずも自己完結したスクリプト言語として中途半端に成功してしまったのが不幸の始まり

65 ：

ただ、閉塞感のただようプログラミング言語の現状に
突破口を作れるのではないか、と感じさせてくれるのは確かなんだよな。
C++0xのようにひたすら肥大化していくか
関数型言語のように実用性のない理論重視の方向性でいくか、
という現状の中で、シンプルさと実用性を両立しようとしているっつう意味では。

66 ：

HSPの場合は両方だめだから話にならない

67 ：

>>65
関数型は別に実用性は問題ないだろ。
単に普及度の問題で。

68 ：

構造体もローカル変数もないバージョンのHSPで数万行のコードを書くHSP信者の頭の良さには脱帽する。

69 ：

ここでHSP煽ってる奴って、HSP 3もまともに使ってないだろ。
3Dゲームまで簡単感覚で作れる言語なんて
世界的にみても稀有だぞ。
同じことをC++でやったら悲惨。

70 ：

海外事情に詳しいみたいだから
ぜひ加筆して世界に広めてやってください。
http://en.wikipedia.org/wiki/Hot_Soup_Processor

71 ：

ここでHSP擁護してる奴って、C++もまともに使ってないだろ。
ここまで低速なのに3Dゲーム作れると謳ってる言語なんて
世界的にみても稀有だぞ。
でも無能しかいないHSP厨がC++やったら悲惨。

72 ：

C++なんて前時代的なプログラムアーキテクチャに固執してる奴って。。。
いわば若者文化についてこれてない老いぼれみたいなもんだな。

73 ：

前時代とかいってるけど設計思想として
オブジェクト指向から何か新しいのでたの？

74 ：

行番号basicに無理やりイベントドリブンやら構造化っぽい機能を継ぎ足したようなhspはc++もビックリなくらい前時代的な感じだけど。

75 ：

メタ・ジェネリック指向

76 ：

結局HSPの自慢の機能って、C++で書いた拡張プラグインとかなんだよなあ

77 ：

そういう拡張プラグインを提供してる連中は、
実際にHSPつかってプログラミングなんてやってないだろうしな。
つーかゲーム開発自体あやしいか。

78 ：

閉塞感のただようプログラミング言語の現状に突破口とか、
でっけぇ釣り針だな・・いやマジで釣りということにしといてくれ頼むから
本気で言ってるのなら良い病院紹介してあげるぞ

79 ：

HSPは殆んどのアプリ分野でC++より圧倒的に生産性が高いのは事実だけどな。

80 ：

その分野のC++で書かれたDLLがあれば。

81 ：

HSPで生産性が高そうなのって書き捨てプログラムくらいだろ
ていうかなんでいちいちC++を目の敵にしてるんだろうねこの人
君が使ってる便利なDLLの数々は何で書かれてると思ってるの？

82 ：

ほとんどの分野で圧倒的に生産性が高いとかって言うけど、
たとえば、指定したフォルダ以下から重複しているファイルを見つけるとか、
C++より圧倒的に簡単に書けたりするのだろうか。

83 ：

それならHSPのほうが速いはず。
C++だとまずディレクトリ名を返す部分でいきなり壁になるだろｗ

84 ：

>>83
壁になる?
標準関数にないからダメとか、そういう話?

85 ：

C++がHSPに勝とうなんて100年速い。
C#がC#++に、C#++がC##にならないと同じ土俵にすらたてんよ。

86 ：

>>84
opendirとかfindfirstとかdirectory_iteratorとか難しいじゃん、使い方分からないじゃん、ってレベルの話なのかも。 > 壁

87 ：

「壁」っていうくらいだから、C++でディレクトリエントリを読めるってことを知らなかったのかもな。

88 ：

彼はHSPに人生を捧げてるんだから、
あんまり彼の人生を全否定して苛めちゃダメよ。

89 ：

さぁさぁ盛り上がって参りました！

90 ：

HSP厨にとって壁なだけだろ
だから厨房って言われるをだよw
確かにPCのリソースを無視したアプリケーション開発の分野では
100年どころか100000000年経っても勝てないだろうな

91 ：

>>87
C++の標準関数にディレクトリエントリ読める関数なんてあるの？

92 ：

>>91
もうやめれ、
これ以上HSPユーザーの評判をさげるなよ

93 ：

>>92
それはどっちの意味で言ってるの？

94 ：

標準関数に無くてもどっかで作ってくれてんじゃねーの？
自作じゃないとだめなの？　関数って。

95 ：

ほとんど標準に近い形で使えるんだから、そういう議論はそれこそ生産的じゃないよ。
HSPならこういう感じで、サクッと書けるけどC++ならどうよ？ みたいな話って出てこないの？

96 ：

>>95
OSごとに違うのに標準？

97 ：

opendirってもろにPOSIX APIじゃん。
API叩かないとディレクトリエントリも読めないC++哀れ。

98 ：

存在するリソースすべて使ってってのならC++の方がそりゃ便利だ。
初じめて使った人が(ちゃんと基礎を通して)それをできるまでの学習時間という
意味でHSPのほうが有利だろ、と書きたかったんだが。

99 ：

opendirは上でも言ってるがPOSIXなんでWinで使うのにちょっと敷居があるだろ。
directory_iteratorは使いやすいが、boostの導入がやはりちょっとした壁になるだろ。
環境によってはboostのコンパイルもしなきゃならんし。
findfirstはほぼ標準と言ってもいいが、それですらFindFirstFile、FindNextFile、FindClose、
と3種と関連APIリファレンス読んで、さらにFIND_DATA構造体についても
調べなきゃらならんだろ。
これらの方法に辿り着くまでにかかる時間、で結局どれを採用するか
評価する時間も必要になるし。
HSPだと確か添付マニュアルのディレクトリ操作の項を
読むだけでいきなり探査ルーチン書けなかったか？
他に魅力的な手段も無いから、標準1択で悩むことも無いだろうし。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
Oven/Egg総合スレ part1
ＷＥＢコンパイラってないの？
プログラミングに必要な細か〜い機能
OpenCLプログラミング#1