OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 25 Август, 2019 16:26

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 127 ]  На страницу 1, 2, 3, 4, 5 ... 7  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 29 Январь, 2011 19:08 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Выделено из: viewtopic.php?p=58946#p58946
ScrollLock писал(а):
Рыжий писал(а):
Надо сгрузить все в АПЛ и не париться. Какой там матлаб.

Посмотрел ради интереса - его синтаксис слишком уж лаконичен и суров)) Да и с библиотеками наверное в APL похуже.

Info21 писал(а):
Да ладно, инкапсуляция. Всё это заплатки на хреновое основание.

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

Настоящий мужик не должен бояться таких трудностей! Императивный стиль в программировании - это рай для домохозяек. За исключением тех случаев, когда он сам по себе создает проблемы, примером чего могут служить Бейсик и Фортран. Глубокое , и самое неочивидное, заблуждение сообщества т.н. "программистов" в том, что язык должен облегчать им процесс создания их шедевров. Отсюда и растут ноги проблемы сложности разработки ПО. Язык, сводящий управление памятью к манипуляциям с типизированными указателями на некоторые унифицированные структуры данных - лучшее средство отучиться думать бошкой. Дейкстра, как неспециалист , не разобравшись в вопросе, поспешил обозвать АПЛ - "ошибкой доведенной до совершенства". То же касается и прочих его заблуждений, касающихся стилистики программных конструкций.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 19:26 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Попытки облегчить жизнь разработчикам, предпринятые Дейкстрой и Виртом, очивидно , провалились. Произошло это потому, что , в данном случае, "проектировщиками" двигало приматическое желание достать банан наиболее простым способом. Как выяснилось, сбивать бананы с помощью универсального бананоуловителя , оказалось еще сложнее, чем без него. Книженки Майерса и Гаммы - тому пример. Вирту же следовало бы поменять местами словосочетания в названии своего классического опуса.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 19:39 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Появление С и Паскаля стало первым шагом к возникновению "узости восприятия" в компьютерном сообществе. Другим, современным, примером такого рода является небезызвестный Хасскел, и рекурсивное программирование в целом, обозванное почему-то "функциональным".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 19:47 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Нелюбовь Дейкстры к GOTO, объясняется подсознательным пониманием последним важности этой конструкции. Виртовско-дейкстровские попытки "унификации" алгоритмов, путем сужения пространства возможных структур данных, с GOTO , конечно, не совместны. В данном случае, определяющую роль сыграла не столько невозможность реализации таким образом каких либо алгоритмов, сколько сам психологический процесс сужения восприятия к данным структурам. Последствия этого процесса проявляются в том плачевном состоянии, в котором ныне находится программная индустрия.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 19:49 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8170
Откуда: Троицк, Москва
Рыжий писал(а):
Вирту же следовало бы поменять местами словосочетания в названии своего классического опуса.
Передам.

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

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

Про рекурсивное программирование то ж. Надо подумать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 19:57 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Речь идет об одном и том же костыле. Только в случае С++ это механизированный костыль с дистанционным управлением для мажоров, а, в случае Оберона, аскетический костыль любителей военизированного мышления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:04 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
В частности, введение т.н. структур, конечно, психологически несовместимо с GOTO, так как GOTO пример оператора "прямого доступа", доступ же к элементам данных в концепции структур, это поименованный доступ к типизированным элементам. Дейкстра просто стал жертвой когнитивного диссонанса, после чего он стал выдумывать особые методики программирования без GOTO.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:07 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2309
Откуда: Россия, Томск
Рыжий писал(а):
Дейкстра просто стал жертвой...
The narrative fallacy.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:26 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Все, что появилось после Бейсика и Фортрана, за исключением PL/I( о котором особая песня) - маршировка сужения восприятия. Это приводит к отсутствию творческого подхода, нежеланию рассматривать реализацию структур данных, как творческое действие, соответственно , к сужению взгляда на алгоритмы по обработке этих структур. В комплексе, это ведет к сужению взгляда на все начиная от интерфейсов пользователя и кончая способами организации программ (см. Гамма и проч.) А также, к выделению несовместимых подходов и жесткой дифференциации различных подобластей в программной инженерии. Наблюдается процесс обратного влияния данных схем на творческий процесс проектирования. Когда-то данные методики сами были творческим подходом, но превратившись в элементы синтаксиса языков, оказали отрицательное воздействия на развитие. Бейсик, например, не являлся попыткой борьбы со "структурной сложностью", таковые попытки бессмысленны с использованием будь какого инструментария. Дейкстра, кстати, это осознавал, однако его приматизм, все равно толкал его на поиски решения изначально неверно сформулированной задачи. То же касается и небезызвестного г-на Вирта.


Последний раз редактировалось Рыжий Суббота, 29 Январь, 2011 20:31, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:28 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Александр Ильин писал(а):
Рыжий писал(а):
Дейкстра просто стал жертвой...
The narrative fallacy.

Идите-идите... :D Мы еще вернемся к этому вопросу... :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:38 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Это т.н. институализация. Пример абсолютно изоморфный институализации в российской политике г-на Путина сотоварищи, ранее рассматриваемый, как творческое проявление политической индустрии. Дейкстра - Путин в информатике.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:39 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Проошу извинения и Ильина, я не имел целью сказать гадость, это студенческий юмор, проклятое демократическое воспитание...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:41 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Банду Дейкстры - под суд времени! Давно пор разобрать откуда какие мифы взялись. В историческом контексте.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:54 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 149
А может быть, исключение GOTO было сделано наоборот, чтобы подстегнуть креативность, реализуя тот же функционал с помощью указателей и самомодифицирующегося кода?))))) Как говорится, "настоящий программист может написать фортрановскую программу на любом языке".

Про MATLAB vs BlackBox: думаю, что не надо никакого vs, их же можно, как оказалось, прекрасно стыковать и программы на BlackBox в принципе вызываются из MATLABа как свои родные функции. Проблема лишь в отсутствии фирменного SDK.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:57 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Существует две параллельных оси развития языков. Первая основана на принципе выделения и институализации наиболее часто повторяющихся программных последовательностей состоящих из елементрных операций, а также на институализации очивидных структур данных, образующихся путем векторизации элементарных однородных элементов данных (что методологически сходно). Вторая базируется на фантастических идеях борьбы с т.н. "структурной сложностью", причины которой, рассматриваются каждой такой "научной школой" с субъективной точки зрения. В первом случае мы имеем естественную последовательность языков , каждый из которых обладает всеми достоинствами предыдущих, и не вносит парадигмальной сумятицы и не ограничивет точки зрения на вещи, это:
Ассемблер,Фортран,Бейсик, АПЛ и т.п.

Во втором случае это:
C, С++, Ада, Паскаль , Оберон, и (ха-ха) -Хаскелл(тут мы имеем поример , как раз резкого отличия в субъективном восприятии причин сложности) и т.п.

Первая ветвь естественна и научно обоснована, вторая неестественна , субъективна, и черпает свое обоснование из себя же самой.


Последний раз редактировалось Рыжий Суббота, 29 Январь, 2011 21:14, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 20:58 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
ScrollLock писал(а):
А может быть, исключение GOTO было сделано наоборот, чтобы подстегнуть креативность, реализуя тот же функционал с помощью указателей и самомодифицирующегося кода?))))) Как говорится, "настоящий программист может написать фортрановскую программу на любом языке".

Про MATLAB vs BlackBox: думаю, что не надо никакого vs, их же можно, как оказалось, прекрасно стыковать и программы на BlackBox в принципе вызываются из MATLABа как свои родные функции. Проблема лишь в отсутствии фирменного SDK.

GOTO, это не совсем то, что о нем возомнил Дейкстра.
Это действительно смешно. :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 21:12 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Приматический характер второй ветки проявляется, как раз, в обилии "научных школ", "концептуальных трудов" и соответствующих методик "креативного проектирования", а также в непрекращающемся холиваре их адептов. :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Январь, 2011 21:15 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 149
Думаю, что сужение спектра приёмов программирование и стандартизация конструкций - это неизбежность, ибо серьёзно облегчает поддержку больших программ и взаимодействие программистов. В конце концов, при производстве материальных изделий используют множество стандартных деталей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Январь, 2011 11:58 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3061
Откуда: Астрахань
Рыжий писал(а):
Банду Дейкстры - под суд времени! Давно пор разобрать откуда какие мифы взялись. В историческом контексте.

А при чем здесь Дейкстра? Когда есть вполне официальное исследование Кнута по GOTO?
Knuth D.E. Structured Programming with GO TO Statements // ASM Computing Surveys. 1974. 6(4). P.261-301.
А еще раньше он исследовал проги фортрана на предмет количества goto и последствий этого для проги.
Knuth, D. E. «An Empirical Study of FORTRAN Programs», Software -Practice & Experience, vol. 1, pp. 105-133, 1971.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 31 Январь, 2011 00:57 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
Info21 писал(а):
Но как тогда учить, непонятно, если структуры данных вводить поперед структур управления. Ниче жужжать не будет, детишки не поймут.
....
А кстати, тут интересный пунктик.
Что значит тонкое замечание, сразу и мыселька забегала.


?
Вот если в области БД выделить "свой Оберон", то можно, видимо, давать структурирование данных до полноценного программирования... Возможно.
?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 127 ]  На страницу 1, 2, 3, 4, 5 ... 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB