Комментарии 56
Хорошо, что вы читаете «правильные» книги.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за уточнения по языкам. Здесь я действительно профан и в детали не вдавался. Просто хотел привести примеры языков, оперирующих понятиями на уровне предметной области.
Мне кажется спор «являются ли языки МЭК злом или панацеей» не влияет на выводы Брукса. Буду рад, если Вы мне поясните, почему считаете по-другому (если я Вас правильно понял)
Мне кажется спор «являются ли языки МЭК злом или панацеей» не влияет на выводы Брукса. Буду рад, если Вы мне поясните, почему считаете по-другому (если я Вас правильно понял)
(ps: это ответ не на мой комментарий =))
Да, Макконел хорошо пишет.
Сразу припомнился Access — программа для не программистов. Вернее, так она была задумана. Один конструктор запросов чего стоит. Но, насколько я знаю, её постигла печальная участь — программисты плюются (из нашей группы все поголовно, а мне было проще написать SQL, чем воспользоваться конструктором), а пользователи не пишут.
Ещё пример — 1С, идея — супер! реализация — фигня :( ИМХО, конечно. Сколько слов новых узнали от меня сотрудники, когда базу с Access загонял в 1С! :)
Сразу припомнился Access — программа для не программистов. Вернее, так она была задумана. Один конструктор запросов чего стоит. Но, насколько я знаю, её постигла печальная участь — программисты плюются (из нашей группы все поголовно, а мне было проще написать SQL, чем воспользоваться конструктором), а пользователи не пишут.
Ещё пример — 1С, идея — супер! реализация — фигня :( ИМХО, конечно. Сколько слов новых узнали от меня сотрудники, когда базу с Access загонял в 1С! :)
Да, с Access такая же херь. Я не то что плююсь — я принципиально не могу понять конструктор… + юзаю ОС на которой Access нету (хотя Word, Excel и… Messanger имеются). Наврядли я сам буду сдавать эту БД с фрезами…
SQL был тоже задуман, как язык для «не программистов». Именно поэтому он по синтаксису близок к естественному языку.
НЛО прилетело и опубликовало эту надпись здесь
Как правило, на объектах предъявляется определенная методика испытаний, согласно которой мы и сдаем в эксплуатацию наше ПО. Применяется ли при этом еще и формальная верификация алгоритмов и программ, к сожалению, точно сказать не могу, т.к. сам в пуско-наладочных работах участия не принимаю.
unit tests?
Да, было дело, наступал на грабли. Написал дизайнер для редактирования правил (фильтр). Фильтр представлялся в виде дерева, в узлах которого были логические функции, а листья — операторы сравнения (+ еще несколько функций). Как в конце концов оказалось — пользователи (медики) спасовали перед таким редактором.
Возможно следовало кроме такого интерфейса сделать ещё один, упрощенный. Просто из списка выбирать частоиспользуемые варианты фильтров и показывать пользователю более простую форму ввода.
Возможно ещё имело смысл приводить в дизайнере правила фильтра в текстовой «человекопонятной» форме. (будут выбраны все ___ у которых ___ меньше/больше/равно ___).
Возможно ещё имело смысл приводить в дизайнере правила фильтра в текстовой «человекопонятной» форме. (будут выбраны все ___ у которых ___ меньше/больше/равно ___).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А что если через 25 лет программы будут писаться генетическими алгоритмами по каким-нибудь автоматическим фитнесс-функциям? ;-) Для биологических существ программисты не нужны.
Нужно ещё умудриться понять самих себя за 25 лет (ИМХО, это нереально), чтобы ещё и алгоритмы копировать.
> Для биологических существ программисты не нужны.
Это еще не доказано.
Это еще не доказано.
Точнее не ГА, а ГП — ген. программирование. Но даже если будет так (а скорее всего так и будет), проблема «программирования» перетекает в проблему «проектирования» фитнесс-функции. Т.е. этап формализации задачи по-любому должен быть решен человеком или в интерактивном режиме человека и САПР.
Мне что то представляется сразу инди-код — куча бессмысленных сравнений, но так уж получилось, что оно работает.
В общем не верю в генетическое программирование.
В общем не верю в генетическое программирование.
Не обязательно задавать фитнесс-функцию жёстко. Как учатся дети — ты им показываешь, что плохо, а что хорошо. Ошиблись — подзатыльник :), получилось выше ожидаемого — конфетка.
Т. е. на входе у нас очень ограниченный набор вх→вых. Мы можем либо в качестве фитнесса уменьшать дельту от этих примерных вх→вых, перезапуская ГП после каждого нового случая.
Если наборов вх→вых не хватает, мы можем их апроксимировать тоже, например, с помощью ГА :).
Т. е. на входе у нас очень ограниченный набор вх→вых. Мы можем либо в качестве фитнесса уменьшать дельту от этих примерных вх→вых, перезапуская ГП после каждого нового случая.
Если наборов вх→вых не хватает, мы можем их апроксимировать тоже, например, с помощью ГА :).
А прописывать цель программы кто будет? У жизни «цель» одна — жить вечно.
Тут, допустим, цель, чтобы модель максимально соответствовала реальности или чему-то еще. Ну а как это соответствие узнать, если самой модели еще нет? Прочитать мысли программиста?
Тут, допустим, цель, чтобы модель максимально соответствовала реальности или чему-то еще. Ну а как это соответствие узнать, если самой модели еще нет? Прочитать мысли программиста?
См. выше
Это дрессировка уже, а не обучение. У детей есть интеллект, они понимают язык, а это принципиально другой уровень. В возможность создания ИИ за 25 лет я не верю, поэтому и спросил про чтение мыслей.
Рассуждения о вх→вых хороши, когда есть вх и вых. А такое бывает редко. Точнее, в работу программиста входит поиск этих входов и выходов, и это важнее, чем непосредственно кодирование.
ГА хороши для тюнинга уже готовых моделей, а не для создания чего-то нового.
А пишется фитнес. Одна «с»; также, как в слове бизнес.
Рассуждения о вх→вых хороши, когда есть вх и вых. А такое бывает редко. Точнее, в работу программиста входит поиск этих входов и выходов, и это важнее, чем непосредственно кодирование.
ГА хороши для тюнинга уже готовых моделей, а не для создания чего-то нового.
А пишется фитнес. Одна «с»; также, как в слове бизнес.
Дрессировка это подпонятие внутри обучения. Дети не сразу понимают речь, но тем не менее успешно учатся. В создание настоящего ИИ я тоже не верю, но даже такое автоматические генетическое программирование слишком далеко до ИИ (я говорю об уровне собаки).
Да мне вообще слово фитнес не нравиться :). Жалко заимствование по сравнению с нормальным (и всем понятным) «отбором» :).
Да мне вообще слово фитнес не нравиться :). Жалко заимствование по сравнению с нормальным (и всем понятным) «отбором» :).
самое сложное в программировании — это придумывать имена переменным :)
И инвалидация кэша :)
Если стоит задача написать красивый код их стоит продумывать заранее, что действительно не простая задача, даже если следовать какому-нибудь паттерну.
Удобно в начале полностью описать в комментариях, как и что будет работать и какая переменная зачем, потом под каждой строчкой коммента уже писать код.
прошу прощения за оффтоп.
Удобно в начале полностью описать в комментариях, как и что будет работать и какая переменная зачем, потом под каждой строчкой коммента уже писать код.
прошу прощения за оффтоп.
Довольно странно, что вы называете No Silver Bullet «менее известной статьёй». Полагаю, что практически все читавшие Брукса пользовались юбилейным изданием «Мифического человека-месяца». Там эта статья есть.
Самое интересное это год издания первой книги Брукса. И ничего с тех пор не изменилось. :-)
Недавно в очередной раз перелистывал Mythical man-month и (в очередной раз) дивился тому, что за последние 30+ почти ничего не изменилось. Отсканировал пару статей и разослал нескольким молодым менеджерам проектов, чтобы хоть чуть-чуть задумались, прежде чем планы рисовать…
«Причем, похоже, эта проблема не может быть решена созданием более удобного пользовательского интерфейса»
во-во, часто приходится слышать от заказчика, что ему нужен сайт с такой панелью администрирования чтобы цитирую
— мы сами могли всё, менять
— это практически невозможно вам нужен будет программист
— ну сейчас же есть куча систем которые позволяют что-либо делать без навыков программирования
Так и хочется ответить без навыков программирования, не значит без мозгов!
во-во, часто приходится слышать от заказчика, что ему нужен сайт с такой панелью администрирования чтобы цитирую
— мы сами могли всё, менять
— это практически невозможно вам нужен будет программист
— ну сейчас же есть куча систем которые позволяют что-либо делать без навыков программирования
Так и хочется ответить без навыков программирования, не значит без мозгов!
Серебряная пуля это не то что «определит взаимосвязи между объектами реального мира, установит за нас исключения, предусмотрит все возможные переходы между состояниями и т.д...» Все это работа человека. Когда человек выполнит эту работу, код который он напишет в идеале должен просто и очевидно отражать эти взаимосвязи, эти исключнения и эти переходы… В моем понимании серебряная пуля как раз и есть инструмент, который поможет выразить мою идею и результаты моего анализа в коде (или метакоде или модели или в чем то еще)… И в этом смысле серебряные пули есть и их скажем так немало… Банальный пример… spring web flow… просто и очевидно описывают логику работы контроллера… взаимосвязи, состояния, переходы и прочее… не на два порядка, но на порядок упрощает весь уровень контроллеров приложения. Что еще от серебряной пули нужно..? Она уменьшают ту сложность, которую можно уменьшить (сложность выражения идеи)… А сложность предметной области это инварианта, мы лишь можем выбирать между более простыми или более сложными моделями этой предметной области… но строить эти модели нам… причем тут серебная пуля?
Я так понимаю вопрос больше не ко мне, а к Бруксу. А вот что пишет сам Брукс: «So we hear desperate cries for a silver bullet--something to make software costs drop as rapidly as computer hardware costs do» (примерный перевод: «и мы слышим мольбы отчаявшихся о серебряной пуле — чему-то, что заставит стоимость разработки ПО снижаться так же быстро, как стоимость аппаратного обеспечения»). Как видите, у Брукса просто более радикальное понимание того, что такое «серебряная пуля».
И в итоге какой бы крутой компьютер не был, какая навороченная б не была IDE: сначала берем лист бумаги, ручку и начинаем проектировать, правильно спроектирована система єто 60% работы.
Во-вторых, хотелось бы предостеречь коллег-разработчиков: если будете разрабатывать инструментальную среду, призванную автоматизировать работу пользователей, подумайте, не упретесь ли в описанную проблему — необходимость в навыках программирования (в том или ином виде) у конечного пользователя.
Уже упёрлись, к сожалению.
Пока пользуемся самописным интерпретатором Паскаля, но чувствуется мне к добру это не приведет. =(
Хотя на данном этапе такой подход пока удовлетворяет всем требованиям. С другой стороны, не такая уж у нас и огромная предметная область.
А какая _принципиальная_ разница между автоматизацией и программированием? Если я хочу, чтобы будильник автоматически прозвонил в 7-30, мне уже нужен определённый навык. Навык программирования будильника, если хотите.
Можете сформулировать чёткий критерий между программичтом и не_программистом?
Можете сформулировать чёткий критерий между программичтом и не_программистом?
Во многом, мне кажется, это провокационный вопрос). Понимание различий между программистом и не_программистом существует скорее на бытовом уровне, нежели в качестве формального критерия. И раз уж зашла речь о будильниках, то тут как раз существует проблема, что многие люди (не_программисты в бытовом понимании) не могут настроть свои электронные часы из-за сложного «интерфейса».
Думаю, можно определить программирование как некую специализацию в настройке автоматизированных систем (программ, компьютеров, других устройств), в противоположность использованию этих устройств широким кругом людей с целью выполнения повседневных задач. Но, опять же, это не может претендовать на формализованный критерий. В примере с будильником пользователем может быть мама, которая просит Вас перевести ей будильник на 7:30, а программистом — Вы, как человек, осуществляющей такую настройку.
Думаю, можно определить программирование как некую специализацию в настройке автоматизированных систем (программ, компьютеров, других устройств), в противоположность использованию этих устройств широким кругом людей с целью выполнения повседневных задач. Но, опять же, это не может претендовать на формализованный критерий. В примере с будильником пользователем может быть мама, которая просит Вас перевести ей будильник на 7:30, а программистом — Вы, как человек, осуществляющей такую настройку.
Что плохого в том, чтобы дать конечному юзеру средства программирования в разрабатываемом ПО? Наша контора уже несколько продуктов таких выпустила: движок+базовый GUI+API для тех, кому базового GUI не хватает. Практика показывает, что 90% юзеров юзают базовый интерфейс и не жужжат, а вот те 10%, которым его не хватает, вполне способны сами написать недостающий функционал (ну или найти кого-то, кто напишет).
Мне кажется, ваше решение подходит для короративных клиентов, которые имеют в штате программистов, или как специализированный софт опять же для программистов. А что делать с коробочными продуктами для не программистов?
Практика показывает, что если сделать API простым и понятным, вынести наиболее часто используемые комманды в короткий HOW-TO мануал, сделать встроенный редактор кода и средства простого и быстрого создания кнопочек-галочек-ползунков, то любой дурак себе напишет всё нужное. Я за 2 часа учу писать скрипты в своём ПО юзера уровня «блондико, умеющее включать компутер».
Плохого ничего, конечно же нет. Но Ваши слова только подтверждают правоту Брукса: чтобы конечные пользователи могли пользоваться Вашим API (те 10%, кому не хватает базовой функциональности), им необходимы навыки программирования. А в 90% процентах случаях эти средства остаются невостребованными.
«в 90% процентах случаях эти средства остаются невостребованными» — ну и классно! Значит базового GUI хватает!
«чтобы конечные пользователи могли пользоваться Вашим API… им необходимы навыки программирования» — ну и классно! Если тебе что-то нужно от данного софта, ты, постаравшись, можешь это сделать.
…
Профит!
«чтобы конечные пользователи могли пользоваться Вашим API… им необходимы навыки программирования» — ну и классно! Если тебе что-то нужно от данного софта, ты, постаравшись, можешь это сделать.
…
Профит!
Правильно ли я понимаю? Есть некий порог сложности — непосредственно сама модель задачи. И как бы мы ни пыжились, проще она не будет — не достигнем результата. А все средства реализации модели только привносят сложности. Проблемно ориентированные языки привносят меньше, но саму модель простой сделать не сможет.
>> но саму модель простой сделать не сможет.
модель можно сделать проще… модель делаете именно вы, но вы не можете сделать проще тот объективный процесс, который вы моделируете… в тот момент когды вы сделаете модель (простоую или сложную это не важно), следующей задачей будет реальзовать эту модель в чем то материальном (в бетоне или в Python'е ) и вот тут вы добавите «сложность выражения» вашей модели в чем то материальном… Идеальная серебреяная пуля материализует вашу модель «as is», в реальности почти «as is»
модель можно сделать проще… модель делаете именно вы, но вы не можете сделать проще тот объективный процесс, который вы моделируете… в тот момент когды вы сделаете модель (простоую или сложную это не важно), следующей задачей будет реальзовать эту модель в чем то материальном (в бетоне или в Python'е ) и вот тут вы добавите «сложность выражения» вашей модели в чем то материальном… Идеальная серебреяная пуля материализует вашу модель «as is», в реальности почти «as is»
С. Макконнелла «Профессиональная разработка программного обеспечения» — эту книгу стоит читать? От товарищей слышал плохие отзывы.
Пожалуй нет, не стоит. Слишком уж много там «воды» и слишком мало действительно важных сведений (я так до конца и не осилил) Про ту же статью Брукса есть упоминание и в «Совершенном коде». Просто впервые я встретил упоминание в «Профессиональной разработке...», вот и сослался на нее. Советую почитать «Совершенный код», если Вы еще не читали, хотя «воды» и там хватает
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Брукс был прав, или главная сложность программирования