LINUX.ORG.RU

История изменений

Исправление SZT, (текущая версия) :

Для этого надо сначала определить, что значит «лучше». Скорость работы программы, скорость написания, среднее количество ошибок, гибкость, возможность изменения синтаксиса, …? Это если брать сам язык в вакууме.

Совершенно верно, нужно начать с того, чтобы четко выработать критерии. Вернемся к цитате AntonI Как заставить Lisp работать быстрее, чем C (комментарий) :

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

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

У языков программирования есть ещё такая вещь, как доступные библиотеки. И здесь чем больше пользователей, тем больше доступных библиотек. Бог на стороне больших батальонов.

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

Исправление SZT, :

Для этого надо сначала определить, что значит «лучше». Скорость работы программы, скорость написания, среднее количество ошибок, гибкость, возможность изменения синтаксиса, …? Это если брать сам язык в вакууме.

Совершенно верно, нужно начать с того, чтобы четко выработать критерии. Вернемся к цитате AntonI Как заставить Lisp работать быстрее, чем C (комментарий) :

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

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

У языков программирования есть ещё такая вещь, как доступные библиотеки. И здесь чем больше пользователей, тем больше доступных библиотек. Бог на стороне больших батальонов.

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

Исходная версия SZT, :

Для этого надо сначала определить, что значит «лучше». Скорость работы программы, скорость написания, среднее количество ошибок, гибкость, возможность изменения синтаксиса, …? Это если брать сам язык в вакууме.

Совершенно верно, нужно начать с того, чтобы четко выработать критерии. Вернемся к цитате AntonI Как заставить Lisp работать быстрее, чем C (комментарий) :

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

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

У языков программирования есть ещё такая вещь, как доступные библиотеки. И здесь чем больше пользователей, тем больше доступных библиотек. Бог на стороне больших батальонов.

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