Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
VD>>>Но у них есть одна проблема — они неудобны. Или скажем, так в большинстве случаев вместо них удобнее использовать озврат множетсва значений (котреж, напимер). Такой подход решает и проблему многопточности (при условии что весь многопоточный код написан в фукнциональном стиле) решает, и просто удобен.
КЛ>>поправь меня, но в Nemerle можно обращаться к элементам кортежа только по индексам, которые должны быть известы в compile-time и нельзя по элементам пробежаться. Так что это лучше "бестолковых безымянных структур" только их отсутствием (структур).
VD>Поправляю. В Немерле есть возможность:
ой спасибо
[отлично что ты опять решил блеснуть знаниями]
VD>Перебирать из довольно бессмысленно так как они могут иметь разные типы данных. Хотя в макросах их можно и переберать и даже генерировать. К примеру, параметры методов тоже генерируеются как кортежи.
хаха, и что? От этого это становится бесмысленным? Че за бред?
КЛ>> А об их отсутствии (точнее о том, что это плохо и они заменяются кортежами.) я уже писал.
VD>(задумчиво) Да, ты много пишешь...
Здравствуйте, VladD2, Вы писали:
CU>>Ну и ты нас пойми, нас очень интересует не сам список, а _почему_ он именно такой!
VD>Этого вопроса пока не звучало. Если это интересует, то могу ответить.
Ок, с учётом всего изложенного есть "контрпреложение": дополнить тебе твой список по каждому из пунктов альтернативами в порядке убывания значимости с твоей точки зрения.
VD>>>А чем по-твоему иявляются параметры функций?
E>>Ага, фрейм стека в C/C++ в перемешку со значениями регистров уже стал кортежем.
BZ>а причём тут процессор? речь идёт о языке. и тут Влад прав — с теоретичсекой точки зрения это кортёж и есть, пока ты не используешь переменнное число аргументов
Какая-то оторванная от практики теория, укуренная, я бы сказал.
Нет в C++ штатных средств получения аргументов метода в виде одного объекта (т.е. никакого экземпляра кортежа получить нельзя). Да, если компилятор не засовывает аргументы в регистры, то хаками на ассемблере можно получить копию стекового фрейма, но к языку это не имеет отношения.
В Ruby можно аргументы метода получать в виде одного объекта штатными средствами языка, там хоть как-то можно кортежи за уши притягивать. А вот в C/C++ -- только, если трава забористая попалась.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Константин Л., Вы писали:
КЛ>как тебе сказать...Неплохо, удобно. Но есть один недостаток — отсутствие имен элементов кортежа в функции, его возвращающей. С параметрами методов этого нет. Читабельность страдает, имхо.
Согласен. Но это уже зависит от дизайна языка. В MATLAB, например, эти имена есть.
Здравствуйте, Константин Л., Вы писали:
FR>>Нужен результат: например вернуть из функции N (разнотиповых) переменных, есть несколько альтернатив как это сделать, в языке подерживающем туплы, это элементарно просто вернуть тупл. В языке не подерживающем туплы или завести структуру из этих N переменных (единственное предназначение которой только возврат этих переменных) или что еще хуже завести у функции out параметры. Тупл здесь средство упростить и очистить от мусора код и ничего больше.
КЛ>вот в чем ошибка, которую мы сами совершаем и сами же фиксим с пом. туплов.
Хоть это только пример объясни в чем ошибка-то?
Мне кажется если бы в C++ были туплы или ты достаточно часто писал на другом языке с туплами, то твое мнение было бы совсем другим.
Здравствуйте, eao197, Вы писали:
E>В Ruby можно аргументы метода получать в виде одного объекта штатными средствами языка, там хоть как-то можно кортежи за уши притягивать. А вот в C/C++ -- только, если трава забористая попалась.
Кстати D в этом отношении очень близок к C++, но позволяет получить аргументы в виде кортежа, так что принципиальных припятствий не видно.
BZ>>а причём тут процессор? речь идёт о языке. и тут Влад прав — с теоретичсекой точки зрения это кортёж и есть, пока ты не используешь переменнное число аргументов
E>Какая-то оторванная от практики теория, укуренная, я бы сказал. E>Нет в C++ штатных средств получения аргументов метода в виде одного объекта (т.е. никакого экземпляра кортежа получить нельзя). Да, если компилятор не засовывает аргументы в регистры, то хаками на ассемблере можно получить копию стекового фрейма, но к языку это не имеет отношения.
скажем так — для теоретического осмысления языка это может быть не так важно. в языках с отдельными арщументами можно передать только один параметр и получить частично применённую функцию. если это невозможно — то с некоторой точки зрения удобно считать, что передаётся один tuple
Здравствуйте, Константин Л., Вы писали:
КЛ>как тебе сказать...Неплохо, удобно. Но есть один недостаток — отсутствие имен элементов кортежа в функции, его возвращающей.
Это не есть обязательный признак кортежа. К примеру, в LInQ у кортежей элементы именованные (у них, правда, есть другая проблема).
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
Здравствуйте, BulatZiganshin, Вы писали:
BZ>такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь. если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру"
Тут у многих первый язык — Бейсик, в том числе и у меня.
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
BZ>>такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь. если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру"
AVK>Тут у многих первый язык — Бейсик, в том числе и у меня.
если бы вторым был пролог — это бы сказалось я к тому, что сейчас вузы т у нас, и за рубежом учат людей шравным образом императивным языкам, и потому-то они и считают это естественным. имхо, функциональный подход даже более естественен, особенно если идти от чистой математики
а когда человек изучит десяток императивных языков, ему в функциональные врубиться уже совсем тяжело, и возникает у него ощущение "а они почему строем не ходят?" у меня-то к моменту изучения хаскела было с пяток языков, обнаруживающих те или иные свойства ФП, и я уже представлял, что мне нужна именно лёгкость записи сложных алгоритмов. вот именно для того, чтобы человек легко сложные алгоритмы осмысливал, и надо его с высокоуровневых языков начинать гонять
Здравствуйте, BulatZiganshin, Вы писали:
BZ>если бы вторым был пролог — это бы сказалось я к тому, что сейчас вузы т у нас, и за рубежом учат людей шравным образом императивным языкам
В моем вузе Пролог был. А то что императивным языкам учат не на программистских специальностях, так это нормально. Ненормально то, что большая часть современных программистов не имеет профильного образования.
BZ>, и потому-то они и считают это естественным. имхо, функциональный подход даже более естественен, особенно если идти от чистой математики
Нет, функциональный подход не естественен, потому что идея неизменяемого мира не может быть естественной. Понимаешь, лет несколько назад я наверное думал так же. А сейчас понимаю — не попадись мне тогда бейски, я скорее всего так и не стал бы программистом. Понять тогда ФП мне было просто без шансов, для меня ООП тогда был крайне сложной штукой.
BZ>а когда человек изучит десяток императивных языков, ему в функциональные врубиться уже совсем тяжело
Это тоже заблуждение. Функциональность вобще слабо коррелирует с императивным программированием, но при этом неплохо комбинируется с ним. Более того, мне вобще не нравится рассматривать ФП как некий монолит. На самом деле в ФП есть несколько идей, и многие из них (immutable структуры, лямбды, pattern matching etc) вполне применимы и в императивном программировании. Я тебе даже больше скажу — огромное количество современных мейнстрим-программистов знает минимум один функциональный язык — SQL. Да, он конечно весьма ограничен, но тем не менее. А есть еще XSLT, который не любят, но продолжают жрать кактус. Беда ФП не в страшном и ужасном образовании, которое навязывает императивщину, а в том, что многие функциональщики упорно тащат свою тележку в сторону элитарности.
Вот для чего действительно требуется ломка сознания, так это для языков вроде Пролог. И для ООП (если начинать со структурного программирования) кстати тоже.
BZ>, и возникает у него ощущение "а они почему строем не ходят?"
Правильное, между прочим, ощущение. Бо действительно не все хорошо в функциональном королевстве. Вот, к примеру, LInQ большинством программистов воспринимается на ура. Так может проблема не во внешнем мире, а внутри? Промышленный язык должен разрабатываться именно как промышленный язык, и никак иначе, вне зависимости от того, какую парадигму он проповедует.
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
Здравствуйте, Константин Л., Вы писали:
КЛ>как тебе сказать...Неплохо, удобно. Но есть один недостаток — отсутствие имен элементов кортежа в функции, его возвращающей. С параметрами методов этого нет. Читабельность страдает, имхо.
Конечно это можно считать проблемой, но практически тоже самое ты имеешь когда смотришь на вызов фунции:
f(1, "aaa", 1.2);
Ты ведь без заглядвания в хэлп тоже не можешь сказать, что означает каждый из параметров. А с заглядыванием и с кортежами проблем не бывает.
Обычно если кортеж используется явно, то он подвергается декомпозиции и каждый его элемент получает имя. Конечно можно ошибиться при задании этих имен, но как показывает практика этого не происходит. Ведь имена задаются теми кто понимает что означает каждый член кортежа. А при чтении мы просто доверяем этим имена. В общем, полная аналогия с параметрами ведь мы тоже можем передать в параметр что-то не то, но совпадающее по типу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
VD>>Перебирать из довольно бессмысленно так как они могут иметь разные типы данных. Хотя в макросах их можно и переберать и даже генерировать. К примеру, параметры методов тоже генерируеются как кортежи.
КЛ>хаха, и что? От этого это становится бесмысленным? Че за бред?
Ну, придумай осмысленную задачу. И вообще, ты же сам сравнивал кортежи со структурами. Тебя не удивляет, что струтуру тоже нельзя перебрать?
Еще интересно почему ты не считашь бредом тот факт, что параметры метода тоже невозможно перебрать (если список фиксирован)?
КЛ>>> А об их отсутствии (точнее о том, что это плохо и они заменяются кортежами.) я уже писал.
VD>>(задумчиво) Да, ты много пишешь...
КЛ>а это к чему? У тебя с этим проблемы? Не читай
Не догадливый?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>функции с побочными эффектами удобно называть прцедурами — как раз чтобы не входить в разрез с математикой
Термин "процедура" уже занят. Он означает фукнцию которая ничего не возрващает. Так что все же прийдется делить функции на чистые и грязные.
BZ>далее, "чистоту" ещё называют ссылочной прозрачностью (referential transparency),
Да, называют. В мире функциональщиков. В этом мире вообще обожают придумывать невнятные термины. Потому ФП и сидит в такой глубокой заднице.
BZ>и это означает, что результат функции зависит только от её аргументов и никак не зависит от состояния внешнего мира. для того, чтобы гарантировать это, *достаточно* запретить ей обращаться к глобальным переменным, вызывать процедуры, сохранять своё состояние в static vars
Ты забыл изменение объектов в методах.
BZ>вот в этом как раз и состоит проблема вызова процедурного кода из функционального, которую ты объявил несуществующей
Нет такой проблемы. Ее придумали пуристы.
BZ>запретив такие вызовы, мы можем *гарантировать* referential transparency, т.е. теперь это проверяет компилятор.
Можем. Но я бы предпочел чтобы такой запрет насил опциональный характер. Скажем хочу я чобы компилятор мог распараллелить код, помечаю фукнцию соотвествующим атрибутом и получаю что хочу. Ну, или наоборот. Помечаю функцию как императивную и могу творить в ней все что хочу. А можно даже явно указывать что я хочу изменять (определять иныариант фукнции).
BZ> если разрешим — придётся проверять программисту. более того, на самом деле такие вызовы возможны с помощью unsafePerformIO — это и есть тот механизм, который позволяет программисту взять ответственность на себя *явно*
Я не против этого. Я против выдумывания для этого соврешенно не естественых идиом. Есть одна идиома котора и так решает все проблемы — изменение переменной. Ее за глаза хватает.
BZ>ну а тезнически запрет таких вызовов, заодно с явным описанием плорядка вызова процедур, решается "эстафетной палочкой" — фиктивным значением типа RealWorld, передаваемым от порцедуры к процедуре, и недоступным функциям. т.е. функция не может вызвать процедуру потому, что она такую эстафетную палочку не получает сверху, и не может создать её сама
В лес всю фикцию. Проблема рашается намного проще. Надо всего лишь отказаться от пуританства.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>все возможности *яызка* Смоллток в руби есть.
+1 Даже больше. Но действитльно языки одного направления, хотя Руби вроде дрался с Перла.
BZ> правда, изменилась терминоллогия, и главное — нет той замечательной среды. ведь это же была первая IDE в мире! и до сих пор, как я понимаю, нет ни одной среды, где было бы так легко работать со структурой классов и проверять, что возвратят те или иные методы
Сполток конечно обладал первой IDE, но на сегодня IDE Явы и Шрпа намного мощьнее. Тут ты не прав. И причина тут в том, что для этих языков доступна полная информация о типах. Кстати, для Хаскеля хорошую IDE сделать можно, хотя язык имеет плохие особенности вроде уникальных идентификаторов (из-за выбранной системы типов и уращения клгоритма вывода типов), что весма странно будет выглядить в современном мире. А у Руби и Смолтока их динамическая типизация приводитк к серьезным ограничениям.
BZ>C# же, как и Delphi — язык чисто практический, я лично в нём ничего концептуального не вижу.
В них выражены все концепции ООП. Причем используется система типов основанная на классах, то есть так что родилась в Симуле. Смоток и Риби пошли своим путем. Лично мне он не нравится. Но в любом случае достаточно одного представителя этого направления — Руби. Теболее что Руби на мой взгляд более интересный язык.
BZ> и вообще, на мой взгляд, изучать ФП надо с...
А причем тут ФП? У тебя случае мунктика на нем нет? В списке били и Хаскель, и Схема. Вот на них пусть ФП и изучается.
BZ> наиболее теоретичсеких, удобных в программировании, но неэффективных (пролог, хаскел),
С каких пор Пролог стал ФЯ?
BZ> и далее спускать к более практичным, но сложным в использовании языкам. и заканчивать на C#, яве или чём-то ещё, что будет реально использоваться. языки более низкого уровня, типа C++, изучать необязательно — разве что чтобы понять, как функционирует процессор, да и это начинающему ни к чему
А я так не считаю. Как раз я бы сначала познакомил людей с выражениями, потом с основами процедурного программировнаи, а потом бы уже давал бы ФП и ООП как его расширения (заужение). На мой взгляд так будет проще донести до людей эти идеии. Возможно даже вначале показывать сам подход в виде паттернов, а потом показывать соотвествующие языковые конструкции.
Что касается языка, то я бы как раз выделил на роль первого языка Немерле или Руби. Руби я бы посоветовал тем учетилям которые считают, что вначале людям не надо морочить голову с типизацией, а Немерле тем кто считает, что типизация важнеший аспект. Ну, и по той причине, что на немерле можно показать практически все приемы кроме разве что ЛП.
BZ>такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь.
Твой подход привьет человеку конкретный образ мышления и осложнит восприятие других парадигм. Точно так же плохо давать в начале ООП, а потом пытаться обучить ФП. В обоих случаях будет отторжение второй парадигмы и ломка. Особенно это актуально для ФП, так как литература по нему полное дерьмо. Вообще удивительно как казалось бы стольк умные люди придумавшие все это так бездарны в писательстве! Ну, да это отдельная тема.
В общем, я виду к тому, что ООП и ФП надо давать параллельно и обязательно как развите стурктурного программирования.
BZ> если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру"
Забавно, что ты заметил, что первый язык привязывает к образу мышления. Стало быть твое предложение сделать ФП первым в изучении ни что иное как попытка привязать программирование к нему. На мой взгляд это ошибка.
Бэйсик же бывает разным. Бывает 70-ых годов с жудчащими goto вместо функций. А бывает VB.NET почти не отличающийся от C#. В прочем VB.NET — это ООЯ, что опять же привяжет к ООП. Что плохо.
А вот как средство изучения структурного программирования Васик довольно хорош. Так чта... а пуркуа бы собственно не па?
Я вот первым языком учил С. И особых проблем не вознкло. ФП крышу рвал по началу, но только от того что писатели пытающиеся его объснить были бездарностями.
Кстати, ООП я освоил на раз. И уверен, что это произошло так легко потому, что я сначала испытал в нем потребность, а затем прочел о нем. Я в 93-ем писал программу выводящую окна на экран и после первого лобового опыта стал задумываться как бы это дело реализовать. Патом я стал читать книжку про Виндвс и восхищался идеями сообщений и окон. Далее я изобразил что-то подобное на структурах и указателях на фукнции. Ну, а потом я уже читалш про С++ и мне все казалось логичным и стройным.
Уверен, что именно так надо преподносить знания в учебных заведениях. То есть:
1. Базовые знания.
2. Постановка задачи хорошо решающеся с помощью некого подхода.
3. Решение в лоб.
4. Анализ проблем.
5. Теоритический рассказ о подходе.
6. Решение задачи с помощью паттерна.
7. Демонстрация встроенных средств языка.
8. Анализ приемуществ встронных средств языка над использованием паттерна.
Уверен, что при таком подходе крышу сносить не будет.
Так что продаю идею.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cl-user, Вы писали:
CU>Ок, с учётом всего изложенного есть "контрпреложение": дополнить тебе твой список по каждому из пунктов альтернативами в порядке убывания значимости с твоей точки зрения.
CU>Если дополнишь объяснениями — вообще будет супер
CU>Идёт?
Считаю это предложение бессмысленным. Мой список я бы разбавил разве что ассемблером и С как средствами демонстрирующими низкоуровневый подход в оптимизации.
Что до альтернатив, то создавайте свои списки сколько влезет. Со своим я определился четко.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
BZ>>все возможности *яызка* Смоллток в руби есть.
VD>+1 Даже больше. Но действитльно языки одного направления, хотя Руби вроде дрался с Перла.
семантика — смолток, синтаксис — эйфель, фичи — перл. вообще, руби — это просто фантастическая коллекция наиболее удачных решений из разнообразных языков. например, в книге "жемчужины прогшраммирвания" описан гипотетический язык с очень удобным операторм case. нигда в реальных яхзыках такого так и не сделали. кроме руби!
BZ>> правда, изменилась терминоллогия, и главное — нет той замечательной среды. ведь это же была первая IDE в мире! и до сих пор, как я понимаю, нет ни одной среды, где было бы так легко работать со структурой классов и проверять, что возвратят те или иные методы
VD>Сполток конечно обладал первой IDE, но на сегодня IDE Явы и Шрпа намного мощьнее.
не видел ни ту, ни другую, ни третью, так что могу ошибаться. но фишка в том, что смолток динамчисекий язык и в его среде во-первых ты работал непосредтсвеенно с классами, а не исходными файлами, во-вторых, мог проверить работу любой функции непосредственно запустив её
>Тут ты не прав. И причина тут в том, что для этих языков доступна полная информация о типах. Кстати, для Хаскеля хорошую IDE сделать можно, хотя язык имеет плохие особенности вроде уникальных идентификаторов (из-за выбранной системы типов и уращения клгоритма вывода типов), что весма странно будет выглядить в современном мире. А у Руби и Смолтока их динамическая типизация приводитк к серьезным ограничениям.
что означает "уникальные идентификаторы"? я вообще лучше знаю английскую терминологию
BZ>>C# же, как и Delphi — язык чисто практический, я лично в нём ничего концептуального не вижу.
VD>В них выражены все концепции ООП. Причем используется система типов основанная на классах, то есть так что родилась в Симуле. Смоток и Риби пошли своим путем. Лично мне он не нравится. Но в любом случае достаточно одного представителя этого направления — Руби. Теболее что Руби на мой взгляд более интересный язык.
вместо C# и Delphi с теоретической точки зрения лучше изучать Eiffel, это дейсвтивительно красивый и мощный язык с чистой ООП идеологией. руби отличается от него динамической титпизацией, это отдельная парадигма со своими преимуществами и недостатками
BZ>> и вообще, на мой взгляд, изучать ФП надо с...
VD>А причем тут ФП? У тебя случае мунктика на нем нет? В списке били и Хаскель, и Схема. Вот на них пусть ФП и изучается.
есть. я вроде и говорил про эти два языка, ты не заметил?
BZ>> наиболее теоретичсеких, удобных в программировании, но неэффективных (пролог, хаскел),
VD>С каких пор Пролог стал ФЯ?
логичнсеколе программирование — тоже мощная, хотя и медлительная парадигма
BZ>> и далее спускать к более практичным, но сложным в использовании языкам. и заканчивать на C#, яве или чём-то ещё, что будет реально использоваться. языки более низкого уровня, типа C++, изучать необязательно — разве что чтобы понять, как функционирует процессор, да и это начинающему ни к чему
VD>А я так не считаю. Как раз я бы сначала познакомил людей с выражениями, потом с основами процедурного программировнаи, а потом бы уже давал бы ФП и ООП как его расширения (заужение). На мой взгляд так будет проще донести до людей эти идеии. Возможно даже вначале показывать сам подход в виде паттернов, а потом показывать соотвествующие языковые конструкции.
имхо после выражений нужно переходить к более сложным выражениям
VD>Что касается языка, то я бы как раз выделил на роль первого языка Немерле или Руби. Руби я бы посоветовал тем учетилям которые считают, что вначале людям не надо морочить голову с типизацией, а Немерле тем кто считает, что типизация важнеший аспект. Ну, и по той причине, что на немерле можно показать практически все приемы кроме разве что ЛП.
вот именно, и ничего хорошего я тут не вижу. мимхо, надо изучать разные параддигмы по их чистым представителям, а не язык, где они как-то сбиты вместе. что касается руби... он очень хорош для некадровых программистов. профессионалы должны думать более систематчисеким путём, они должны жить со сторгой типизщацией в уме, и для них руби будет полезен ближе к концу курса как красивый практический язык
BZ>>такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь.
VD>Твой подход привьет человеку конкретный образ мышления и осложнит восприятие других парадигм. Точно так же плохо давать в начале ООП, а потом пытаться обучить ФП.
а ты собираешься их смешанно давать, типа одно предложение их одной парадигмы, второе из другой? имхо надо изучить каждую из них — ООП, ФП, ЛП в чистом виде, на чистых языках, и затем уже идти к тому, как они могут сочетаться. иначе вчедловек, привыкший к ФП-поверх-ООП в Немерле будет *очень* обескуражен ООП-поверх-ФП в окамле, и скорей всего до него долго не дойдёт в чём тут приницпиальная разница
VD>В обоих случаях будет отторжение второй парадигмы и ломка. Особенно это актуально для ФП, так как литература по нему полное дерьмо. Вообще удивительно как казалось бы стольк умные люди придумавшие все это так бездарны в писательстве! Ну, да это отдельная тема.
а ты читал книгу Вадлера или Худака или судишь по Хал-Ван Даму?
VD>В общем, я виду к тому, что ООП и ФП надо давать параллельно и обязательно как развите стурктурного программирования.
почему? потому, что ты сам начинал с него? в хаскеле неструктурное программирование вообще трудно поредставить, оно лежит в самой идеологии языка. то же самое в прологе
BZ>> если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру"
VD>Забавно, что ты заметил, что первый язык привязывает к образу мышления. Стало быть твое предложение сделать ФП первым в изучении ни что иное как попытка привязать программирование к нему. На мой взгляд это ошибка.
я вообще-то предлагал начать с Пролога, поскольку считаю ЛП наиболее высокоуровневой парадигмой. и дальше идти по остальным парадигмам, чтобы человек с самого начала усвоидл каждую из них. но по отдельности, а не в виде nuj бутерброда, которы они приняли в том или ином конкретном языке. иначе он не научится видеть, что здесь принадлежит к ФП, что к ООП, и как их можно соединить иначе или вообще одну из них выкинуть
VD>Бэйсик же бывает разным. Бывает 70-ых годов с жудчащими goto вместо функций. А бывает VB.NET почти не отличающийся от C#. В прочем VB.NET — это ООЯ, что опять же привяжет к ООП. Что плохо.
VD> А вот как средство изучения структурного программирования Васик довольно хорош. Так чта... а пуркуа бы собственно не па?
с.п. на данный момент уже можно считать частью ООП. я не вижу смысла изучать его отдельно, благо что при других парадигмах нестурктурно программировать всё равно не получится
VD>Я вот первым языком учил С. И особых проблем не вознкло. ФП крышу рвал по началу, но только от того что писатели пытающиеся его объснить были бездарностями.
имхо, ты м сейчас мыслишь в императивном стиле, используя ФП только локально. на что несомненно откладывает отпечаток используемый тобой язык
VD>Кстати, ООП я освоил на раз. И уверен, что это произошло так легко потому, что я сначала испытал в нем потребность, а затем прочел о нем. Я в 93-ем писал программу выводящую окна на экран и после первого лобового опыта стал задумываться как бы это дело реализовать. Патом я стал читать книжку про Виндвс и восхищался идеями сообщений и окон. Далее я изобразил что-то подобное на структурах и указателях на фукнции. Ну, а потом я уже читалш про С++ и мне все казалось логичным и стройным.
VD>Уверен, что именно так надо преподносить знания в учебных заведениях. То есть: VD>1. Базовые знания. VD>2. Постановка задачи хорошо решающеся с помощью некого подхода. VD>3. Решение в лоб. VD>4. Анализ проблем. VD>5. Теоритический рассказ о подходе. VD>6. Решение задачи с помощью паттерна. VD>7. Демонстрация встроенных средств языка. VD>8. Анализ приемуществ встронных средств языка над использованием паттерна.
VD>Уверен, что при таком подходе крышу сносить не будет. VD>Так что продаю идею.
т.е. сначала надо научить людей структурному программированию, чтобы они поняли что это бяка и освоили ООП? а перед этим научить их програмимровать на асме, чтобы затем преподнести им идеи стурктурного программирования? а перед этим — в машинных кодах, да?
твой подход хорош для доучивания людей, которые уже владжеют некоей неэффектвиной парадигмой. с нуля же их учить этой парадигме только чтобы продемонстрирвоать её неэффектинвость, нет никакого смысла. их надло сразу учить мыслить в правильном ключе, и pfmtv уже более простые подходы давать только для парктических нужд
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>C# же, как и Delphi — язык чисто практический, я лично в нём ничего концептуального не вижу.
VD>>В них выражены все концепции ООП. Причем используется система типов основанная на классах, то есть так что родилась в Симуле. Смоток и Риби пошли своим путем. Лично мне он не нравится. Но в любом случае достаточно одного представителя этого направления — Руби. Теболее что Руби на мой взгляд более интересный язык.
BZ>вместо C# и Delphi с теоретической точки зрения лучше изучать Eiffel, это дейсвтивительно красивый и мощный язык с чистой ООП идеологией. руби отличается от него динамической титпизацией, это отдельная парадигма со своими преимуществами и недостатками
И тут влезу я
Я давеча для себя сформулировал, что, вообще говоря, есть два "совсем разных" ООП — "мейнстрим-ООП" и "радикальное ООП".
Мейнстрим-ООП — это то, что пошло от Симулы и наиболее чисто (почти без грязи-для-большей-практичности) выражено в Eiffel. У него ноги растут от "стремления структурности", главный лозунг — "основная единица организации кода — это класс" ("класс" здесь, — это в душе всегда "модуль на стероидах"). Т.е. предлагается думать о программе в терминах "декомпозиции на классы".
Радикальное ООП — пошло от Smalltalk (точнее, от некоторых более ранних разработок, но эту деталь мы опустим). У него ноги растут от "стремления к естественности и простоте", главный лозунг — "все есть объект", "программа это взаимодействие объектов". Классы здесь могут быть (Smalltalk, Ruby), а может и не быть (Self, Io) — это как бы вторичная по отношению к объекту сущность; все потому, что классы — это тоже объекты, но со специализированной задачей.
Приверженцы двух традиций друг друга не очень любят, и только свое ООП считают истинным (помнится, Влад где-то выше по ветке весь второй вариант широким жестом нарек "языками с прототипной орканизации"). Понятно, что в какой-то степени они обмениваются "приемчиками" (иначе Руби не считался бы наследником некоторых идей и Смоллтолка и Эйфеля)
А вот связан ли "тип ООП" с динамичностью самого языка — я не вполне уверен. Сходу кажется, что да (иначе классы нельзя менять в рантайме, и тогда они не полноценные объекты), но так ли оно?
ЗЫ: кстати, высказывания на тему "Ruby — это правильный Smalltalk" считаю примерно настолько же экстремистскими как "Nemerle — это правильный Haskell" (хотя, кажется, я знаю человека, который с последним согласится).
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>И тут влезу я ЗХ>Я давеча для себя сформулировал, что, вообще говоря, есть два "совсем разных" ООП — "мейнстрим-ООП" и "радикальное ООП".
Скорее согласен
ЗХ>А вот связан ли "тип ООП" с динамичностью самого языка — я не вполне уверен. Сходу кажется, что да (иначе классы нельзя менять в рантайме, и тогда они не полноценные объекты), но так ли оно?
В Яве класс — это объект (полноценный), ему можно посылать сообщение. Менять в рантайме нельзя, нет таких методов. От этого он не перестаёт быть объектом. В других ОО-языках может вообще не быть классов.
ЗХ>ЗЫ: кстати, высказывания на тему "Ruby — это правильный Smalltalk" считаю примерно настолько же экстремистскими как "Nemerle — это правильный Haskell" (хотя, кажется, я знаю человека, который с последним согласится).
ЗХ>Я давеча для себя сформулировал, что, вообще говоря, есть два "совсем разных" ООП — "мейнстрим-ООП" и "радикальное ООП".
ЗХ>Мейнстрим-ООП — это то, что пошло от Симулы и наиболее чисто (почти без грязи-для-большей-практичности) выражено в Eiffel. У него ноги растут от "стремления структурности", главный лозунг — "основная единица организации кода — это класс" ("класс" здесь, — это в душе всегда "модуль на стероидах"). Т.е. предлагается думать о программе в терминах "декомпозиции на классы".
ЗХ>Радикальное ООП — пошло от Smalltalk (точнее, от некоторых более ранних разработок, но эту деталь мы опустим). У него ноги растут от "стремления к естественности и простоте", главный лозунг — "все есть объект", "программа это взаимодействие объектов". Классы здесь могут быть (Smalltalk, Ruby), а может и не быть (Self, Io) — это как бы вторичная по отношению к объекту сущность; все потому, что классы — это тоже объекты, но со специализированной задачей.
имхо твоё разделение — на самом деле статические языки портив динамических, и все вытекаюбщие отсюда плюшки. в eiffel тоже everything is object, это c++/java — языки со смешанной парадигмой, в c# опять все данные — объекты, за исключением unmanaged кода
ЗХ>ЗЫ: кстати, высказывания на тему "Ruby — это правильный Smalltalk" считаю примерно настолько же экстремистскими как "Nemerle — это правильный Haskell" (хотя, кажется, я знаю человека, который с последним согласится).
руби порсто имеет все средства смолтокаЮ, насколько я в курсе. его объектная модель — именно смолтоковская. плюс к этому удобный синтаксис из паскале-подобных языков
кстати, я впервые слышу про предшественников смолтока. не расскажешь зотя бы вкратце о них?
