Ответ на »сообщение 1419« (Jack Of Shadows)
___________________________
Что это означает ? Это означает что импетаривное программирование совершенно не нужно для того чтобы научить человека правильно программировать.
...на функциональном языке.
Так более корректно, Вам не кажется?

Ответ на »сообщение 1421« (Артем)
___________________________
:о) Супер!!!

Операции присваивания вас погубят! Каждая операция присваивания приближает использующих ее программистов к смерти. Удивительно, как здравомыслящие люди до сих пор не распознали смертоносности этой операции. Несмотря ни на что, использование операции присваивания неуклонно растёт. С операциями присваивания связаны все телесные недуги и вообще все людские несчастья :
1. Практически все, страдающие хроническими заболеваниями программисты, использовали операции присваивания. Эффект явно кумулятивен.
2. 99,9 % всех, умерших от рака программистов использовали операции присваивания.
3. 99.7 % программистов - жертв автомобильных и авиа катастроф использовали операции присваивания как минимум за две недели до фатальной даты.
4. 93,1 % малолетних преступников, родителями которых являются программисты, происходят из семей, где постоянно используют операции присваивания.

Ещё более убедительным доказательством служат исследования, полученные известным коллективом учёных - медиков: у программистов, которых принудительно заставляли набирать (без использования буфера) в текстовом редакторе  notepad по 10 000 операций присваивания в в день в течение месяца, возникли серьезные проблемы со здоровьем. Некоторым даже потребовалась реанимация.
Единственный способ избежать губительного воздействия операций присваивания – изменить стиль программирования. Используйте чистое функциональное программирование. От него, насколько нам известно, ещё никто не умирал.

Ответ на »сообщение 1415« (Сергей Перовский)
___________________________


Кстати, как насчет сборки мусора в системах реального времени?


http://www.memorymanagement.org/bib/gc.html#real-time

http://www.memorymanagement.org/bib/a.html#baker

На днях ковырялся в DrScheme. Обнаружил весьма интересную вешь.
Для начала расскажу что такое DrScheme.

Есть такой известный на западе проект http://www.teach-scheme.org/ спонсриуемый Американским Научным Фондом.
Это проект создан для распространнения программирования среди студентов.
Ближайшим аналогом в России наверное будет проет info21
Только teach-scheme наверное на порядок помощнее по охвату, спонсированию и конечно известности.
В качестве обучающего языка программирования используется, как понятно из  названия, диалект лиспа, scheme.
В качестве среды - разработанная ими же DrScheme. А основным учебным материалом является книга которую я многократно здесь упоминал: htdp.org
Одной из основных идей является то что язык программирования для обучения должен быть как можно более простым и исключать все что лишнее или мешает процессу обучения.
Ну точно как оберон скажете вы.
Однако достигают такой вот  простоты они совершенно другим образом.
Не обрезают язык, выбрасывая из него "все лишнее", а создают графическую среду, в которой можно ограничивать язык по нескольким уровням.
Самый первый уровень включает в себя только самые базовые конструкции языка. Любая попытка использовать функции или возможности языка вне этого базового набора просто выдаст ошибку.
Далее с ростом знаний студента и по мере прохождения материала, открываются все более высокие уровни языка, давая доступ к более сложным и может даже более опасным конструкциям языка и концепциям программирования.
Всего там 5 уровней от Beginning Student до Advanced Student.
Так вот господа, основа основ императивного программирования, оператор присваивания, открывается только на самом последнем уровне.
Причем если вы просмотрите материал курса то поймете что практически весь материал проходится до этого.
То есть к моменту когда студенту становится доступным оператор присваивания, он уже курс практически прошел. А материала там немало.
Что это означает ? Это означает что импетаривное программирование совершенно не нужно для того чтобы научить человека правильно программировать.
Что давать его надо в самом конце, как технический прием, позволяющий работать на компьютерах с той архитектурой, которая исторически сложилась. Но ни в коем случае не во время обучения и становления программиста. Иначе частный, технический метод общения компьютера с внешним миром, в сознании ученика подменит само понятие программирования. Что мы с вами и наблюдаем в массовом порядке в учебных заведениях, где программирование ведется на базе семейства паскалей/java/си

Это как вы видите не только мое мнение. Это мнение огромного количества людей, стоящих за проектом teach-scheme.
Вот такоя вот пища для размышлений :))

Ответ на »сообщение 1414« (al_mt)
___________________________
В конце-концов, пришли к выводу (и Сишники согласились), что наличие сборщика мусора, когда не требуется всенепременно явно освобождать память, правоцирует программиста на неаккуратный код.
Сомнительно...
Нашли один пример, когда наличие сборщика мусора в Си привело к  возникновению очень тяжелоотлавливаемой ошибки в большом проекте.
1. Чтой-то за зверь такой "Си со сборщиком мусора"? Или это это очередная прилепка в виде "hениальных указателей" а ля ACE, boos или Loki?
2. Если вы такую одну ошибку строго определили - не приведёте ли её, хотя бы общее, описание. Интеренсо же!

Writing a Lisp interpreter in Haskell
http://joel.reddit.com/goto?rss=true&id=pd54

Пост иллюстрирует преисущества хаскеля на примере написания простенького интерпретатора лиспа.

Ответ на »сообщение 1415« (Сергей Перовский)
___________________________

... это не опечатка, а ошибка проектирования, которую в системе со сборкой мусора просто не уловить.
Еще как уловить.
По кр. мере в Блэкбоксе: надо просто реализовать предопределенный метод FINALIZE, который вызывается в момент "сбора" данного объекта.

"Применять сборку мусора" -- это quasi как "применять технику безопасности".
Надеюсь, диссонанс Вам слышен в правой части -- это укажет на недопонимание в левой.
"Pensate!" (C) Giuseppe Verdi

Ответ на »сообщение 1414« (al_mt)
___________________________
>>>наличие сборщика мусора правоцирует программиста на неаккуратный код.
+1
Когда задумывается новый объект, необходимость четко понять, когда он должен быть уничтожен, заставляет более точно осознать ЗАЧЕМ этот объект нужен.
Количество AV из за неправильного уничтожения объектов у меня в среднем 1(один) на проект. Причем это не опечатка, а ошибка проектирования, которую в системе со сборкой мусора просто не уловить.
Вот в NET, когда объект не является собственностью приложения, автоматическая сборка мусора необходима. Так, что у всякого средства есть область применимости.
Кстати, как насчет сборки мусора в системах реального времени?

К слову о сборщике мусора. Мы вчера обсуждали на работе разницу между C++ и Delphi (не спорили, что лучше), на предмет что есть в одном такого, чего нет в другом, как это применить и как прикрутить к Delphi шаблоны в Сишном смысле (например).
Говорили и о сборщике мусора. В конце-концов, пришли к выводу (и Сишники согласились), что наличие сборщика мусора, когда не требуется всенепременно явно освобождать память, правоцирует программиста на неаккуратный код. Нашли один пример, когда наличие сборщика мусора в Си привело к  возникновению очень тяжелоотлавливаемой ошибки в большом проекте. Я не Сишник, тонкости не передам, но в общих чертах, один модуль написан с кучей мусора, и при стыковке с другим под отладочной библиотекой всё нормально, а в откомпилированной конечной версии - баг :( Так что, сборщик мусора штука хорошая, но видимо не для всех стилей программирования.

P.S. Кажется начал въезжать в принципы ЛИСПа :)))

Ответ на »сообщение 1406« (Сергей Перовский)
___________________________
Функциональщик: Сборка мусора это один из механизмов функционального программирования. Впрочем полезный и сам по себе. Вам императивщикам будет очень полезен.

Императивщик: Чем полезен, пример можно ?

Ф: Показывает пример в 4 строчки. Видишь не нужно в ручную освобождать память.

И: И это ВСЕ ? Одна строчка ? Ради этого многократно усложнять компилятор и тащить за собой VM ?

Ф: Это на маленьком примере одна строчка. Но на больших проектах она выливается в огого (расписывает прелести сборщика мусора)

И: Да ты покажи, я так понять не могу. Или если не можешь показать то хотя бы приведи класс задач для которых сборка мусора может быть полезной. Позиционируй так сказать по классам задач, в процентном отношении.

Ф: Ошалело смотрит на И пытаясь сообразить как в принципе можно в процентах по классам задач выразить пользу сборки мусора.

Ф: Сборка мусора полезна сама по себе, вне относительности к классу задач.

И: Так не бывает. Вот SQL он полезен для БД, а Пролог он тоже для чего то там полезен (Я правда в это не верю, поскольку сам никогда в жизни не только не пользовался Прологом но даже и задачи такой не могу представить где он мне понадобился бы. Но говорят кто то им пользуется). Универсальных инструментов не бывает. А вдруг мне сборка мусора не понадобится. Да и вообще, количество строчек, которыми я осовбождаю память в моих проектах не превышает 1% (может даже меньше). Дергаться нет смысла.

Ф: Да но это один процент строчек ответственен за 50% всех ошибок в твоей программе. Из за этого 1% строчек рост твоей программы в какой то момент просто останавливается.

И: Докажи, в моей практике этого никогда не было. Это все слова.

Ф: А ты попробуй, собственный опыт лучше любых доказательств.

И: Сначала убеди, потом попробую.

И так по бесконечному кругу.
------------------------------

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

Как в приведенном мною примере с библиотекой sftp, все просто упирается в наличие определенных библиотек и инструментов. Дельфи ничуть не лучше для задач с GUI чем лисп. Как язык. Но вот то что вместе с языком поставляется программа (Delphi IDE) для рисования окошек и бросания кнопочек и других визуальных обьектов, а вместе с лиспом такой программы не поставляется - именно это является решающим фактором при выборе языка для конкретной задачи, а не то что функицональный ли язык или императивный.
Если функциональынй и имепративный языки оба предоставляют все небходимые для решения задачи инструменты (билиотеки, билдеры итд), то функциональный язык всегда предпочтительнее.

Именно из за такой мелочи как отсутствие GUI билдера для лиспа, я виндовые программы пишу на делфи/сишарп.
Плююсь но пишу. Завтра лисп перекочует на dotnet, или кто то напишет к нему нечто похожее на Delphi IDE, и этот класс задач буду делать на лиспе.

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



Для меня ЛИСП остался в далеком прошлом вместе с ФОРТРАНом, СНОБОЛом и КОБОЛом. И особенного впечатления не произвел. Может быть это связано с моей личной убогостью, а может с теми алгоритмами, которые я тогда разрабатывал.


:)))) Помните наналогию с машинами и самолетом которую я приводил.
"Да ездил я на этих запорожцах, москвичах и самолете, все хреново ездют (а самолет хуже всех), мой мерседес лучше." :))