アカウント名:
パスワード:
プログラミング言語の文法は所詮UIでしょう。UIが実作業において生産性に影響を及ぼすのは間違いないし、UI談義がそれ自身気楽で楽しいことも否定しませんが、現代のプログラミング言語処理系として大事なのはその「UI」を介して表された抽象的なモデル(オブジェクトであれ、論理規則であれ)を高速に実行するための最適化の能力を備えることでしょう。(あるいはそういう最適化に有用なヒントを提供しつつ、かつ記述能力を高めるような抽象化方式の発見。)
(UIが大事な言語ももちろんありましょう。例えばスクリプト言語はしばしば「糊(グルー)」と評さ
>現代(中略)大事(中略)高速に実行するための最適化の能力を備えること
そうですか?RubyやJavaScriptみたいなLispの末裔、つまりUIをいかに整理するかに重点をおいた言語が最近は注目され主流になってるような気がする。むしろ速度はインフラ任せで。
コレにしても、バックトラックつきの「重い」言語が「重い」処理狙いの言語であるとは、もともと思いにくいのですけども…
>スクリプト言語はしばしば「糊(グルー)」と評されるようにプログラム相互間、人-プログラム間のインターフェースを提供するものなので
もともとScript言語をつかまえてグルーという呼び方には引っかかりを
もともとScript言語をつかまえてグルーという呼び方には引っかかりを覚えています。それいったらあらゆる言語がプログラム間やマンマシン間を繋ぐグルーですから。繋がないならそれは言語ではない。(というか言語ってもともとInterfaceでしょ)
ここでは機能を利用するための最低限のインターフェース(しばしばテキストベースの)を備えた既存プログラム間をつなぐ。それもしばしば運用の場において、ad-hocでもいいし、多少性能が落ちてもいいから手早くつなぐことを主要な目的とした言語を想定しています。狙いの違い、重視するところの違いによる言語の設計方針の違いを考えたいわけなので、インターフェースするんだからみな同じでしょという立場では一般的すぎると思います。(グルーの語感もボルトや溶接といったより手間がかかるけれど堅固な構造の代わりにボンドでペタリと手軽にというところから取られているように思います。くっつけるんだからなんでも同じでしょとは言えないわけで適材適所が求められます。)
狭い意味で糊という言葉を使うのだとしても、じゃあScript言語で「アプリケーション(のコアロジック)」を書かないのか?といえば、(それこそ速度重視な一部場面を除けば)そんなこたぁ無いわけです今時は。コアロジックじゃなく速度が必要な一部…ドライバ的な…を低級言語に振ることは有りますが。
「アプリケーション」自身が多様ですからね。ゴリゴリ数値計算、カリカリ組み込み機器制御、サクサク伝票処理、etc.ではそれぞれ求められるものが違います。それにあった言語も当然違うでしょう。
Script言語といえども近頃は簡易言語というわけでもないのは確かで、基本的な制御機構やデータ構造は備えており(というかしばしば結構リッチな制御機構やデータ構造を基本構文や基本データ型として備えている)、書くだけなら理論上は大概のものは書けるでしょう。でもそれで十分な性能(実行性能、堅牢性、メンテナンスしやすさ、再利用性、相互運用性などなど)が見合ったコストで達成できるかどうかは別の問題です。
もちろんいずれも程度問題なのですが、
まさにその程度問題を問題にしたいわけなので皆一緒でしょというわけにはいきません。
少なくともインフラのほうは年々高速化してるため、「言語のほうで速度を稼ぐ必要性」は年々減っているのも事実。
冒頭にも書いたように人口ベースで関心を持つ人の割合が減ってるのはおそらくそうなのでしょうが、インフラを作らなくて良くなったわけではありませんし、ここで話題になっている言語は大規模科学技術計算という、どっちかといえばインフラ寄りの要求がある種類のアプリケーションの記述をターゲットの1つに想定していると開発者が言ってますので。
#もしこれが手軽にバックトラックが書けるところに焦点を置いていると書かれていれば#パフォーマンスだ最適化だと大人げない無粋なコメントは私もしなかったと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
大事なのは最適化 (スコア:3, すばらしい洞察)
プログラミング言語の文法は所詮UIでしょう。
UIが実作業において生産性に影響を及ぼすのは間違いないし、UI談義がそれ自身気楽で楽しいことも否定しませんが、現代のプログラミング言語処理系として大事なのはその「UI」を介して表された抽象的なモデル(オブジェクトであれ、論理規則であれ)を高速に実行するための最適化の能力を備えることでしょう。(あるいはそういう最適化に有用なヒントを提供しつつ、かつ記述能力を高めるような抽象化方式の発見。)
(UIが大事な言語ももちろんありましょう。例えばスクリプト言語はしばしば「糊(グルー)」と評さ
Re: (スコア:0)
>現代(中略)大事(中略)高速に実行するための最適化の能力を備えること
そうですか?
RubyやJavaScriptみたいなLispの末裔、つまりUIをいかに整理するかに重点をおいた言語が
最近は注目され主流になってるような気がする。
むしろ速度はインフラ任せで。
コレにしても、バックトラックつきの「重い」言語が
「重い」処理狙いの言語であるとは、
もともと思いにくいのですけども…
>スクリプト言語はしばしば「糊(グルー)」と評されるようにプログラム相互間、人-プログラム間のインターフェースを提供するものなので
もともとScript言語をつかまえてグルーという呼び方には引っかかりを
スクリプト言語とグルー (スコア:1)
>スクリプト言語はしばしば「糊(グルー)」と評されるようにプログラム相互間、人-プログラム間のインターフェースを提供するものなので
もともとScript言語をつかまえてグルーという呼び方には引っかかりを覚えています。
それいったらあらゆる言語がプログラム間やマンマシン間を繋ぐグルーですから。
繋がないならそれは言語ではない。
(というか言語ってもともとInterfaceでしょ)
ここでは機能を利用するための最低限のインターフェース(しばしばテキストベースの)を備えた既存プログラム間をつなぐ。
それもしばしば運用の場において、ad-hocでもいいし、多少性能が落ちてもいいから手早くつなぐことを主要な目的とした言語を想定しています。
狙いの違い、重視するところの違いによる言語の設計方針の違いを考えたいわけなので、インターフェースするんだからみな同じでしょという立場では一般的すぎると思います。
(グルーの語感もボルトや溶接といったより手間がかかるけれど堅固な構造の代わりにボンドでペタリと手軽にというところから取られているように思います。くっつけるんだからなんでも同じでしょとは言えないわけで適材適所が求められます。)
狭い意味で糊という言葉を使うのだとしても、
じゃあScript言語で「アプリケーション(のコアロジック)」を書かないのか?といえば、
(それこそ速度重視な一部場面を除けば)そんなこたぁ無いわけです今時は。
コアロジックじゃなく速度が必要な一部…ドライバ的な…を低級言語に振ることは有りますが。
「アプリケーション」自身が多様ですからね。ゴリゴリ数値計算、カリカリ組み込み機器制御、サクサク伝票処理、etc.ではそれぞれ求められるものが違います。それにあった言語も当然違うでしょう。
Script言語といえども近頃は簡易言語というわけでもないのは確かで、基本的な制御機構やデータ構造は備えており(というかしばしば結構リッチな制御機構やデータ構造を基本構文や基本データ型として備えている)、書くだけなら理論上は大概のものは書けるでしょう。でもそれで十分な性能(実行性能、堅牢性、メンテナンスしやすさ、再利用性、相互運用性などなど)が見合ったコストで達成できるかどうかは別の問題です。
もちろんいずれも程度問題なのですが、
まさにその程度問題を問題にしたいわけなので皆一緒でしょというわけにはいきません。
少なくともインフラのほうは年々高速化してるため、
「言語のほうで速度を稼ぐ必要性」は年々減っているのも事実。
冒頭にも書いたように人口ベースで関心を持つ人の割合が減ってるのはおそらくそうなのでしょうが、インフラを作らなくて良くなったわけではありませんし、ここで話題になっている言語は大規模科学技術計算という、どっちかといえばインフラ寄りの要求がある種類のアプリケーションの記述をターゲットの1つに想定していると開発者が言ってますので。
#もしこれが手軽にバックトラックが書けるところに焦点を置いていると書かれていれば
#パフォーマンスだ最適化だと大人げない無粋なコメントは私もしなかったと思います。