Выбор языка программирования

[EtCetera]

Alexu007

Alexu007 в сообщении #520090 писал(а):

Напишите на разных языках программу, выводящую на экран фразу "Hello World". Чем меньше кода придётся для этого написать - тем проще язык для непрофессионала. Чё тут думать то?

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

(Hello, world!)

Вывод фразы Hello, world! на языке HQ9+:

H

[Maslov]

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

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

Munin в сообщении #520138 писал(а):

практически эта задача вполне разрешима, даже если результатом будет "вот эти два языка почти одинаковы, выбор между ними - дело вкуса"

Кроме достаточно очевидных случаев, этих почти одинаковых языков будет не два, а гораздо больше. Например, при разработке какого-нибудь web-приложения общего назначения можно выбирать из PHP, Ruby, Python, Java, C# и еще много чего, и доказывать, что какой-то из них "объективно лучше" -- дело довольно бесперспективное. Другими словами, выбор языка обычно определяется не столько достоинствами самого языка, сколько всякими дополнительными обстоятельствами: операционное окружение, наличие необходимых библиотек и средств разработки, распространенность, доступность информационных ресурсов, уровень поддержки производителем и т. п. Ну и личную склонность тоже, конечно, нельзя исключать :)

[Yuri Gendelman]

Alexu007 в сообщении #520090 писал(а):

Напишите на разных языках программу, выводящую на экран фразу "Hello World". Чем меньше кода придётся для этого написать - тем проще язык для непрофессионала. Чё тут думать то?

Да, если непрофессионалу нужно только выводить строки на экран. Тогда Python лучше, чем Delphi. Но если тому же непрофессионалу нужно выводить фразы в окна на экране, то тогда уже визуальная среда Delphi будет для него проще. И т.п. Так что есть о чем подумать.

[Maslov]

Yuri Gendelman в сообщении #520179 писал(а):

Да, если непрофессионалу нужно только выводить строки на экран. Тогда Python лучше, чем Delphi.

И даже в этом случае есть о чем подумать :) Программу на Питоне легче запустить, но труднее отлаживать и модифицировать (из-за отсутствия строгой типизации).

[Munin]

Maslov в сообщении #520173 писал(а):

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

А они и есть проще, в смысле простоты использования :-)

Maslov в сообщении #520173 писал(а):

Кроме достаточно очевидных случаев, этих почти одинаковых языков будет не два, а гораздо больше. Например, при разработке какого-нибудь web-приложения общего назначения можно выбирать из PHP, Ruby, Python, Java, C# и еще много чего

Мне трудно представить себе ситуацию, в которой бы группы PHP, Ruby, Python и Java, C# шли бы нос в нос. Скорее, одна другую будет отчётливо обгонять, или другая первую. Или одна часть приложения требует одного языка, а другая другого.

Maslov в сообщении #520173 писал(а):

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

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

Maslov в сообщении #520173 писал(а):

Ну и личную склонность тоже, конечно, нельзя исключать :)

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

[arseniiv]

Кстати, что-то действительно мало кто заговаривал об отладке! А ведь с ней у языков большой разброс. Для одних языков есть среды с «хорошей» отладкой, и даже по нескольку разных, а для других таких не сыщешь…

[Maslov]

Munin в сообщении #520188 писал(а):

А они и есть проще, в смысле простоты использования

Смотря о каких программах мы говорим и что понимаем под простотой использования. Можно говорить о простоте компиляции, простоте отладки, простоте сопровождения (поиск ошибок и модификация) и т. п. Программы на скриптовых языках с динамической типизацией проще откомпилировать, но труднее заставить работать правильно: большинство ошибок, связанных с неправильной типизацией, "строгие" языки выловят на стадии компиляции, а динамические -- только на стадии выполнения. Чем больше информации о наших данных мы сообщим компилятору, тем больше наших ошибок он сможет найти.
Примерно та же ситуация с модификацией уже написанных программ и с попытками разобраться в функционировании кода, полученного со стороны (или просто написанного несколько месяцев назад :)): глядя на функцию на Delphi, Java, C++ или C# можно, по крайней мере, понять, что за данные она принимает на входе и что выдает на выходе; для скриптовых языков эта информация недоступна.

Munin в сообщении #520188 писал(а):

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

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

[arseniiv]

Maslov в сообщении #520200 писал(а):

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

Однако хорошие комментарии перед заголовком убивают эту проблему в обоих случаях наповал!

[wallflower]

(Оффтоп)

arseniiv в сообщении #520192 писал(а):

Для одних языков есть среды с «хорошей» отладкой, и даже по нескольку разных, а для других таких не сыщешь…

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

[arseniiv]

(Оффтоп)

Именно для этого для него таки есть модуль Trace [или как-то там]?

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

[Maslov]

arseniiv в сообщении #520205 писал(а):

Однако, хорошие комментарии перед заголовком убивают эту проблему в обоих случаях наповал!

Положа руку на сердце, Вы часто видели хорошие "комментарии под заголовком" в стороннем коде? Возьмите, например, Ruby On Rails: что-то откомментировано весьма прилично, а что-то -- мягко говоря, похуже.

Комментарии могут быть неполными, устаревшими или просто ошибочными, другими словами, они могут не соответствовать коду. Явная информация о типах соответствует работающему коду всегда.

[arseniiv]

Увы! Я даже сам никак себя не научу к последовательному комментированию.

[Maslov]

arseniiv в сообщении #520216 писал(а):

Увы! Я даже сам никак себя не научу к последовательному комментированию.

Тут нечего стесняться, Вы не одиноки :)

У динамических языков есть еще одно достоинство, в некоторых случаях оборачивающееся проблемами: они очень динамичны :) Глядя на описание класса на Java, я твердо знаю, что этот код работает для всех объектов данного класса. В Ruby методы класса могут быть свободно удалены, добавлены или изменены любым модулем программы, причем как на уровне класса в целом, так и на уровне отдельного экземпляра. Ни в чем нельзя быть уверенным

На самом деле, я хорошо отношусь к скриптовым языкам :); просто хочу подчеркнуть, что в больших и сложных проектах "строгие" языки могут оказаться более предпочтительными.

[wallflower]

Maslov в сообщении #520224 писал(а):

На самом деле, я хорошо отношусь к скриптовым языкам :); просто хочу подчеркнуть, что в больших и сложных проектах "строгие" языки могут оказаться более предпочтительными.

У скриптовых языков есть важная миссия -- т. н. быстрое прототипирование.

[Munin]

Maslov в сообщении #520200 писал(а):

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

Правда, второе растёт с размером и связностью программы, да и для "правильно" бывают разные по строгости критерии. Так что своя ниша у этих языков есть, где эти проблемы некритичны.

Maslov в сообщении #520200 писал(а):

Чем больше информации о наших данных мы сообщим компилятору, тем больше наших ошибок он сможет найти.

Вообще, идеальная цель программирования - это не чтобы машина нашла все наши ошибки, а чтобы она сделала то, что требуется, несмотря на эти ошибки. DWIM в чистом виде.

Maslov в сообщении #520200 писал(а):

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

Почти тривиальный: на одном хоть что-то, на других вообще ничего. Так обычно и делается выбор языка для решения задачи непрофессиональными программистами.