アカウント名:
パスワード:
ぼくは Lisp をやらないのですが、 Lisper は、C のソースも Lisp みたいな括弧のレイアウトで書こうとする 誘惑と常に戦っているのでしょうか?
ぼくは、年に数度、ごくたまに Emacs の設定ファイルをいじるとき、括弧のレイアウトを C ライクに書こうとする誘惑に負けてしまいます。
# でも、仕事でプログラムを書く人にとって、汚いソースというのは 切実な問題なんだろうなあ。
しばらく様子を見ていたんですが、 LISP 使いの方が出て来ませんね。 というわけで僭越ながら――あたし自身は基本的に主兵装 C/C++ なんですが、 一応 Common LISP を主に使用していた職場に三年半程居た事がありますので。
Lisper は、C のソースも Lisp みたいな括弧のレイアウトで書こうとする誘惑と常に戦っているのでしょうか?
少なくとも件の職場ではそういう傾向は無かったように思います。 もちろん[他人\ひと]の内心の誘惑まで判るわけではありませんが、 走り書きのコードでもそういった括弧の置き方をしたものは見た事がありません。
こちらは結構ありましたよ――あたしと同じく C/C++ が主言語の人の LISP ソースで。 ただそれ自体は別に見難いとは感じませんでした(あたしも C/C++ の頭だからかもしれませんが)。 それよりもむしろ、 progn の多用で手続き型言語風の処理ばかりが目立つのに違和感を感じていました。
数値計算を多用する巨大プロジェクトで、 Fotranから入ったプログラマが多くを占めるのは仕方ないんですが。 構造化というものが存在しないんです。
会社をやめるときに上司から不満は何かと聞かれて、 あのソースはあまりにもひどすぎますといったら、 たしかにそうだ、と肯定されてしまいました(笑)。
もしかして変数が全て大域変数だったりするのでしょうか? 実は15年程前にCOBOLプログラマの書いたコードの変数が全て大域変数で, 関数のパラメータが全く有りませんでした.
実は15年程前にCOBOLプログラマの書いたコードの変数が全て大域変数で, 関数のパラメータが全く有りませんでした.
# そしてこのコードが年始にはカットオーバー。 # さぁ、大丈夫かな?
#ifdef 言い訳 違う、ウチじゃないんだ。 コード書いた会社が逃げただけなんだ...。 #endif
構造化というものが存在しないんです。
私の狭い世間の範囲内において、COBOL プログラマよりは FORTRAN (や、PL/I) プログラマの方が真っ当な C のコードを書く確率が高いんですが。
# 元物理屋なんでそう思うだけかも。 # 量産型 COBOL 屋さんのコードはよう読まん...
んと、ようするに、 C の構文をあまり知らない、 というか、知ろうとしない人たちでした。
規模の大きなソフトウェアで、 全体的な設計は非常によくできていたのですが、 その分末端のモジュールのコーディングをするプログラマには、 それほどの知識を
いつものくせで、つい7カラムめから書き始めたり、それもインデントはFORTRANの美学に反するからと、全てのステートメントがビシっと7カラムにそろっていたり、小文字の変数名は何か気持ち悪いから、大文字しか使わなかったり、1行を72カラムまでしか使わなかったり、入力設計にも思わず80桁のカードを意識したり…
1行を72カラムまでしか使わなかったり
「解約お願いします」
# その著者は直後に干されたらしいので誌名は伏せておきます
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
Lisp みたいな C、C みたいな Lisp (スコア:1)
ぼくは Lisp をやらないのですが、 Lisper は、C のソースも Lisp みたいな括弧のレイアウトで書こうとする 誘惑と常に戦っているのでしょうか?
ぼくは、年に数度、ごくたまに Emacs の設定ファイルをいじるとき、括弧のレイアウトを C ライクに書こうとする誘惑に負けてしまいます。
# でも、仕事でプログラムを書く人にとって、汚いソースというのは 切実な問題なんだろうなあ。
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
TeXだけどPythonみたいなコード
若しくは
PythonだけどTeXみたいなコード
のどっちかが該当したりするのだろうか...いずれもキツイ気がしますが。
> 汚いソースというのは 切実な問題なんだろうなあ。
汚いといっても、いろいろありますが、shやPerlの$1みたいに数値に意味があるならともかく、命名規則hoge1 hoge2とか後に数字つけられると混乱の元ですね。少しでも意味を匂わせるくらいの名前くらいにして欲しい...tmpでもいいし(w)
私がC書くときは、構造体があってそれをどう料理するか、できるかを書いてワンセットします。外に晒したくない関数はstaticでおさえつけて、いかにもJavaとかPythonのなりそこないみたいになります。
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
>
>若しくは
>
> PythonだけどTeXみたいなコード
それはひどい…(;_;)
PerlだけどCみたいなコード、は書いたことありますが
上みたいな痛いのは書いたことないですよぅ。
# TeXだけどPythonみたいなコード、は書きたいけど書けない…
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
>>
>>若しくは
>>
>> PythonだけどTeXみたいなコード
>
>それはひどい…(;_;)
あは、悪い冗談でしたがお気に召さなかったようで(^^;
Pythonはエディタの縛りがないとやりにくいっすよね。
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
いえいえ :-)
> Pythonはエディタの縛りがないとやりにくいっすよね。
まあ今ごろ言語支援機能のないエディタで開発することもないですし、
読むことに重点を置いているPythonの仕様は個人的に結構好きです。
文法にインデントが含まれてるのが生理的に嫌!ってひとがいるのは知ってますけど…(^^;;;
汚く「も」書ける、と自称している言語で書かれた
どうしようもなく汚いソースを見てると胸がムカムカと…(ひひ
Re:Lisp みたいな C、C みたいな Lisp (スコア:1)
しばらく様子を見ていたんですが、 LISP 使いの方が出て来ませんね。 というわけで僭越ながら――あたし自身は基本的に主兵装 C/C++ なんですが、 一応 Common LISP を主に使用していた職場に三年半程居た事がありますので。
少なくとも件の職場ではそういう傾向は無かったように思います。 もちろん[他人\ひと]の内心の誘惑まで判るわけではありませんが、 走り書きのコードでもそういった括弧の置き方をしたものは見た事がありません。
こちらは結構ありましたよ――あたしと同じく C/C++ が主言語の人の LISP ソースで。 ただそれ自体は別に見難いとは感じませんでした(あたしも C/C++ の頭だからかもしれませんが)。 それよりもむしろ、 progn の多用で手続き型言語風の処理ばかりが目立つのに違和感を感じていました。
Fotran みたいな C。 (スコア:0)
数値計算を多用する巨大プロジェクトで、 Fotranから入ったプログラマが多くを占めるのは仕方ないんですが。 構造化というものが存在しないんです。
会社をやめるときに上司から不満は何かと聞かれて、 あのソースはあまりにもひどすぎますといったら、 たしかにそうだ、と肯定されてしまいました(笑)。
Re:Fotran みたいな C。 (スコア:1)
もしかして変数が全て大域変数だったりするのでしょうか? 実は15年程前にCOBOLプログラマの書いたコードの変数が全て大域変数で, 関数のパラメータが全く有りませんでした.
COBOL みたいな C (Re:Fotran みたいな C。) (スコア:1)
# そしてこのコードが年始にはカットオーバー。
# さぁ、大丈夫かな?
#ifdef 言い訳
違う、ウチじゃないんだ。 コード書いた会社が逃げただけなんだ...。
#endif
Re:COBOL みたいな C (Re:Fotran みたいな C。) (スコア:0)
数年前にたまたまお知り合いになった専門学校卒のプログラマの人のノートを見せてもらったことがありますが、COBOLのプログラムをCの文法っぽく書き換えてみました、な代物を授業で教えられたと思しき跡が残っておりました。
察するにCOBOLを教えるのがメインの学校だったんでしょう。流行ってる(?)からCにも触れとかなきゃって慌てて授業を組んだ感じ?
その
COBOLそのもの (Re:COBOL みたいな C) (スコア:1)
ええ、GOTOでびゅんびゅん飛んでましたとも。
その会社の社員に聞いてみたら、構造化と言う言葉すら分かってないようでした。(昔の話とはいえ10年以内)
コードをサブルーチン化してみたら、「読めない」の一言でバッサリ。
それ以来、COBOLはあまり書かせてもらえなくなりましたね。
いまはOpenCOBOLでもObject指向をサポートするようになりましたが、そんな彼らはいまだにVBのプログラムが読めないと文句ばかり言っているようです。
がんばれコボラー!言語の違い云々で文句を言ってる事自体が間違いだって早く気づいて!!(笑)
Fotran みたいな? COBOL (スコア:1)
未だいるのか、こんなん流派は?
BASIC みたいな C++ (スコア:0)
(正確にはちょっと違うが、事実上)
# 冗談でなく有名メーカの命運をかけたプロジェクトだったのだ
Re:Fotran みたいな C。 (スコア:1)
私の狭い世間の範囲内において、COBOL プログラマよりは FORTRAN (や、PL/I) プログラマの方が真っ当な C のコードを書く確率が高いんですが。
# 元物理屋なんでそう思うだけかも。
# 量産型 COBOL 屋さんのコードはよう読まん...
Re:Fotran みたいな C。 (スコア:0)
んと、ようするに、 C の構文をあまり知らない、 というか、知ろうとしない人たちでした。
規模の大きなソフトウェアで、 全体的な設計は非常によくできていたのですが、 その分末端のモジュールのコーディングをするプログラマには、 それほどの知識を
Re:Fotran みたいな C。 (スコア:1)
いつものくせで、つい7カラムめから書き始めたり、それもインデントはFORTRANの美学に反するからと、全てのステートメントがビシっと7カラムにそろっていたり、小文字の変数名は何か気持ち悪いから、大文字しか使わなかったり、1行を72カラムまでしか使わなかったり、入力設計にも思わず80桁のカードを意識したり…
Re:Fotran みたいな C。 (スコア:1)
Re:Fotran みたいな C。 (スコア:0)
一画面の横幅が200桁くらいなんですきっと。
Re:Fotran みたいな C。 (スコア:1)
ラインプリンタイメージ(132桁くらい)なのでは?
でもテープイメージ(無制限)だったりして...
その場合は,UNIXのファイルのイメージ(
単純なバイト列)と相性がいいかも.
Re:Fotran みたいな C。 (スコア:0)
Re:Lisp みたいな C、C みたいな Lisp (スコア:0)
○○みたいなC (スコア:0)
#define end }
Re:○○みたいなC (スコア:1)
Re:○○みたいなC (スコア:1)
こことかね :D
Re:○○みたいなC (スコア:1)
OKがでた時はマジでほっとしました。
Re:○○みたいなC (スコア:0)
創刊号が届いたので、早速読んでみると、いきなりそういうソースが出てきました。
速攻で裏表紙にある日経BPの電話番号を確認し、受話器を取り、その番号を回しました。
「解約お願いします」
# その著者は直後に干されたらしいので誌名は伏せておきます