338lm: (Ada)
Народ, как обычно, неправильно определяет цель и достигает странного.
Все хотят сделать такие игрушки как можно более похожими на настоящую жизнь, забывая что люди играются в них, чтобы отвлечься от жизни.
И ещё изобретая всякие гильдии и прочие иерархии забывают, что каждый кто приходит поиграть хочет быть независимым и самым главным в игре. Ни кто не хочет вступать в игру в качестве полного ничтожества, которое будет добывать лут из ботов для вышестоящих потому, что он и так это делает каждый день в реальности.

Очень это похоже на ситуацию с объектно ориентированным проектирование где почти всегда вместо решения задачи автоматизации пытаются задизайнить модель уже существующей системы, сделанной из желудей и пластилина, и образно говоря, решая задачу транспортировки груза делают не телепорт а модель дороги и грузовика со всеми их асфальтами, дорожными знаками, карбюраторами, бензобаками, рулями и колёсами существующими в реальной жизни но нафиг не нужными если есть возможность просто перемещать груз мгновенно.
338lm: (Ada)
Q What is a protected abstract virtual base pure virtual private destructor? (Van Der Linden, Peter. Expert C Programming. Page 327)

A It is a pure virtual private destructor that is inherited from a protected abstract virtual base. In other words, a destructor function that can only be called by members or friends of the class (private), and is assigned a 0 (pure virtual) in the base class (abstract base) that declares it, and will be defined later / overriden in a derived class that shares the multiply-inherited base (virtual base) in a protected way.
338lm: (Ada)
Или о том что мерить надо лучше. Или меньше обобщать.

Наверное все читали кучу литературы где, на основе исследований и экспериментов, авторы доказывают, что выбор правильного языка программирования даёт прирост скорости разработки не более чем на 2-5 процентов. Я никогда не сомневался в фундаментальности проведённых исследований, и опыте парней вроде авторов Peopleware, но не мог принять результаты таких исследований потому, что они не совпадали с тем, что я видел сам в реальных проектах.

Сегодня я кажется понял что общего во всех этих исследованиях и почему они противоречат моим ощущениям.

Они все мерили только скорость написания кода для решения конкретной задачи. Ни кто никогда не мерил затраты на сопровождение этого кода включая: тестирование, документирование, исправление ошибок, затраты времени на понимание старого кода новыми сотрудниками и т.п.

Они всегда проводили исследование на основе небольшой задачи со строго описанным ТЗ которая требовала всего несколько часов на решение, и почти всегда решением занимался всего один человек. Но ведь ни кто не имеет проблем с такими мелкими задачами. Проблемы начинаются тогда когда задача большая, когда её решают много людей разной квалификации, когда требования нечёткие и постоянно меняются.

Я понимаю этих парней. Такое исследование требует огромных затрат, которые ни кто не согласится нести только из научного интереса. Но измерив решение примитивной задачи одним человеком в течение нескольких часов делать выводы об отсутствии влияния языков на проекты любого масштаба и длительности я считаю неправильным.
338lm: (Ada)
Что-то меня сегодня пробило в Скайпе на графоманство во время беседы с одним хорошим человеком. Ниже немного тематического бессвязного бреда.

Идеальный бизнес-процесс, это идеально прогнозируемый и масштабируемый процесс, с нулевым влиянием человеческого фактора. Я мечтаю сделать в софтваре-девелоперской индустрии такой же конвейер как Форд сделал в автомобилестроении.
Короче я главный враг всех программистов. :)
Потому Ада мой любимый язык программирования - он пиздит по рукам нещадно пока не напишешь действительно хорошо читаемую программу.
Программными извращениями должны заниматься люди в исследовательских лабораториях, а в промышленном программировании всё должно быть просто, ясно и понятно.
Java, например, стала такой популярной именно потому, что нужно быть очень талантливым долбоёбом, чтобы завалить всю систему из метода своего класса. Только в жабе это достигается с помощью ВМ, которая всё контролирует, а в Ада с помощью языка. Потому адский софт на этапе выполнения может не иметь вообще ни какого оверхеда на проверки, а жаба жрёт ресурсы как не в себя.
Oleksandr Okhrimenko: хорошо что предупредил
Oleksandr Okhrimenko: но этого то пока нет
Oleksandr Okhrimenko: людей пока не отменили
Людей никогда не отменят. Это вообще основная ценность любой затеи. Но из-за людей, и самые большие проблемы. Тот кто умеет управлять людьми может всё на что способно человечество. Макдоналдс так богат потому, что смог написать детальный рецепт как управлять людьми в закусочной, и даже из самых тупых идиотов сделать нормальный персонал, который сделает вкусный пирожок. А для софтвера такого ещё не сделали. А жаль. Это моя мечта. :)
Oleksandr Okhrimenko: ну в маке имхо работа больше механическая и это действительно конвейер
Oleksandr Okhrimenko: а вот в софте приходится иногда думать
Ага, потому там и зарплаты больше. Но практически все думы в промышленной программе сводятся к тому какое из уже известных решений применить. Так что ни какого высокого творчества это не требует. Любой человек, который не дурак, может успешно писать промышленный софт. Заниматься изобретением чего-то совершенно неимоверного не только практически никогда не нужно но и почти всегда вредно. Все те случаи когда я видел чьё-то "изобретение" происходили от недостаточного знания готовых решений. Чем меньше опыт и квалификация программиста тем больше велосипедов он изобретает самостоятельно.
Кстати IMHO ООП это зло в принципе, потому, что применяющие его на серьёзном уровне, почти всегда вместо решения задачи тонут в нагромождениях искусственных абстракций, которые они сами же и придумали. И всё время думанья улетает на то какой шаблон проектирования применить вместо простейшего решения влоб.
А самое забавное, что обычно именно вот такое простейшее решение потом никогда не подвергается ни каким расширениям или изменениям. А если и подвергается то суммарное время на написание нового решения влоб с нуля иногда на порядки меньше въезжания в архитектуру расширяемого решения и расширения его правильным образом.
Чаще всего такие развесистые ООПные расширяемые системы переполнены костылями, с помощью которых новый функционал добавляли люди, которые просто не поняли, или не захотели понять архитектуру, из-за ее переусложненности и заумности.
338lm: (Default)
Потратил сегодня два часа на взлом второго старкрафта. Понял что для того чтобы поломать последний патч нужно потратить еще часа 4 и забил на него вообще. Теперь размышляю правильна ли такая стратегия: "не давать не платившим играть вообще или лучше давать но с ограничениями". Ибо тот кто играет тот потенциальный покупатель а так же лучший рекламщик (если ему нравится то он по любому будет это советовать другим кто не пробовали, а ему они поверят больше чем любой другой рекламе), а тот кто даже не пробовал тот потребитель рекламы ибо его нужно привлекать и тратиться на него, а так же он нелоялен и легко может выбрать конкурента. Короче говорят пришел к выводу что нельзя совсем не давать пользоваться программами забесплатно ибо это же дешевая но очень эффективная реклама, а так же окучивание будущих покупателей.
Page generated Jul. 21st, 2017 04:40 pm
Powered by Dreamwidth Studios