Кто знает объективные критерии качества языка программирования, или хотя бы синтаксиса?

>объективные критерии оценки. (собственно, их для ЯП я и спрашиваю)

в общем случае их нет. и не может быть. может, ты всё-таки укажешь область применения ЯП? а то SQL не очень удобно применять для синтаксического анализа, а Perl не очень подходит для описания запросов

> не очень удобно

> не очень подходит

Теперь осталось формализовать эти две вещи. Вероятно, это пытались сделать, писали статьи на эту тему?

> а то SQL не очень удобно применять для синтаксического анализа, а Perl не очень подходит для описания запросов

ОК, моя точка зрения -- потому, что они не поддерживают нужные для этого абстракции.

> в общем случае их нет. и не может быть.

Уже боюсь!

>Вероятно, это пытались сделать

что именно? проектировать язык под конкретную задачу? да. делать универсальный язык? тоже да. первое получалось хорошо, второе неосуществимо в принципе

>потому, что они не поддерживают нужные для этого абстракции

семантика у них разная. какие нафиг абстракции?

>Уже боюсь!

лучше бы думал, честное слово

Второй и пятый пункты вычеркнуть нахрен.

> что именно? проектировать язык под конкретную задачу? да. делать универсальный язык? тоже да. первое получалось хорошо, второе неосуществимо в принципе

Неосуществимо в принципе? Ну так выпиши необходимые условия осуществления, и докажи их совместную противоречивость, хотя бы на пальцах. Ну или дай ссылку на такую статью.

Можешь даже доказательство на пальцах не приводить, а только выписать условия :-)

Теперь зайдем с другой стороны -- аргументы в пользу существования универсального языка.

1. Недостатки существующих языков программирования достаточно обозримы и достаточно легко формализуемы.

2. В основном, эти недостатки сводятся к "не хватает", "не проверяется".

3. Недостаток, связанный с избыточной сложность языков программирования появляется в основном в том случае, когда языки делают для поддержки старого синтаксиса (и старых паттернов).

4. Сложность изучения сложного языка можно снизить, если изучать его подмножество, достаточное для (быдло)использования существующих библиотек, а не создания новых (где требуется высокий уровень абстракций).

5. Язык научного общения достаточно стабилен.

> Второй и пятый пункты вычеркнуть нахрен.

Даааа, второй пункт пришел к нам из 60-х годов, когда подсчитывали милисекунды процессора :-)

Насчет пятого -- он нужен, но в облегченной формулировке -- насколько легко овладеть языком до уровня использования его в *приложениях*, а не *библиотеках*.

>Второй и пятый пункты вычеркнуть нахрен.

тогда вычёркивай все, что уж там. или подходить к вопросу серъёзно, или не подходить никак

> тогда вычёркивай все, что уж там. или подходить к вопросу серъёзно, или не подходить никак

1,3,4 пункты имеют смысл. 2 бессмысленен.

5 стоит разделить на 5-small-scale-development 5-large-scale-development.

>1. Недостатки существующих языков программирования достаточно обозримы и достаточно легко формализуемы.

обозри. формализуй. подбей табличку. вот тогда и поговорим

>3. Недостаток, связанный с избыточной сложность языков программирования появляется в основном в том случае, когда языки делают для поддержки старого синтаксиса (и старых паттернов).

неочевидно и голословно. формальные доказательства будут?

>5. Язык научного общения достаточно стабилен.

которой из наук? тезаурус в студию, пожалуйста

5-large-scale-development почти бессмысленен -- хочешь писать большой софт -- придется много поучиться.

>1,3,4 пункты имеют смысл. 2 бессмысленен.

научность подхода поражает воображение

>Даааа, второй пункт пришел к нам из 60-х годов, когда подсчитывали милисекунды процессора :-)

В 60е и слова-то такого не знали - "миллисекунды" :)

В самом деле, какое значение может иметь время компиляции? Конечно, если не отлаживать методом тыка:

while(упало) { исправить буковку; скомпилировать; запустить; }

Пятый пунк не имеет значения от того, что сложность освоения этих language features пренебрежима мала в сравнении со сложностью освоения библиотеки. Я уж не говорю об общем обучении программированию.

>но в облегченной формулировке

это задачу свою ты решаешь в облегчённой формулировке. пользователь может выбрать любые критерии оценки языка, as long as they are bla~w такие же как у тебя

а разница между тобой, и приведённой мной статьёй Карделли заключается в том, что он хотя бы как-то свои критерии обосновывает. ты же сплошь голословен. что толку было создавать подобный топик, если тебе нечего сказать по существу?

> обозри. формализуй. подбей табличку.

в процессе :-) правда, опять хотелось СНАЧАЛА бы почитать чужое на эту тему

>> Недостаток, связанный с избыточной сложность языков программирования появляется в основном в том случае, когда языки делают для поддержки старого синтаксиса (и старых паттернов).

> неочевидно и голословно. формальные доказательства будут?

Сравни Хаскель и С++. Первый намного проще второго (если брать в расчет сам язык, а не необходимость извращений с функциональными структурами данных, которого могло бы и не быть), при этом местами мощнее и мало где слабее. Посмотри, откуда взялась избыточная сложность с++ по сравнению с хаскелем.

>тогда вычёркивай все, что уж там. или подходить к вопросу серъёзно, или не подходить никак

Окей. Серьёзно.

1. Economy of execution. How fast does a program run?

2. Economy of compilation. How long does it take to go from sources to executables?

3. Economy of small-scale development. How hard must an individual programmer work?

4. Economy of large-scale development. How hard must a team of programmers work?

5. Economy of language features. How hard is it to learn or use a programming language?

Весовые коэффициенты:

1: 1,0

2: 0,0

3: 0,85

4: 1,0

5: 0,1

> В самом деле, какое значение может иметь время компиляции?

Представь, что программа компилируется час после каждого исправления.

> сложность освоения этих language features пренебрежима мала в сравнении со сложностью освоения библиотеки

Зависит от языка и от библиотеки.

>Пятый пунк не имеет значения от того, что сложность освоения этих language features пренебрежима мала в сравнении со сложностью освоения библиотеки

а ты никогда не думал, что может быть наоборот? что одно дело - C++ + boost.join, и другое дело - Join-calculus (который ЯП)

>какое значение может иметь время компиляции?

большое. особенно если это JIT-компиляция, или любая динамическая верификация

> а разница между тобой, и приведённой мной статьёй Карделли заключается в том, что он хотя бы как-то свои критерии обосновывает. ты же сплошь голословен. что толку было создавать подобный топик, если тебе нечего сказать по существу?

Мне есть что сказать по существу. Но это долго, может распугать весь народ, и главное -- умный любит учиться (вторую половину этой поговорки лучше не цитировать -- она может привести к неверным выводм).

Поэтому я формулирую свои мысли без доказательств, в надежде, что кто-то начнет их аргументированно (хотя бы на пальцах или собственных ощущениях) опровергать -- тогда мне будет о чем подумать.

>Сравни Хаскель и С++

это не доказательство - это сравнение на пальцах двух ЯП. у Haskell, кстати, история ничуть не беднее C++, а ФП не особо моложе процедурного стиля

>функциональными структурами данных, которого могло бы и не быть

а с этого места поподробней, пожалуйста. ты улучшил достижения Окасаки в сфере персистентных структур данных? :)

>Мне есть что сказать по существу

просим! просим!

>может распугать весь народ

на ЛОРе народ закалённый, всякое повидавший

>умный любит учиться

а глупый - саночки возить? я не особо силён в поговорках :(

>Представь, что программа компилируется час после каждого исправления.

Очевидно, что-то не так с процессом разработки. Может модульности недостаёт, может сервак линейки надо с билд-сервера удалить.

>Зависит от языка и от библиотеки.

Ну, да. Но таких суперзапаренных языков не так много. Хотя, пожалй я погорячился.

1. Economy of execution. How fast does a program run?

Этот пункт опять надо разбить на 3.

1А. Насколько не сильно медленно работает прототип программы (написанный на том же самом универсальном языке)?

1В. Насколько быстро работает прототип, в который добавили хинты и переписали небольшую часть кода?

1С. Насколько много пришлось переписывать?

>большое. особенно если это JIT-компиляция, или любая динамическая верификация

Это уже производительность времени исполнения. Другой пункт.

>> Представь, что программа компилируется час после каждого исправления.

> Очевидно, что-то не так с процессом разработки.

Бгг. Я тебе описал ситуацию с PL/I на ЕС ЭВМ :) Просто язык был сложноват для машинки. Еще можно вспомнить Turbo Vision для Си++ - тоже раздражало медленной компиляцией.

Для всех языков чем лучше 1В тем больше 1С.

>Это уже производительность времени исполнения. Другой пункт.

нет. если у языка есть вариант реализации с JIT-компиляцией, то учитываться будет именно пункт два. эффективность копиляции (насколько быстро будет работать результирующий код) - это к первому пункту, а здесь подразумевается, например, выбор грамматики для синтаксиса

>1А. Насколько не сильно медленно работает прототип программы (написанный на том же самом универсальном языке)?

а тебе не кажется, что это сильно зависит от того, что там в этом прототипе есть? или тебя средняя температура по больнице интересует (вроде shootout'а)?

>>Мне есть что сказать по существу

> просим! просим!

Странно ты просишь. Никто (и ты тоже) не обратил внимание на ключевые слова "оперирование абстракциями". Впрочем, на full-size статью и доказательства того же размаха здесь не рассчитывай, т.к. меня интересует на статьяписание, а проектирование языка в соответствии с обоснованными на пальцах соображениями.

>Бгг. Я тебе описал ситуацию с PL/I на ЕС ЭВМ

А в час времени компиляции входит дорога до ВЦ, очередь на машинное время, пожаротушения там всякие?

>не обратил внимание на ключевые слова "оперирование абстракциями"

потому что они ничего не означают. с не меньшим успехом ты мог бы написать "жонглирование крабами"

>проектирование языка в соответствии с обоснованными на пальцах соображениями

а почему не попробовать нормально спроектировать, не на пальцах? семантику расписать, систему типов опять же, грамматику прикрутить. в качестве proof-of-concept интерпретатор какой забабахать. и тут вот уже предлагать обсудить то, что получилось

а то таких, которые вот так "на пальцах" - много; а толку как не было, так и нет

> А в час времени компиляции входит дорога до ВЦ, очередь на машинное время

Нет, там был теминальный класс.

> нет. если у языка есть вариант реализации с JIT-компиляцией, то учитываться будет именно пункт два.

JIT-компиляция != компиляция

Например, на яве дженерики дают инфу, которую компилятор *проверяет*, а потом она полностью стирается, и JIT-компилятор ее совсем не видит.

JIT-компилятор вообще много чего может не видеть.

>В. возможность цеплять чужие либы.

кстати, ты обратного не учёл. стандартизованный ABI - ничуть не меньший плюс, чем хороший FFI

>JIT-компиляция != компиляция

оголтело, например. и что?

>JIT-компилятор вообще много чего может не видеть

именно потому, что его авторы задумывались над вторым пунктом той шкалы. и сделали выводы, которых ты делать упорно не хочешь

> а почему не попробовать нормально спроектировать, не на пальцах? семантику расписать, систему типов опять же, грамматику прикрутить. в качестве proof-of-concept интерпретатор какой забабахать. и тут вот уже предлагать обсудить то, что получилось

> а то таких, которые вот так "на пальцах" - много; а толку как не было, так и нет

Толк будет, не беспокойся. Но порядок д.б. иным. Сначала обсуждаются критерии качества, потом проектируется прототип. Не наоборот.

З.Ы. да, у меня есть свой список критериев некачественности. Но опять -- умный...

>Толк будет, не беспокойся

ты меня успокоил :) кстати, с какими аналогичными проектами/разработками ты знаком?

>> А в час времени компиляции входит дорога до ВЦ, очередь на машинное время

> Нет, там был теминальный класс.

А там случайно не те машинки стояли, которые американцы выбросили на свалку в упомянутых мной 60-х годах?

А если серьезно, то компилятор *можно* поставить на колени, реализуя нужные фичи. Вот пример: http://www.artima.com/cppsource/codefeatures.html

>> не обратил внимание на ключевые слова "оперирование абстракциями"

> потому что они ничего не означают. с не меньшим успехом ты мог бы написать "жонглирование крабами"

У тебя образование хоть высшее? У меня просто слов нет.

Посмотри на template<class T> T min(T x, T y) { return x<y?x:y; }

Подумай, что здесь абстракции.

Даже сишный оператор ptr++ есть пример абстракции. Он абстрагируется от конкретного типа данных, и зависит не от типа данных, а от sizeof.

> ты меня успокоил :) кстати, с какими аналогичными проектами/разработками ты знаком?

Давай поставим вопрос по другому -- с какими разработками ты мне посоветуешь ознакомиться, зачем, и до какой глубины?

>> JIT-компилятор вообще много чего может не видеть

> именно потому, что его авторы задумывались над вторым пунктом той шкалы. и сделали выводы, которых ты делать упорно не хочешь

И получили на выходе что? Эклипс компилиться чуть побыстрее, чем ядро (даже допустим в 4 раза -- это все равно чуть), а ява как была тормозом, так и осталась.

Так что приоритет п.2 очень маленький, я даже предположу, что в случае поддержки должных абстракций компилятором (а не кривое моделирование, как по приведенной мной ссылке) сделает настоящую (не JIT) компиляцию достаточной по скорости.

>У меня просто слов нет.

ну, это твои личные половые трудности :)

>Подумай, что здесь абстракции.

согласно определению астракции - всё

>Даже сишный оператор ptr++ есть пример абстракции

и тебя не смущает, что ты оперируешь термином, подходящем для всего подряд?

>И получили на выходе что?

значит плохо получилось. если о нём вообще не думать - получится ещё хуже

>в случае поддержки должных абстракций компилятором

извини, которая часть компилятора должна "поддерживать должные абстракции"?

> а с этого места поподробней, пожалуйста. ты улучшил достижения Окасаки в сфере персистентных структур данных? :)

Зачем? Кому надо, пусть те и улучшают. Мне достаточно этого. Кстати, пиратская книжка Окасаки в djvu (220 стр.) у меня есть, не только общедоступная пдф-ка.

>Давай поставим вопрос по другому -- с какими разработками ты мне посоветуешь ознакомиться, зачем, и до какой глубины?

с любыми, относящимися к твоей теме. чтобы не изобретать велосипедов с квадратными колёсами. до упора

>Кстати, пиратская книжка Окасаки в djvu (220 стр.) у меня есть, не только общедоступная пдф-ка.

круто. у меня она есть в бумаге. и что? :)

> и тебя не смущает, что ты оперируешь термином, подходящем для всего подряд?

*именно* такой термин должен использоваться для описания универсального ЯП.

> согласно определению астракции - всё

Таки придется дать определение абстракции...

Абстра́кция, или абстра́кт, (от лат. abstractio — «отвлечение», введённого Боэцием как перевод греческого термина, употреблявшегося Аристотелем) — мысленное отвлечение, обособление от тех или иных сторон, свойств или связей предметов или явлений для выделения существенных признаков.

В примере min мы абстрагируемся от всех сторон типа Т, за исключением того, что он имеет оператор >, который является существенным признаком.

И кто-то этого не знает?

> с любыми, относящимися к твоей теме. чтобы не изобретать велосипедов с квадратными колёсами. до упора

C любыми и до упора займет слишком много времени :-)