OberonCore
https://forum.oberoncore.ru/

Свежый взгляд (Рыжий vs Дейкстра и др.)
https://forum.oberoncore.ru/viewtopic.php?f=27&t=3216
Страница 2 из 7

Автор:  Илья Ермаков [ Понедельник, 31 Январь, 2011 01:05 ]
Заголовок сообщения:  Re: Исп-е Octave/Matlab для векторно-матричных вычислений

Рыжий писал(а):
Все, что появилось после Бейсика и Фортрана, за исключением PL/I( о котором особая песня) - маршировка сужения восприятия. Это приводит к отсутствию творческого подхода, нежеланию рассматривать реализацию структур данных, как творческое действие, соответственно , к сужению взгляда на алгоритмы по обработке этих структур. В комплексе, это ведет к сужению взгляда на все начиная от интерфейсов пользователя и кончая способами организации программ (см. Гамма и проч.)


Ой ли? Мне кажется, что процесс "отлива в схемы" ранее творческих вещей является обязательным для НТ-развития. Чтобы выйти на рубеж реально интересных и актуальных задач, надо заморозить вариативность старых задач, закрепить какие-то типовые их решения. Чтобы сконцентрировать на этом актуальном рубеже свежие человеческие ресурсы. Для этого те же студенты должны не ломать голову над всё теми же вопросами, а получить сразу в руки инструмент - с каким-то вариантом ответа на эти вопроса. И пусть идут решать более сложные, более дальние задачи. И только некоторые, кому интересно, пусть остаются работать на старых рубежах и искать новые решения.

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

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

Автор:  QWERTYProgrammer [ Понедельник, 31 Январь, 2011 02:18 ]
Заголовок сообщения:  Re: Исп-е Octave/Matlab для векторно-матричных вычислений

Рыжий писал(а):
(см. Гамма и проч.)

Да, вот и Роб Пайк тоже считает, что patterns are just evidence of a failure in your notation :wink:

Автор:  Илья Ермаков [ Понедельник, 31 Январь, 2011 02:37 ]
Заголовок сообщения:  Re: Исп-е Octave/Matlab для векторно-матричных вычислений

QWERTYProgrammer писал(а):
Да, вот и Роб Пайк тоже считает, что patterns are just evidence of a failure in your notation :wink:


Угу, вот только упускается из виду - что notation и инструментальная её поддержка - наиболее трудоёмкая и наименее гибкая составляющая. Эксперименты с ней дороги, долгосрочны - и если не основаны на долгом практическом опыте и применении patterns, то обычно "пальцем в небо".

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

Автор:  Info21 [ Понедельник, 31 Январь, 2011 02:48 ]
Заголовок сообщения:  структуры данных впереди алгоритмов

Илья Ермаков писал(а):
Info21 писал(а):
Но как тогда учить, непонятно, если структуры данных вводить поперед структур управления. Ниче жужжать не будет, детишки не поймут.
....
А кстати, тут интересный пунктик.
Вот если в области БД выделить "свой Оберон", то можно, видимо, давать структурирование данных до полноценного программирования... Возможно.
То есть, что -- мини-среду "база данных"?
Почему нет.
Только нет представления, как тут можно было бы устроить.

Автор:  Илья Ермаков [ Понедельник, 31 Январь, 2011 02:58 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Увы, у меня тоже нет пока.

Автор:  Рыжий [ Понедельник, 31 Январь, 2011 13:20 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Кому как не Вам Илья знать про MUMPS. Темы типа SQL туда навешивались - леггко, дальнейшее развитие это получило в Cache и т.п. Так что, Базы данных, в этом отношении, несколько консервативнее оказались. Зачем ограничивать пользователя SQL , если в серверах речь идет о тех же B+ - деревьях и т.п. Нравиться SQL? Удобнее в конкретном случае его использовать - пожалуйста. Но институализировать - на кой? Потом все эти ограничения порождают, как следствие, массу форматов данных не нужных. А те, в свою очередь, кучу новых способов их обработки.Никакого облегчения, о котором упоминал ScrollLock не выходит. Кому нужен пресловутый XML в MUMPS, например? А вот Cache уже новый форматик прихватило. Дерево оно и есть дерево. Хоть в виде ассоциативного массива хоть чего. И так во всем. Чистейшей воды приматизм.

Автор:  Рыжий [ Понедельник, 31 Январь, 2011 13:23 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Борьба с "структурной сложностью" таким вот способом, не ведет к упрощению, а наоборот.

Автор:  Рыжий [ Понедельник, 31 Январь, 2011 13:29 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Некой "научной школе" привиделось,что SQL - лучший способ борьбы со структурной сложностью. В итоге работа с современными серверами БД превратилась в шаманство. Яркий пример. Помимо этого SQL Отвлекает от устройства БД, способов организации данных и их обработки такими, какими они есть в реальности.
А документация по этим вопросам дял SQL - серверов в рецепты правильного приготовления жабы на ивана купало в полночь.

Автор:  Рыжий [ Понедельник, 31 Январь, 2011 13:33 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Т.е. опять пример субъективизма и приматичности якобы во благо.

Автор:  Рыжий [ Понедельник, 31 Январь, 2011 13:38 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Ну и самое главное, что все это заужение пространства выбора приводит к невозможности "философского" осмысления основ. А в такой ситуации о борьбе со сложностью нечего и говорить. Т.к., при рассмотрении способов устранения этой сложности, опираются на вдолбленные в голову институализированные конструкции.
Анекдотичный пример - Euphoria. Там в виде библиотек все на свете навешано, от работы с windows - хренью, до десятка различных реализаций ООП. Не мудрено, что Вирт скуксился, когда при нем заговорили об этом языке.

Автор:  Рыжий [ Понедельник, 31 Январь, 2011 13:54 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

В теме про GOTO был явный перехлест приматизма. В PL/I вычисляемый GOTO, действительно, очень мощная конструкция. Учитывая наличие в PL/I еще и дополнительных точек входа в код процедуры - это сказка песня. GOTO, в развитой среде, это не оператор перехода, а скорее "оператор вызова". Его дальнейщее развитие привело бы к многим полезным результатам. В т.ч. и в плане борьбы со структурной сложностью. Непонятно, чем он вреден вообще. Зато хорошо понятно, чем он вреден в парадигме школы Дейкстры.
P.S. PL/I часто всплывает в связи с этими темами. Но его замочили ПК, Вирт и Дейкстра. А нынешнее поколение о нем вообще слыхом не слыхивало. Даже концепция указателя, впервые возникшая в PL/I віглядела там очень грамотно. Паскалисты и Сишники потом ее извратили путем обрезания.

Автор:  Илья Ермаков [ Понедельник, 31 Январь, 2011 14:36 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Моё мнение - современники Дейкстры были правы в максиме "долой GOTO".
Это сейчас хорошо эдак порассуждать "а вот тут, а вот так, а вот особые случаи, а вот ничего страшного нет".

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

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

Это нормальный и оптимальный путь НТР.

Ведь сейчас вы не найдёте среди даже "быдлокодеров" кого-нибудь, кто напишет "макаронную программу". Им уже практически неоткуда "всосать" такой стиль. Поэтому даже наличие-отсутствие GOTO уже совершенно некритично, а может быть в некоторой форме даже полезно, особенно в системных языках. В форме "переход только вперёд, до ближайшего END, не внутрь вложенных конструкций". Важно отсутствие break-continue, потому что следующий этап развития - выкурить это "циклоклепание".

Автор:  Alexey Veselovsky [ Понедельник, 31 Январь, 2011 15:56 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Развитие методом половинного деления :-)

Автор:  Илья Ермаков [ Понедельник, 31 Январь, 2011 16:21 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Просто самая обычная спираль... Гегелевская... или какая ещё :)

Автор:  Alexey Veselovsky [ Понедельник, 31 Январь, 2011 16:23 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Илья Ермаков писал(а):
Просто самая обычная спираль... Гегелевская... или какая ещё :)

Не, тут же не совсем спираль. Спираль подразумевает медленное приближение, а тут мы кидаемся из крайности в крайность (локальную). Т.е. таки половинное деление :-)

Автор:  Сергей Прохоренко [ Понедельник, 31 Январь, 2011 17:13 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

Илья Ермаков писал(а):
Поэтому даже наличие-отсутствие GOTO уже совершенно некритично, а может быть в некоторой форме даже полезно, особенно в системных языках. В форме "переход только вперёд, до ближайшего END, не внутрь вложенных конструкций". Важно отсутствие break-continue, потому что следующий этап развития - выкурить это "циклоклепание".


1) А для чего это может понадобиться? Реально встречаются такие ситуации? Если да, то для такой ситуации, с учетом ее особенностей, вполне можно сделать многоветочную уравляющую конструкцию типа switch без break в Си - в духе структурной парадигмы программирования. Можно даже использовать в заголовке конструкции ключевое слово goto. :D

2) Если наложить столь жесткие ограничения, то такой goto легко заменяется на невложенные IFы:

k := z;
IF k > 0 THEN
...
END;
IF k > 1 THEN
...
END;
IF k > 2 THEN
...
END;

Автор:  Илья Ермаков [ Понедельник, 31 Январь, 2011 17:29 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

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

Возможно.

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

Возьмите самый обычный ациклический алгоритм. Пусть его граф - ДАГ (= ориентированный ациклический, как граф импорта). Что в этом ДАГе плохого или неясного, с точки зрения восприятия программы или понимания её свойств? Почему всё-таки необходимо наворачивать дублирование, дополнительные переменные и проч., только лишь чтобы сделать алгоритм удобным для записи линейно-структурным текстом?

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

Автор:  Виктор О [ Понедельник, 31 Январь, 2011 19:08 ]
Заголовок сообщения:  Re: Исп-е Octave/Matlab для векторно-матричных вычислений

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

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

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

Но есть и другое мнение о личностном росте. Меня, к приммеру , учили таблице умножения (была такая штука в докомпьютерную эру), а еще умножать в столбик. Причем не только умножать, но даже и (вы не поверите!) квадратный корень извлекать. В столбик. А также в уме.

Предполагалось, что несмотря на наличие счетов и феликсов (а по городам даже и ЕэСов), считать сможет лишь тот, кто способен проверить машину. И понять, чего она там в себе делает. Страшно подумать, но есть уже программисты, неспособные перевести в ассемблер даже пару строк языка высокого уровня.

Кстати, тема о "цене" используемых конструкций тут где-то пробегала.

Автор:  Сергей Прохоренко [ Понедельник, 31 Январь, 2011 19:13 ]
Заголовок сообщения:  Re: Свежый взгляд (Рыжий vs Дейкстра и др.)

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

Автор:  Илья Ермаков [ Понедельник, 31 Январь, 2011 19:22 ]
Заголовок сообщения:  Re: Исп-е Octave/Matlab для векторно-матричных вычислений

Виктор О писал(а):
Вот и министр не понимает, зачем в школе обязательные предметы, типа математики и русского?
Когда еще в детском саду можно раздать детишкам мобилы с кверти-клавиатурой и спелчекером, и к школе они уже научатся на этом готовом инструменте брякать в твиттере.
....
Но есть и другое мнение о личностном росте. Меня, к приммеру , учили таблице умножения (была такая штука в докомпьютерную эру), а еще умножать в столбик. Причем не только умножать, но даже и (вы не поверите!) квадратный корень извлекать. В столбик. А также в уме.


Приведена куча каких-то не совсем прямых ассоциаций. Например, причём тут курс общего образования и развития личности - и проф. образование?

Если бы каждый конструктор "системы в целом" (например, самолёта) должен был бы с нуля спроектировать своими силами двигатель для него, вместо того, чтобы обратиться к двигателестроителям... Или каждый раз при разработке этого двигателя выводились бы в различных формах законы реактивного движения или методы расчёта процессов горения. Представляете - каждый гордо на коленке придумывает свой неповторимый метод это посчитать?

Формируется "стержневой набор методов", который применяется как есть. И есть люди, которые продолжают исследовать и предлагать новые методы. Но они именно этим занимаются.

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

Страница 2 из 7 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/