Про учителя в согласен, он переводит из ментальной модели взрослого в ментальную модель ребенка. Посредством например дидактической редукции. Доктор переводит из человеческого языка симптомов (тут болит) на формальный язык диагноза. И если заказчик (пациент) хочет это лечить врач предлагает известные ему методы избавления от симптомов и причин. (Что-то похожее на работу архитектора в айти). И передает работу хирургу, у кторого в конце концов на карточке написано что и где отрезать. Работа хирурга, практически не творческая. Но это все не значит что для этой работы не нужен талант. Талант нужен, чтобы свою функцию (ср. книги «Черновик», «Чистовик» у С. Лукьяненко) выполнять хорошо или лучше чем большинство других.
Вы уж простите за такую «механистическую» перспективу. Это всего лишь взгляд под другим углом.
На Хабре нельзя ставить под вопрос элитизм которым овеяна личность человека стоящего по ту сторону информационных технологий. (с) Я.
Но, иронию в сторону. Я для себя пришел к выводу, после того как перевел один текст с английского на русский, что программирование это работа переводчика. Сделав перевод, я подправил его с учетом рекомендаций читателей. И в скоре даже забыл про что был текст.
Это просто рутинная работа. Порой мучительно сложная, но при определенном навыке перевести можно все.
Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.
Романтики в этой профессии не больше чем в профессии переводчика. И творчества соответственно тоже. Переводчик может позволить себе удачный художественный оборот, чтобы выйти из положения когда прямой перевод невозможен. На этом пожалуй все «творчество» и заканчивается.
Насчет вывода я не совсем понял, ну получил я синусоидальный график, как анализировать то? Что говорит мне точка на графике (1.5, -0.20)? Эта функция охватывает колебания цен на любой продукт относительно изменений цен валюты? Или имеется ввиду индекс цен в стране. Какая валюта имеется ввиду? Твоей страны? Или всех валют мира? Работает эта модель для всех стран мира, стран любого размера, стран с любой экономичиской структурой и политическим строем?
Вобщем хотелось бы увидеть побольше оговорок. А то создается впечатление, что найдена золотая формула зависимости чего-то от чего-то. А это вряд ли так.
у меня есть коллега который гораздо общительнее меня, он знает уйму людей у нас на фирме, знает у кого какие дела, но я не замечал чтобы ему удалось обернуть эту свою способность в значительной мере себе на пользу. Видимо решает целенаправленность такого поведения.
разве не получается. что при таком подходе ответственность за защиту пользовательских данных переходит с сервиса на емеил провайдера. И в конце концов ложится опять на плечи пользователя, который должен обезопасить доступ к своей почте, причем еще сильнее. Я например потерял доступ к своей яндекс почте, процесс восстановления аккаунта на Яндексе такой дикий, (с авторизацией по веб камере с паспортными данными) что я плюнул на это. И что делать? Все, досвидания все сервисы завязанные на эту почту. Это не решение или во всяком случае всего лишь полумера.
совершенно согласен, если бы мы знали какие факторы влияют на исход сражения, нам не нужно было бы прогнозирование. Вот я слежу за киберспортом (cs:go), и там часто играет роль то, что называют моралью — боевой дух. Одна и та же команда, с одним и тем же противником, на одной и той же карте и стороне, может сыграть совершенно по-разному в зависимости от боевого настроя, фазы луны, и того отцвела сакура или еще нет. И есть записи всех игр за последние года, с подробной статистикой, но никто еще не построил модель которая могла бы предсказывать исход противостояния двух команд. А казалось бы тут пространство вариантов куда меньше. Да в конце концов, наши головы полны совершенно необоснованных суеверий, когнитивных искажений, суждений, предельно далеких от объективности, куда нам предсказывать будущее. Не в том измерении человек мыслит для этого. Мы видим только проекции, берем ногу слона и говорим что это дерево, хватаемся за хобот и говорим что это змея. Смешно.
Я до сих пор считал, что компьютерные системы прогнозирования сравнительно слабы, поскольку опираются на математическую модель, в которой невозможно всего учесть. Да и база классического теорвера для таких прогнозов мне видится не достаточно пригодной.
Процитирую из Станислава Лема «О невозможности жизни»:
… все это вздор — чтобы, произошло нечто крайне маловероятное, вовсе не нужно, чтобы множество событий, к которому оно принадлежит, представляло собой непрерывную серию. Если я бросаю десять монет разом, зная, что вероятность выпадения одновременно десяти орлов или десяти решек составляет лишь 1:1024, мне вовсе не обязательно бросать по меньшей мере 1024 раза, чтобы вероятность выпадения десяти орлов или решек стала равна единице. Ведь я всегда могу сказать, что мои бросания — продолжение эксперимента, в который входят все прошлые бросания десяти монет сразу. За последние пять тысяч лет их было, конечно, без счету...
Я верю в то, что предсказание сколько-нибудь значительно сложнозависимых событий — неподвластная человеческому сознанию задача в принципе. Но люди упорно продолжают веками дурачить себя. И будут продолжать. Ведь и в бизнесе тратяться серьезные деньги на прогнозирование. Какие-то консалтинговые фирмы пишут отчеты о будущем индустрии, основаные на симуляциях и прочее и прочее. Можно пойти к гадалке, с той лишь разницей, что она не носит галстук, а работает быстрее и дешевле. А зачем людям эти прогнозы — им страшно. Вот и находятся шарлатаны которые продают им уверенность. Или они сами этих шарлатанов назначают, и приказывают им работать. Вобщем, вселенский бред — слов нет.
Рискуя хряпнуть минусов, я все таки скажу. Вот мы на работе в проекте используем subversion. Молча. О нем никто не говорит, все с ним просто работают. Про гит же в корридорах слышно либо хайп, либо истории как кто-то выстрелил себе в ногу. Раньше я тоже приветствовал все революционное и радикальное. Но со временем, поработав, пришел к выводу, что правильно — это во всем держать здоровый компромисс. Не существует идеальных решений, поэтому не надо расстраиваться, что твой инструмент, твоя архитектура или что-то еще чего-то не могут. Главное чтобы было достаточно удобно этим пользоваться и принцип действия был лего понятен любому, возможно даже в ущерб скорости применения отдельными мастерами. А вот высокая технологичность решения, как раз таки скорее опасна.
Спасибо за статью. Одно упоминание Кея, Пиаже и Папперта, уже достойно уважения.
Шикарнейшие отсылки. (Кстати, ссылочки на доступные цифровые копии упомянутых вами журналов и книг, для тех кому лень искать, можно в конце статьи оставить, это не возбраняется, насколько мне известно ;)
Краткий актуальный справочный обзор, как мне кажется, вполне оправданный формат.
Сейчас ведь, если в интернете начинаешь искать, не всегда ясно, актуальная ли это информация. Пробуешь — бац — а оно не работает, потому, что когда писали статью, актуальным был, ну, например, ангуляр 1.4 и все его называли ангуляр. Никто и не задумался в статье приписать какой версии касаются эти инструкции. Такая же история с гайдами по персонажам из игр, их переделывают с такой скоростью, что как правило гайд через три-шесть месяцев теряет свою актуальность. Получается интернет завален кучей устаревшей информации.
Айтишный русский язык может и состоит чуть больше чем наполовину из англицизмов, но от «дефиниции», честно, сводит скулы. (Вот как теперь стереть это словообразование из головы..)
без риска возникновения коллизий с существующими дефинициями.
или «определениями», или «обьявлениями» или в худшем случае «декларациями». А лучше, вообще опустить это дополнение. Просто, "… без риска возникновения коллизий". Точка.
Русский читатель достаточно сообразителен, и подкован, чтобы понять о чем идет речь.
я имею ввиду, что разработчик пишет например тест на контейнер с методами добавления и удаления элементов. Часто можно увидеть такой тест: три раза добавили, три раза удалили, проверили размер ноль. Т.е. проверка только того чем разработчик собирается пользоваться. При этом редко тестируются крайние случаи, как например, что будет если контейнер пустой, и мы попытаемся удалить элемент. Потому что как бы зачем это делать. «Я же не собираюсь удалять что-то из пустого контейнера» — думает себе разработчик. А по ходу программы такое может произойти. И выяснится, что вылетит какое нибудь исключение. А исключение это что? Это обычно указание на то, что какой-то случай не учли. Например то, что объект может быть нулевым. Каждую неделю один-два тикета из-за NPE это норма.
Вот, ради примера, кусок теста из опенсурсного проекта jmonkeyengine:
То, что эта струкрура данных делает, то что должна по замыслу разработчика, я не сомневаюсь — этот случай не интересен. Интересно, что будет когда ключом будет строка а значением null. Или еще какой-нибудь странный случай. Мы не знаем для чего будут использовать эту структуру данных и где.
Я пишу тесты не для того чтобы покрыть код тестами, а потому, что я ни нихрена не знаю как поведет себя этот код в нестандартной ситуации. Я давно избавился от наивной веры в то, что «оно как написано так и работает». Практика показывает, что это не так. Даже у лучших из лучших. Баги возникают именно в той ситуации которая как бы не должна была произойти.
Ну вот, я вам обьяснил, что я имею ввиду, теперь вы мне обьясните, что Вы имеете ввиду. Желательно с примером.
Я тут еще размышлял над этим, и мне стало ясно, что выведение правил и условий из поставленной задачи по сути явлется анализом требований. Значит requirements engineering это интересная и чертовски сложная умственная работа. И, ссылаясь на замечание Dr_Dash ниже, любопытно, что хороший инженер выведет условия как в статье, а превосходный инженер скажет, что «мужик не нужен». И сэкономит этим самым деньги клиента.
да, теперь я понял, что не до конца понял. Под телепортацией я понял телепортацию с берега на берег. Но имеется ввиду, одновременная разгрузка-загрузка челнока. Тогда все как вы говорите. Спасибо за терпение. Распишу подробно для тех, кому интересно:
Коза садится в челнок и переправляется на другой берег, челнок возвращается, капуста загружается на челнок, челнок едет к козе, капуста выгружается на другой берег, а коза тут же загружается на челнок, коза едет к волку на берег, коза выгружается, а волк загружается и перезжает к капусте. Челнок возвращается пустой, забирает козу, и перевозит ее на другой берег.
Вы уж простите за такую «механистическую» перспективу. Это всего лишь взгляд под другим углом.
.doc (требования) -> .java (или любой другой понятный машине язык)
Но, иронию в сторону. Я для себя пришел к выводу, после того как перевел один текст с английского на русский, что программирование это работа переводчика. Сделав перевод, я подправил его с учетом рекомендаций читателей. И в скоре даже забыл про что был текст.
habrahabr.ru/company/edison/blog/301666
Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.
Романтики в этой профессии не больше чем в профессии переводчика. И творчества соответственно тоже. Переводчик может позволить себе удачный художественный оборот, чтобы выйти из положения когда прямой перевод невозможен. На этом пожалуй все «творчество» и заканчивается.
Вобщем хотелось бы увидеть побольше оговорок. А то создается впечатление, что найдена золотая формула зависимости чего-то от чего-то. А это вряд ли так.
Процитирую из Станислава Лема «О невозможности жизни»:
Я верю в то, что предсказание сколько-нибудь значительно сложнозависимых событий — неподвластная человеческому сознанию задача в принципе. Но люди упорно продолжают веками дурачить себя. И будут продолжать. Ведь и в бизнесе тратяться серьезные деньги на прогнозирование. Какие-то консалтинговые фирмы пишут отчеты о будущем индустрии, основаные на симуляциях и прочее и прочее. Можно пойти к гадалке, с той лишь разницей, что она не носит галстук, а работает быстрее и дешевле. А зачем людям эти прогнозы — им страшно. Вот и находятся шарлатаны которые продают им уверенность. Или они сами этих шарлатанов назначают, и приказывают им работать. Вобщем, вселенский бред — слов нет.
Посмотреть на Яндекс Картах
Шикарнейшие отсылки. (Кстати, ссылочки на доступные цифровые копии упомянутых вами журналов и книг, для тех кому лень искать, можно в конце статьи оставить, это не возбраняется, насколько мне известно ;)
Сейчас ведь, если в интернете начинаешь искать, не всегда ясно, актуальная ли это информация. Пробуешь — бац — а оно не работает, потому, что когда писали статью, актуальным был, ну, например, ангуляр 1.4 и все его называли ангуляр. Никто и не задумался в статье приписать какой версии касаются эти инструкции. Такая же история с гайдами по персонажам из игр, их переделывают с такой скоростью, что как правило гайд через три-шесть месяцев теряет свою актуальность. Получается интернет завален кучей устаревшей информации.
или «определениями», или «обьявлениями» или в худшем случае «декларациями». А лучше, вообще опустить это дополнение. Просто, "… без риска возникновения коллизий". Точка.
Русский читатель достаточно сообразителен, и подкован, чтобы понять о чем идет речь.
Вот, ради примера, кусок теста из опенсурсного проекта jmonkeyengine:
Я пишу тесты не для того чтобы покрыть код тестами, а потому, что я ни нихрена не знаю как поведет себя этот код в нестандартной ситуации. Я давно избавился от наивной веры в то, что «оно как написано так и работает». Практика показывает, что это не так. Даже у лучших из лучших. Баги возникают именно в той ситуации которая как бы не должна была произойти.
Ну вот, я вам обьяснил, что я имею ввиду, теперь вы мне обьясните, что Вы имеете ввиду. Желательно с примером.
Коза садится в челнок и переправляется на другой берег, челнок возвращается, капуста загружается на челнок, челнок едет к козе, капуста выгружается на другой берег, а коза тут же загружается на челнок, коза едет к волку на берег, коза выгружается, а волк загружается и перезжает к капусте. Челнок возвращается пустой, забирает козу, и перевозит ее на другой берег.