Является ли программирование творчеством?

[bin]

Esp_

Esp_ в сообщении #651703 писал(а):

Для одной задачи существует бесконечное множество программ, которые ее решают. Умение выбирать "правильные" программы из этого множества - это творчество воистину.

В этом полностью согласен. Но во второй части Вы, вслед за svb, говорите, что новые языки - это показатель развития (нпр., для конкретной страны). Это, извините, ИМХО не верно! Предложены тысячи тысяч языков, и что? Лучший из предложенных ИМХО - язык Паскаль, трансформировавшийся в Delphi 7/ Kylix. Лучший, потому что надежен (защитное программирование) и минимизирует неоднозначности. А сейчас именно надежности софта всем особо не хватает. Я знаю много интересных языков и их разработчиков, нпр., Dee (чистое ООП), Т (промежуточный между ЯП высокого уровня и ассемблером) и т.д. Но языки выбирают магнаты индустрии, сами программ не пишущие: сказал один такой: "васик!", и долго еще многие талантливые люди будут вынуждены мучиться с VBA, а Dee, Т и, даже, Оберон остались невостребованными. Этот же магнат, когда его "мелкомягкую" фирму побили в ОО Паскале, разозлился на Паскаль, но, несмотря на свою любовь к Васику, был вынужден выбрать более мощный язык для своих раз-рабов. Ничего лучше не нашел как С++. Теперь, когда пошли многопоточные CPU, пришлось выдумывать всякие TBB для Си, а Delphi 7 внутри себя очень неплохо реализует стандартные решения для многопоточности (мьютексы, семафоры и т.д.). Можно долго продолжать сравнение языков, но новых сейчас пока не нужно: старым (уже придуманным) пользовались бы правильно - были бы первыми на всей планете.

-- Пт ноя 30, 2012 00:21:17 --

Aritaborian в сообщении #650810 писал(а):

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

Но! Такой известный художник, как Сальвадор Дали подчеркивал в своих дневниках, что творчество - тяжкий ежедневный труд, а не только полет! Оценивать программинг, как и живопись, только по размаху крыльев вдохновения было бы поверхностно. У многих рядовых художников, как и у рядовых футболистов "размах на рубль, удар на копейку"

[Aritaborian]

bin, полностью согласен с вами (и с Дали). И не спорил даже ;-)

[Toucan]

post651209.html#p651209,
post651219.html#p651219,
post651547.html#p651547,
post651682.html#p651682

докер, JMH, arseniiv, замечание за оффтопик

[Esp_]

bin в сообщении #651769 писал(а):

Это, извините, ИМХО не верно! Предложены тысячи тысяч языков, и что? Лучший из предложенных ИМХО - язык Паскаль, трансформировавшийся в Delphi 7/ Kylix

Вы говорите про Object Pascal?

Цитата:

Лучший, потому что надежен (защитное программирование) и минимизирует неоднозначности.

Что такое "надежен" ? Поясните.

Цитата:

А сейчас именно надежности софта всем особо не хватает

Вы хотите сказать, что если софт писать на паскале, то это как-то поможет?

Цитата:

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

Этим никого не удивишь. И это относится не к языку, а мы здесь обсуждаем языки.

Цитата:

старым (уже придуманным) пользовались бы правильно - были бы первыми на всей планете.

Старые языки неповоротливы.

[bin]

Esp_ в сообщении #651903 писал(а):

Вы говорите про Object Pascal?

Не только. В Delphi интегрировано много технологий. Реализаций Object Pascal было много. Так, был Turbo Pascal 5.5 от Борланда, и одновременно другая реализации от Микрософта. Первая оказалась сильно удачнее, и Уильям Генри Гейтс III (более известный как Билл Гейтс) очень обиделся...

Esp_ в сообщении #651903 писал(а):

Что такое "надежен" ? Поясните.

См., например:

Цитата:

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

Esp_ в сообщении #651903 писал(а):

Вы хотите сказать, что если софт писать на паскале, то это как-то поможет?

Да.

Esp_ в сообщении #651903 писал(а):

Этим никого не удивишь. И это относится не к языку, а мы здесь обсуждаем языки.

Однако в С++ с этим очень плохо

Esp_ в сообщении #651903 писал(а):

Старые языки неповоротливы.

Что значит "неповоротливы"? Какие ЯП "поворотливы"?

[Esp_]

bin в сообщении #652534 писал(а):

Не только. В Delphi интегрировано много технологий. Реализаций Object Pascal было много. Так, был Turbo Pascal 5.5 от Борланда, и одновременно другая реализации от Микрософта. Первая оказалась сильно удачнее, и Уильям Генри Гейтс III (более известный как Билл Гейтс) очень обиделся...

Говорить о Паскале вообще смысла нет. Язык устарел. Для обучения и сейчас сгодится.
На сколько я понимаю, с поддержкой Delphi сейчас тоже какая-то плохая история, после смерти Борланда.

Цитата:

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

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

Цитата:

Вы хотите сказать, что если софт писать на паскале, то это как-то поможет?
Да.

Это очень вряд ли, коллега. По двум основным причинам. Первая - качество софта, я уверен, достаточно слабо зависит от языка, на котором этот софт сделан, если говорить о промышленных масштабах. Нет, конечно, на Delphi писать качественный код проще, чем на С++, но при хорошем знании этих языков корелляция будет достаточно слабой. Влиять на качество будут совсем другие вещи, в первую очередь, умение людей , которые этот софт делают "программировать вообще". Вторая - этот язык устарел, инструменты и библиотеки под этот язык не поддерживают и не выпускают. Может, Delphi.Net только и будет выходом. Но зачем писать на Delphi, если есть C#, который гораздо удобнее?

Цитата:

Однако в С++ с этим очень плохо

Я понимаю о чем вы говорите, но времена изменились. сейчас вы попробуйте найти людей, которые пишут на С++ и используют только стандартные библиотеки - их количество стремительно упало за последние 7 лет.
Сейчас многие используют Qt , Boost и прочие обертки и библиотеки, в них все проблемы подобного плана уже решены.

Что значит "неповоротливы"? Какие ЯП "поворотливы"?

Поворотливы гибридные языки. Это прежде всего C#, F#, Python.

Я имел в виду, что есть некоторый спектр задач, который на таких языках как Object Pascal требует написать ощутимо больше кода, чем это реально нужно. Не говоря уже о сложности этого кода.
Сейчас нешуточную популярность, а можно сказать и вторую жизнь получило функциональное программирование. Используя его практики, можно экономить не только в количестве кода, но и поднимать его качество, снижать риск ошибок. Также это влияет на скорость программирования.
Многие были недовольны тем, что в Java функциональное программирование никак не может устояться. Microsoft же в этом плане вовремя подсуетился.

[Pphantom]

Esp_ в сообщении #652563 писал(а):

Говорить о Паскале вообще смысла нет. Язык устарел.

Чем именно?

Esp_ в сообщении #652563 писал(а):

Первая - качество софта, я уверен, достаточно слабо зависит от языка, на котором этот софт сделан, если говорить о промышленных масштабах. Нет, конечно, на Delphi писать качественный код проще, чем на С++, но при хорошем знании этих языков корелляция будет достаточно слабой. Влиять на качество будут совсем другие вещи, в первую очередь, умение людей , которые этот софт делают "программировать вообще".

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

Esp_ в сообщении #652563 писал(а):

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

Хм...

peter@antares:~> fpc -i
Free Pascal Compiler version 2.6.0

Compiler Date      : 2012/11/28
Compiler CPU Target: x86_64

Supported targets:
  Linux for x86-64
  FreeBSD for x86-64
  Win64 for x64
  Darwin for x86_64
  Solaris for x86-64 (under development)

Посмотрите внимательно на дату выхода этой версии.

[Esp_]

Pphantom в сообщении #652581 писал(а):

Чем именно?

В своем посте я написал - чем. Посмотрите про гибридные языки.

Pphantom в сообщении #652581 писал(а):

Посмотрите внимательно на дату выхода этой версии.

Pphantom

Я поясню, почему это не то:
Во-первых, Free Pascal - это не индустриальное решение, а такой же опер сорс продукт, написанный не пойми кем (впрочем, возможно у истоков проекта и стоял кто-то большой и сильный, но сейчас вряд ли), с таким же опен сорсным качеством. Кто будет использовать это в индустриальном программировании? http://bugs.freepascal.org/my_view_page.php - посмотрите на список актуальных багов. Да это просто ужас.

Во-вторых - на одном компиляторе далеко не уедешь. В Сишарпе у меня есть супер IDE с плагинами и свежими фрейморками. А что у меня есть в Паскале?

[vvb]

Написать красочную захватывающую игру для 8-битной приставки с 48 килобайтами памяти и 3,5 МГц процессором - вот это искусство.
Еще в детстве поражался, как четко, с точностью буквально до тактов, были выверены алгоритмы.

[Pphantom]

Esp_ в сообщении #652621 писал(а):

В своем посте я написал - чем. Посмотрите про гибридные языки.

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

Esp_ в сообщении #652621 писал(а):

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

Т.е. если закрыть код и не показывать Вам список багов, то все сразу станет хорошо?

Но допустим. Чем Вам не нравится какая-либо реализация Ada?

Esp_ в сообщении #652621 писал(а):

Во-вторых - на одном компиляторе далеко не уедешь. В Сишарпе у меня есть супер IDE с плагинами и свежими фрейморками. А что у меня есть в Паскале?

Во-первых, совместно с компилятором можно использовать прорву различных IDE (если только что-то одно производитель не прибил к своему продукту гвоздями намертво). Во-вторых, если уж нужно что-то одно "самое правильное", то есть Lazarus. Ну и наконец, что делать с этим самым C# еще лет через 6-7, когда единственная убогая платформа, на которой им еще как-то можно пользоваться, в очередной раз откажется от обратной совместимости?

P.S. Вообще говоря, мы, похоже, ушли от темы. Может быть, выделить все это в отдельное производство?

[Esp_]

Pphantom в сообщении #652631 писал(а):

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

А я вам и не про размер в килобайтах писал.

Цитата:

Т.е. если закрыть код и не показывать Вам список багов, то все сразу станет хорошо?

Но допустим. Чем Вам не нравится какая-либо реализация Ada?

Во-первых, список багов многих закрытых продуктов открыт. Даже если он закрыт, есть поддержка, которая отвечает вполне оперативно и помогает решить проблему. Во-вторых, толку от того, что код того или иного продукта открыт в конечном счете не много. Качество open sourc'а за последние 5 лет реально не изменилось.
Кто делает эти программы и как? Кто их тестирует и как?

Я про Аду ничего не знаю, в глаза ее не видел. Зато какой open source продукт не возьми - руки чешутся его доделать.

[bin]

Esp_ в сообщении #652563 писал(а):

Нет, конечно, на Delphi писать качественный код проще, чем на С++, но при хорошем знании этих языков корелляция будет достаточно слабой.

Т.е. добавим дополнительные сложности, чтобы было, что преодолевать? При хорошем знании и спагетти с goto даст результаты. Но кому это нужно и кто это выдержит?

Esp_ в сообщении #652563 писал(а):

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

Ранее я уже отметил:

bin в сообщении #649688 писал(а):

можно вспомнить, что еще в прошлом веке В.Ш.Кауфман опубликовал статью в журнале Программирование, где показал, что любой универсальный язык программирования высокого уровня содержит так называемые "темные места", ведущие к неоднозначностям. Про неоднозначности такого модного языка, как С++, ленивый только не писал. Но и более строгие языки невозможны, по Кауфману, без неоднозначностей.

Esp_ в сообщении #652563 писал(а):

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

Упомянутый выше Б.Гейтс искренне верит, что все можно делать на Васике

Esp_ в сообщении #652563 писал(а):

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

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

Esp_ в сообщении #652563 писал(а):

Поворотливы гибридные языки.

Как насчет ДРАКОНа (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность)? У меня был печальный опыт создания IDE на двух языках (одни модули на одном, другие на другом) - пока не уговорил перейти на один язык, постоянно буксовали. Это только в теории многоязычная разработка (и всяческая гибридизация) выглядит беспроблемно. Иногда гибридность нужна. Не спорю. Но только ИМХО в особых случаях.

Esp_ в сообщении #652563 писал(а):

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

Цитата:

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

Для преодоления недостатков функциональных программ уже первые языки функционального программирования включали не только чисто функциональные средства, но и механизмы императивного программирования (присваивание, цикл, «неявный PROGN» были уже в LISPе). Использование таких средств позволяет решить некоторые практические проблемы, но означает отход от идей (и преимуществ) функционального программирования и написание императивных программ на функциональных языках. (Википедия:Функциональное программирование)

Esp_ в сообщении #652621 писал(а):

Во-вторых - на одном компиляторе далеко не уедешь. В Сишарпе у меня есть супер IDE с плагинами и свежими фрейморками. А что у меня есть в Паскале?

В Паскале есть IDE Delphi с плагинами и т.д.

Pphantom в сообщении #652631 писал(а):

Вообще говоря, мы, похоже, ушли от темы. Может быть, выделить все это в отдельное производство?

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

[Xaositect]

Esp_ в сообщении #652660 писал(а):

Во-первых, список багов многих закрытых продуктов открыт. Даже если он закрыт, есть поддержка, которая отвечает вполне оперативно и помогает решить проблему. Во-вторых, толку от того, что код того или иного продукта открыт в конечном счете не много. Качество open sourc'а за последние 5 лет реально не изменилось.

Я пользуюсь в основном OpenSource последние 7 лет, и за это время его качество изменилось очень сильно. А качество небольших опенсорсных проектов на мой взгляд всегда было выше качества коммерческих проектов, разрабатываемых одним человеком или небольшой командой. Понятно, что FPC и C# - это проекты сильно разных уровней.

[Esp_]

bin в сообщении #652666 писал(а):

Что не выпускают достаточно спец.библиотек, не значит, что язык устарел.

Есть куда более простой тест: посмотрите на ваших товарищей, посчитайте количество программистов Delphi сред них.

Цитата:

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

Для преодоления недостатков функциональных программ уже первые языки функционального программирования включали не только чисто функциональные средства, но и механизмы императивного программирования (присваивание, цикл, «неявный PROGN» были уже в LISPе). Использование таких средств позволяет решить некоторые практические проблемы, но означает отход от идей (и преимуществ) функционального программирования и написание императивных программ на функциональных языках. (Википедия:Функциональное программирование)

Это прошлый век здесь описан. Ей богу! Сейчас ситуация ощутимо иная.
Во-первых, в гибридных языках такие проблемы почти что не возникают, т.к. стандартные функциональные конструкции там имеют достаточно простой вид и хорошо известно, в какой код они компилируются. В то же время, если такие конструкции не использовать - код усложняется.
Во-вторых, функциональное программирование нужно понимать и использовать его с умом. Если вы единожды поняли суть- проблемы в стиле копирования данных будут побеждены тем или иным способом.

Цитата:

В Паскале есть IDE Delphi с плагинами и т.д

Не смешите меня. Вы видели VS 2012 ? Где Delphi и где оно?

Xaositect в сообщении #652672 писал(а):

Я пользуюсь в основном OpenSource последние 7 лет, и за это время его качество изменилось очень сильно. А качество небольших опенсорсных проектов на мой взгляд всегда было выше качества коммерческих проектов, разрабатываемых одним человеком или небольшой командой. Понятно, что FPC и C# - это проекты сильно разных уровней.

Я не знаю, что вы имеете в виду под небольшими проектами, но я что-то с трудом могу назвать таковые, качество которых выше аналогичных коммерческих. Не могли бы вы назвать несколько примеров?

А вот мои примеры:
- Open Office - проблемы с производительностью так и не победили до конца. И по сей день существенный заметный отклик.
- Apache - нашли много дыр, сценариев где он крашится, итд
- Texnic Center - это хрень , а не редактор.
- Eclipse - это просто феерический ужас стал. Проблемы с производительностью.
- Tortoise<X> - крашится.

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

[Aritaborian]

Esp_, примеры отличных опенсорс-продуктов: Blender, LuxRender.