DRAKON.SU https://forum.drakon.su/ |
|
Язык ДРАКОН и улучшение работы ума https://forum.drakon.su/viewtopic.php?f=62&t=5897 |
Страница 1 из 1 |
Автор: | Владимир Паронджанов [ Пятница, 23 Сентябрь, 2016 12:04 ] |
Заголовок сообщения: | Язык ДРАКОН и улучшение работы ума |
В книге "Как улучшить работу ума" я впервые подробно изложил идею языка ДРАКОН. Там же я попытался объяснить, как алгоритмический язык (язык представления процедурных знаний) связан с идеей улучшения работы человеческого ума. Поводом для этой темы послужил перепост Ильи Ермакова из Хабра, который я цитирую ниже: viewtopic.php?f=27&t=4278 Илья Ермаков писал(а): http://habrahabr.ru/post/170443/
Цитата: Visual Studio нам помогает, но она также толкает нас к написанию (или не написанию) кода специфическим путём. Среда направляет нас. Делает ли это нас более продуктивными? Я даже не знаю как измерить продуктивность разработчика, так что я не могу дать ответ. Учимся ли мы, когда программируем таким способом? Я бы сказал – не особо. Несмотря на то, что Visual Studio, во многом, является впечатляющим и весьма полезным программным обеспечением, меня беспокоит то, что я очень зависим от неё. Чтобы изучить новые методики, я пытаюсь следить за тем, что происходит вне .NET\Microsoft экосистемы. ... Однако, я чувствую себя скованным из-за моей зависимости от Visual Studio. Я хочу изучать и использовать множество других технологий, как и .NET, так что я совсем не ищу инструментов, которые будут усиливать мои узы с Visual Studio. Использование простой обыкновенной Visual Studio [без продвинутых средств типа ReSharper] – наименьшее, что я могу сделать для расширения своих горизонтов. Цитата: Основным аргументом «за» инструменты повышения производительности является то, что их использование делает вас более эффективным программистом. «Без ReSharper моя производительность падает на 50%, я удивлён, что вы можете справлять без него». Это очень интересное утверждение. А как вы вообще измеряете производительность? Во имя аргументации, давайте на минуту сделаем вид, что производительность программиста измеряется количеством написанных строк кода. Существует довольно распространённый миф о том, что профессиональный программист пишет всего 10 строк кода в день. Возможно, это не правда, но даже если так, то какое количество строк в день вы пишете в среднем? 100? 200? Действительно ли вы собираетесь утверждать, что узкое горлышко вашей производительности определяется тем, как быстро вы можете печатать? Серьёзно? Тогда учитесь печатать быстрее. Положим, что большую часть времени, код читают, а не пишут. Код должен быть оптимизирован для чтения, а не для написания. Таким образом, производительность, если она вообще может быть измерена, должна измеряться тем как быстро программисты смогут прочитать и понять кусок кода, а не тем, как быстро этот кусок кода может быть написан. Более того, если вы считаете, что парное программирование это хороший и эффективный способ производства программного обеспечения, то вы также должны понимать, что при парном программировании в каждый отдельно взятый момент, как минимум один человек вообще ничего не печатает. Как разъяснил это Мартин Фаулер: «Парное программирование сокращало бы производительность наполовину, если бы самой сложной частью программирования было печатание». По моему опыту, печатание – не самая сложная часть. Таким образом, я не убеждён в том, что «инструменты повышения производительности» делают кого-то более эффективным программистом. Цитата: Чарльз Петцольд обратил в своей замечательной статьей внимание на то, что Visual Studio принуждает к стилю разработке снизу-вверх, что не очень вяжется с потребностями бизнеса. Visual Studio (с инструментом повышения производительности или без) делает сложной (но не невозможной) разработку «снаружи-внутрь». Я полагаю, что помогая действовать нам строго определённым образом, инструмент закрывает для нас множество других возможностей. Мы можем даже не подозревать о том, что от нас остаётся скрытым, но если мы сможем отделаться от подобной руки помощи, то мы, возможно, сможем увидеть и другие возможности. Я не против того, чтобы инструмент мне изредка помогал, но в остальное время я бы предпочёл принимать обоснованное решение, с учётом всей имеющейся информации самостоятельно. Я думаю, что, по крайней мере нужно понимать, что принятие помощи означает принятие решений за нас. Получается не беспроигрышная ситуация. Может быть я и получаю возможность завершить задание быстрее, но лишаюсь возможности учиться. Мало того, чем больше я полагаюсь на содействие инструмента, тем более зависимым от него я становлюсь. Для обозначения такой ситуации даже слово специальное есть. Оно звучит как «вендор-запирание» (vendor lock-in). |
Автор: | andr [ Суббота, 24 Сентябрь, 2016 07:03 ] |
Заголовок сообщения: | Re: Язык ДРАКОН и улучшение работы ума |
Владимир Паронджанов писал(а): В книге "Как улучшить работу ума" я впервые подробно изложил идею языка ДРАКОН. Там же я попытался объяснить, как алгоритмический язык (язык представления процедурных знаний) связан с идеей улучшения работы человеческого ума. Поводом для этой темы послужил перепост Ильи Ирмакова из Хабра, который я цитирую ниже: viewtopic.php?f=27&t=4278 Илья Ермаков писал(а): http://habrahabr.ru/post/170443/ Цитата: Чарльз Петцольд обратил в своей замечательной статьей внимание на то, что Visual Studio принуждает к стилю разработке снизу-вверх, что не очень вяжется с потребностями бизнеса. Visual Studio (с инструментом повышения производительности или без) делает сложной (но не невозможной) разработку «снаружи-внутрь». Первый раз встречаю выражение типа: разработка снаружи-внутрь. Всю (сознательную) жизнь разработок в области автоматизации производства с управлением на компьютерной основе (где-то с начала 70-х) знал и применял направления разработок: сверху вниз, снизу вверх и от середины вниз и вниз. Выражение "от середины вниз и вверх" впервые встретил в публикациях команды академика Глушкова В.М. в области АСУ. С тех пор сознательно не заморачивался жестким требованием одного подхода (сверху или снизу). Да и реально в разработках, хочешь-не-хочешь, параллельно работают все три эти подхода. Но ведущее направление разработок сверху вниз: -- как обязательное условия для изначального обеспечения системной целостности представлений; -- как средство (одно из средств) борьбы со сложностью и т.п. Но оно сопровождается гибким переходом на другие направления по мере необходимости. А в изложении системного описания разработанных объектов автоматизации уже обязательно (достаточно жестко) принимается направление сверху вниз. Но и здесь иногда случается заглянуть вперед (вниз) - для ясности изложения. --------------------------- Это относится (точнее относилось при коммунизме) к общим (системным) разработкам технологических автоматизированных (и роботизированных) систем и подсистем АСУП и АСУТП. При этом сначала стихийно, а затем сознательно пришлось осваивать алгоритмизацию разработок: 1 Для алгоритмического описания работы технологических автоматизированных систем : здесь до сих пор большие проблемы. 2 Для алгоритмического описания программных разработок - совместно с программистами: -- убедился, что заставить программиста писать алгоритмы - это только с ревом, со слезами, причем "много шуму, мало шерсти", как сказал черт, пытаясь постричь кошку; -- позднее стал понимать, что параллельно программисту должен работать специалист по программной документации (это разные культуры - генерить исходные коды и программную документацию); -- позднее это стало увязываться с работой системного аналитика в автоматизации проектирования программных систем. К сожалению, специальности системотехника и системного аналитика исчезли из обучения, сейчас идут бакалавры (недоученные инженеры) широкого профиля, и часть из них выходит на магистров - с защитой не проектов, а магистерских диссертаций (недоученных ученых). Куды котимся? ----------------------------- В разработках программных систем использовал и использую все три направления. Не очень понятно сетование на Visual Studio типа: Цитата: Visual Studio принуждает к стилю разработке снизу-вверх Для разработок программ сверху вниз на любом уровне используются заглушки вызовов подпрограмм и любой программной единицы: пустые подпрограммы или подпрограммы с выводом сообщения о вызове. И в принципе можно сходу вести отладку это программной единицы. ----------------------- Более того, от студентов, которые мне что-то там программируют, на любом уровне требую: 1) начинать с пустого алгоритма типа: Ai = () 2) с соответствующего псевдокода - под конкретный язык, типа: alg Ai begin end alg Ai() { } 3) с выходом на исходный код и его отладку 4) с последующим пошаговым наполнением алгоритма и его программной реализации. 5) И с самого начала - пошаговая визуализация алгоритма: большая работа, но хорошая отладка, например, блок-схемы алгоритма. Но это все - только в идеале. Достаточно редко попадаются работящие и инициативные в этом отношении студенты. Основная масса тянет до упора (под конец семестра) - что-то принесет и слава богу: идет продвижение по мелочам, но по широкому фронту (в общей массе). Все это связано с тем обстоятельством, что параллельные алгоритмы и программы у меня пока идут вставками в разные другие другие дисциплины. =================== Но в личных программных разработках - все это не так, все не по таким красивым правилам. Такова сель-ави. Увы мне. Точнее так только в разработках примеров программной реализации параллельных алгоритмов на разных языках программирования: как примеры к структурной теории параллельных алгоритмов. Сейчас есть личные программные разработки только по простым учебным средам по автоматизации схемных построений алгоритмов и временных диаграмм (и сводные комплекты примеров с динамическими мнемосхемами объектов управления): все это делается в темпе (второпях), на колене, без проектирования. Но очень внимательно и точно, по-возможности, комментирую исходные тексты: не раз проверял - позднее, на доработках, когда все позабыл, это помогает разобраться и вспомнить, что хотел. Такова реальная диалектика параллельной теории и практики (в личных масштабах). ================== Но концепция программирования "снаружи внутрь" хороша. Это не просто сверху вниз. Здесь что-то еще теплится. |
Автор: | andr [ Суббота, 24 Сентябрь, 2016 11:07 ] |
Заголовок сообщения: | Re: Язык ДРАКОН и улучшение работы ума |
andr писал(а): Всю (сознательную) жизнь разработок в области автоматизации производства с управлением на компьютерной основе (где-то с начала 70-х) знал и применял направления разработок: сверху вниз, снизу вверх и от середины вниз и вниз. Ошибочка вышла. Надо: от середины вверх и вниз. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |