Здравствуйте, Undying, Вы писали:
U>Кстати, за что не люблю математику это за ее способность делать простое сложным. Для объяснения механизма тут достаточно одной фразы: при DELETE и POST происходит сброс кэшей, при GET — нет. Никакой математики и заумных терминов тут даром не надо.
Любое обобщение это и усложнение и универсализация (повторное использование).
Здравствуйте, Sinclair, Вы писали:
S>В этом, в частности, и есть проблема. К примеру, многие гражданские инженеры понимают, что они пользуются математикой. Поэтому мосты, скажем, падают редко. А большинство программистов — не понимают, что пользуются математикой. Поэтому их программы падают часто
Главная проблема надежности программирования в невозможности проверить все ли варианты были рассмотрены. Тестирование и иногда математика могут помочь лишь проверить обрабатывается ли правильно конкретный вариант, но не могут определить сколько и каких вариантов надо рассмотреть всего, чтобы гарантировать надежность и правильность работы.
В строительстве мостов набор влияющих факторов почти не меняется от моста к мосту, соответственно давно известен. Поэтому математическим преобразованием этих факторов и умножением полученного результата на три можно добиться высокой надежности. В программировании этот подход не работает, т.к. у каждой программы набор влияющих факторов свой.
Здравствуйте, samius, Вы писали:
S>Уточню, что в С нет вообще никакого наследования, и в частности, интерфейсов там тоже нет. Соответственно создание полиморфного поведения объекта без ветвлений (if/switch) требует ручной эмуляции VMT.
Суть полиморфизма вовсе не в отказе от ветвлений. А в том, что код выбора нужного метода для текущего состояния пишется один раз, а не дублируется при каждом вызове. И на C это делается без особых проблем. Проблема C в другом, он позволяет инкапсулировать выбор метода, но не позволяет инкапсулировать данные, т.е. в рамках C мы вынуждены передавать методу инкапсулирующему выбор жирную структуру данных, которая должна быть способна хранить данные и для первой реализации метода, и для второй, и для десятой.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, samius, Вы писали:
S>>Уточню, что в С нет вообще никакого наследования, и в частности, интерфейсов там тоже нет. Соответственно создание полиморфного поведения объекта без ветвлений (if/switch) требует ручной эмуляции VMT.
U>Суть полиморфизма вовсе не в отказе от ветвлений. А в том, что код выбора нужного метода для текущего состояния пишется один раз, а не дублируется при каждом вызове.
В языках с поддержкой ad-hoc полиморфизма код выбора нужного метода не пишется вообще ни разу (если не вспоминать о множественной диспетчеризации).
U>И на C это делается без особых проблем.
Особых нет, но вообще они есть. Иначе нафига бы нужна была поддержка в других языках.
U>Проблема C в другом, он позволяет инкапсулировать выбор метода, но не позволяет инкапсулировать данные, т.е. в рамках C мы вынуждены передавать методу инкапсулирующему выбор жирную структуру данных, которая должна быть способна хранить данные и для первой реализации метода, и для второй, и для десятой. SelectObject видел? Никаких жирных структур с данными для десяти реализаций. Точнее, как оно там на самом деле — я не знаю, но барьер абстракции позволяет спокойно использовать специальные структуры для каждого случая, т.е. инкапсулировать данные.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Sinclair, Вы писали:
S>>В этом, в частности, и есть проблема. К примеру, многие гражданские инженеры понимают, что они пользуются математикой. Поэтому мосты, скажем, падают редко. А большинство программистов — не понимают, что пользуются математикой. Поэтому их программы падают часто
U>Главная проблема надежности программирования в невозможности проверить все ли варианты были рассмотрены. Тестирование и иногда математика могут помочь лишь проверить обрабатывается ли правильно конкретный вариант, но не могут определить сколько и каких вариантов надо рассмотреть всего, чтобы гарантировать надежность и правильность работы.
Если это софт для какой-нить АЭС, то тебя вполне могут попросить еще и доказать коректность используемых алгоритмов/кода, чтобы гарантировать надежность и правильность. Ну а так это извечное соотнощение цена/качество, есть коррекность некритична, то и тесты подойдут.
Опять же, всякие системы для проверки корректности многопоточных алгоритмов...
Здравствуйте, Sinclair, Вы писали:
S>Вы — не использовали. А зря. Одной фиксированности последовательности недостаточно для того, чтобы выбрать массив. Нужно ещё учитывать то, какие операции будут выполняться. К примеру, если часто выполняется поиск в этой коллекции, то дерево всё ещё может оказаться эффективнее массива.
В первую очередь нам нужно понять, что в задаче есть сущность, которую следует представить как набор данных и что в этом наборе данных нужно производить поиск по таким-то параметрам. На этом этапе математика нам ничем помочь не может. После этого, да, при выборе подходящего контейнера под набор данных в том числе используется и математика. Т.е. математика это обычный инструмент, как и любой другой инструмент незаменимый в некоторых случаях и совершенно не нужный в других.
S>Это нам даёт возможность выполнять рассуждения, не вдаваясь в то, что именно делает программа. Например, можно доказать некоторые вещи — типа type safety, проверяемой верификатором в дотнете.
Ты что доказываешь? То что все программирование это математика? Тогда покажи каким образом математика позволяет 1) записать условие произвольной задачи программирования 2) преобразовать полученное условие задачи в программный код 3) убедиться, что полученный программный код решает поставленную задачу.
Корректность типов это необходимое, но и близко недостаточное условие для работоспособности программы.
Здравствуйте, Sinclair, Вы писали:
S>Совершенно верно. Вы выполняете преобразование реальных сущностей в абстрактные в рамках прикладного программирования. А в дальнейшем работаете исключительно математикой. Просто вы не всегда это осознаёте.
Нет, я не работаю дальше исключительно математикой. Т.к. пользуясь исключительно математикой нельзя ни понять что нужно сделать с полученными абстрактными сущностями, ни убедиться в том, что записанное преобразование абстрактных сущностей правильно решает поставленную задачу.
S>Осознание математичности программирования помогает писать более хорошие программы. Например, понимание отличий stateless от stateful на математическом, а не образном уровне, помогает делать осознанный выбор между ними и избегать "гибридных" реализаций, обладающих недостатками обоих вариантов.
Поподробнее можно. В чем проблема гибридных реализаций?
Здравствуйте, Ziaw, Вы писали:
Z>Ну так это частные приемы в частных языках. К программированию вообще они имеют мало отношения. На универсальную нотацию не тянут.
Упаси господь, где я предлагал паттерны программирования как универсальную нотацию? Мне просто было интересно как паттерны записываются на математическом языке. Но потом меня просветили, что любой язык программирования это математический язык и что те кто говорят о необходимости близости синтаксиса языка программирования к математической нотации не понимают что относится к математике, а что нет.
U>Согласно стандарту HTTP, запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
Safe является более сильной гарантией, чем идемпотентность.
U>И причем здесь математика? Обычный хак, т.е. решение корректное использование которого неочевидно и возможно только после прочтения документации. Прочтение документации уже стало математическим актом?
Ну так всю математику можно считать хаком. Вот то же БПФ — это же хак! Корректное использование свойств комплексной экспоненты в алгоритме кули-тьюки невозможно без прочтения "документации".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Undying, Вы писали: U>Кстати, за что не люблю математику это за ее способность делать простое сложным. Для объяснения механизма тут достаточно одной фразы: при DELETE и POST происходит сброс кэшей, при GET — нет. Никакой математики и заумных терминов тут даром не надо.
А я люблю — за то, что она делает смутное понятным. В приведённой формулировке фраза не является корректной. И даже если бы она была корректной, то она никак не помогает писать правильные приложения — потому что непонятно, нужно ли "сбрасывать кэш" или нет в каждом конкретном случае. Именно из таких вот "народных примет" и получаются неэффективные и глючащие веб-приложения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Undying, Вы писали:
U>В первую очередь нам нужно понять, что в задаче есть сущность, которую следует представить как набор данных и что в этом наборе данных нужно производить поиск по таким-то параметрам. На этом этапе математика нам ничем помочь не может.
Совершенно верно. U>После этого, да, при выборе подходящего контейнера под набор данных в том числе используется и математика. Т.е. математика это обычный инструмент, как и любой другой инструмент незаменимый в некоторых случаях и совершенно не нужный в других.
А кто-то претендовал на то, что этот инструмент — необычный?
U>Ты что доказываешь? То что все программирование это математика? Тогда покажи каким образом математика позволяет 1) записать условие произвольной задачи программирования 2) преобразовать полученное условие задачи в программный код 3) убедиться, что полученный программный код решает поставленную задачу.
Ну, в общем-то, все современные языки программирования — они именно про это. Пишешь условия на С#, компилятор и джит преобразуют их в машинный код, который в большинстве случаев (кроме багов в компиляторе и джите) решает ровно поставленную задачу. Чем большую часть условия задачи вы можете описать формально, тем больше шансов на строгое доказательство корректности решения. См. например generic collections по сравнению со старым List.
U>Корректность типов это необходимое, но и близко недостаточное условие для работоспособности программы.
Корректность типов — это то, что можно проверить в условиях задачи, записанных на языке программирования.
Поясню на примере из другой области: артиллерист наводит орудие по таблицам, рассчитанным при помощи математики. Это не означает, что математика объяснит ему ещё и как заряжать снаряд и как сделать так, чтобы расчёт не разбежался. Но без математики его шансы попасть в противника совсем никакие.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Undying, Вы писали:
U>Нет, я не работаю дальше исключительно математикой. Т.к. пользуясь исключительно математикой нельзя ни понять что нужно сделать с полученными абстрактными сущностями, ни убедиться в том, что записанное преобразование абстрактных сущностей правильно решает поставленную задачу.
Первое — нельзя. Второе — можно.
U>Поподробнее можно. В чем проблема гибридных реализаций?
У них плохая производительность stateless сочетается с плохой масштабируемостью stateful.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Шахтер, Вы писали:
Ш>Я знаю, что такое поле Галуа, я спросил, что такое "алгебра полей Галуа". Ш>Правильный ответ -- это произвольная комбинация слов.
Гм. Я, возможно, как-то неправильно употребляю термины. Но с моей, непрофессиональной точки зрения, поле Галуа — это алгебраическая система. Именно але
Ш>Я спрашивал, какое отношение БПФ имеет к полям Галуа. Ш>Правильный ответ -- никакого.
Почему же? Если верить википедии, Many FFT algorithms only depend on the fact that is an Nth primitive root of unity, and thus can be applied to analogous transforms over any finite field. То есть их можно применять к аналогичным преобразованиям над произвольными полями Галуа.
Ш>Совсем тяжелый случай. ООП не имеет каких-то математических основ. Совсем.
А вы пробовали читать по ссылке?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
U>Согласно стандарту HTTP, запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
Да, на всякий случай, дополню: русскоязычная википедия, как и во многих других случаях, в процитированной статье содержит ошибку.
Если посмотреть на оригинал, куда ссылается сносочка из процитированной фразы, ошибка станет очевидной.
Во-первых, подчёркивается идемпотентность GET, как бы противопоставляя его остальным методам. В то время, как неидемпотентный метод в HTTP/1.1 ровно один. Это не совсем ошибка — строго говоря, фраза корректна. Скорее введение в заблуждение.
Во-вторых, индукция "Это позволяет кэшировать" абсолютно неверна.
Если бы она была верна, то и можно было бы кэшировать результаты любого другого идемпотентного метода, и нельзя было бы кэшровать результаты неидемпотетного. Тем не менее, для идемпотентных PUT и DELETE читаем "Responses to this method are not cacheable", а для неидемпотентного Post читаем "Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields". Т.е. всё же иногда ответы могут кэшироваться.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, gandjustas, Вы писали:
LVV>>>>>Сравнивали G>>>>А количество? LVV>>>Группа — 30 человек. G>>То есть преподаватель один? Выборка нерепрезентативна. LVV>F мы и не собирались Заниматься наукой, а стремились получить опыт.
Лет 30-40 назад, еще при советском союзе было очень модно заниматься внедрением новых методик обучения. Были съезды преподавателей, где они делились опытом, выступали ведущие новаторы итд. Вот только большинство не могло эти методики использовать, не получалось ничего хорошего.
В итоге оказалось что все эти новаторы были сами по себе очень харизматичными, грамотными и талантливыми людьми. Им удавалось использовать любые методики.
LVV>>>1. пока a > 10 делать ... конец пока; — это учить не надо. Это читается и понятно без специальной учебы. Причем, даже третьекласснику. G>>Читаться может и читается, но не понимается смысла этого. В этом и разница естественного языка и формальной нотации. LVV>Еще как понимается — см. выше "опыт"...
Когда есть опыт тогда нотация пофиг, человек обязательно увидит знакомые конструкции (паттерны) за любой чередой символов.
А вот когда опыта нет — вопрос гораздо интереснее.
LVV>>>2. Не приведете линки на исследования по "соотношение сигнала\шума"? G>>Я их не собираю, но можно провести простой эксперимент реализовав на pascal и c примерно одинковый функционал посчитать количество символов. В pascal будет больше за счет begin\end, procedure\function и array of. LVV>То есть исследований тоже нет...
Вы сами можете провести эксперимент, даже времени много не понадобится.
LVV>Вы забываете, что не язык является целью обучения, а программирование. Язык только инструмент обучения.
Слышал я это. А ты знаешь что язык влияет на мышление (это я про человеческий язык), а идиомы компьютерного языка на мышление человека как программиста влияют еще больше. Ты сам со своим blackbox показываешь это очень ярко.
Вот скажи, как обучить человека на pascal, да еще и с русским синтаксисом, чтобы он потом смог написать программу на haskell?
LVV>Летчиков учат на кукурузнике, а летают они на совсем других самолетах.
Неправда. Применяются учебно-боевые самолеты, в которых параметры управляемости настраиваются чтобы сымитировать реальный самолет. И то только потому что самолеты дорогие.
А то что по факту много где учать на кукурузнике — только от бедности.
LVV>Водители новички и водители профи — ездят на разных машинах.
Тоже неверно. Вроде даже хотели разделить права на категории водителей с автоматический коробкой и механической. Это разные водители.
Аналогично обучаясь программированию на языке Х получаются программисты на Х. А если Х — не используемый на практике, то такие программисты не нужны.
LVV>Музыканты-новички и музыканты-профи byhf.n на разных инструментах. Ага, новички на баяне, а профи на гитаре.
LVV>Спортсмены-новички и спортсмены-профи — просто в разных кроссовках бегают, не говоря уже о всяком другом инвентаре (например, стрелки или велосипедисты).
Вообще-то все спортсмены в разных бегают. Но если рассмотреть инвентарь любых спортсменов, то он зависит только от количества денег которые на это готовы потратить.
LVV>Так что инструменты для обучения и инструменты для профессиональной деятельности во всех сферах деятельности — РАЗНЫЕ!
1) Все что ты привел — неправда
2) Аналогии лживы, ты не доказал что любая из аналогий верна
Вообщек довольно страшное заблуждение что обучать программированию можно на любом языке. Для этого язык должен быть достаточно высокоуровневым и мощным. Паскаль сюда точно не подходит, оберон кстати тоже.
Z>>Ну так это частные приемы в частных языках. К программированию вообще они имеют мало отношения. На универсальную нотацию не тянут.
U>Упаси господь, где я предлагал паттерны программирования как универсальную нотацию? Мне просто было интересно как паттерны записываются на математическом языке.
Здравствуйте, Sinclair, Вы писали:
U>>Кстати, за что не люблю математику это за ее способность делать простое сложным. Для объяснения механизма тут достаточно одной фразы: при DELETE и POST происходит сброс кэшей, при GET — нет. Никакой математики и заумных терминов тут даром не надо. S>А я люблю — за то, что она делает смутное понятным. В приведённой формулировке фраза не является корректной. И даже если бы она была корректной, то она никак не помогает писать правильные приложения — потому что непонятно, нужно ли "сбрасывать кэш" или нет в каждом конкретном случае. Именно из таких вот "народных примет" и получаются неэффективные и глючащие веб-приложения.
У тебя с пониманием русского языка как? Как после "происходит сброс кэша" может быть нужен "ручной сброс кэша"?
Здравствуйте, Sinclair, Вы писали:
S>Если бы она была верна, то и можно было бы кэшировать результаты любого другого идемпотентного метода, и нельзя было бы кэшровать результаты неидемпотетного.
Поэтому для понимания происходящего в данном случае термин "идемпотентность" является мусорным. Важным является разделение обращений на меняющие и не меняющие данные. И как следствие, на те при которых происходит сброс кэшей и при которых нет. В начальном сообщении ты обращение не сбрасывающее кэши назвал термином "безопасное", но это очень неудачный термин для описания происходящего, т.к. интуитивно этот термин с использованием кэша никак не ассоциируется.
S>Тем не менее, для идемпотентных PUT и DELETE читаем "Responses to this method are not cacheable", а для неидемпотентного Post читаем "Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields". Т.е. всё же иногда ответы могут кэшироваться.
Т.е. объяснение нужно дополнить тем, что в POST есть хак, позволяющий вручную отключить сброс кэшей.
Здравствуйте, Undying, Вы писали:
U>Поэтому для понимания происходящего в данном случае термин "идемпотентность" является мусорным. Важным является разделение обращений на меняющие и не меняющие данные.
Важным является разделение обращений на те, которые
а) не меняют данные
б) приводят данные в одно и то же целевое состояние при повторном выполнении
в) все остальные.
U>И как следствие, на те при которых происходит сброс кэшей и при которых нет. В начальном сообщении ты обращение не сбрасывающее кэши назвал термином "безопасное", но это очень неудачный термин для описания происходящего, т.к. интуитивно этот термин с использованием кэша никак не ассоциируется.
Это проблема не термина, а вашей интуиции. Я неоднократно говорил — интуицию надо тренировать.
Для двух из трёх видов обращений, которые я перечислил выше, спецификация вводит специальные термины. Которые позволяют избегать в общении и мышлении громоздких конструкций вроде "приводят данные в одно и то же целевое состояние при повторном выполнении", а обходится словом "идемпотентный".
U>Т.е. объяснение нужно дополнить тем, что в POST есть хак, позволяющий вручную отключить сброс кэшей.
Сила математики — в том, что она сокращает количество "сущностей", с которыми надо работать. Вы сейчас пытаетесь представить программирование как набор заученных наизусть "хаков", каждый из которых никак не связан с остальными.
Это — народные приметы, вроде "ласточка низко летает — к дождю".
И даже в этом конкретном топике, при обсуждении тривиальнейших вещей вроде поведения протокола HTTP, ваш продход пробуксовывает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ага, новички на баяне, а профи на гитаре.
