DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 10:51

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 3 ] 
Автор Сообщение
СообщениеДобавлено: Пятница, 23 Сентябрь, 2016 12:04 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В книге "Как улучшить работу ума" я впервые подробно изложил идею языка ДРАКОН.
Там же я попытался объяснить, как алгоритмический язык (язык представления процедурных знаний) связан с идеей улучшения работы человеческого ума.

Поводом для этой темы послужил перепост Ильи Ермакова из Хабра, который я цитирую ниже: 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).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Сентябрь, 2016 07:03 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Паронджанов писал(а):
В книге "Как улучшить работу ума" я впервые подробно изложил идею языка ДРАКОН.
Там же я попытался объяснить, как алгоритмический язык (язык представления процедурных знаний) связан с идеей улучшения работы человеческого ума.

Поводом для этой темы послужил перепост Ильи Ирмакова из Хабра, который я цитирую ниже: viewtopic.php?f=27&t=4278

Илья Ермаков писал(а):
http://habrahabr.ru/post/170443/
Цитата:
Чарльз Петцольд обратил в своей замечательной статьей внимание на то, что Visual Studio принуждает к стилю разработке снизу-вверх, что не очень вяжется с потребностями бизнеса.
Visual Studio (с инструментом повышения производительности или без) делает сложной (но не невозможной) разработку «снаружи-внутрь».

Первый раз встречаю выражение типа:
разработка снаружи-внутрь.

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

Выражение "от середины вниз и вверх" впервые встретил
в публикациях команды академика Глушкова В.М. в области АСУ.
С тех пор сознательно не заморачивался жестким требованием одного подхода (сверху или снизу).
Да и реально в разработках, хочешь-не-хочешь, параллельно работают все три эти подхода.

Но ведущее направление разработок сверху вниз:
-- как обязательное условия для изначального обеспечения системной целостности представлений;
-- как средство (одно из средств) борьбы со сложностью и т.п.
Но оно сопровождается гибким переходом на другие направления по мере необходимости.

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

---------------------------
Это относится (точнее относилось при коммунизме) к общим (системным) разработкам
технологических автоматизированных (и роботизированных) систем и подсистем АСУП и АСУТП.
При этом сначала стихийно, а затем сознательно пришлось осваивать алгоритмизацию разработок:
1
Для алгоритмического описания работы технологических автоматизированных систем :
здесь до сих пор большие проблемы.
2
Для алгоритмического описания программных разработок - совместно с программистами:
-- убедился, что заставить программиста писать алгоритмы - это только с ревом, со слезами,
причем "много шуму, мало шерсти", как сказал черт, пытаясь постричь кошку; :D
-- позднее стал понимать, что параллельно программисту должен работать специалист по программной документации
(это разные культуры - генерить исходные коды и программную документацию);
-- позднее это стало увязываться с работой системного аналитика в автоматизации проектирования программных систем.

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

-----------------------------
В разработках программных систем использовал и использую все три направления.
Не очень понятно сетование на Visual Studio типа:
Цитата:
Visual Studio принуждает к стилю разработке снизу-вверх

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

-----------------------
Более того, от студентов, которые мне что-то там программируют,
на любом уровне требую:
1)
начинать с пустого алгоритма типа:
Ai = ()
2)
с соответствующего псевдокода - под конкретный язык, типа:
alg Ai begin end
alg Ai() { }

3)
с выходом на исходный код и его отладку
4)
с последующим пошаговым наполнением алгоритма и его программной реализации.
5)
И с самого начала - пошаговая визуализация алгоритма:
большая работа, но хорошая отладка, например, блок-схемы алгоритма.

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


===================
Но в личных программных разработках - все это не так, все не по таким красивым правилам.
Такова сель-ави.
Увы мне. :D

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

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

Такова реальная диалектика параллельной теории и практики
(в личных масштабах). :D


==================
Но концепция программирования "снаружи внутрь" хороша.
Это не просто сверху вниз.
Здесь что-то еще теплится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Сентябрь, 2016 11:07 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
Всю (сознательную) жизнь разработок в области автоматизации производства
с управлением на компьютерной основе (где-то с начала 70-х)
знал и применял направления разработок:
сверху вниз,
снизу вверх
и
от середины вниз и вниз.

Ошибочка вышла. Надо:
от середины вверх и вниз.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 3 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB