アカウント名:
パスワード:
JSやCSSでこの手のプリプロセッサ作る|使うのは処理系に容易に手を入れられない事情があるから仕方が無しにやってる訳で、決して最善の策ではないと若い人たちにちゃんと伝えていきたい。うちの会社ではrails3系でcoffeescriptが入ったとき素で書くより便利でしょ？で済ませてしまってそのあたりをちゃんと言わなかったら、後にnode使うようになってビルドプロセス含め更にaltjs周りが煩雑になってもこれが当たり前と思われてしまった。
いや、むしろ若い人たちに学ぶべきだよ貴方は
前処理を煩雑だと思うなんて、今の若者はすっかりインタプリタに溺れちまってるなあ。
C/C++でもコンパイラの前に入るプリプロセッサもそれでアレコレするのは邪悪と呼ばれる傾向にあるようなまぁそんなんよりもC++のテンプレート周りでメタプログラミングする黒魔術のほうが段違いにヤバイんだがまぁテンプレートの展開もコンパイルの中心部よりは若干前に入ってくるし邪悪になるのも仕方がない(大嘘)
みんなRubyとかPythonとかよく使えるよね古い人間だからN88BAISICアセンブラC言語なんだけどC++,JAVA、javascript、PHPなら読めるし書ける必要に迫られてPerlも描いたけど後で自分で読めないプログラミング言語全部C言語っぽい文法にしたら世界中のIT幸せになれるだろemacsの色分けも綺麗だぞ！
Cがイケるなら、python でTypeHintsを使うと、割と読みやすくなると思います。コメント扱いなので見た目だけで実行時には何もしませんが、mypyとかのツールを使えば事前チェックもできるようになるので、ミスも減らせるかと。
Ruby や python は、充実したライブラリ群が容易に使えるのが肝だと思います。その辺、Cは極めて貧弱(C++は11/14/17と充実してきたけどまだまだ)なので、作業効率を考えるとCではできるだけやりたくないなぁ、と思ってます。Cの代替としてrustもオススメ。Core部分だけ使えばKBytes単位のプログラムサイズになります。Dはなんかマイナー確定状態ですが、C++でウンザリしたら代替になりえます。
俺も古い人間だがTurbo Pascalを常用してたので、begin end には違和感がない。
俺も古い人間だがawkを常用してたので、begin endには違和感がない。
# なんか違う# そしてほんとはむしろ常用してたのはperl
＞古い人間だからN88BAISICアセンブラC言語なんだけど機械語、FORTRAN、LISP、COBOLあたりが並ばないとは、実は新しい人ですね！
> 機械語、FORTRAN、LISP、COBOLあたりが並ばないと
LISPではなく、PL/I でお願いします [ipa.go.jp]。
#機械語がCAP-Xだったら古い人、CASLだったら新しい人。
さすがにALGOLは知りません…
わたしの大学時代、学生部長から学長になった先生はPL/Iは使える、ALGOLは使ったことないが似たようなものだろと講義中の雑談であっさり片付けてました。FORTRANとCOBOLも使えるとの由。LISPは当時の経済学分野ではまだまだ及びでなかったので名前が挙がっていない。
機械語 c9アセンブラ ret
あなたと同じような経験をしてきたけれどPythonが一番簡単だと思うよ。
> プログラミング言語全部C言語っぽい文法にしたら世界中のIT幸せになれるだろ
これは流石に時代錯誤。
コンパイラでもぷりぷせったでもなくてトランスパイらだと思う
遙か昔はC++でさえC言語にトランスレートしてからコンパイルしていたものです
自分的には実行時エラーのエラー発生場所の情報が変換前ソース基準になってくれるならコンパイラって感じですね。
逆に、実行時エラーの発生位置が「特別な工夫をしなくても」ソースの行番号で求まる実行環境こそインタプリタであり、「特別な工夫をしなくても」ソースとアウトプットのマッピング情報を出力出来る変換系こそプリプロセッサ的だと思う。
C/C++とかはソースとのマッピング情報を構文木の段階でも保持した上でデバッグ用メタ情報としてわざわざ別途出力し、その上デバッガ上で実行時エラーの発生位置をトラップしてマッピング情報を解析した場合にしか行番号出ないのが元々だし。そのくせはC/C++のプリプロセッサ部分は#LINEディレクティブを埋め込む位で楽勝に変換前行番号を埋め込めている。
altJSでも同じで単純な変換であればあるほど行番号のマッピング情報を作りやすいが、がっつり構文解析して出力し直してると解析済みの状態から最適化その他の過程までずっと行番号保持するとかいう処理が必要になる。
機械語を吐くのしかコンパイラと認めないってやつでしょ彼らにとってはJavaやC#もインタプリタ言語
機械語だけ派とVMまでOK派はあるべ。まぁ高級言語を吐こうが機械語吐こうがトランスパイラ(トランスコンパイラ)も一応コンパイラの区分ではあるけどな。
ただ、字句解析から構文解析までして構文木なりなんなりから出力を吐いてないとコンパイラにはならないと思う。CoffeeScriptはどの程度までやってるんだろう？
＞プリプロは本来邪悪Pro*Cのことですね。
(ぼそ)Ratfor…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
プリプロは本来邪悪 (スコア:1)
JSやCSSでこの手のプリプロセッサ作る|使うのは処理系に容易に手を入れられない事情があるから仕方が無しにやってる訳で、
決して最善の策ではないと若い人たちにちゃんと伝えていきたい。
うちの会社ではrails3系でcoffeescriptが入ったとき素で書くより便利でしょ？で済ませてしまってそのあたりをちゃんと言わなかったら、
後にnode使うようになってビルドプロセス含め更にaltjs周りが煩雑になってもこれが当たり前と思われてしまった。
Re:プリプロは本来邪悪 (スコア:1)
いや、むしろ若い人たちに学ぶべきだよ貴方は
Re: (スコア:0)
前処理を煩雑だと思うなんて、今の若者はすっかりインタプリタに溺れちまってるなあ。
Re: (スコア:0)
C/C++でもコンパイラの前に入るプリプロセッサもそれでアレコレするのは邪悪と呼ばれる傾向にあるような
まぁそんなんよりもC++のテンプレート周りでメタプログラミングする黒魔術のほうが段違いにヤバイんだが
まぁテンプレートの展開もコンパイルの中心部よりは若干前に入ってくるし邪悪になるのも仕方がない(大嘘)
Re:プリプロは本来邪悪 (スコア:2)
みんなRubyとかPythonとかよく使えるよね
古い人間だからN88BAISICアセンブラC言語なんだけど
C++,JAVA、javascript、PHPなら読めるし書ける
必要に迫られてPerlも描いたけど後で自分で読めない
プログラミング言語全部C言語っぽい文法にしたら世界中のIT幸せになれるだろ
emacsの色分けも綺麗だぞ！
Re:プリプロは本来邪悪 (スコア:3)
Cがイケるなら、python でTypeHintsを使うと、割と読みやすくなると思います。コメント扱いなので見た目だけで実行時には何もしませんが、mypyとかのツールを使えば事前チェックもできるようになるので、ミスも減らせるかと。
Ruby や python は、充実したライブラリ群が容易に使えるのが肝だと思います。その辺、Cは極めて貧弱(C++は11/14/17と充実してきたけどまだまだ)なので、作業効率を考えるとCではできるだけやりたくないなぁ、と思ってます。Cの代替としてrustもオススメ。Core部分だけ使えばKBytes単位のプログラムサイズになります。Dはなんかマイナー確定状態ですが、C++でウンザリしたら代替になりえます。
ほえほえ
Re:プリプロは本来邪悪 (スコア:1)
俺も古い人間だがTurbo Pascalを常用してたので、begin end には違和感がない。
Re: (スコア:0)
俺も古い人間だがawkを常用してたので、begin endには違和感がない。
# なんか違う
# そしてほんとはむしろ常用してたのはperl
Re: (スコア:0)
＞古い人間だからN88BAISICアセンブラC言語なんだけど
機械語、FORTRAN、LISP、COBOLあたりが並ばないとは、実は新しい人ですね！
Re:プリプロは本来邪悪 (スコア:1)
> 機械語、FORTRAN、LISP、COBOLあたりが並ばないと
LISPではなく、PL/I でお願いします [ipa.go.jp]。
#機械語がCAP-Xだったら古い人、CASLだったら新しい人。
さすがにALGOLは知りません…
Re:プリプロは本来邪悪 (スコア:1)
わたしの大学時代、学生部長から学長になった先生は
PL/Iは使える、ALGOLは使ったことないが似たようなものだろ
と講義中の雑談であっさり片付けてました。FORTRANとCOBOLも使えるとの由。
LISPは当時の経済学分野ではまだまだ及びでなかったので名前が挙がっていない。
Re: (スコア:0)
機械語 c9
アセンブラ ret
Re: (スコア:0)
あなたと同じような経験をしてきたけれどPythonが一番簡単だと思うよ。
> プログラミング言語全部C言語っぽい文法にしたら世界中のIT幸せになれるだろ
これは流石に時代錯誤。
Re: (スコア:0)
関数型と比べたら Smalltalk だって、似たような構文で読めるんだし。
Re: (スコア:0)
ほかに非構造的な言語というと逐次処理的な古いBASICやステートマシン的なSNOBOLなどが有名どころ
Re: (スコア:0)
あんまりプリプロセッサという意識で使ってる人はいないと思うが。
Re:プリプロは本来邪悪 (スコア:1)
TypeScriptはコンパイラっぽい気がしているが
CoffeeScriptはプリプロセッサな印象がある
Re: (スコア:0)
コンパイラでもぷりぷせったでもなくてトランスパイらだと思う
Re: (スコア:0)
遙か昔はC++でさえC言語にトランスレートしてからコンパイルしていたものです
Re: (スコア:0)
自分的には実行時エラーのエラー発生場所の情報が変換前ソース基準になってくれるならコンパイラって感じですね。
Re: (スコア:0)
逆に、実行時エラーの発生位置が「特別な工夫をしなくても」ソースの行番号で求まる実行環境こそインタプリタであり、
「特別な工夫をしなくても」ソースとアウトプットのマッピング情報を出力出来る変換系こそプリプロセッサ的だと思う。
C/C++とかはソースとのマッピング情報を構文木の段階でも保持した上でデバッグ用メタ情報としてわざわざ別途出力し、
その上デバッガ上で実行時エラーの発生位置をトラップしてマッピング情報を解析した場合にしか行番号出ないのが元々だし。
そのくせはC/C++のプリプロセッサ部分は#LINEディレクティブを埋め込む位で楽勝に変換前行番号を埋め込めている。
altJSでも同じで単純な変換であればあるほど行番号のマッピング情報を作りやすいが、
がっつり構文解析して出力し直してると解析済みの状態から最適化その他の過程までずっと行番号保持するとかいう処理が必要になる。
Re: (スコア:0)
機械語を吐くのしかコンパイラと認めないってやつでしょ
彼らにとってはJavaやC#もインタプリタ言語
Re: (スコア:0)
機械語だけ派とVMまでOK派はあるべ。
まぁ高級言語を吐こうが機械語吐こうがトランスパイラ(トランスコンパイラ)も一応コンパイラの区分ではあるけどな。
ただ、字句解析から構文解析までして構文木なりなんなりから出力を吐いてないとコンパイラにはならないと思う。
CoffeeScriptはどの程度までやってるんだろう？
Re: (スコア:0)
＞プリプロは本来邪悪
Pro*Cのことですね。
Re: (スコア:0)
(ぼそ)Ratfor…