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 |
Автор: | Илья Ермаков [ Понедельник, 31 Январь, 2011 02:37 ] |
Заголовок сообщения: | Re: Исп-е Octave/Matlab для векторно-матричных вычислений |
QWERTYProgrammer писал(а): Да, вот и Роб Пайк тоже считает, что patterns are just evidence of a failure in your notation Угу, вот только упускается из виду - что 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. 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/ |