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

А экономические критерии являются объективными?

> А экономические критерии являются объективными?

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

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

красота кода ещё зависит от кодера, ага?

А так говнокодер легко превратит в говно вашу любимую яву/си/пайтон/баш/вотевеар.

Объективные: возможности, качество компилятора, выходная производительность кода одинаковой сложности

Субъективные: всё остальное

Правильный ответ: С/С++ лучший (и не надо ныть про сборщики мусора и прочую ересь, при наличии прямых рук это лучший инструмент)

> Правильный ответ: С/С++ лучший

Вы уж определитесь, C или C++...

> Вы уж определитесь, C или C++

:) +1

> (и не надо ныть про сборщики мусора и прочую ересь, при наличии прямых рук это лучший инструмент)

Мне кажется, что сборшик мусора можно аккуратно прикрутить к С++. Т.е. не нарушая возможности оперировать не-gc-указателями.

качество - совокупность потребительских свойств товара
(критерии качества - разновидность масла масленного)

т.е. просто нужно определить по каким свойствам оценить языки и эти свойства важны для тех кто им пользуется

разумеется они субъективны, так как важны для субъектов(потребителей)

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

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

p.s. это не для диплома случаем?

> p.s. это не для диплома случаем?

нет. захотелось небольшой такой syntax and type aware preprocessor написать с выхлопом в С++ (или даже С, но это не проще, а сложнее).

> количество ключевых слов или групп ключевых слов

Это как раз находится гуглем.

> несколько алгоритмов и кол-во строк, которое понадобится для закодирования, ...

Для одноразовых программ (а-ля однострочник на перле) это критерий.

Для программ посерьезнее... я боюсь всех распугать своими разговорами про абстракции :-)

Ну и еще... я все жду, как кто-нить скажет например "в синтаксисе важны 1. ключевые слова и 2. возможность использовать слова в правильном порядке, т.е. не something.moveTo(new_position), а move( something to=new_position)".

>возможность использовать слова в правильном порядке, т.е. не something.moveTo(new_position), а move( something to=new_position)".

Мастер Йода с тобой несогласен тут. Тогда самый реальный это сравнить формальные языки с естественными и выявить какой естественнее :)

>не something.moveTo(new_position)

Правильно. В нормальных языках будет:

new_position something move-to

:)

читайте книги, в них рулез:
http://lucacardelli.name/Papers/BadPropertiesOfOO.html

Consider the following (informal) metrics:

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? 

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

> new_position something move-to

Вопрос не в *конкретном* порядке слов, а в том, что язык его не должен навязывать.

(new_position, something).move_to()

Хотя я предпочел бы, если уж...

something.move_to(new_position).rotate_by(45)

Ну и фортовская странная запись -- это отнюдь не достостоинства. Достоинства -- это например x [ 123 456 + SOMETHING ] * ( если я скобки не перепутал )

Критерии не связанные с языком непосредственно: 1) Комьюнити (адекватное, многочисленное) 2) Платформа для разработки - IDE, степень надежности либ, документированность и тп.

Связанные с языком: 1) Статическая типизация 2) Возможность "расширить" если чего-то не будет хватать 3) Большая степень защищенности от дурака.

ЗЫ. Итого: 1 место присуждается Java (с расширениями туго - горы XML, но тем не менее) 2 место присуждается С++ (защиту от дурака можно прикрутить при желании)

ЗЗЫ. Однако есть критерий, который перекрывает все остальные - количество фана, которое получаешь при написании=))))) Приятно писать код - язык хорош. Сплошные подводные камни, матюки, язык плох (ну или не дорос до него просто, в любом случае он не для тебя)

> читайте книги, в них рулез:

Ага, о том и спрашиваю. На сайте у него есть интересные заголовки. В самой статье в пдф-ке уж больно совсем мало.

>Ага, о том и спрашиваю. На сайте у него есть интересные заголовки. В самой статье в пдф-ке уж больно совсем мало.

ну это популярная статья всё-таки; серъёзно он про ОО пишет, как-никак. ну и про биологию

> Связанные с языком: 1) Статическая типизация

и local type inference обязательно

> 2) Возможность "расширить" если чего-то не будет хватать

мне тут с++ больше всего жмет, а лисповский подход к расширению (макросы) считаю неправильным

> 3) Большая степень защищенности от дурака.

Тут есть куча сторон:

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

- возможность запретить опасные фичи (например, приводящие к динамической аллокации памяти)

- понятные сообщения об ошибках

> ну это популярная статья всё-таки; серъёзно он про ОО пишет, как-никак.

Ну это типично для исследователя. "А давай-ка я подробно изучу... ООП". А зачем ООП нужно (т.е. те самые критерии качества языка программирования), и может вовсе не ООП надо подробно изучать, а effect system?

>> Связанные с языком: 1) Статическая типизация

>и local type inference обязательно

если кто-то добавит в замечательный event-oriented язык Tcl статическую типизацию, он перестанет быть таким замечательным; то же самое, в общем-то, про Erlang. с подобным подходом выведения "абсолютных критериев" для "универсального языка" (область применения ты не указываешь, так что считаю что она не выражена) полезность твоих действий стремится к нулю

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

к языку это мало относится, на самом деле. в такой трактовке это можно сделать в любом языке с хоть какой-то поддержкой абстракции данных и процедур

>А зачем ООП нужно (т.е. те самые критерии качества языка программирования), и может вовсе не ООП надо подробно изучать, а effect system?

ты статьи его почитай, что ли, для начала. умник нашёлся

Можешь ещё сравнивать языки с основными моделями вычислений: машиной Поста. машиной Тьюринга, Диофантовами выражениями и рекурсивными функциями

> ты статьи его почитай, что ли, для начала. умник нашёлся

Да, умник, и да, нашелся.

Кстати, насчет прошлого твоего несогласия со мной -- вот тебе ссылка http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf "Verifiable Functional Purity in Java". Я считал это настолько тривиальным, что и доказательство можно и не приводить, хотя детали там почитать интересно. Там они еще парочку дополнительных свойств предлагают.

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

> Можешь ещё сравнивать языки с основными моделями вычислений:

Я правда не курсовик делаю :-)

> Тогда самый реальный это сравнить формальные языки с естественными и выявить какой естественнее :)

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

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

Пример маленького "плохого кода" можно? При условии, что local type inference у нас есть.

>в правильном порядке, т.е. не something.moveTo(new_position), а move( something to=new_position)"

Это субъективно. Слыхал, что китайцам привычнее первый вариант. При попытке объективизации число китайцев определит "правильным" именно его.

> Это субъективно. Слыхал, что китайцам привычнее первый вариант. При попытке объективизации число китайцев определит "правильным" именно его.

Тогда это называется "объективно зависит от естественного языка читателя". Ну и повторюсь -- язык программирования не должен навязывать этот порядок.

>детали там почитать интересно

почитаю, хотя вряд ли там есть что-то большее, чем в том же Slice

>доказательства мне не интересны

жаль

>Пример маленького "плохого кода" можно? При условии, что local type inference у нас есть.

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

>язык программирования не должен навязывать этот порядок

ты же вроде выступал против вариабельного синтаксиса?

>ты же вроде выступал против вариабельного синтаксиса?

Луна в каком тогда знаке зодиака была^W^W^W^W^W^W^W В этом треде или раньше?

Синтаксис может быть вариабельным по-разному.

> event-oriented язык Tcl

Аааахренеть... "event-oriented язык" O_o

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

1. гетерогенный список значений -- на плюсах пишется элементарно, я вот даже den73 работающую прогу постил. На яве м.б. проблемы, ибо боксинг. На С# не знаю, но дженерики там по слухам разные для значений и не-значений.

2. endianess -- а нельзя в результате просто переставить байты? Если нельзя, то рефлекшен и где подвох? (в плюсах в стандарте рефлекшена нет, но есть на основе gccxml)

______________________________

Ну и главное -- я-то просил пример кода на тикле, который вдруг испортиться, если ввести типизацию в тикль.

> Аааахренеть... "event-oriented язык"

гугль http://www.google.com/search?q=event-oriented мне дает первый две ссылки не на программирование, а третью -- на tcl вику.

>1. гетерогенный список значений -- на плюсах пишется элементарно

>2. endianess -- а нельзя в результате просто переставить байты?

можно. я нигде не говорил что нельзя. но станет намного менее удобно,
вот в чём беда

>если ввести типизацию в тикль

динамическая типизация там есть

>просил пример кода на тикле, который вдруг испортится

set str1 [list $messageLength]
set str2 [list [PF MTPTYPE_MOSTMessage] \
               [PF MTP_SUBTYPE_UNUSED] \
               0 0 \
               $fblock \
               $instance]
set str3 [list $fid]
set str4 [list $optype \
               [PF TRANS_TX_CONTROL_CHANNEL]]
                 
set res [binary format S1c6S1c2c[llength $data] $str1 $str2 $str3 $str4 $data]

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

>Аааахренеть... "event-oriented язык" O_o

http://en.wikipedia.org/wiki/Event-driven_programming

http://en.wikipedia.org/wiki/Comparison_of_programming_languages:
Tcl: imperative, procedural, event-driven

>В этом треде или раньше?

раньше

>Синтаксис может быть вариабельным по-разному.

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

> http://en.wikipedia.org/wiki/Comparison_of_programming_languages

Так бы и помер, не узнав, что generic, multithreaded, и reflective - это парадигмы %)

И еще, бл*, tacit!!111 Википедия отожгла напалмом :D

>generic, multithreaded, и reflective - это парадигмы %)

*с олимпийским спокойствием* а я что, употреблял слово "парадигма"? :)

>tacit

ну, APL-подобные языки с чистой совестью можно считать point-free-ориентированными

Что качественнее: финский, шведский, арамейский, латынь или фарси? Объективно. :D

http://mail.python.org/pipermail/python-list/2001-April/078716.html http://www.springerlink.com/content/q573nlm42442k638/ http://209.85.129.132/search?q=cache:5bNcnAYbwsQJ:www.cis.uab.edu/files/activ... http://www.google.ru/search?q=%22programming+language%22+quality+criteria

Что качественнее, финка, шведка, итальянка или мусульманка? :D

Всё зависит от объектива ...

> Что качественнее: финский, шведский, арамейский, латынь или фарси? Объективно. :D

Да без проблем! Только ты сначала выкати объективные критерии оценки. (собственно, их для ЯП я и спрашиваю).

> set str1 [list $messageLength] > set ... > set ... > set ... > set res [binary format S1c6S1c2c[llength $data] $str1 $str2 $str3 $str4 $data]

Не вижу никакого подвоха. Если тут действительно надо создавать гетерогенные списки -- система типов тут не мешает. Однако подозрения закрадывается, что код кривой, особенно вот из-за этого -- S1c6S1c2c[llength $data] -- языки с типами вычислили бы эту фигню *сами*.

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

Задачу не понял.

> Что качественнее, финка, шведка, итальянка или мусульманка?

Выкати объективные критерии. Например, "отношение длины ног к росту".

90-60-90

>языки с типами вычислили бы эту фигню *сами*

покажи мне язык с типами, в котором была бы такая фигня, с чем-то вроде Word[big-endian]. а кайф этой конструкции, вообще говоря, именно в том, что эта строка вычисляется не сама - и ты в любой момент можешь её подстроить так, как тебе нужно. проверится только общее количество байт

>Задачу не понял.

void f(int, double, int);

и пусть есть гетерогенный список vec, хранящий три значения - int, double и int. задача - передать функции значения из вектора, не используя явно количество аргументов:

f({*}vec) должно превратиться в f(vec[0], vec[1], vec[2])