OberonCore :: - Семантический редактор

[Неужели таких тупых абитуриентов принимают в ВУЗы на программирование?

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

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

2. И математика - чисто прикладная наука. Ибо нафига она нужна, кроме как площади и объемы вычислять (несколько утрирую, но суть - именно такая). И программирование - чисто абстрактная наука - смотрите ссылку Женипро на статью о проекциях Футамуры и следом - смешанные вычисления Ершова.
Поэтому все зависит от взгляда.

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

Гораздо больше для ускорения работы программы может дать <тщательное структурирование программной системы "в большом">.

Более того, задача оптимизации важна только для наиболее долгих и критичных алгоритмов ... А в остальных 99% случаев (с учетом роста вычислительных мощностей ...) она вообще не имеет смысла.

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

И кстати, давно хотел задать вопрос:
если все же индекс вылетает за границу массива, то АВОСТ неизбежен?
И нет никаких средств оставить прогу на плаву?
А как же с надежностью?

И идет эффективность лесом.

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

Надежность инструмента можно понимать в двух ипостасях:
1. инструмент диктует жесткую дисциплину организации кода.

2. инструмент выполняет тотальные проверки всего и при компиляции и при выполнении.
И идет эффективность лесом.
Ы?

Повторяю, что семантикой задачи диктуется "икс в квадрате". Все остальные измышления есть синтаксис конкретного исполнителя. Учить синтаксису конкретного исполнителя необходимо в специальном профессиональном учебном заведении. В школе надо учить информатике, и в её рамках - выбору адекватного метода решения и инструмента, а вовсе не разнице между x*x и x^2.

Geniepro писал(а):

Three Futamura Projections и не только

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

И привычка видеть, как проецируется операция верхнего слоя в операцию нижнего быть должна.

Автор:	Info21 [ Суббота, 04 Июль, 2009 11:29 ]
Заголовок сообщения:	Re: Семантический редактор
Сергей Прохоренко писал(а): [Неужели таких тупых абитуриентов принимают в ВУЗы на программирование? Все-таки тут не обязательно тупость.

Автор:	Валерий Лаптев [ Суббота, 04 Июль, 2009 11:45 ]
Заголовок сообщения:	Re: Семантический редактор
Блин, чего-то я не понял. Вроде уже написал и отправил ответ, но он тут не появился. Попробую еще раз. Алексею Донскому. 1. Все ваши рассуждения о семантике верны. Но в этом случае нужно иметь соответствующий язык, в котором есть, например, только числа, а не целый набор машинно-ориентированных типов: целые, натуральные, дробные, да еще разных размеров и диапазонов (Оберон в этом случае не является исключением). Кстати, именно такой, максимально очищенный от машинных структур язык я и собираюсь зафигачить в семантический редактор - поскольку именно в первичном в обучении эффективность не важна. Но при переходе к машинной конкретике от вычислительной абстракции придется все-таки вернуться к разнице между x*x и pow(x,2) - для профессиональных программистов. А пока ваш исполнитель напоминает сферического коня в вакууме, ибо абстрактного исполнителя в жизни (и на компьютере) не бывает. 2. И математика - чисто прикладная наука. Ибо нафига она нужна, кроме как площади и объемы вычислять (несколько утрирую, но суть - именно такая). И программирование - чисто абстрактная наука - смотрите ссылку Женипро на статью о проекциях Футамуры и следом - смешанные вычисления Ершова. Поэтому все зависит от взгляда.

Автор:	Alexey_Donskoy [ Суббота, 04 Июль, 2009 12:12 ]
Заголовок сообщения:	Re: Семантический редактор
Валерий Лаптев писал(а): Но при переходе к машинной конкретике от вычислительной абстракции придется все-таки вернуться к разнице между x*x и pow(x,2) - для профессиональных программистов. Естественно. Не ставьте только во главу угла, потому как частный технический вопрос, зависит от конкретного исполнителя. Валерий Лаптев писал(а): А пока ваш исполнитель напоминает сферического коня в вакууме, ибо абстрактного исполнителя в жизни (и на компьютере) не бывает. Вообще-то я говорил как раз о конкретных исполнителях - процессорах и компиляторах. А почему мне интересен данный форум - именно потому, что здесь обсуждаются вопросы о подходе к абстрактным исполнителям (один из кандидатов - Дракон). Вопрос об абстрактном исполнителе и о переходе от абстрактного алгоритма к конкретике тех или иных процессоров я поднимал в теме Что же такое алгоритм?. Характерно, что удовлетворительного ответа пока не найдено. Валерий Лаптев писал(а): 2. И математика - чисто прикладная наука. Ибо нафига она нужна, кроме как площади и объемы вычислять (несколько утрирую, но суть - именно такая). И программирование - чисто абстрактная наука - смотрите ссылку Женипро на статью о проекциях Футамуры и следом - смешанные вычисления Ершова. Поэтому все зависит от взгляда. Естественно! Тем не менее, математика "более фундаментальна" тем, что даёт инструмент для построения адекватных моделей в подавляющем большинстве прикладных задач; информатика уже годится только для класса информационных задач, а программирование - в сугубо ограниченном сегменте таких задач.

Автор:	Alexey Veselovsky [ Суббота, 04 Июль, 2009 12:51 ]
Заголовок сообщения:	Re: Семантический редактор
Да, а 2*x тоже неправильно писать, ибо умножение суть дорогостоящая операция. Нужно писеть x+x. PS. Чем то мне ваш спор напоминает спор в вот этой ветке: viewtopic.php?f=27&t=1671 Только там обсуждается эффективность функциональных языков и можно ли полагаться на их оптимизатор, а тут в точности то же, но про императивные языки.

Автор:	Alexey_Donskoy [ Суббота, 04 Июль, 2009 13:08 ]
Заголовок сообщения:	Re: Семантический редактор
Дык, речь не об эффективности, а о том, чему стОит учить школьников, а чему - профессионалов. В профессиональном же ракурсе вопрос следует сформулировать так - нужно ли учить ручной оптимизации (каковой являются все упомянутые примеры и паттерны программирования) или лучше учить правильному мышлению, а оптимизацию возложить на инструментальные средства (компилятор в т.ч.). При этом, что такое эффективность кода, понимают все, а вот что такое эргономика (в т.ч. когнитивная) - увы

OberonCore https://forum.oberoncore.ru/

Семантический редактор https://forum.oberoncore.ru/viewtopic.php?f=93&t=1542	Страница 4 из 34

Автор:	Сергей Прохоренко [ Суббота, 04 Июль, 2009 22:47 ]
Заголовок сообщения:	Re: Семантический редактор
Честно говоря, задача оптимизации в той форме, в которой она здесь обсуждалась, мне кажется вообще не заслуживающей внимания. Эффект от такой оптимизации в масштабе крупной программной системы будет незаметен. Гораздо больше для ускорения работы программы может дать уменьшение обращений к жесткому диску, грамотно расставленные приоритеты обработки прерываний (чтобы пользователь не смотрел бессильно на "песочные часы"), меньшая зависимость от пропускной способности канала, вдумчивое разбиение программы на загружаемые модули и т.п. более высокоуровневые задачи, требующие соответствующих инструментальных средств проектирования архитектуры программной системы. Более того, задача оптимизации важна только для наиболее долгих и критичных алгоритмов в системах жесткого реального времени. А в остальных 99% случаев (с учетом роста вычислительных мощностей, развития облачных вычислений и т.п.) она вообще не имеет смысла. А вот задача повышения надежности программных систем (от боевых, транспортных и медицинских систем до корпоративных транзакционных систем) пользуется гораздо меньшим вниманием. И именно этому надо бы учить, а соответствующих инструментальных средств до сих пор нет. Наконец, разработка, отладка, интеграция и модификация программных продуктов отъедает все большие и большие бюджеты. Надо учить писать быстро модифицируемые программы с небольшой совокупной стоимостью владения. Для этого пока тоже нет никакого инструментария. Еще одна проблема - научить писать такие программы, с которыми легко могли бы обращаться пользователи - непрограммисты, адаптируя их под себя. Такие программы пока можно пересчитать по пальцам одной руки. В остальных случаях пользователи вынуждены долго ждать, пока программисты им "передвинут запятую". Иногда инструментарий для этого есть (например, Business Intelligence), но доступ к нему закрыт лицензиями и астрономическими ценами. Общий вывод: инструментарий должен прежде всего позволять быстро и безошибочно создавать правильную архитектуру программного продукта и легко ее модифицировать (в т.ч. силами пользователей - непрограммистов), а не выискивать блох типа x*x vs. pow(x,2). В крайнем случае для этого всегда можно найти "оптимизатора", которых миллион на всех программистских форумах.

Автор:	Alexey_Donskoy [ Воскресенье, 05 Июль, 2009 07:50 ]
Заголовок сообщения:	Re: Семантический редактор
Ага. Только не "выискивать блох", а правильно сформировать направления в обучении. И акценты расставить. Для топика - "семантический редактор" вообще должен бы оперировать высокоуровневыми конструкциями. Даже абстракция цикла на начальном этапе решения задачи есть низкоуровневая техническая мелочь. Типовой учебный пример. Дано: трансцендентное уравнение. Задача: найти корни. Используемая семантика: выбор метода, преобразование уравнения. Всё! Сугубо учебный пример: реализация метода. Семантика: итерации, вычисление формулы, оценка точности. Ну и т.д., вплоть до ассемблера и маш.кодов , если кому приспичит с учебной целью... Кстати, вот. Написал про выбор метода... А зачем? Что, мы итерации на линейке логарифмической считать будем? Какой смысл сегодня в использовании, скажем, метода Ньютона? Простого половинного деления хватит для 99.99% практических случаев!

Автор:	Info21 [ Воскресенье, 05 Июль, 2009 09:15 ]
Заголовок сообщения:	Re: Семантический редактор
Сергей Прохоренко писал(а): ... задача оптимизации в той форме, в которой она здесь обсуждалась, мне кажется вообще не заслуживающей внимания. Эффект от такой оптимизации в масштабе крупной программной системы будет незаметен. Гораздо больше для ускорения работы программы может дать <тщательное структурирование программной системы "в большом">. Более того, задача оптимизации важна только для наиболее долгих и критичных алгоритмов ... А в остальных 99% случаев (с учетом роста вычислительных мощностей ...) она вообще не имеет смысла. А вот задача повышения надежности программных систем (от боевых, транспортных и медицинских систем до корпоративных транзакционных систем) пользуется гораздо меньшим вниманием. ... Золотые слова. Работаем ровно в этом направлении. Беда в том, что комбинаторные игры с мелкой оптимизацией легко затягивают (1й умотип), и чтобы сопротивляться, нужна некая ментальная дисциплина, достигаемая только (если говорить о массовом масштабе) достаточно длительным правильным твердым обучением. А для возникновения системы такого обучения требуется либо много времени (поколения), либо жесткое внедрение.

Автор:	Валерий Лаптев [ Воскресенье, 05 Июль, 2009 16:40 ]
Заголовок сообщения:	Re: Семантический редактор
Возникла мысль, и я ее думаю: повышение надежности разрабатываемых систем, в первую очередь, упирается в надежность инструмента, на котором пишется система, и в специальную организацию кода. Например, локализация аварийных ситуаций только тем модулем, где возникла, и разруливание этой ситуации там же на месте. Надежность инструмента можно понимать в двух ипостасях: 1. инструмент диктует жесткую дисциплину организации кода. 2. инструмент выполняет тотальные проверки всего и при компиляции и при выполнении. И идет эффективность лесом. Ы?

Автор:	Сергей Прохоренко [ Воскресенье, 05 Июль, 2009 20:52 ]
Заголовок сообщения:	Re: Семантический редактор
Валерий Лаптев писал(а): Возникла мысль, и я ее думаю: повышение надежности разрабатываемых систем, в первую очередь, упирается в надежность инструмента, на котором пишется система, и в специальную организацию кода. Например, локализация аварийных ситуаций только тем модулем, где возникла, и разруливание этой ситуации там же на месте. Не всегда. Иногда должна вмешаться "центральная нервная система, эндокринная система или имунная система", а иногда поможет только напарник или "реаниматолог", то есть модуль-контролер. Мне кажется, что аналогии с живыми организмами, чья отказоустойчивость изумляет, здесь очень уместна. Вообще же отказоустойчивость - это целая наука: http://en.wikipedia.org/wiki/Fault-tolerant_system Валерий Лаптев писал(а): Надежность инструмента можно понимать в двух ипостасях: 1. инструмент диктует жесткую дисциплину организации кода. Это идеал! Валерий Лаптев писал(а): 2. инструмент выполняет тотальные проверки всего и при компиляции и при выполнении. И идет эффективность лесом. Ы? При помодульной отладке время компиляции никого уже особо не волнует. Что касается проверок при выполнении, то с этим придется смириться. Программист ОБЯЗАН предусмотреть и, если необходимо, указать действия системы во всех исключительных ситуациях, возникающих при ошибках времени исполнения (возможный выход вводимой переменной за пределы допустимого диапазона значений, недопустимое отклонение расчетной величины от контрольного значения, противоречивые данные, отсутствие необходимых данных и т.п.), иначе компилятор не должен принимать исходный код. Для этого инструментарий должен показать программисту все возможные места возникновения ошибок времени исполнения. Кроме того, инструментарий должен содержать механизмы разруливания исключительных ситуаций "по умолчанию" и, может быть, какие-то сценарии, из которых программист выберет один. Критичная система может содержать механизмы самообучения в процессе тестирования и генерить тестовые данные, но вряд ли это удастся как-то встроить в инструментарий. В то же время, проверки времени исполнения должны осуществляться как параллельные процессы, чтобы не тормозить основной алгоритм. Тогда все забудут даже слово такое - "эффективность".

Автор:	Илья Ермаков [ Воскресенье, 05 Июль, 2009 21:59 ]
Заголовок сообщения:	Re: Семантический редактор
Geniepro писал(а): Three Futamura Projections и не только Вообще-то, они всегда назывались "проекции Ершова-Футамуры". Народ своих книг старых не читает, а всасывает всё как откровения понятно откуда...

Автор:	Geniepro [ Воскресенье, 05 Июль, 2009 22:41 ]
Заголовок сообщения:	Re: Семантический редактор
Илья Ермаков писал(а): Geniepro писал(а): Three Futamura Projections и не только Вообще-то, они всегда назывались "проекции Ершова-Футамуры". Народ своих книг старых не читает, а всасывает всё как откровения понятно откуда... Вот так вот хреново у нас с пропагандой своих открытий. Делать умеем, а делиться ими -- нет. "А потом вопим -- караул! украли!" ЗЫ. Даже гугл -- и тот не знает о "проекциях Ершова-Футамуры".

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