Antikrot однажды (02 октября 2008 [Четверг] 17:01) писал в rsdn.life:
> баян+самореклама+провокация
Ни-ни. Хочеш в качестве доказательства вообще больше в этой ветке отписываться не буду?
Мне действительно интересно мнение.
Сейчас выльется вторая волна, поскольку я скажу, что в этой идиосинкразии к «визуальным средствам разработки», «managed systems», к тем, кому «некомфортно лезть в консоль», «пуляет кнопочки на формочки» итп., я, простите, усматриваю всего лишь косность взглядов, цеховой обскурантизм и ориентацию на процесс, а не на результат.
Есть задачи, для которых необходимы одни средства, и есть – другие, для которых другие и необходимы, и настоящий профессионализм заключается в том, чтобы правильно выбирать – для чего что. Было время, когда считалось очень круто – починить телевизор с помощью одной отвертки, и что? Это – профессионализм? Нет – это выпендреж.
Однако, подлинная суть дела не в этом. И решающую роль здесь играет не выпендреж, а смутное сознание, что с каждым годом – все больше возможностей и желающих отбить у нас хлеб. И мало этого, еще и опустить авторитет профессии – а значит жалование – еще ниже, чем это есть сейчас. Страшный образ «программирую на C++ за еду» преследует всех нас по ночам, и скоро начнет преследовать наяву. Иначе говоря, это современный IT-луддизм. Но такие проблемы, как известно из истории, решаются не разрушением машин и возвратом к ручному щелканью на счетах, а организацией, например, профсоюзов, забастовками итд.
Решаются профессионалами, а не клубами любителей Windows, Linux, Brainfuck, или чего бы то ни было еще. Ну и, разумеется, не дилетантами, только вчера нарисовавшими первый в жизни интерфейс с разноцветными карамельными кнопками и не способными внятно объяснить, в чем отличие компилируемой программы от интерпретируемой – тут я снова полностью согласен с ранее выступавшими ораторами. Им нужно просто учиться
Современный программист ленив. Ему лень настроить систему, ему лень читать документацию, не относящуюся к его языку программирования. Ему просто лень. Современный программист — просто рабочий. У него есть станок, у него есть рабдень, и у него нет интереса к работе. Нет, к программированию у него интерес еще может и быть, а вот с интересом к IT вообще уже туго.
Я, к сожалению, не попал во времена ассемблера, да и комп у меня появился довольно поздно, но я не могу понять — как можно программировать, не имея понятия об администрировании, о механизмах ОС? Как можно давать такому кодеру проект, когда этот кодер боится консоли как огня и все время ищет кнопку "Сделать мне песдато"?
Ув. товарищ Шеридан, если вы администратор, то вы и говорите об администрировании. Вы лучше скажите, зачем мне
знать (учить) администрирование для того, чтобы быть программистом? IT нынче весьма обширный термин. Мне интересны паттерны, ООА, ООД, я бы с удовольствием поразбирался с функциональными языками программирования, это все не за деньги, это просто так — for fun. Мне это все жутко интересно. Я не замыкаюсь на платформе, я не боюсь новых библиотек, фреймворков, принципиально других подходов в программировании. Даже наоборот, у меня от этого огонек внутри разгорается, ведь это шанс узнать что-то новое. Пусть я программирую под .net на C#, это вообще ничего незначит.
Удивляет, когда программирующий администратор говорит, что ему жаль нынешних "сереньких" кодеров, потому что они не понимают ничего в администрировании и не умеют работать в коммандной строке. Моя сфера интересов лежит вдалеке от администрирования. Зачем прикладнику глубокое понимания механизмов конкретной ОС? Повару все равно, как делают черпаки или кастрюли, он от этого плохим поваром не становится.
Мне кажется что это глупо и некрасиво говорить такое о коллегах. Используешь шарп — получи ярлыком "фе, дотнетчик" в лоб.
ПыСы. Прошу прощение за возможно излишнюю эмоциональность. Достало. Возможно и неправ.
На самом деле появление высокоуровневых языков и средств разработки, таких как C# например не приводит к тому что теперь домохозяйки могут программировать и понижать среднюю зарпплату программиста. Нет. Просто у таких домохозяек будет низкое качество кода и выполненной работы. Т.е. по прежнему есть программисты совершенно разного уровня, кто-то правда может только кнопочки на формы накидывать, но есть и настоящие профессионалы, выполняющие проекты качественно и т.д. И вот такие вот специалисты и востребованы, а программисты-новички — ну есть они и есть, учатся себе потихоньку и не беспокойтесь, не понижают они вашу зарплату, у них своя ниша.
MozgC пишет: > > но есть и настоящие > профессионалы, выполняющие проекты качественно и т.д. И вот такие вот > специалисты и востребованы, а программисты-новички — ну есть они и есть, > учатся себе потихоньку и не беспокойтесь, не понижают они вашу зарплату, > у них своя ниша.
Где?
Статью не читал, но свое мнение выскажу
Net говно не потому, что говно само по себе, это не так. Net говно потому, что его используют не там где надо и не так как надо — т.е. неумеючи.
Вот купил я отличную и дорогую веб-камеру, все прекрасно — и показывает хорошо, и сама крутится и т.д. но дрова к ней... это товарищи ПИ..Ц! помимо охренительного размера и требования net они ТАК тормозят и глючат!!! На обслуживание этой камеры уходит почти вся мощь весьма нехилого проца, да у них там даже в требованиях двухядерник рекомендуется! Это маразм! и отказаться нельзя — сторонних драйверов само собой нет.
Купил сканер, отличный сканер — сканирует быстро и хорошо. НО БЛИН ДРОВА!! опять net — диалог сканирования открывается минуту, педалит как я не знаю кто (реакция на нажатие кнопки, появление меню — пара секунд). Ну и сделан прям специально вредительски — никакие настройки не сохраняются и окошко закрывается после каждой отсканированной страницы.
Здравствуйте, Vintik_69, Вы писали:
V_>Здравствуйте, Allix, Вы писали:
A>>Net говно потому, что его используют не там где надо и не так как надо — т.е. неумеючи.
V_>Интересная логика. Говно ли микроскоп, если им забивают гвозди?
Микроскоп прекрасный, но легче ли мне от этого, если гвозди загоняют в мою голову? Я к тому и веду, что либо оставьте в покое мою голову и пользуйтесь микроскопом как полагается, либо вобще уберите микроскоп на фиг. К сожалению забивать гвозди прибором очень соблазнительно, поэтому мне, как пользователю, было бы гораздо лучше если бы net никогда и не существовало.
Программист — это тот, кто за свою профессиональную жизнь написал много хороших программ (даже пусть просто программ). На практике большинство тру-кодеров в чистом С, которые экономят байты, всю жизнь пишут никому не известную подпрограмму управления двухкиловаттным мотором. Этот стон "молодежь пошла не то что мы, одни халявщики да любители бабла срубить ни за что" есть всего-лишь зависть перед более опытными и образованными. Да, молодежь может быть более опытной, чем сорокалетний пердун, восхваляющий паскаль за "эффективность". Потому что опыт со сроком давности более пяти лет уже устарел и на практике не применим. Молодежь может написать сложную систему, а оптимизатор нет. А для не работающей программы эффективность не имеет значения. Молодежь пишет отличный, легкий, читаемый код, который без проблем поддерживается и расширяется. То, что мне приходилось видеть из области "олдскул программистское кунг-фу" даже читать можно было с трудом, проще переписать все заново. Отрасль не умерла пять лет назад, жива сейчас и будет процветать через десять лет, даже когда все оптимизаторы уйдут на пенсию. Количество программ растет, сложность растет, сроки разработки сокращаются. Новые игры почему-то не пишутся на паскале.
Время от времени я пересматриваю свое резюме и упрощаю его. Когда-то давно там были длинные строчки аббревиатур с названиями технологий и развернутые описания выполненных проектов. Все это постепенно рефакторится — убираются неактуальные на сегодняшний день вещи, сокращаются описания, самые старые проекты вообще удаляются. Резюме становится меньше по объему и количеству пафоса, а ценность его растет. И почему-то я совершенно не парюсь, что никто не узнает о моем опыте экономии байт при программировании на ассемблере КР580ВМ80А. Да и то что когда-то писал на С++ показывать становится все более "стеснительно".
Здравствуйте, IT, Вы писали: IT>Странная какая-то подборка. По теме мужик вроде всё толково и правильно пишет. А вот дальше идёт обсуждение непонятно чего
Так это просто нарезка отдельных несвязанных высказываний разного народа примерно на одну и ту же тему. Ильин, естественно, написал ближе всего к делу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Allix, Вы писали:
V_>>Интересная логика. Говно ли микроскоп, если им забивают гвозди? A>Микроскоп прекрасный, но легче ли мне от этого, если гвозди загоняют в мою голову? Я к тому и веду, что либо оставьте в покое мою голову и пользуйтесь микроскопом как полагается, либо вобще уберите микроскоп на фиг. К сожалению забивать гвозди прибором очень соблазнительно, поэтому мне, как пользователю, было бы гораздо лучше если бы net никогда и не существовало.
Хрена там. Железячные конторы никогда не умели писать софт. Не было бы дотнета — они бы нативное говно клепали с тем же успехом. Не стоит высказываться о том, в чем нихрена не понимаешь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
[skipped]
Согласен на 50%, на столько же % не согласен.
Развитие технологий приводит к тому, что мы постоянно вводим новые абстракции. Старые абстракции и инструменты или не справляются вовсе, или крайне неудобны при построении новых более сложных систем. Здесь мы придумываем новую абстракцию и снова весело летим вперед. Проблема в том, что иногда, да ладно, вру, очень часто приходится оглядываться назад, проваливаться внутрь абстракции, копаться в ее потрахах. Джоэл Спольски называет это законом дырявых абстракций:
Все нетривиальные абстракции дырявы.
В абстракциях обнаруживаются дыры. В одних немного, в других целая куча. Эти дыры постоянно просвечивают, протекают, абстракции не срабатывают.
Закон дырявых абстракций означает, к сожалению, что абстракции не так сильно упрощают нашу жизнь, как хотелось бы.
Программист, который не может (не умеет, не пробовал, пасует) справиться с дырками в используемых им каждодневно абстракциях, по мне просто кодер. Разумеется, все знать невозможно и непрактично, речь же идет о поиске золотой середины: замыкаться на узкой области знаний языков программирования (да, там много всего интересного, но все же) по мне почти также неэффективно с точки зрения профессионального роста.
Здравствуйте, Sinclair, Вы писали:
S>Хрена там. Железячные конторы никогда не умели писать софт. Не было бы дотнета — они бы нативное говно клепали с тем же успехом. Не стоит высказываться о том, в чем нихрена не понимаешь.
Ну некоторые все же умели. Раньше говно-программисты писали говно-код на дельфях или студии, теперь те же самые говно-программисты пишут (в два раза быстрее) говно-код на net. Проблема в том что на net сделать "какашку" в разы проще чем на С++ или дельфи (это я по результатам сужу) и получается в... нет не в два, к сожалению в 10 раз хуже.
Может конечно это такие уникальные программисты нынче, и на дельфях они тоже сделали бы в 10 раз хуже, но что-то сомневаюсь.
Вот и получается, как пользователь я этот нет готов обматерить, а как программист вполне не против на нем работать, хороший инструмент однака, да вот беда — по факту что-то испоганить используя нет получается куда легче чем на дельфих или с++
в том что на net сделать "какашку" в разы проще чем на С++ или дельфи (это я по результатам сужу) и получается в... нет не в два, к сожалению в 10 раз хуже.
Это ты как-то неправильно судишь по результатам. Не в те результаты смотришь, наверное. A>Может конечно это такие уникальные программисты нынче, и на дельфях они тоже сделали бы в 10 раз хуже, но что-то сомневаюсь.
А вот не надо сомневаться.
A>Вот и получается, как пользователь я этот нет готов обматерить, а как программист вполне не против на нем работать, хороший инструмент однака, да вот беда — по факту что-то испоганить используя нет получается куда легче чем на дельфих или с++
Это иллюзия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
По поводу чего? Если по поводу автора блога, то у него явно психологические проблемы. Если по поводу цитаты Ильина — то в общем и целом похоже на правду, за исключением того, что у него не очень широкий кругозор и он плохо видит мир программирования за пределами своей песочницы. Если по поводу твоих цитат — то дилетант, вещающий о судьбах программирования, выглядит очень смешно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Allix, Вы писали:
A>Раньше говно-программисты писали говно-код на дельфях или студии, теперь те же самые говно-программисты пишут (в два раза быстрее) говно-код на net. Проблема в том что на net сделать "какашку" в разы проще чем на С++ или дельфи (это я по результатам сужу)
Вторая гипотеза (на net сделать "какашку" в разы проще) излишня. Для объяснения результов достаточно одной (говно-программисты пишут говно-код в два раза быстрее).
Здравствуйте, BokiyIS, Вы писали:
BIS>Ув. товарищ Шеридан, если вы администратор, то вы и говорите об администрировании.
Ой, а можно я рискну и пофилософствую на тему и программирования, и администрирования, не являясь при этом ни программистом, ни администратором?
BIS>Вы лучше скажите, зачем мне знать (учить) администрирование для того, чтобы быть программистом?
По моему глубокому убеждению, программист (не кодер), не понимающий сути работы платформ, под которые он пишет код (ОС, СУБД, различные сервера приложений, балансеры, средства виртуализации, и т.п. — не важно), не будет столь же эффективен в процессе разработки, как его коллега, владеющий подобными знаниями. Разумеется — это перебор, утверждать, что любой программист просто обязан уметь поднимать базовые серверные системы уровня предприятия и осуществлять их поддержку. Но понимать как работает то, под что ты пишешь свой код — программист IMO обязан. Иметь опыт администрирования и поддержки того, под чем будет работать твой код — тоже огромный плюс, особенно если в обязанности программиста входит саппорт второго и выше уровня разрабатываемого продукта.
Это как с бортовыми компьютерами на автомобилях. Теоретически можно, будучи пешеходом, разрабатывать систему для такого компьютера, просто слепо следуя спецификации на его интерфейсы и зная, с какого датчика какие данные считывать, как их обрабатывать и какие команды слать на выходы. Но для обеспечения оптимального расхода топлива и динамики разгона, быть заядлым автомобилистом — будет явно не лишним.
Это как и с предметной областью. Теоретически можно, не владея предметной областью для которой разрабатывается приложение, не менее слепо следовать проектным спецификациям и даже чего-нибудь там накодить в соответствии с архитектурой проекта и поставленными задачами. На практике же (например) не владея хотя азами банковского дела, в сфере разработки АБС программистам делать нечего...
Так почему столь широко распространено мнение, что "прикладникам" негоже в своей деятельности учитывать факторы, обусловленные средой под которую разрабатывается продукт, если по сути она является такой же предметной областью, только не для конечного пользователя продукта, а для разрабатывающего его программиста? Этого я наверное никогда не смогу понять
Кроме того, имея за плечами почти две сотни тестов на проникновение и полтора десятка ревью безопасности кода, могу сказать, что наиболее "чистым" кодом могут похвастаться отнюдь не команды "прикладников" пытающиеся абстрагироваться от всего, не имеющего по их мнению отношения к непосредственно процессу разработки, скорее наоборот. Чисто статистически.
BIS>Пусть я программирую под .net на C#, это вообще ничего незначит.
Напротив, это значит, что большая часть уязвимостей в твоем коде будет относится к совершенно иным (действительно — более прикладным и легче отлавливаемым) классам , по сравнению с тем, как если бы ты использовал неуправляемые среды Хотя (опять-таки, статистически) средняя температура по больнице тут одинаковая и для управляемых и для неуправляемых сред. Просто процентное соотношение классов уязвимостей — разное, а вот их количество — примерно одинаковое и коррелирует лишь с уровнем квалификации участников проекта (см. рассуждения выше).
BIS>Мне кажется что это глупо и некрасиво говорить такое о коллегах. Используешь шарп — получи ярлыком "фе, дотнетчик" в лоб.
ИМХО, ряд разумных мыслей в статье есть. Там конечно, ИМХО, много притянуто за уши а много гипертрофировано, но в целом соглашусь с тем что сейчас стали писать гораздо более высокоуровневый код.
Лично я не согласен с тем, что знание "как оно там все работает" всем-всем нужно. Если среда разработки хорошо инкапсулирована и позволяет решать все необходимые задачи — то программисту совсем не обязательно знать, как именно там внутри реализован sort, когда закрываются файлы и из скольких частей состоит механизм отрисовки окон в операционной системе.
Но, тем не менее, с пользой таких знаний я согласен. Все-таки если программист точно знает почему в винде мигает перерисовка окошек он гораздо быстрее решит поставленную задачу "чтобы не мигало". Гуру под рукой иногда может и не быть.
Драйвера и прикладной софт в основном работают нормально. Ясное дело, что тестировали их на мейнстрим компьютерах. И при попытке запустить сканилку на PII-233 она будет тормозить. Но не потому что программисты плохие, а потому что задачу "чтобы быстро было" не ставили. Потому что сроки и прибыли.
Что до вырождения... Вопрос неочевидный. Хорошие и плохие специалисты были всегда. Спрос рождает предложение. Социум меняется. Раньше хороших программистов было больше — программистов вообще было меньше. Сейчас же можно в любом супермаркете за 100р купить 10-и кнопочную мышку и к ней будет программа дл мапинга этих кнопок. Да, она написана не гуру. Она будет тормозить на слабых компьютерах и может даже будет падать. Но она будет. За 100р. В любом супермаркете.
Глобализация, интеграция, конкуренция. Все течет, все менется. Спрос рождает предложения, деньги получаются с масс. Возможно, скоро повится такой критерий оценки как "качество программы". И появятся в софте свои бентли и банги с оуфстенами. Если будет спрос. Если это будет нужно и будет приносить деньги. Вы ведь хотите денег?
Душевно написано. Блин, я когда-то давно вывел для себя мысль, что в развитии многих вещей можно проследить 3 этапа: зарождения, развития и перехода в стабильное состояние. В программировании и в современной компьютерщине давно уже настал 3-й этап. Бывший СССР догнал всех очень быстро, лет за 10 или меньше, поэтому многие вещи проявляются особенно ярко.
Многое из того, что обсуждается, — это характерные свойства наступления 3-го этапа: снижение требований к квалификации (в отличие от первых 2-х этапов, основная масса задач уже стандартна), ламеризация; приход в область относительно большой массы кадров, в том числе блондинок; недовольство "старой гвардии" (объективно потребность в суперпрофи даже нередко исчезает, становятся нужнее надежные труженики конвейера). Тут речь идет об индустрии, но я несколько раз наблюдал очень похожее в конторах, в которых на моих глазах происходил собственный переход к 3-му этапу. Я не притягиваю факты к своей "теории", это само бросается в глаза: признаки, ситуации и реакции на это очень характерны и похожи.
Проявлять недовольство положением дел бессмысленно, т.к. происходящее объективно и с большой вероятностью характерно для любой отрасли или вида деятельности. Только иногда почему-то вспоминается 2-е начало термодинамики .
Здравствуйте, goto, Вы писали:
G>Душевно написано. Блин, я когда-то давно вывел для себя мысль, что в развитии многих вещей можно проследить 3 этапа: зарождения, развития и перехода в стабильное состояние. В программировании и в современной компьютерщине давно уже настал 3-й этап. Бывший СССР догнал всех очень быстро, лет за 10 или меньше, поэтому многие вещи проявляются особенно ярко.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, goto, Вы писали:
G>>Душевно написано. Блин, я когда-то давно вывел для себя мысль, что в развитии многих вещей можно проследить 3 этапа: зарождения, развития и перехода в стабильное состояние. В программировании и в современной компьютерщине давно уже настал 3-й этап. Бывший СССР догнал всех очень быстро, лет за 10 или меньше, поэтому многие вещи проявляются особенно ярко.
К>Hype cycle?
Нет. Hype circle — это скорее взгляд на явление снаружи, его имимдж, маркетинговая сторона. То, про что я писал, — это взгляд изнутри, относится к восприятию происходящего самими участниками процесса. Я сам работал в нескольких местах именно на 2-м этапе — развития. Когда он переходит в 3-й, среди тех, кто фактически поднимал дело, начинаются разговоры: ерунда какая-то происходит; начальство офигело; набирают непонятно кого; задача дебильна; профессионалов не ценят; потенциал не используется... Это грубо, но по характеру примерно так. Видел своими глазами несколько раз. На протяжении 2-го этапа приходилось решать новые неординарные задачки, люди подбирались соответствующие. На 3-м этапе все это становится в основе не нужно, начинают ценится другие качества работников, и "гвардия" начинает массово "тухнуть" на этом месте. Чаще всего большинство уходит в другие места (те, кто не тормоз или не пошел в администраторы). Подобное может происходить и в отрасли.
Например, для меня лично программирование как таковое себя в значительной степени исчерпало. Технологии глубоко вторичны, и в них почти все уже было . Их современное развитие, насколько я могу судить, в основном направлено просто на более эффективную организацию конвейера и (в массе) на более эффективный труд простых служащих.
Здравствуйте, goto, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, goto, Вы писали:
G>>>Душевно написано. Блин, я когда-то давно вывел для себя мысль, что в развитии многих вещей можно проследить 3 этапа: зарождения, развития и перехода в стабильное состояние. В программировании и в современной компьютерщине давно уже настал 3-й этап. Бывший СССР догнал всех очень быстро, лет за 10 или меньше, поэтому многие вещи проявляются особенно ярко.
К>>Hype cycle?
G>Нет. Hype circle — это скорее взгляд на явление снаружи, его имимдж, маркетинговая сторона. То, про что я писал, — это взгляд изнутри, относится к восприятию происходящего самими участниками процесса. Я сам работал в нескольких местах именно на 2-м этапе — развития. Когда он переходит в 3-й, среди тех, кто фактически поднимал дело, начинаются разговоры: ерунда какая-то происходит; начальство офигело; набирают непонятно кого; задача дебильна; профессионалов не ценят; потенциал не используется... Это грубо, но по характеру примерно так. Видел своими глазами несколько раз. На протяжении 2-го этапа приходилось решать новые неординарные задачки, люди подбирались соответствующие. На 3-м этапе все это становится в основе не нужно, начинают ценится другие качества работников, и "гвардия" начинает массово "тухнуть" на этом месте. Чаще всего большинство уходит в другие места (те, кто не тормоз или не пошел в администраторы). Подобное может происходить и в отрасли.
Cycle!=circle, а противопоставление внутри/снаружи по-моему натянуто и описывается по сути то же самое, только в несколько ином масштабе (в Hype cycle рассматривается именно отрасль).
Здравствуйте, Курилка, Вы писали:
... К>Cycle!=circle, а противопоставление внутри/снаружи по-моему натянуто и описывается по сути то же самое, только в несколько ином масштабе (в Hype cycle рассматривается именно отрасль).
Описался, бывает.
Противопоставления нет. Этот Cycle понятен, просто я писал про другое. Для меня это когда-то стало личным открытием. Я уходил с разных работ, когда там, с моей т. зр., начиналось "не то". Дальше в том месте это "не то" усугублялось, и оттуда уходила значительная часть прежнего состава. Это происходило несколько раз, и я стал думать, что я как крыса, бегущая первой с тонущего корабля, рано начинаю чувствовать появление "запашка", "гнильцы", как я тогда это оценивал. Но постепенно я понял, что все объективно, что есть характерные этапы, что я по натуре являюсь тружеником 2-го этапа, и когда начмнается 3-й, для меня и части моих коллег естественным образом наступает это "не то".
Возможно эти проблемы вам лично не близки. Для меня это личный опыт, подтвержденный наблюдениями. "Теории" своей я какого-то особого мирового значения не придаю (просто рассказал), поэтому не согласны, так не согласны .
Здравствуйте, goto, Вы писали:
G>Здравствуйте, Курилка, Вы писали: G>... К>>Cycle!=circle, а противопоставление внутри/снаружи по-моему натянуто и описывается по сути то же самое, только в несколько ином масштабе (в Hype cycle рассматривается именно отрасль).
G>Описался, бывает.
G>Противопоставления нет. Этот Cycle понятен, просто я писал про другое. Для меня это когда-то стало личным открытием. Я уходил с разных работ, когда там, с моей т. зр., начиналось "не то". Дальше в том месте это "не то" усугублялось, и оттуда уходила значительная часть прежнего состава. Это происходило несколько раз, и я стал думать, что я как крыса, бегущая первой с тонущего корабля, рано начинаю чувствовать появление "запашка", "гнильцы", как я тогда это оценивал. Но постепенно я понял, что все объективно, что есть характерные этапы, что я по натуре являюсь тружеником 2-го этапа, и когда начмнается 3-й, для меня и части моих коллег естественным образом наступает это "не то".
G>Возможно эти проблемы вам лично не близки. Для меня это личный опыт, подтвержденный наблюдениями. "Теории" своей я какого-то особого мирового значения не придаю (просто рассказал), поэтому не согласны, так не согласны .
Не надо, пожалуйста, делать выводы за меня (про близко или нет), я лишь говорю, что то, о чём вы говорите давно уже многими замечено, а hype cycle — один из вариантов.
Здравствуйте, CreatorCray, Вы писали: CC>А с другой стороны: там где unmanaged давно бы упало managed будет тормозить и жрать память но как то работать.
Ничего подобного. Лично наблюдал нативное овно, тормозящее и жрущее память, но не падающее.
На всякий случай напомню, что на дотнете несколько труднее совершить memory leak.
К примеру, на Delphi большинство тяп-ляпщиков вообще никогда ничего не удаляет. Потому, что TComponent умирает вместе с Owner, а про остальное тяп-ляпщики просто не думают никогда.
По-прежнему настаиваю на необходимости предварительного знакомства с предеметом, о котором не терпится высказать какое-либо мнение.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
CC>>А с другой стороны: там где unmanaged давно бы упало managed будет тормозить и жрать память но как то работать. S>Ничего подобного. Лично наблюдал нативное овно, тормозящее и жрущее память, но не падающее.
Таланты везде имеются. Но таких единичных случаев на любой вкус можно привести.
S>На всякий случай напомню, что на дотнете несколько труднее совершить memory leak.
В манагед "утечки" несколько иного рода. Например в виде указателя, переданного в какой нить вечноживой контейнер, из которого его забыли грохнуть и в результате он держит офигенных размеров "дерево".
S>К примеру, на Delphi большинство тяп-ляпщиков вообще никогда ничего не удаляет. Потому, что TComponent умирает вместе с Owner, а про остальное тяп-ляпщики просто не думают никогда.
Дельфи это вообще отдельный п%%%ц.
S>По-прежнему настаиваю на необходимости предварительного знакомства с предеметом, о котором не терпится высказать какое-либо мнение.
Не стоит так волноваться, знакомство имеется. Причем с худшей стороны — индусского C# кода.
Здравствуйте, CreatorCray, Вы писали: CC>Таланты везде имеются. Но таких единичных случаев на любой вкус можно привести.
Совершенно верно. Мы говорим не о талантах, а о том, что будет происходить в одинаковых случаях на разных платформах.
S>>На всякий случай напомню, что на дотнете несколько труднее совершить memory leak. CC>В манагед "утечки" несколько иного рода. Например в виде указателя, переданного в какой нить вечноживой контейнер, из которого его забыли грохнуть и в результате он держит офигенных размеров "дерево".
Я в курсе. Но для этого этот указатель хотя бы нужно поместить в контейнер. В анменеджед достаточно просто его потерять. Например, с чистой душой присвоить новый объект в ссылку на старый, типа currentImage = LoadImage();
CC>Дельфи это вообще отдельный п%%%ц.
Ничего отдельного он не представляет. Никаких специальных средств ухудшения программ в нем нету.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>На всякий случай напомню, что на дотнете несколько труднее совершить memory leak. CC>>В манагед "утечки" несколько иного рода. Например в виде указателя, переданного в какой нить вечноживой контейнер, из которого его забыли грохнуть и в результате он держит офигенных размеров "дерево". S>Я в курсе. Но для этого этот указатель хотя бы нужно поместить в контейнер. В анменеджед достаточно просто его потерять. Например, с чистой душой присвоить новый объект в ссылку на старый, типа currentImage = LoadImage();
Лики хотя бы отлавливаются (BoundsChecker сильно в таком помогает). А как отловить автоматически подобную забывчивость?
CC>>Дельфи это вообще отдельный п%%%ц. S>Ничего отдельного он не представляет. Никаких специальных средств ухудшения программ в нем нету.
В нем самом, почти — нету. А вот в сложившемся коммюнити бОльшая часть дельфеписателей сами по себе средство по ухудшению любой программы.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, goto, Вы писали:
... G>>Возможно эти проблемы вам лично не близки. Для меня это личный опыт, подтвержденный наблюдениями. "Теории" своей я какого-то особого мирового значения не придаю (просто рассказал), поэтому не согласны, так не согласны .
К>Не надо, пожалуйста, делать выводы за меня (про близко или нет), я лишь говорю, что то, о чём вы говорите давно уже многими замечено, а hype cycle — один из вариантов.
Я немного позанудствую.
Касательно вас лично я использовал слово "возможно". Как вариант, некто мог бы всю свою сознательную жизнь проработать на острие науки/технологии и с ярким проявлением таких этапов просто не сталкиваться. Возможны и другие варианты героической и славной трудовой биографии, когда человек просто не бьется об эти этапы лбом несколько раз подряд, как я. По-разному бывает. Так что я с вами здесь жизненными опытами не меряюсь, а лишь предполагаю, что они отличаются, не более.
Про мое "открытие". Во-первых, я писал, что сделал его для себя. Было бы смешно здесь претендовать на что-то большее. Не удивлюсь, если похожие мысли уже изложены в древнеегипетских папирусах (и про hype cycle, кстати, тоже). Современные профессиональные исследователи уже написали кучу всего про этапы и циклы. Меня здесь интересуют не столько сами этапы, сколько связанные с ними психологические проблемы, то, что изнутри смена этапов в коллективе или отрасли частью людей восприннимается болезненно, неадекватно. Это имеет прямое отношение к ссылке, предложенной Шериданом, где такие нотки прослеживаются.
Между hype cycle и тем, о чем писал я, существует корреляция. Hype cycle сам по себе, как я его понимаю, имеет отношение ы 1-ю очередь к внешней стороне развития (ожидания народных масс, деньги, внимание прессы и т.п.). То, что при этом происходит внутри фирм-участниц, с этим конечно связано, но кривая внутренних изменений уже не обязана повторять hype cycle.
Здравствуйте, goto, Вы писали:
G>Душевно написано. Блин, я когда-то давно вывел для себя мысль, что в развитии многих вещей можно проследить 3 этапа: зарождения, развития и перехода в стабильное состояние. В программировании и в современной компьютерщине давно уже настал 3-й этап. Бывший СССР догнал всех очень быстро, лет за 10 или меньше, поэтому многие вещи проявляются особенно ярко.
А чем этапы зарождение и развития отличаются? И где у нас финальный этап? Или оно всё накапливается не помирая?
G>Многое из того, что обсуждается, — это характерные свойства наступления 3-го этапа
Конвеер он и есть конвеер. Дешево и нудно.
Хотя, дело скорее в человеке, чем в технологии (за исключением клинических случаев вроде реального конвеера).
Что за работа у токаря — точишь и точишь одни и те-же детали, год за годом.
Но говорят, есть токари 6-го разряда, и им не скучно.
Я уверен, что место творчеству есть на всех этапах развития технологии. Включая и тот, который вы назвали 3-й.
Может вы эти возможности не замечаете?
ЗЫ Кстати, этот 3-й этап и есть этам настоящего развития. А 2-й — это не развитие, а "экспансия".
Количественный рост, не более того. На развитие он похож только внешне.
Здравствуйте, mkizub, Вы писали:
M>А чем этапы зарождение и развития отличаются? И где у нас финальный этап? Или оно всё накапливается не помирая?
Зарождение, например, бизнеса — это завершение первых шагов: идея, план, потенциальный источник первых денег, официальные бумажки, открытие офиса и тому подобное. 2-й этап — когда все стартовало и развивается. Обычно нанимаются люди. 2 этап естественным образом закангчивается, когда наступает 3-й, т.е. все становится достаточно успешным, стабильным, выходит на "полочку". Финальным, разумеется, может стать любой этап, если все накроется медным тазом. Или, например, если стартап продается. 3 этап, — название условное, там куча своих телодвижений. Я туда просто не лезу. Я лишь написал о некоторых частных проблемах, характерных для перехода от интенсивного развития к относительно стабильному состоянию.
G>>Многое из того, что обсуждается, — это характерные свойства наступления 3-го этапа
M>Конвеер он и есть конвеер. Дешево и нудно. M>Хотя, дело скорее в человеке, чем в технологии (за исключением клинических случаев вроде реального конвеера). M>Что за работа у токаря — точишь и точишь одни и те-же детали, год за годом. M>Но говорят, есть токари 6-го разряда, и им не скучно. M>Я уверен, что место творчеству есть на всех этапах развития технологии. Включая и тот, который вы назвали 3-й. M>Может вы эти возможности не замечаете?
Почему не замечаю? Конечно все зависит от самого человека. Но люди и ситуации бывают очень разные. Если какая-то ситуация объективно меняется, то некоторым людям приходится менять место работы . Мне лично, например, всегда было интересно делать новые проекты, а не поддерживать и развивать уже готовый продукт, пусть даже свой собственный.
M>ЗЫ Кстати, этот 3-й этап и есть этам настоящего развития. А 2-й — это не развитие, а "экспансия". M>Количественный рост, не более того. На развитие он похож только внешне.
Почему? Может быть, мы говорим о разных вещах?
На 2-м этапе решаются качественно новые задачи. Если обизнесе, то не просто нарабатываются новые связи, а ищутся новые способы, техники, пододы для этого. Если о технологической стороне, то "поднимаются" новые проекты, осваиваиаются или создаются продукты, технологии. Иногда даже выращиваются рынки. А в дальнейшем это все уже в основном равивается количественно и поддерживатеся.
Я не абсолютизирую все эти несчастные этапы. Речь о тенденциях. В абсолютно чистом виде почти ничего не бывает.
Здравствуйте, goto, Вы писали:
G>Например, для меня лично программирование как таковое себя в значительной степени исчерпало. Технологии глубоко вторичны, и в них почти все уже было . Их современное развитие, насколько я могу судить, в основном направлено просто на более эффективную организацию конвейера и (в массе) на более эффективный труд простых служащих.
Тут самое главное — не перепутать свое субъективное нежелание постоянно перевариавть новое с объективным состоянием индустрии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ой, а можно я рискну и пофилософствую на тему и программирования, и администрирования, не являясь при этом ни программистом, ни администратором?
Насколько я понял из Вашей истории сообщений, Вы все же администратор, как хобби увлекающийся программированием.
KV>По моему глубокому убеждению, программист (не кодер), не понимающий сути работы платформ, под которые он пишет код (ОС, СУБД, различные сервера приложений, балансеры, средства виртуализации, и т.п. — не важно), не будет столь же эффективен в процессе разработки, как его коллега, владеющий подобными знаниями. Разумеется — это перебор, утверждать, что любой программист просто обязан уметь поднимать базовые серверные системы уровня предприятия и осуществлять их поддержку. Но понимать как работает то, под что ты пишешь свой код — программист IMO обязан. Иметь опыт администрирования и поддержки того, под чем будет работать твой код — тоже огромный плюс, особенно если в обязанности программиста входит саппорт второго и выше уровня разрабатываемого продукта.
Мда, слабо связанные с реальностью пространные рассуждения о том, о чем не имеем ни малейшего представления. Чтобы не быть голословным, приведу пример одного проекта в котором я участвовал. Весь код, взаимодействия с ОС мы выделили в отдельный слой абстракции. Этот код занимал меньше 5% от всего кода проекта. Остальные 95% кода связаны с самой предметной областью проекта. Я думаю выводы очевидны.
KV>Это как с бортовыми компьютерами на автомобилях. Теоретически можно, будучи пешеходом, разрабатывать систему для такого компьютера, просто слепо следуя спецификации на его интерфейсы и зная, с какого датчика какие данные считывать, как их обрабатывать и какие команды слать на выходы. Но для обеспечения оптимального расхода топлива и динамики разгона, быть заядлым автомобилистом — будет явно не лишним.
Как практик разрабатывавший бортовые системы навигации скажу, надо тупо следовать спецификации на 100%. Быть заядлым автомобилистом тут явно лишнее.
KV>Это как и с предметной областью. Теоретически можно, не владея предметной областью для которой разрабатывается приложение, не менее слепо следовать проектным спецификациям и даже чего-нибудь там накодить в соответствии с архитектурой проекта и поставленными задачами. На практике же (например) не владея хотя азами банковского дела, в сфере разработки АБС программистам делать нечего...
Программист не может быть экспертом одновременно в программировании и предметной области (если учесть, что этих предметных областей множество). Поэтому и есть такая практика связки программист — эксперт в предметной области, и как показывает практика, она наиболее эффективна. Но это конечно не исключает знания азов предметной области.
KV>Так почему столь широко распространено мнение, что "прикладникам" негоже в своей деятельности учитывать факторы, обусловленные средой под которую разрабатывается продукт, если по сути она является такой же предметной областью, только не для конечного пользователя продукта, а для разрабатывающего его программиста? Этого я наверное никогда не смогу понять
И не поймешь наверное. Т.к. "среда" не есть предметная область программиста, предметная область программиста гораздо шире.
KV>Кроме того, имея за плечами почти две сотни тестов на проникновение и полтора десятка ревью безопасности кода, могу сказать, что наиболее "чистым" кодом могут похвастаться отнюдь не команды "прикладников" пытающиеся абстрагироваться от всего, не имеющего по их мнению отношения к непосредственно процессу разработки, скорее наоборот. Чисто статистически.
Можно подумать ты свечку держал в процессе разработки этих "прикладников"
KV>Напротив, это значит, что большая часть уязвимостей в твоем коде будет относится к совершенно иным (действительно — более прикладным и легче отлавливаемым) классам , по сравнению с тем, как если бы ты использовал неуправляемые среды Хотя (опять-таки, статистически) средняя температура по больнице тут одинаковая и для управляемых и для неуправляемых сред. Просто процентное соотношение классов уязвимостей — разное, а вот их количество — примерно одинаковое и коррелирует лишь с уровнем квалификации участников проекта (см. рассуждения выше).
Опять какая-то непонятная статистика, процентное соотношение, а где источник?
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, CreatorCray, Вы писали:
S>>Я в курсе. Но для этого этот указатель хотя бы нужно поместить в контейнер. В анменеджед достаточно просто его потерять. Например, с чистой душой присвоить новый объект в ссылку на старый, типа currentImage = LoadImage(); CC>Лики хотя бы отлавливаются (BoundsChecker сильно в таком помогает). А как отловить автоматически подобную забывчивость?
BoundsChecker помогает не всегда. А в менеджед средах увидеть, то где утечка можно всегда. Разницу чувствуешь?
CC>>>Дельфи это вообще отдельный п%%%ц. S>>Ничего отдельного он не представляет. Никаких специальных средств ухудшения программ в нем нету. CC>В нем самом, почти — нету. А вот в сложившемся коммюнити бОльшая часть дельфеписателей сами по себе средство по ухудшению любой программы.
Как будто среди С++ников их меньше.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
CC>>>>Дельфи это вообще отдельный п%%%ц. S>>>Ничего отдельного он не представляет. Никаких специальных средств ухудшения программ в нем нету. CC>>В нем самом, почти — нету. А вот в сложившемся коммюнити бОльшая часть дельфеписателей сами по себе средство по ухудшению любой программы.
Y>Как будто среди С++ников их меньше.
Немного меньше. Объектная модель и умные указатели помогают.
Здравствуйте, gandjustas, Вы писали:
G>Немного меньше. Объектная модель и умные указатели помогают.
Откуда в С++ взялась объектная модель? Плюсы — это темный зоопарк совершенно противоположных парадигм программирования. Где-то полиморфизм достигается честным наследованием, где-то — шаблонной подстановкой, где-то — макросом. Где-то вообще полиморфизм получается полуслучайно, благодаря тому, что принципиально разные вещи выглядят одинаково, и компилятор обязан это компилировать.
Вот в джаве есть объектная модель; в дотнете есть. В MFC и VCL есть. А в С++ есть только разрозненный набор прикольных трюков.
Умные указатели — замечательная штука, если не считать того, что они не запрещают использование глупых указателей.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Немного меньше. Объектная модель и умные указатели помогают. S>Откуда в С++ взялась объектная модель? Плюсы — это темный зоопарк совершенно противоположных парадигм программирования. Где-то полиморфизм достигается честным наследованием, где-то — шаблонной подстановкой, где-то — макросом. Где-то вообще полиморфизм получается полуслучайно, благодаря тому, что принципиально разные вещи выглядят одинаково, и компилятор обязан это компилировать.
А программист обязан еще и понять что там написано. Но я не это имел ввиду.
Я имел ввиду реализацию работы с объектами. В C++ есть атоматические деструкторы, конструкторы копирования, из метода можно вернуть объект или умный указатель и в большенстве случаев утечек не будет.
В Делфи нельзя просто вернуть объект из метода потому что совсем непонятно кто отвечает за его уничтожение.
S>Умные указатели — замечательная штука, если не считать того, что они не запрещают использование глупых указателей.
Но они хотябы есть, уже немалое преимущество.
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, kochetkov.vladimir, Вы писали:
Y>Насколько я понял из Вашей истории сообщений, Вы все же администратор, как хобби увлекающийся программированием.
На "ты" можно? Нет, это не так. Хотя опыт работы в области поддержки систем у меня есть. На данный же момент (уже третий год) в мои обязанности в равной степени входит как проведение blackbox-тестов защищенности эксплуатируемых ИС, так и такие вещи как ревью разрабатываемого внутри компании кода на ту же тему.
Y>Мда, слабо связанные с реальностью пространные рассуждения о том, о чем не имеем ни малейшего представления. Чтобы не быть голословным, приведу пример одного проекта в котором я участвовал. Весь код, взаимодействия с ОС мы выделили в отдельный слой абстракции. Этот код занимал меньше 5% от всего кода проекта. Остальные 95% кода связаны с самой предметной областью проекта. Я думаю выводы очевидны.
Разумеется очевидны. Их два:
1. У вас нормальный архитектор
2. Реализовывавшие эти 5% кода программеры, более квалифицированны нежели их остальные коллеги
Y>Как практик разрабатывавший бортовые системы навигации скажу, надо тупо следовать спецификации на 100%. Быть заядлым автомобилистом тут явно лишнее.
Аргументация?
Y>И не поймешь наверное. Т.к. "среда" не есть предметная область программиста, предметная область программиста гораздо шире.
Ну извини, если подобным категоричным утверждением я как-то задел самолюбие программиста. Разумеется, предметная область программиста очень широкая (а главное длинная ). Я подразумевал, что в большинстве случаев "среда" является частью предметной области. Хотя от проекта зависит.
Я ведь под "средой" не только ОС понимаю. CLR/JVM — тоже среды, например.
Y>Можно подумать ты свечку держал в процессе разработки этих "прикладников"
Хуже. Я проводил ревью их кода, после чего неоднократно участвовал в обсуждениях, подобных этому.
Y>Опять какая-то непонятная статистика, процентное соотношение, а где источник?
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, CreatorCray, Вы писали:
S>>>Я в курсе. Но для этого этот указатель хотя бы нужно поместить в контейнер. В анменеджед достаточно просто его потерять. Например, с чистой душой присвоить новый объект в ссылку на старый, типа currentImage = LoadImage(); CC>>Лики хотя бы отлавливаются (BoundsChecker сильно в таком помогает). А как отловить автоматически подобную забывчивость?
Y>BoundsChecker помогает не всегда. А в менеджед средах увидеть, то где утечка можно всегда. Разницу чувствуешь?
Можно доказательство второго утверждения во всей его полноте?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>На "ты" можно? Нет, это не так. Хотя опыт работы в области поддержки систем у меня есть. На данный же момент (уже третий год) в мои обязанности в равной степени входит как проведение blackbox-тестов защищенности эксплуатируемых ИС, так и такие вещи как ревью разрабатываемого внутри компании кода на ту же тему.
Жесть, админ, который делает ревью кода программистов Обычно в обычных конторах, ревью кода делают более опытные, матерые программисты, код менее опытных коллег.
KV>1. У вас нормальный архитектор
+1 KV>2. Реализовывавшие эти 5% кода программеры, более квалифицированны нежели их остальные коллеги
Феерическое резюме Тут даже комментировать нечего
Y>>Как практик разрабатывавший бортовые системы навигации скажу, надо тупо следовать спецификации на 100%. Быть заядлым автомобилистом тут явно лишнее.
KV>Аргументация?
Спецификацию составляет эксперт в предметной области, несоблюдение спеки, равносильно грубой ошибке программиста.
KV>Ну извини, если подобным категоричным утверждением я как-то задел самолюбие программиста. Разумеется, предметная область программиста очень широкая (а главное длинная ). Я подразумевал, что в большинстве случаев "среда" является частью предметной области. Хотя от проекта зависит.
KV>Я ведь под "средой" не только ОС понимаю. CLR/JVM — тоже среды, например.
Ага, офис например тоже "среда" программиста Вы специально пытаетесь меня запутать? Речь ведь изначально шла про администрирование. А про ширину и длину зря ты так, я имел ввиду, сегодня у программиста одна предметная область, завтра другая и невозможно везде быть экспертом. Кстати прикладнику не обязательно быть экспертом в внутренностях CLR\JVM Это я так, к слову
Y>>Можно подумать ты свечку держал в процессе разработки этих "прикладников" KV>Хуже. Я проводил ревью их кода, после чего неоднократно участвовал в обсуждениях, подобных этому. Y>>Опять какая-то непонятная статистика, процентное соотношение, а где источник? KV>Источником, в данном случае, являюсь я
Ну т.е. понятно, сугубо субъективная точка зрения на основании какого-то своего малого опыта.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>На "ты" можно? Нет, это не так. Хотя опыт работы в области поддержки систем у меня есть. На данный же момент (уже третий год) в мои обязанности в равной степени входит как проведение blackbox-тестов защищенности эксплуатируемых ИС, так и такие вещи как ревью разрабатываемого внутри компании кода на ту же тему.
Y>Жесть, админ, который делает ревью кода программистов Обычно в обычных конторах, ревью кода делают более опытные, матерые программисты, код менее опытных коллег.
позволю себе немного высказться за Владимира:
Вы немного не совсем верно поняли, чем он занимается. насколько я знаю из истории сообщений Владимира, он занимается информационной безопасностью. соответсвенно, ревью кода выполняется на предмет потенциальных уязвимостей и пр., что может повредить безопасности и/или нарушить существующую инфраструктуру.
Здравствуйте, yumi, Вы писали:
Y>>>Кстати прикладнику не обязательно быть экспертом в внутренностях CLR\JVM Это я так, к слову
здесь категорически не соглашусь. знание спецификации и принципов работы среды, в которой выполняется код этого прикладника позволяет писать этот же код лучше, больше соответствовать требованиям.
или по вшему мнению, знать, как работают исключения, ref/value types, ч из себя представлют using{...} statements, список можно продолжать до бесконечности... совсем не обязательно?
по моему глубокому убеждению, которое подтверждено и собственным опытом работы, и наблюдением за джуниорами в тиме, знать среду ооочень желательно. иначе прикладник тк и останется кодером.
Здравствуйте, a_kutovets, Вы писали:
Y>>>>Кстати прикладнику не обязательно быть экспертом в внутренностях CLR\JVM Это я так, к слову
_>здесь категорически не соглашусь. знание спецификации и принципов работы среды, в которой выполняется код этого прикладника позволяет писать этот же код лучше, больше соответствовать требованиям.
Требованиям можно лишь соответствовать или нет. "Соответствовать больше" — оч. странная формулировка.
_>или по вшему мнению, знать, как работают исключения, ref/value types, ч из себя представлют using{...} statements, список можно продолжать до бесконечности... совсем не обязательно?
Это вряд ли можно отнести к "внутренностям CLR". Внутренности — это например, тонкости того, как работает GC, как устроена таблица виртуальных методов, как работает interop и т.д. Необходимость в этих знаниях на практике очень мала.
Здравствуйте, a_kutovets, Вы писали:
_>Вы немного не совсем верно поняли, чем он занимается. насколько я знаю из истории сообщений Владимира, он занимается информационной безопасностью. соответсвенно, ревью кода выполняется на предмет потенциальных уязвимостей и пр., что может повредить безопасности и/или нарушить существующую инфраструктуру.
Простите, но по моим сугубо религиозным взглядам, ревью кода должны делать именно сами программисты, а не безопасники, админы, дворники ит.д. Тестировать конечный продукт, ради бога! А проводить ревью кода программистов, это уже, смахивает на маразм... Для этого как минимум самому надо быть программистом
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>На "ты" можно? Нет, это не так. Хотя опыт работы в области поддержки систем у меня есть. На данный же момент (уже третий год) в мои обязанности в равной степени входит как проведение blackbox-тестов защищенности эксплуатируемых ИС, так и такие вещи как ревью разрабатываемого внутри компании кода на ту же тему.
Y>Жесть, админ, который делает ревью кода программистов Обычно в обычных конторах, ревью кода делают более опытные, матерые программисты, код менее опытных коллег.
Там выше уже пояснили, что я не админ (2a_kutovets — ). А вообще логика — железная. Т.е. если человеку довелось поработать админом, то это ему несмываемое клеймо на всю жизнь? Так у меня по трудовой, первая запись — художником-оформителем в течении 5 месяцев, это я еще будучи студентом подрабатывал, в силу своего среднего образования (оно у меня художественное). Это тоже повод ахнуть, "жесть", мол: "фотошопник, ревью кода делает "?
KV>>1. У вас нормальный архитектор Y>+1 KV>>2. Реализовывавшие эти 5% кода программеры, более квалифицированны нежели их остальные коллеги Y>Феерическое резюме Тут даже комментировать нечего
Ну, я на такой коммент тоже затрудяюсь ответить
Y>>>Как практик разрабатывавший бортовые системы навигации скажу, надо тупо следовать спецификации на 100%. Быть заядлым автомобилистом тут явно лишнее.
KV>>Аргументация?
Y>Спецификацию составляет эксперт в предметной области, несоблюдение спеки, равносильно грубой ошибке программиста.
Т.е. любую спецификацию всегда можно реализовать только одним способом / путем / инструментами / подходами?
Не-а.
KV>>Ну извини, если подобным категоричным утверждением я как-то задел самолюбие программиста. Разумеется, предметная область программиста очень широкая (а главное длинная ). Я подразумевал, что в большинстве случаев "среда" является частью предметной области. Хотя от проекта зависит.
KV>>Я ведь под "средой" не только ОС понимаю. CLR/JVM — тоже среды, например.
Y>Ага, офис например тоже "среда" программиста
Конечно, если он пишет под MSTO, либо продукт заточен под какую-либо интеграцию с MSO.
Y>Вы специально пытаетесь меня запутать?
Разумеется, это ж азы риторики
Y>Речь ведь изначально шла про администрирование. А про ширину и длину зря ты так, я имел ввиду, сегодня у программиста одна предметная область, завтра другая и невозможно везде быть экспертом.
Я просто пошутил, сорри.
Y>Кстати прикладнику не обязательно быть экспертом в внутренностях CLR\JVM Это я так, к слову
Эксперту-прикладнику — обязательно, IMHO, без этого он не будет экспертом (о чем я изначально и говорил)
Y>>>Можно подумать ты свечку держал в процессе разработки этих "прикладников" KV>>Хуже. Я проводил ревью их кода, после чего неоднократно участвовал в обсуждениях, подобных этому. Y>>>Опять какая-то непонятная статистика, процентное соотношение, а где источник? KV>>Источником, в данном случае, являюсь я
Y>Ну т.е. понятно, сугубо субъективная точка зрения на основании какого-то своего малого опыта.
Я свой опыт, в исходном сообщении, выразил в достаточно конкретных цифрах. На всяйкий случай поясню: один тест на проникновение — это одна система, одно ревью безопасности кода — это один продукт. По моим меркам, это отнюдь не малый опыт
Здравствуйте, Lloyd, Вы писали:
L>Это вряд ли можно отнести к "внутренностям CLR". Внутренности — это например, тонкости того, как работает GC, как устроена таблица виртуальных методов, как работает interop и т.д. Необходимость в этих знаниях на практике очень мала.
отчасти вы правы, конечно, но грань, где внутренности среды, а где языка провести очень сложно зачастую. знание boxing/unboxing не нужно? Generic types — List<int> vs ArrayList, где Add(0)?
второй пример, event handlers — binding/unbinding событий. знание, как работает GC пригодиться, знание о поколениях.
многие прикладники, приходящие на собеседовние глубоко убеждены, что им это не нужно. извините, но я таких на работу не беру, так как нам кодеры не нужны.
да, я согласен, что приложения бывают разные, соответственно, и требования к разработчикам разные. но я буду очень удивлен, если предел мечтания для программиста — клепать калькуляторы и накидывать гриды на формы.
Здравствуйте, a_kutovets, Вы писали:
_>отчасти вы правы, конечно, но грань, где внутренности среды, а где языка провести очень сложно зачастую. знание boxing/unboxing не нужно? Generic types — List<int> vs ArrayList, где Add(0)? _>второй пример, event handlers — binding/unbinding событий.
Это не внутренности CLR. Вполне себе штатные возможности, которые описаны в любом учебнике.
_>знание, как работает GC пригодиться, знание о поколениях.
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, a_kutovets, Вы писали:
_>>Вы немного не совсем верно поняли, чем он занимается. насколько я знаю из истории сообщений Владимира, он занимается информационной безопасностью. соответсвенно, ревью кода выполняется на предмет потенциальных уязвимостей и пр., что может повредить безопасности и/или нарушить существующую инфраструктуру.
Y>Простите, но по моим сугубо религиозным взглядам, ревью кода должны делать именно сами программисты,
Это может вызвать конфликт интересов с одной стороны, и на порядок снизит их продуктивность с другой. Хотя уделять безопасности должное внимание при написании кода, программисты конечно должны (см. Ховарда и компанию).
Y>а не безопасники, админы, дворники ит.д.
Спасибо, я тоже с уважением отношусь к профессиям других.
Y>Тестировать конечный продукт, ради бога! А проводить ревью кода программистов, это уже, смахивает на маразм...
Вообще-то, это общепринятая мировая практика.
Y>Для этого как минимум самому надо быть программистом
По знаниям — да (иначе в ревью будет мало смыла), но не обязательно по профессии. Знаний у меня хватает. Или вас шокирует то, что навыки разработки могут применятся не по своему прямому назначению?
Здравствуйте, yumi, Вы писали:
Y>Простите, но по моим сугубо религиозным взглядам, ревью кода должны делать именно сами программисты, а не безопасники, админы, дворники ит.д. Тестировать конечный продукт, ради бога! А проводить ревью кода программистов, это уже, смахивает на маразм... Для этого как минимум самому надо быть программистом
простите, но по сугубо религиозным взглядам программист не сможет это делать настолько эффективно, насколько это делает специалист по безопасности.
вы, наверное, так и представляете как бывший админ/дворник и т.д. и т.п. открывает листинг кода и усердно пытается понять, а к какой уязвимости приведет сей кусок кода. заранее извиняюсь, если я ошибся.
исследование КОДА на уязвимости проводится различными tools, специализированными на этом. тестировать готовый продукт, конечно, нужно. но, скажите, как смоделировать ВСЕ возможные ситуации при работе с этим продуктом? зачастую это оказывется неоправданно дорогим. специалисту по безосности нужен исходный код, чтобы с помощью рзличных инструментов протестировать различные участки кода — как они поведут в различных ситуациях, как реагируют на различные входящие данные, что в дальнейшем происходит.
вы всерьез считаете, что программист будет этим заниматься? что ему хватит на это время, если он и так постоянно в цейтноте?
Здравствуйте, Lloyd, Вы писали:
L>Это не внутренности CLR. Вполне себе штатные возможности, которые описаны в любом учебнике.
простите, но это "штатные возможности" среды, описанные в любом учебнике. или вы считаете, что среду описывают в каких-то мало распространенных талмудах, которые в огранниченны в экземплярах и нужны не всем?
_>>знание, как работает GC пригодиться, знание о поколениях.
L>Для чего?
навскидку, знать хотя бы, что неуправляемые ресурсы освобождать нужно. не говоря уже о ресурсах, к которым происходит обращение из различных участков кода.
Здравствуйте, a_kutovets, Вы писали:
L>>Это не внутренности CLR. Вполне себе штатные возможности, которые описаны в любом учебнике.
_>простите, но это "штатные возможности" среды, описанные в любом учебнике. или вы считаете, что среду описывают в каких-то мало распространенных талмудах, которые в огранниченны в экземплярах и нужны не всем?
в сообщении выше по ветке речь шла не о среде, о внутренностях среды.
в моем понимании внутренности это как раз что-то, что недостаточно хорошо покрыто основной массой литературы/документации.
_>>>знание, как работает GC пригодиться, знание о поколениях.
L>>Для чего?
_>навскидку, знать хотя бы, что неуправляемые ресурсы освобождать нужно. не говоря уже о ресурсах, к которым происходит обращение из различных участков кода.
Сорри, не совсем внятно написал свой вопрос. Зачем нужно знание о поколениях?
Здравствуйте, a_kutovets, Вы писали:
_>или по вшему мнению, знать, как работают исключения, ref/value types, ч из себя представлют using{...} statements, список можно продолжать до бесконечности... совсем не обязательно?
До бесконечности, говорите. Ну-ну. А как можно иметь знания о бесконечной череде вещей не подскажите?
Продолжая вашу логику можно сказать, что C++ник должен знать каким образом ofstream::write отображается на FileWrite под Windows, и как FileWrite взаимодействует с подсистемой ввода-вывода ОС, и как эта подсистема дергает драйвер, и как драйвер позиционирует головки винчестера, и как их этих головок электроны вырываются, и как они изменяют магнитные поля на поверхности дисков винчестера, и как... А иначе кодер!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, yumi, Вы писали:
Y>Как практик разрабатывавший бортовые системы навигации скажу, надо тупо следовать спецификации на 100%.
Прошу прощения за оффтоп, но очень интересно -- на каких платформах эти системы навигации строятся и какие языки программирования используются в их разработке?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, a_kutovets, Вы писали:
Y>>>>Кстати прикладнику не обязательно быть экспертом в внутренностях CLR\JVM Это я так, к слову
_>здесь категорически не соглашусь. знание спецификации и принципов работы среды, в которой выполняется код этого прикладника позволяет писать этот же код лучше, больше соответствовать требованиям.
Быть экспертом в внутренностях CLR/JVM и знание спецификации и принципов работы это две разные вещи. Первое, это знание того, как все устроено изнутри, того, как работает тот или иной механизм. А второе это минимальное и обязательное требование. Как говорится feel the difference.
_>или по вшему мнению, знать, как работают исключения, ref/value types, ч из себя представлют using{...} statements, список можно продолжать до бесконечности... совсем не обязательно?
Как работает механизм исключения внутри самой CLR мне действительно до фени, а вот с точки зрения "пользователя" исключений, того как ими пользоваться, как их генерировать и обрабатывать, да знать надо обязательно. Все то же самое по вашему списку далее.
_>по моему глубокому убеждению, которое подтверждено и собственным опытом работы, и наблюдением за джуниорами в тиме, знать среду ооочень желательно. иначе прикладник тк и останется кодером.
По моему глубокому убеждению, и тот и другой могут быть кодерами, только один будет более продвинутым кодером А тот, у кого отличное фундаментальное образование в CS, способности к инженерному мышлению, опыт работы в разных средах не будет кодером, пусть даже он слабо разбирается в кишках CLR или JVM. Если надо, то он разберется, поверь
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, goto, Вы писали:
G>Мне лично, например, всегда было интересно делать новые проекты, а не поддерживать и развивать уже готовый продукт, пусть даже свой собственный.
Да, разные люди, разные интересы. Если честно, то мне подобный стиль напоминает комманданте Че. Устраивал революции,
и даже успешные, но плодами побед (был министром на Кубе) воспользоваться не захотел, и пошёл делать революции дальше.
Я сам в чём-то такой. Только у меня это выглядит как поэтапное развитие того-же, а не изготовление каждый раз с нуля.
Да, было время, я годами не занимался этим своим. Но постепенно дошёл до места, где на 2-й этап можно потратить
всю жизнь. На том, видимо, и успокоюсь со своими революциями.
M>>ЗЫ Кстати, этот 3-й этап и есть этам настоящего развития. А 2-й — это не развитие, а "экспансия". M>>Количественный рост, не более того. На развитие он похож только внешне.
G>Почему? Может быть, мы говорим о разных вещах?
G>На 2-м этапе решаются качественно новые задачи. Если обизнесе, то не просто нарабатываются новые связи, а ищутся новые способы, техники, пододы для этого. Если о технологической стороне, то "поднимаются" новые проекты, осваиваиаются или создаются продукты, технологии. Иногда даже выращиваются рынки. А в дальнейшем это все уже в основном равивается количественно и поддерживатеся.
Наверное, всё-ж об одном и том-же. Хотя меня настораживают слова, что в дальнейшем это развивается количественно.
Для меня это — всё тот-же 2-й этап. С ростом размера происходят внутренние трансформации, перед бизнесом
встают новые задачи, они требуют новых (для данного руководства) методов решения.
Вот когда и количественного раста нет — тогда это для меня 3-й этап, этап качественного, а не количественного
развития.
2-й этап — это как-бы период детства, роста. Постоянно всё меняется, постоянно интересно.
А 3-й этап — это как-бы взрослость.
Но с другой стороны — ведь детство было ради взрослости, в детстве мы осваивали для нас новое и
набивали свои шишки — но с точки зрения мира в этом небыло ничего нового. Те-же самые проблемы решали
бесчисленное количество раз до нас. И фирмы строили бесчисленное количество.
А вот когда человек или бизнес стал взрослым — вот тут и может начаться настоящее творчество.
Стабильность — это скучно. Но без этой стабильности невозможно появление более сложных, тонких
вещей. Ну не могут университеты и наука существовать без стабильного города — учёные не производят
продукты непосредственно, надо чтоб их кто-то кормил. Правда, потом учёные изобретают паровые
машины, электричество, ракеты, всё это облегчает жизнь города, он выходит на новый уровень
гомеостаза, потом учёные изобретают генетику, компьютеры, и так далее. А если жизнь не
стабильна — то учёные никому не нужны, есть более насущные задачи выживания и роста.
Не все фирмы и не все люди выбирают творчество на 3-м этапе. Точнее, выбирают его совсем
не многие. Кто не выбрал и доволен стабильным существованием — тот загниёт и подохнет.
Здравствуйте, Lloyd, Вы писали:
L>в сообщении выше по ветке речь шла не о среде, о внутренностях среды. L>в моем понимании внутренности это как раз что-то, что недостаточно хорошо покрыто основной массой литературы/документации.
в принципе, согласен, запутался в самих формулировках.
о внутренностях вреды в контексте моих сообщений я подрзумеваю понимание, как происходит выполнение кода, написанного программистом.
L>Сорри, не совсем внятно написал свой вопрос. Зачем нужно знание о поколениях?
знать, как происходит сборка мусора. понимать, что некоторые объекты практически никогда не будут убраны (основные формы, например).
понимать/знать, что в некоторых случааях система поколений не работает (очень большие объекты, например).
з.ы. спорить больше не буду, так как кишки устройства среды (вирутальной машины) и впрямь редко необходимо.
Здравствуйте, eao197, Вы писали:
E>Прошу прощения за оффтоп, но очень интересно -- на каких платформах эти системы навигации строятся и какие языки программирования используются в их разработке?
Платформа, это разработка самой компании, свое железо, свой процессор, своя мини-ос, а язык старый добрый Си Был еше какой-то скриптовый язык тоже нашей разработки, для связи с другими устройствами, но я с этой подсистемой и языком слабо знаком.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, a_kutovets, Вы писали:
_>>или по вшему мнению, знать, как работают исключения, ref/value types, ч из себя представлют using{...} statements, список можно продолжать до бесконечности... совсем не обязательно?
E>До бесконечности, говорите. Ну-ну. А как можно иметь знания о бесконечной череде вещей не подскажите?
E>Продолжая вашу логику можно сказать, что C++ник должен знать каким образом ofstream::write отображается на FileWrite под Windows, и как FileWrite взаимодействует с подсистемой ввода-вывода ОС, и как эта подсистема дергает драйвер, и как драйвер позиционирует головки винчестера, и как их этих головок электроны вырываются, и как они изменяют магнитные поля на поверхности дисков винчестера, и как... А иначе кодер!
понимаю ваш сарказм по поводу категоричности моих суждений))) за что и приношу all свои извинения.
но также хочу заметить, что и такие знания нужны при разрботке библиотек, например. другие при разрботке драйверов.
конечно, мы сейчас говорили о прикладниках. им железо, ОС знать не так важно/нужно/совсем не нужно. я утверждаю о знании прикладниками среды выполнения его кода.
Здравствуйте, a_kutovets, Вы писали:
_>но также хочу заметить, что и такие знания нужны при разрботке библиотек, например. другие при разрботке драйверов.
_>конечно, мы сейчас говорили о прикладниках. им железо, ОС знать не так важно/нужно/совсем не нужно. я утверждаю о знании прикладниками среды выполнения его кода.
По моему субъективному мнению даже такие упрощенные требования (не говоря уже о первоначальных высказываниях kochetkov.vladimir: "программист (не кодер), не понимающий сути работы платформ, под которые он пишет код (ОС, СУБД, различные сервера приложений, балансеры, средства виртуализации, и т.п. — не важно), не будет столь же эффективен в процессе разработки, как его коллега, владеющий подобными знаниями.") не соответствуют доминирующему принципу "разделяй и властвуй" при помощи которого и разрабатывается современное ПО. Благодоря слоям абстракций и разделению ПО по этим слоям программистам (обычным людям, не гениям) удается справляться со сложностью современного ПО. Как раз благодоря тому, что прикладник _не знает_, что происходит "под капотом", он имеет возможность забивать свою голову задачами своей предметной области и решать их. Я, например, понятия не имею, как устроен штатный распределитель памяти в моем C++ компиляторе и как мой компилятор реализует обработку исключений. Мне это и не нужно, т.к. я знаю, что кто-то уже озаботился решением этих вопросов на более низком слое абстракции. Более того, я вообще не пытаюсь претендовать на точное понимание того, как работает мой код, поскольку современные оптимизирующие компиляторы и процессоры с переупорядочением инструкций уделывают его как бог черепаху. И ничего, работает.
Разговоры о знании принципов -- это всего лишь разговоры. Например, понимание принципов работы современных СУБД -- это как понимание принципов современной атомной модели: где-то что-то слышал про электроны, протоны и нейтроны. Кто-то из них еще состоит из кварков, которые как-то хитро могут объединяться между собой. Так же и СУБД -- есть анализатор запросов, есть оптимизатор, есть какая-то система хранения, есть write-ahead-log. Практической пользы от этих знаний -- никакой. Людей, понимающих в ядерной физике (и способных извлекать из своих знаний пользу), как и людей, разрабатывающих СУБД -- гораздо меньше, чем тех, кто успешно пользуется результатами их труда не задумываясь о сути происходящего.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>По моему субъективному мнению даже такие упрощенные требования (не говоря уже о первоначальных высказываниях kochetkov.vladimir: "программист (не кодер), не понимающий сути работы платформ, под которые он пишет код (ОС, СУБД, различные сервера приложений, балансеры, средства виртуализации, и т.п. — не важно), не будет столь же эффективен в процессе разработки, как его коллега, владеющий подобными знаниями.") не соответствуют доминирующему принципу "разделяй и властвуй" при помощи которого и разрабатывается современное ПО. Благодоря слоям абстракций и разделению ПО по этим слоям программистам (обычным людям, не гениям) удается справляться со сложностью современного ПО.
[skipped]
Мне кажется, вы лукавите. Про закон дырявых абстракций слыхали?
Здравствуйте, yumi, Вы писали:
Y>А в менеджед средах увидеть, то где утечка можно всегда.
Утечек в unmanaged стиле в managed не бывает. О чем ты?
Y>Как будто среди С++ников их меньше.
По моему опыту — сильно меньше. А вот в индусско-американском C# коммюнити такое ощущение что 99% дебилов.
Здравствуйте, rsn81, Вы писали:
R>Мне кажется, вы лукавите. Про закон дырявых абстракций слыхали?
Если я лукавлю, а верите в закон дырявых абстракций, то любимые вами Java-технологии примерами таких абстракций и являются. Ну и как доведенное до апупеоза следствие -- корпоративное ПО можно разрабатывать на ассемблере без всяких там дырявых J2EE.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, yumi, Вы писали:
E>>Прошу прощения за оффтоп, но очень интересно -- на каких платформах эти системы навигации строятся и какие языки программирования используются в их разработке?
Y>Платформа, это разработка самой компании, свое железо, свой процессор, своя мини-ос, а язык старый добрый Си
Если не секрет: компания Российская? Своя мини-ос полностью своя или же базируется на коде Linux/BSD?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
О том, что если в managed какой-то объект живет дольше, чем мы ожидаем, то можно подробно посмотреть, кто именно его держит.
А в анменеджед нужно искать, кто именно его не удалил.
CC>По моему опыту — сильно меньше. А вот в индусско-американском C# коммюнити такое ощущение что 99% дебилов.
Ничего. Стоит зайти в форум "о жизни" на RSDN — сразу становится понятно, что умственный уровень русскоязычного программистского комьюнити не сильно лучше.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mkizub, Вы писали:
M>Да, разные люди, разные интересы. Если честно, то мне подобный стиль напоминает комманданте Че. Устраивал революции, M>и даже успешные, но плодами побед (был министром на Кубе) воспользоваться не захотел, и пошёл делать революции дальше. M>Я сам в чём-то такой. Только у меня это выглядит как поэтапное развитие того-же, а не изготовление каждый раз с нуля. M>Да, было время, я годами не занимался этим своим. Но постепенно дошёл до места, где на 2-й этап можно потратить M>всю жизнь. На том, видимо, и успокоюсь со своими революциями.
Че — это сильно. Кому-то буря — мать родная . Я вот вспоминаю детство голоштанное. Возимся мы в песочнице, строим город с дорогами, тоннелями, мостами — это я с удовольствием. А когда город наконец построен, и все начинают ездить по нему мафынками, мне уже становится не так интересно. Во взрослом возрасте из этого, было дело, вырос комплекс: вот довожу дело до какого-то логического конца, а потом каким-то путем рассасываюсь. Воспользоваться плодами — не судьба, ништяки достаются другим . Далеко не сразу начал себя понимать и расслабился по этому поводу.
M>>>ЗЫ Кстати, этот 3-й этап и есть этам настоящего развития. А 2-й — это не развитие, а "экспансия". M>>>Количественный рост, не более того. На развитие он похож только внешне.
G>>Почему? Может быть, мы говорим о разных вещах?
G>>На 2-м этапе решаются качественно новые задачи. Если обизнесе, то не просто нарабатываются новые связи, а ищутся новые способы, техники, пододы для этого. Если о технологической стороне, то "поднимаются" новые проекты, осваиваиаются или создаются продукты, технологии. Иногда даже выращиваются рынки. А в дальнейшем это все уже в основном равивается количественно и поддерживатеся.
M>Наверное, всё-ж об одном и том-же. Хотя меня настораживают слова, что в дальнейшем это развивается количественно. M>Для меня это — всё тот-же 2-й этап. С ростом размера происходят внутренние трансформации, перед бизнесом M>встают новые задачи, они требуют новых (для данного руководства) методов решения. M>Вот когда и количественного раста нет — тогда это для меня 3-й этап, этап качественного, а не количественного M>развития. M>2-й этап — это как-бы период детства, роста. Постоянно всё меняется, постоянно интересно. M>А 3-й этап — это как-бы взрослость. M>Но с другой стороны — ведь детство было ради взрослости, в детстве мы осваивали для нас новое и M>набивали свои шишки — но с точки зрения мира в этом небыло ничего нового. Те-же самые проблемы решали M>бесчисленное количество раз до нас. И фирмы строили бесчисленное количество. M>А вот когда человек или бизнес стал взрослым — вот тут и может начаться настоящее творчество. M>Стабильность — это скучно. Но без этой стабильности невозможно появление более сложных, тонких M>вещей. Ну не могут университеты и наука существовать без стабильного города — учёные не производят M>продукты непосредственно, надо чтоб их кто-то кормил. Правда, потом учёные изобретают паровые M>машины, электричество, ракеты, всё это облегчает жизнь города, он выходит на новый уровень M>гомеостаза, потом учёные изобретают генетику, компьютеры, и так далее. А если жизнь не M>стабильна — то учёные никому не нужны, есть более насущные задачи выживания и роста.
В основном не спорю. Я за свои наблюдения и определения этапов не настолько держусь, чтобы их навязывать . Они вообще не строги и не научны.
Та песочница — отличная иллюстрация этапов в чистом виде, просто воспользуюсь для доп. пояснения:
1. пацан собрал пацанов у песочницы, увлек их своей идеей построить город;
2. строят, подтягиваются еще пацаны;
3. построили, началась запланированная игра в машинки (что и было целью мероприятия).
На 3 этапе может быть и требуется еще что-то строить и переделывать, но от большинства уже требуется ездить. Кроме того, песочница ограничена, и у фанатов бесконечного строительства могут возникнуть проблемы . Еще не забываем, что у всего есть заводила, лидер — обычно тот пацан, кто организовал 1 этап. Скажет: "все, строить прекратили, всем ездить!", и либо придется ездить, либо конфликтовать. При этом творчески-то можно и ездить — это просто другой вид деятельности, сам по себе объективно ничем не хуже строительства. Дело только в личных предпочтениях
M>Не все фирмы и не все люди выбирают творчество на 3-м этапе. Точнее, выбирают его совсем M>не многие. Кто не выбрал и доволен стабильным существованием — тот загниёт и подохнет.
Творчество — категория отдельная. Кому-то ломать — творчество; кому-то — строить; кому-то — совершенствовать существующее или, скажем, себя самого. Большинство стремится к стабильности по некоторым осям кординат — минимизирует затраты энергии на то, что считает второстепеннвм. А я, допустим, могу знать человека именно с той стороны, с которой он себя "минимизирует". Людей совсем "застойных" я практически не встречал. И у бомжей, "синяков", гопоты и троллей можно обнаружить творческий потенциал, было бы желание .
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, goto, Вы писали:
G>>Например, для меня лично программирование как таковое себя в значительной степени исчерпало. Технологии глубоко вторичны, и в них почти все уже было . Их современное развитие, насколько я могу судить, в основном направлено просто на более эффективную организацию конвейера и (в массе) на более эффективный труд простых служащих.
AVK>Тут самое главное — не перепутать свое субъективное нежелание постоянно перевариавть новое с объективным состоянием индустрии.
Знаешь, новизна, если вдуматься, — понятие по своей природе субъективное. Попробуй перечитать свою фразу с учетом этого. Лично я там вижу штамп, построенный из ненадежных терминов и аксиом. Уж извини.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, goto, Вы писали:
G>>Знаешь, новизна, если вдуматься, — понятие по своей природе субъективное.
AVK>А я про новизну ничего и не говорил.
Не делай такие невинные глаза . "... переваривать новое" — чье? Таки перечитай, будь добёр. Хотя я не настаиваю на продолжении этой заведомо бесплодной дискуссии .
Здравствуйте, eao197, Вы писали:
E>Если не секрет: компания Российская? Своя мини-ос полностью своя или же базируется на коде Linux/BSD?
Не секрет, компания Российская, но названия здесь публиковать как-то не хочется. Но надо отметить, что наши заказчики забугорные. Мини-ОС полностью своя, но она действительно мини, там реализован именно тот минимум, который необходим нам. Более подробно наверное только в личке.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Не секрет, компания Российская, но названия здесь публиковать как-то не хочется. Но надо отметить, что наши заказчики забугорные. Мини-ОС полностью своя, но она действительно мини, там реализован именно тот минимум, который необходим нам. Более подробно наверное только в личке.
Спасибо, информации уже достаточно. Дело в том, что меня время от времени начинающие программисты спрашивают, можно ли где-нибудь применить свои силы в качестве системных программистов, разработчиков ОС, драйверов и пр. низкоуровневых вещей. Или же сейчас все захвачено Web-ом и корпоративными системами. Когда им отвечаешь, хочется приводить какие-то примеры. Вроде вашей разработки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если я лукавлю, а верите в закон дырявых абстракций, то любимые вами Java-технологии примерами таких абстракций и являются. Ну и как доведенное до апупеоза следствие -- корпоративное ПО можно разрабатывать на ассемблере без всяких там дырявых J2EE.
Ага, вначале лукавили, а теперь юродствуете, "апупеозствуете".
Здравствуйте, rsn81, Вы писали:
E>>Если я лукавлю, а верите в закон дырявых абстракций, то любимые вами Java-технологии примерами таких абстракций и являются. Ну и как доведенное до апупеоза следствие -- корпоративное ПО можно разрабатывать на ассемблере без всяких там дырявых J2EE. R>Ага, вначале лукавили, а теперь юродствуете, "апупеозствуете".
А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски?
А у вас какие-то полезные комментарии по поводу его рассуждений? Или всё, что скажет Спольски, априори неверно?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски? Может генерировать свое в стиле "и в то время, как наши космические корабли бороздят просторы" (Re[9]: О программировании
Здравствуйте, eao197, Вы писали:
E>Разговоры о знании принципов -- это всего лишь разговоры. Например, понимание принципов работы современных СУБД -- это как понимание принципов современной атомной модели: где-то что-то слышал про электроны, протоны и нейтроны. Кто-то из них еще состоит из кварков, которые как-то хитро могут объединяться между собой. Так же и СУБД -- есть анализатор запросов, есть оптимизатор, есть какая-то система хранения, есть write-ahead-log. Практической пользы от этих знаний -- никакой.
В жизни не видел людей, которые способны успешно оптимизировать запросы, не понимая, что означает query plan. Развитие разработчика по этому пути неизбежно приводит к пониманию принципов работы. Причем совершенно не обязательно до кварков, но про index seek vs index scan знать уже нужно.
E>Людей, понимающих в ядерной физике (и способных извлекать из своих знаний пользу), как и людей, разрабатывающих СУБД -- гораздо меньше, чем тех, кто успешно пользуется результатами их труда не задумываясь о сути происходящего.
Это только повышает зарплату тех, кто задумывается о сути происходящего.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
E>>Разговоры о знании принципов -- это всего лишь разговоры. Например, понимание принципов работы современных СУБД -- это как понимание принципов современной атомной модели: где-то что-то слышал про электроны, протоны и нейтроны. Кто-то из них еще состоит из кварков, которые как-то хитро могут объединяться между собой. Так же и СУБД -- есть анализатор запросов, есть оптимизатор, есть какая-то система хранения, есть write-ahead-log. Практической пользы от этих знаний -- никакой. S>В жизни не видел людей, которые способны успешно оптимизировать запросы, не понимая, что означает query plan. Развитие разработчика по этому пути неизбежно приводит к пониманию принципов работы. Причем совершенно не обязательно до кварков, но про index seek vs index scan знать уже нужно.
Не согласен. Понимание плана выполнения запросов -- это одно, а понимание механизма получения этого плана из SQL-выражения -- совсем другое, а понимание того, как план будет воплощен в жизнь с учетом кластеризации, распараллеливания, управления памятью и асинхронных I/O операций -- уже третье. Более того, план выполнения запроса является видимой частью абстракции РСУБД, фактически это часть ее интерфеса. Пользователь РСУБД вынужден в той или иной мере знакомиться с ней. Как и с такими понятиями, как уровни изоляции транзакций. Тем не менее, пользователь освобождается от знаний того, как же эти уровни изоляции реализуются.
E>>Людей, понимающих в ядерной физике (и способных извлекать из своих знаний пользу), как и людей, разрабатывающих СУБД -- гораздо меньше, чем тех, кто успешно пользуется результатами их труда не задумываясь о сути происходящего. S>Это только повышает зарплату тех, кто задумывается о сути происходящего.
По такой логике самую большую зарплату должны получать те, кто способен расписать в деталях выполнение SQL запроса от вызова ODBC-функции до записи последнего байта на диск. Но я таких вообще не видел живьем.
Поэтому я и говорю, что утверждения о том, что более эффективен тот разработчик, который понимает суть платформ на которых он работает -- это ерунда. Поскольку деталей здесь столько, что вряд ли под силу удерживать в голове одному человеку и при этом еще заниматься написанием кода с учетом этих деталей. Значит, это всего лишь приближение -- какие-то общие вещи должны быть на слуху. Попросту говоря, банальная эрудиция.
По моему мнению, важно не понимание сути (т.е. знания), а способность и желание при необходимости эти знания приобретать. Довелось человеку столкнуться с SQL -- освоить в необходимом объеме и использовать. Возникли после этого проблемы с производительностью SQL запросов -- разобраться с query plan. Показали замеры, что итерации по массиву идут слишком долго -- не полениться заглянуть в литературу и узнать об особенностях кэшей и размещения данных в памяти.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, rsn81, Вы писали:
E>>А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски? R> Может генерировать свое в стиле "и в то время, как наши космические корабли бороздят просторы" (Re[9]: О программировании
Отлично, оставим в стороне мои филофовские измышления по поводу "разделяй и властвуй". Вот описание суровой реальности:
я не понимаю, что происходит внутри operator new. Не имею понятия о том, откуда берется память, какие накладные расходы накладываются как по времени, так и по размеру выделяемых блоков;
я не понимаю, как просходит пробрасывание исключений после new и как они приходят в catch;
я не понимаю, что происходит в коде:
std::string make_params(...) {
std::string a = ...;
std::string b = ...;
...
return a+b;
}
std::string c = make_params(...);
я не знаю, какие представления используются в std::string (small string optimization, динамическое распределение памяти, copy-on-write, rope), происходит ли return value optimization при обращении к make_params. Я не представляю, в какие ассемблерные инструкции преобразует этот код VC++ для x86 (ассемблером которого я когда-то пользовался) и совершенно не имею понятия, во что это все преобразуется на SPARK-ах и MIPS-ах, ассемблера которых я вообще в глаза не видел, но на которых этот код работает;
при работе с РСУБД средствами OTL я понятия не имею, в какие вызовы каких API и в какой именно момент OTL преобразует мои манипуляции с otl_stream;
я не представляю, по каким алгоритмам MSSQL и Oracle строят планы исполнения моих SQL запросов и какую информацию, кроме имеющихся в схеме БД индексов, они при этом могут еще использовать;
я не представляю, какие структуры данных MSSQL/Oracle используют для ведения, например, индексов;
я не представляю, как MSSQL/Oracle организует работу с диском, добиваясь при этом и высокой скорости и достаточной степени надежности хранения информации;
отправляя 5Kb данных в TCP/IP сокет я понятия не имею, куда они попадают, где дробятся на пакеты TCP/IP протоколов (и дробятся ли вообще), как и когда они уйдут в сеть.
Ничего из вышеперечисленного не мешает мне писать программы. Благодоря тому, что я пользуюсь готовыми абстракциями не задумываясь без необходимости о деталях их реализации.
Если вы со мной не согласны, значит вы знаете подобные детали. Поэтому сможете в точности рассказать, что именно делает MSSQL (или какая-нибудь другая РСУБД) при получении запроса с insert-ом вплоть до записи последнего байта на диск. Сможете?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Не согласен. Понимание плана выполнения запросов -- это одно, а понимание механизма получения этого плана из SQL-выражения -- совсем другое,
И что, у кого-то есть иллюзия, что можно заниматься оптимизацией, понимая план, но не понимая, как он образовался из SQL выражения? E>а понимание того, как план будет воплощен в жизнь с учетом кластеризации, распараллеливания, управления памятью и асинхронных I/O операций -- уже третье.
И что, у кого-то есть иллюзия, что план запроса не учитывает кластеризацию и распараллеливание? E> Более того, план выполнения запроса является видимой частью абстракции РСУБД, фактически это часть ее интерфеса. Пользователь РСУБД вынужден в той или иной мере знакомиться с ней.
Фактически план запроса частью интерфейса РСУБД не является. Мы дальше будем обсуждать твои заблуждения в этой области? E>Как и с такими понятиями, как уровни изоляции транзакций. Тем не менее, пользователь освобождается от знаний того, как же эти уровни изоляции реализуются.
Ни разу не видел такого, чтобы человек хорошо понимал, что такое уровень изоляции, при этом не понимая, как именно они реализуются.
E>По такой логике самую большую зарплату должны получать те, кто способен расписать в деталях выполнение SQL запроса от вызова ODBC-функции до записи последнего байта на диск. Но я таких вообще не видел живьем.
Наверное, это от того, что они редко ходят в те же клубы, что и ты. E>Поэтому я и говорю, что утверждения о том, что более эффективен тот разработчик, который понимает суть платформ на которых он работает -- это ерунда.
Это противоречит реальности, данной мне в ощущениях. Нет, есть конечно некий предел уровню абстракции, в который нужно закопаться. Но в общем случае, чем глубже человек понимает платформу, на которой он работает, тем эффективнее получаются его решения. И необходимая глубина сильно зависит от дырявости абстракций.
E> Поскольку деталей здесь столько, что вряд ли под силу удерживать в голове одному человеку и при этом еще заниматься написанием кода с учетом этих деталей. Значит, это всего лишь приближение -- какие-то общие вещи должны быть на слуху. Попросту говоря, банальная эрудиция.
Эрудиция — это всего лишь знание "оглавления". Я совершенно не понимаю, как знание того, что существует уровень изоляции, поможет выбрать правильный уровень изоляции. E>По моему мнению, важно не понимание сути (т.е. знания), а способность и желание при необходимости эти знания приобретать. Довелось человеку столкнуться с SQL -- освоить в необходимом объеме и использовать. Возникли после этого проблемы с производительностью SQL запросов -- разобраться с query plan. Показали замеры, что итерации по массиву идут слишком долго -- не полениться заглянуть в литературу и узнать об особенностях кэшей и размещения данных в памяти.
Ну это как бы две стороны одной медали. Понятно, что человек с удочкой универсальнее, чем человек с рыбой. Но если у человека принципиальное непонимание того, что для решения задачи нужно с чем-то разобраться, то он вряд ли приобретет знания при необходимости. Потому что он уже заучил твою мантру "утверждения о том, что более эффективен тот разработчик, который понимает суть платформ на которых он работает -- это ерунда" и доволен ей на 100%.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
E>>Не согласен. Понимание плана выполнения запросов -- это одно, а понимание механизма получения этого плана из SQL-выражения -- совсем другое, S>И что, у кого-то есть иллюзия, что можно заниматься оптимизацией, понимая план, но не понимая, как он образовался из SQL выражения?
Можешь рассказать алгоритм посторения плана, например, из MSSQL 2005?
E>>а понимание того, как план будет воплощен в жизнь с учетом кластеризации, распараллеливания, управления памятью и асинхронных I/O операций -- уже третье. S>И что, у кого-то есть иллюзия, что план запроса не учитывает кластеризацию и распараллеливание?
Глаза протри. Я писал не про учет, а про знание деталей реализации плана. Ты можешь озвучить эти детали для какой-нибудь РСУБД?
E>> Более того, план выполнения запроса является видимой частью абстракции РСУБД, фактически это часть ее интерфеса. Пользователь РСУБД вынужден в той или иной мере знакомиться с ней. S>Фактически план запроса частью интерфейса РСУБД не является.
Где я говорил про интерфейс РСУБД?
S> Мы дальше будем обсуждать твои заблуждения в этой области?
У тебя есть занятие получше?
E>>Как и с такими понятиями, как уровни изоляции транзакций. Тем не менее, пользователь освобождается от знаний того, как же эти уровни изоляции реализуются. S>Ни разу не видел такого, чтобы человек хорошо понимал, что такое уровень изоляции, при этом не понимая, как именно они реализуются.
Детали реализации этого для конкретной РСУБД можешь рассказать?
S>Ну это как бы две стороны одной медали. Понятно, что человек с удочкой универсальнее, чем человек с рыбой.
На русский можешь перевести?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
E>>А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски? S>А у вас какие-то полезные комментарии по поводу его рассуждений?
Вернёмся к TCP. Я тут для простоты слегка загнул, и у кого-то, может быть, от этого уже пар из ушей пошёл. Я сказал, будто TCP гарантирует, что сообщение прибудет на место. Вообще-то, это не так. Если ваш любимый хомячок перегрызёт сетевой кабель, так что никакие пакеты IP не дойдут до компьютера, то TCP ничего не сможет поделать, и сообщение не придёт. Если же вы поругались с сетевым администратором, который в отместку включил ваш компьютер в перегруженный хаб, то некоторые из пакетов IP все же дойдут, и хотя TCP будет работать, но так медленно, что за время пути собачка, сами понимаете, того.
Вот это я и называю дырявой абстракцией. TCP пытается абстрагироваться от ненадёжной сети полностью, но иногда эта сеть все-таки просвечивает сквозь дыры в абстракции, так что абстракция не всегда защищает от необходимости иметь дело с глубокими подробностями.
Как говорят на одном забавном форуме, то, что Спольски решил, что TCP его абстрагирует от ненадежной сети полностью, это личные половые трудности самого Спольски. Спольски выдает свой закон дырявой абстракции с той позиции, что абстракция должна быть железобетонной плитой, каменной стеной, за которой можно быть совершенно спокойным и не думать ни о чем.
Я с такой интерпритацией понятия абстрации не согласен, поэтому и весь закон "дырявых абстракций" в моем понимании так же является ошибочным. Если уж пользоваться аналогиями, то мне больше нравится рассматривать абстракции как строительные леса -- конструкции, которые позволяют подниматься все выше и выше, требуя при этом все большей и большей осторожности и осмотрительности. Поэтому не нужно громких выводов о том, что "любая нетривиальная абстракция дырява" -- просто напросто любая абстракция не является сплошной и надежной железобетонной плитой изначально. И откровения Спольски -- это как будто он подошел к строительным лесам и воскликнул: "Да они же дырявые!". Так ведь они изначально были задуманы таковыми.
S>Или всё, что скажет Спольски, априори неверно?
Не могу судить обо всем, что Спольски пишет, только о том, что сам читал. Но даже тут на моей памяти Спольски перемывали косточки пару раз (один раз по поводу претензий к размеру .NET Framework дистрибутива, второй раз по поводу его "открытия" лямбда-функций) и, имхо, не зря.
У меня отношение к фельетонам Спольски уже давно достаточно однозначное -- после их прочтения не остается сухого остатка. Пока читаешь забавно, после прочтения не можешь понять, что же из всей прочитанной истории можно вынести.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Как говорят на одном забавном форуме, то, что Спольски решил, что TCP его абстрагирует от ненадежной сети полностью, это личные половые трудности самого Спольски.
Ничего подобного. На том забавном форуме, наверное, все такие мега гуру в TCP. И никогда, к примеру, не пользуются открытием сокетов по имени хоста, потому что эта операция может занять слишком долго, и неизвестно, какой именно неймсервер она будет использовать. E>Спольски выдает свой закон дырявой абстракции с той позиции, что абстракция должна быть железобетонной плитой, каменной стеной, за которой можно быть совершенно спокойным и не думать ни о чем.
E>Я с такой интерпритацией понятия абстрации не согласен, поэтому и весь закон "дырявых абстракций" в моем понимании так же является ошибочным.
Я не понимаю, в чем ошибка.
E> Если уж пользоваться аналогиями, то мне больше нравится рассматривать абстракции как строительные леса -- конструкции, которые позволяют подниматься все выше и выше, требуя при этом все большей и большей осторожности и осмотрительности. Поэтому не нужно громких выводов о том, что "любая нетривиальная абстракция дырява" -- просто напросто любая абстракция не является сплошной и надежной железобетонной плитой изначально.
Да, именно это Спольски и пытается донести. Потому что 90% народу ходит по любой абстракции как по железобетонной плите. Именно потому, что никто и не пытается рассматривать абстракции как леса. E> И откровения Спольски -- это как будто он подошел к строительным лесам и воскликнул: "Да они же дырявые!". Так ведь они изначально были задуманы таковыми.
Нет, наоборот: "мы спрячем от вас ненужные подробности, и вы можете полагаться на более простую абстракцию". Вот, к примеру, RPC. Если бы он был задуман как леса, то несоменнно в нем были бы способы управлять таймаутами и кэшированием. Увы, RPC упорно пытается делать вид, что происходит локальный вызов. Где тут строительные леса?
S>>Или всё, что скажет Спольски, априори неверно?
E>Не могу судить обо всем, что Спольски пишет, только о том, что сам читал. Но даже тут на моей памяти Спольски перемывали косточки пару раз (один раз по поводу претензий к размеру .NET Framework дистрибутива, второй раз по поводу его "открытия" лямбда-функций) и, имхо, не зря.
И что? Все могут ошибаться. Тем не менее, он пишет и довольно много умных вещей.
E>У меня отношение к фельетонам Спольски уже давно достаточно однозначное -- после их прочтения не остается сухого остатка. Пока читаешь забавно, после прочтения не можешь понять, что же из всей прочитанной истории можно вынести.
О да. Из обсуждаемой статьи совершенно невозможно понять, что "все нетривиальные абстракции дырявы".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>Отлично, оставим в стороне мои филофовские измышления по поводу "разделяй и властвуй". Вот описание суровой реальности:
Ок, я буду это учитывать в дальнейшем общении. E>Ничего из вышеперечисленного не мешает мне писать программы.
На основании чего сделан такой вывод? Я правильно понимаю, что ты просто не пишешь программ, которые работают с Oracle или MS SQL, или программ на C++, которым предъявляются хоть какие-то требования по производительности?
E>Благодоря тому, что я пользуюсь готовыми абстракциями не задумываясь без необходимости о деталях их реализации.
Ага. То есть ходим по ним, как по железобетонной стене.
E>Если вы со мной не согласны, значит вы знаете подобные детали. Поэтому сможете в точности рассказать, что именно делает MSSQL (или какая-нибудь другая РСУБД) при получении запроса с insert-ом вплоть до записи последнего байта на диск. Сможете?
До последнего байта — нет. Но те вещи, которые существенны для разработки приложения, конечно же знаем. В частности, в каких структурах хранятся индексы, что учитывает оптимизатор при построении плана запроса, как хранятся данные таблиц, как происходит захват и отпускание блокировок в зависимости от уровня изоляции. Ты не переживай — мы еще очень много всего лишнего знаем. Например, какие классы генерятся C# при обработке конструкции yield return, каким образом linq получает SQL из сишарпного кода. Знаем, какие заголовки возвращает асп.нет после того, как я подтвердил аутентификацию пользователя. Знаем, как именно кодируются данные в SOAP вызове, и какие накладные расходы это влечет. И это я только так, по поверхности поскреб.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали: E>Можешь рассказать алгоритм посторения плана, например, из MSSQL 2005?
Это будет долго . Там довольно сложный алгоритм. Но я знаю, какие факторы он учитывает. И я знаю, из каких операций строится query plan, и какие когда можно, а когда нельзя применять.
S>>И что, у кого-то есть иллюзия, что план запроса не учитывает кластеризацию и распараллеливание? E>Глаза протри. Я писал не про учет, а про знание деталей реализации плана. Ты можешь озвучить эти детали для какой-нибудь РСУБД?
Естественно. Операции распаралллеливания явно указываются в плане запроса. Там прямо так и будет написано: здесь распараллелили, здесь слили.
E>Где я говорил про интерфейс РСУБД?
Тремя строчками выше. Цитирую: "фактически это часть ее интерфеса".
E>Детали реализации этого для конкретной РСУБД можешь рассказать?
Могу. Но не буду — тебе быстрее будет открыть страничку "transaction isolation levels" в MS SQL Books Online и прочитать. Да, я всё это помню до сих пор, несмотря на то, что базы данных не проектирую лет пять. Просто не умею я не получать знания в процессе работы. И все знакомые мне успешные разработчики именно такие. Что находится в полном противоречии с твоими воззрениями.
S>>Ну это как бы две стороны одной медали. Понятно, что человек с удочкой универсальнее, чем человек с рыбой. E>На русский можешь перевести?
Могу, но не буду.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Можешь рассказать алгоритм посторения плана, например, из MSSQL 2005? S>Это будет долго .
Т.е. ответа не будет.
S>Там довольно сложный алгоритм.
Не сомневаюсь. Дьявол, как известно, в деталях. Нет деталей -- нет понимания, т.к. в общих словах даже строение вселенной и основные типы сил взаимодействия в ней рассказать можно.
S>Но я знаю, какие факторы он учитывает. И я знаю, из каких операций строится query plan, и какие когда можно, а когда нельзя применять.
В качестве ремарки -- это говорит человек, который БД занимается, по его же словам, 20 лет.
А я во с БД имею дело раз в полгода. И когда я воспользовался помощью инструмента Database Engine Tuning Advisor, он мне столько интересного насоветовал, чего я в принципе не знал (например, про модификаторы NONCLUSTERED для индексов, опции SORT_IN_TEMPDB и пр.). По твоей логике получается, что все это я должен был выучить еще до того, как взяться за проектирование схемы БД.
S>>>И что, у кого-то есть иллюзия, что план запроса не учитывает кластеризацию и распараллеливание? E>>Глаза протри. Я писал не про учет, а про знание деталей реализации плана. Ты можешь озвучить эти детали для какой-нибудь РСУБД? S>Естественно. Операции распаралллеливания явно указываются в плане запроса. Там прямо так и будет написано: здесь распараллелили, здесь слили.
Я спрашивал -- ты знаешь, с помощью каких операций выполняется распараллеливание? Запуск новых процессов или нитей, или фиберов. Через какие структуры данных происходит обмен результатами параллельной обработки?
E>>Где я говорил про интерфейс РСУБД? S>Тремя строчками выше. Цитирую: "фактически это часть ее интерфеса".
Ты видишь то, что хочешь видеть, поэтому и разговариваешь сам с собой. Цитата:
Более того, план выполнения запроса является видимой частью абстракции РСУБД, фактически это часть ее интерфеса.
"ее интерфес" относится к "абстракции РСУБД".
Интерфейс абстракции -- это дико звучит, наверное. Но нужно же было как-то обозвать тот понятийный базис, который нужно знать при работе с какой-то абстракцией (для РСУБД его составляют общие знания о реляционных отношениях и алгебре, SQL, схеме данных, индексах, понятии плана выполнения запроса).
E>>Детали реализации этого для конкретной РСУБД можешь рассказать? S>Могу.
Расскажи. В деталях, с точностью до структур данных и примитивов синхронизации. Сам.
Потому, что если не можешь сам в деталях, то это уже не понимание -- это знание того, где можно найти информацию какой-то степени подробности.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
E>>Ничего из вышеперечисленного не мешает мне писать программы. S>На основании чего сделан такой вывод?
На основании последствий эксплуатации написанных мной программ.
S>Я правильно понимаю, что ты просто не пишешь программ, которые работают с Oracle или MS SQL
Обычно нет. Необходимость в этом возникает раз в полгода, иногда реже.
S>или программ на C++, которым предъявляются хоть какие-то требования по производительности?
Да кто ж мне позволит это делать? На C++ сейчас писать что-нибудь производительное? Да это нонсенс. :/
E>>Благодоря тому, что я пользуюсь готовыми абстракциями не задумываясь без необходимости о деталях их реализации. S>Ага. То есть ходим по ним, как по железобетонной стене.
Не переноси свой опыт на остальных.
E>>Если вы со мной не согласны, значит вы знаете подобные детали. Поэтому сможете в точности рассказать, что именно делает MSSQL (или какая-нибудь другая РСУБД) при получении запроса с insert-ом вплоть до записи последнего байта на диск. Сможете? S>До последнего байта — нет.
Тогда в топку заявления о понимании.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
E>>Как говорят на одном забавном форуме, то, что Спольски решил, что TCP его абстрагирует от ненадежной сети полностью, это личные половые трудности самого Спольски. S>Ничего подобного. На том забавном форуме, наверное, все такие мега гуру в TCP.
Нет, там просто в выражениях не стесняются, поэтому частно разывают вещи своими именами, даже если это и нецензурно.
S>И никогда, к примеру, не пользуются открытием сокетов по имени хоста, потому что эта операция может занять слишком долго, и неизвестно, какой именно неймсервер она будет использовать.
А какой у нас выбор, если кроме имени хоста ничего нет?
E>> Если уж пользоваться аналогиями, то мне больше нравится рассматривать абстракции как строительные леса -- конструкции, которые позволяют подниматься все выше и выше, требуя при этом все большей и большей осторожности и осмотрительности. Поэтому не нужно громких выводов о том, что "любая нетривиальная абстракция дырява" -- просто напросто любая абстракция не является сплошной и надежной железобетонной плитой изначально.
S>Да, именно это Спольски и пытается донести. Потому что 90% народу ходит по любой абстракции как по железобетонной плите.
А вот это мне уже пофигу. 90% народу могут думать, что Бог сотворил Землю. Это не значит, что данное утверждение нужно считать законом.
S>Нет, наоборот: "мы спрячем от вас ненужные подробности, и вы можете полагаться на более простую абстракцию". Вот, к примеру, RPC. Если бы он был задуман как леса, то несоменнно в нем были бы способы управлять таймаутами и кэшированием.
А ты уверен, что все реализации RPC страдают этими недостатками?
S>Увы, RPC упорно пытается делать вид, что происходит локальный вызов. Где тут строительные леса?
Как раз в том, что все идет коту под хвост при проблемах в сети. Разработчику предоставляется компромис между простотой написания основного кода и тяжестью последствий нештатных ситуаций. Принимать этот компромис или нет -- это проблемы разработчика, но не RPC.
S>>>Или всё, что скажет Спольски, априори неверно?
S>И что? Все могут ошибаться. Тем не менее, он пишет и довольно много умных вещей.
Ну вот мне не доводилось их находить в его фельетонах. Можешь примеры привести?
E>>У меня отношение к фельетонам Спольски уже давно достаточно однозначное -- после их прочтения не остается сухого остатка. Пока читаешь забавно, после прочтения не можешь понять, что же из всей прочитанной истории можно вынести. S>О да. Из обсуждаемой статьи совершенно невозможно понять, что "все нетривиальные абстракции дырявы".
Для меня -- нет. Поскольку я знал о том, что абстракции не являются железобетонными плитами задолго до прочтения этой статьи.
Собственно, об этом знали все, кто осознавал применимость афоризм "дьявол в деталях" к тому, что происходит при разработке ПО.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Нет, там просто в выражениях не стесняются, поэтому частно разывают вещи своими именами, даже если это и нецензурно.
А, то есть в протоколе не шарят, зато знают много матов. Хороший, должно быть, форум.
E>А какой у нас выбор, если кроме имени хоста ничего нет?
Как какой? Вручную выполнить DNS resolution, точно управляя таймаутом и алгоритмом перебора primary/secondary. Например, можно отправить запрос всем одновременно, не дожидаясь, пока primary стаймаутится. Да мало ли тонкостей — ты же сам говоришь, что абстракции это всего лишь леса. Ну вот к примеру абстракция сокетов еще абстрактнее, чем протокол TCP. Стало быть, ты в курсе, что именно скрывает эта абстракция, и готов в любой момент отойти от лесов или использовать их с осторожностью.
E>А вот это мне уже пофигу. 90% народу могут думать, что Бог сотворил Землю. Это не значит, что данное утверждение нужно считать законом.
Ты его пока что не смог опровергнуть. Да и вообще, сформулировать свои претензии к этому закону.
E>А ты уверен, что все реализации RPC страдают этими недостатками?
Конечно. Потому что вся идеология RPC эти недостатки считает достоинствами.
E>Как раз в том, что все идет коту под хвост при проблемах в сети. Разработчику предоставляется компромис между простотой написания основного кода и тяжестью последствий нештатных ситуаций.
Это какой-то неправильный компромисс. Правильный компромисс — это "я могу выбирать, что игнорировать, а что — нет". Вот, к примеру, в типичных HTTP клиентах ты можешь полагаться на стандартную реакцию на особенные ситуации, типа редиректов, а можешь обработать их самостоятельно. Ты, к примеру, можешь сделать такую штуку, как сказать "у меня уже есть данные от позавчера, если они изменились, то пришли мне новую версию, а если нет — то не присылай". Это одно из следствий того, что HTTP не старается изолировать разработчика от факта удаленности вызова. Ни одна реализация RPC не умеет делать такие вещи на уровне протокола.
E>Принимать этот компромис или нет -- это проблемы разработчика, но не RPC.
Ну так мы всё время говорим о разработчике, разве нет? Закон, предлагаемый Спольски, говорит только о том, что нельзя полагаться на железобетонность абстракций.
E>Ну вот мне не доводилось их находить в его фельетонах. Можешь примеры привести?
Ну, вот к примеру — закон дырявых абстракций. Или принципы ценообразования в софте. Или способы проведения интервью. Или то, как выбирать фичи для следующего релиза коробочного продукта.
E>Для меня -- нет. Поскольку я знал о том, что абстракции не являются железобетонными плитами задолго до прочтения этой статьи.
Молодец, возьми с полки пирожок. Мы всё еще говорим о полезности Спольски для прочтения произвольным разработчиком? Или только о полезности лично для тебя? Если лично ты не узнаешь ничего нового из его постов, то почему ты берешь на себя наглость критиковать тех, кто узнает? Или хотя бы узнает новые формулировки инстинктивно известных вещей?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>Не сомневаюсь. Дьявол, как известно, в деталях. Нет деталей -- нет понимания, т.к. в общих словах даже строение вселенной и основные типы сил взаимодействия в ней рассказать можно.
Совершенно верно — можно. Непонятно, почему ты столь категорично противопоставляешь — либо вообще ничего не знать, кроме приятной абстракции, либо уж знать всё досконально. Вот я тебе приводил пример про сокеты и TCP: для того, чтобы писать хорошо работающие программы, крайне полезно знать о том, какое место занимает DNS в том, что тебе кажется чистым TCP. Знать бинарное представление DNS пакета уже необязательно. Знать, каким именно образом TCP реализован поверх IP/ICMP — тоже полезно для понимания поведения программы в ситуациях, к примеру, обрыва связи. А вот детали реализации Ethernet и ее использования в IP — это уже экзотика, хотя для человека, который проектирует сетевые приложения, это тоже совсем не лишняя информация.
E>В качестве ремарки -- это говорит человек, который БД занимается, по его же словам, 20 лет.
Да. Не ежедневно, но 20 лет.
E>По твоей логике получается, что все это я должен был выучить еще до того, как взяться за проектирование схемы БД.
По моей логике получается, что если бы ты это знал, то ты был бы более хорошим проектировщиком схемы БД.
E>Я спрашивал -- ты знаешь, с помощью каких операций выполняется распараллеливание? Запуск новых процессов или нитей, или фиберов.
Фиберов. E>Через какие структуры данных происходит обмен результатами параллельной обработки?
Нет, вот эти вещи я не знаю.
E>>>Где я говорил про интерфейс РСУБД? S>>Тремя строчками выше. Цитирую: "фактически это часть ее интерфеса".
E>Интерфейс абстракции -- это дико звучит, наверное.
Совершенно верно. E>Но нужно же было как-то обозвать тот понятийный базис, который нужно знать при работе с какой-то абстракцией (для РСУБД его составляют общие знания о реляционных отношениях и алгебре, SQL, схеме данных, индексах, понятии плана выполнения запроса).
Хорошо, давайте поймем, что именно входит в "понятийный базис" какой-нибудь абстракции. Вот, к примеру, почему ты планы к этому базису отнес, а, к примеру, устройство индексов — нет? Как по-твоему, детали хранения BLOB относятся к базису абстракции, или это несущественные детали? В какой момент эти детали станут существенными?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Не сомневаюсь. Дьявол, как известно, в деталях. Нет деталей -- нет понимания, т.к. в общих словах даже строение вселенной и основные типы сил взаимодействия в ней рассказать можно. S>Совершенно верно — можно. Непонятно, почему ты столь категорично противопоставляешь — либо вообще ничего не знать, кроме приятной абстракции, либо уж знать всё досконально.
Потому что все очень просто: либо человек знает все от и до, либо он опирается на какие-то абстракции, деталей реализации он может не знать. Полагая (до поры до времени), что эта абстракция его удовлетворяет.
Об этом я и сказал в самом начале, но меня стали обвинять в лукавстве и юродствовании.
E>>По твоей логике получается, что все это я должен был выучить еще до того, как взяться за проектирование схемы БД. S>По моей логике получается, что если бы ты это знал, то ты был бы более хорошим проектировщиком схемы БД.
Но это вовсе не значит, что если бы я был более хорошим проектировщиком БД для MSSQL, то я бы был более хорошим разработчиком в своей предметной области.
S>Хорошо, давайте поймем, что именно входит в "понятийный базис" какой-нибудь абстракции. Вот, к примеру, почему ты планы к этому базису отнес, а, к примеру, устройство индексов — нет?
Потому что одних только вариаций B+ деревьев существует несколько штук. Не говоря уже о том, что разные БД могут размещать индексы в отдельных файлах, либо вместе с файлом БД, объединять несколько индексов в один файл или же разносить по разным файлам или даже дробить один индекс на серии файлов. А мне более важно, чтобы индекс ускорял выполнение запросов, а не то, как он устроен физически.
S>Как по-твоему, детали хранения BLOB относятся к базису абстракции, или это несущественные детали?
Для базиса это несущественные детали.
S>В какой момент эти детали станут существенными?
Когда эти детали станут сказываться на производительности ПО или будут вызывать проблемы в разработке ПО.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Потому что все очень просто: либо человек знает все от и до, либо он опирается на какие-то абстракции, деталей реализации он может не знать. Полагая (до поры до времени), что эта абстракция его удовлетворяет.
Непонятно, на каком основании делается вот это бинарное утверждение. Речь не шла о том, чтобы потребовать знания зонной теории от любого разработчика софта, исполняющегося на полупроводниковой элементной базе. Речь шла о том, что ограничение знания только поверхностью платформы, под которую кодит человек — плохо.
К примеру, программировать на C#, не зная ничего о MSIL и GC — хуже, чем зная. Ровно потому, что абстракция С# неидеальна. И хотя бы основные вопросы этой неидеальности знать практически необходимо.
E>Но это вовсе не значит, что если бы я был более хорошим проектировщиком БД для MSSQL, то я бы был более хорошим разработчиком в своей предметной области.
А по-моему, как раз значит. Если ты взялся проектировать схему БД, то ты уже вышел за пределы чисто предметной области, и тебе знаний чистого DDL+DML будет недостаточно для того, чтобы хорошо сделать свою работу.
E>Потому что одних только вариаций B+ деревьев существует несколько штук. Не говоря уже о том, что разные БД могут размещать индексы в отдельных файлах, либо вместе с файлом БД, объединять несколько индексов в один файл или же разносить по разным файлам или даже дробить один индекс на серии файлов. А мне более важно, чтобы индекс ускорял выполнение запросов, а не то, как он устроен физически.
Очень интересно. То есть ты считаешь, что можно не знать про различия хеш индексы, B+tree, и Bitmap? Что разработчику БД можно игнорировать различия между скалярными индексами и full text индексами? Или может быть ты объявишь знания о различиях кластерных и некластерных индексов входящими в базис абстракции?
S>>Как по-твоему, детали хранения BLOB относятся к базису абстракции, или это несущественные детали? E>Для базиса это несущественные детали.
Ок, читаем следуюший ответ: E>Когда эти детали станут сказываться на производительности ПО или будут вызывать проблемы в разработке ПО.
Отлично. В соответствии с законом дырявых абстракций, который так тебе не нравится, в любой нетривиальной абстракции есть детали, сказывающиеся на производительности или вызывающие проблемы. В частности, детали хранения блобов сильно влияют на производительность ПО. Поэтому знания только самой абстракции недостаточно, нужно знать и то, что просвечивает через дырки в ней.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>На C++ сейчас писать что-нибудь производительное?
Позвольте полюбопытствовать: на чем же пишут сейчас производительное?
Здравствуйте, CreatorCray, Вы писали:
E>>На C++ сейчас писать что-нибудь производительное? CC>Позвольте полюбопытствовать: на чем же пишут сейчас производительное?
Ну это нужно спрашивать у тех, что C++ охаивает (на профессиональной основе)
По слухам, серьезную конкуренцию C++ должны составлять Java, C#, OCaml, Haskell, Pascal, Ada, Eiffel, Modula-2, Oberon, Clean, Lisaac. Fortran еще в области HPC.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
E>>Потому что все очень просто: либо человек знает все от и до, либо он опирается на какие-то абстракции, деталей реализации он может не знать. Полагая (до поры до времени), что эта абстракция его удовлетворяет. S>Непонятно, на каком основании делается вот это бинарное утверждение. Речь не шла о том, чтобы потребовать знания зонной теории от любого разработчика софта, исполняющегося на полупроводниковой элементной базе. Речь шла о том, что ограничение знания только поверхностью платформы, под которую кодит человек — плохо.
Речь шла о том, что человек, знающий детали работы нижележащих слоев (т.к. БД, ОС и пр.) будет эффективнее, чем тот, кто этого не знает. Это ерунда на том основании, что "знание деталей" ("понимание сути") это эрудиция + некоторая дельта(реального знания деталей). Причем чем дальше, тем больше становится эта дельта.
А мое бинарное утверждение как раз должно было показать, что нельзя меня упрекать в лукавстве, когда я говорю о том, что успешно опираюсь в своей работе на абстракции, детали реализации которых я не знаю. Поскольку это обычное дело и принцип "разделяй и властвуй" еще никто не отменял.
S>К примеру, программировать на C#, не зная ничего о MSIL и GC — хуже, чем зная. Ровно потому, что абстракция С# неидеальна.
Про GC не буду спорить, а вот по поводу MSIL твое утверждение не выглядит правдоподобным. Поскольку оно похоже на утверждения, что лучше уж не писать на C++ для Spark Solaris не зная ассемблера Spark, а на Java -- не зная байт-кодов JVM.
Или же речь идет о том, чтобы писать сборки, которые можно будет использовать из нескольких языков и не во всех языках есть непосредственные средства поддержки чего-либо (операторов индексации, к примеру)?
E>>Но это вовсе не значит, что если бы я был более хорошим проектировщиком БД для MSSQL, то я бы был более хорошим разработчиком в своей предметной области. S>А по-моему, как раз значит. Если ты взялся проектировать схему БД, то ты уже вышел за пределы чисто предметной области, и тебе знаний чистого DDL+DML будет недостаточно для того, чтобы хорошо сделать свою работу.
При инкрементной разработке будет достаточно для того, чтобы получать "good enough" решение на каждой итерации, постепенно пополняя собственный запас знаний. И дойдя в конце-концов до точки, в которой дешевле будет привлечь специалиста по БД, чем заниматься этой работой дальше самостоятельно.
E>>Потому что одних только вариаций B+ деревьев существует несколько штук. Не говоря уже о том, что разные БД могут размещать индексы в отдельных файлах, либо вместе с файлом БД, объединять несколько индексов в один файл или же разносить по разным файлам или даже дробить один индекс на серии файлов. А мне более важно, чтобы индекс ускорял выполнение запросов, а не то, как он устроен физически. S>Очень интересно. То есть ты считаешь, что можно не знать про различия хеш индексы, B+tree, и Bitmap?
На начальном этапе можно.
S>Что разработчику БД можно игнорировать различия между скалярными индексами и full text индексами?
"Разработчик БД" звучит как человек, занимающийся исключительно БД. Такому нельзя игнорировать различия. А если мне нужна табличка с несколькими целочисленными полями, и я делаю индекс по одному из этих полей, то нужно ли мне рассматривать различия между скалярными или full text индексами?
S>Или может быть ты объявишь знания о различиях кластерных и некластерных индексов входящими в базис абстракции?
В базис абстракции РСУБД эти знания, на мой взгляд, не входят.
S>Отлично. В соответствии с законом дырявых абстракций, который так тебе не нравится, в любой нетривиальной абстракции есть детали, сказывающиеся на производительности или вызывающие проблемы. В частности, детали хранения блобов сильно влияют на производительность ПО. Поэтому знания только самой абстракции недостаточно, нужно знать и то, что просвечивает через дырки в ней.
Это не нужно знать априори. Нужно иметь возможность и желание приобретать эти знания. Знать нужно лишь то, что эти знания в любой более-менее серьезной задаче придется приобретать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
S>>И что? Все могут ошибаться. Тем не менее, он пишет и довольно много умных вещей.
E>Ну вот мне не доводилось их находить в его фельетонах. Можешь примеры привести?
Я согласен с тем что его очень часто заносит, но даже за эту пару
E>Речь шла о том, что человек, знающий детали работы нижележащих слоев (т.к. БД, ОС и пр.) будет эффективнее, чем тот, кто этого не знает. Это ерунда на том основании, что "знание деталей" ("понимание сути") это эрудиция + некоторая дельта(реального знания деталей). Причем чем дальше, тем больше становится эта дельта.
E>А мое бинарное утверждение как раз должно было показать, что нельзя меня упрекать в лукавстве, когда я говорю о том, что успешно опираюсь в своей работе на абстракции, детали реализации которых я не знаю. Поскольку это обычное дело и принцип "разделяй и властвуй" еще никто не отменял.
Есть ситуации когда просто необходимо знать детали, в одно время например, я хоть и писал на C++, но приходилось приличную часть рабочего времени читать ассемблерный выхлоп компиляторов, да еще для двух разных платформ, да из профайлера не вылазить, а потом еще и подробно разбиратся с менеджером памяти под одну из них и писать свой. Притом ничего ничего кроме вполне гражданского кода на C++ я при этом не писал.
Здравствуйте, Sinclair, Вы писали:
E>>Нет, там просто в выражениях не стесняются, поэтому частно разывают вещи своими именами, даже если это и нецензурно. S>А, то есть в протоколе не шарят, зато знают много матов. Хороший, должно быть, форум.
Нормальный, linux.org.ru. По количеству полезной информации не сильно хуже этого, только стиль общения там совсем другой. Поэтому и выражение "половые сложности" там обычное явление.
E>>А какой у нас выбор, если кроме имени хоста ничего нет? S>Как какой? Вручную выполнить DNS resolution, точно управляя таймаутом и алгоритмом перебора primary/secondary. Например, можно отправить запрос всем одновременно, не дожидаясь, пока primary стаймаутится.
И в определенных условиях получить неудачное завершение всех операций из-за истечения слишком коротких для данных условий тайм-аутов.
E>>А вот это мне уже пофигу. 90% народу могут думать, что Бог сотворил Землю. Это не значит, что данное утверждение нужно считать законом. S>Ты его пока что не смог опровергнуть. Да и вообще, сформулировать свои претензии к этому закону.
А что опровергать, если Спольски ничего не доказывал?
Основные претензии к его статье такие:
— он делает громкий вывод на основании своих личных ложных предположений. И приводит такие же примеры, вроде того, что TCP не абсолютно надежный протокол;
— он наделяет "дыры в абстракциях" отрицательным смыслом (или же сами абстракции у него приобретают отрицательный смысл на основании наличия этих дыр). Хотя ничего отрицательного в них нет -- это данность. Такая же, как холодные зимы в высоких широтах серверного полушария. Про них так же можно написать какой-нибудь закон, а можно просто спокойно воспринимать как данность.
E>>Как раз в том, что все идет коту под хвост при проблемах в сети. Разработчику предоставляется компромис между простотой написания основного кода и тяжестью последствий нештатных ситуаций. S>Это какой-то неправильный компромисс. Правильный компромисс — это "я могу выбирать, что игнорировать, а что — нет". Вот, к примеру, в типичных HTTP клиентах ты можешь полагаться на стандартную реакцию на особенные ситуации, типа редиректов, а можешь обработать их самостоятельно. Ты, к примеру, можешь сделать такую штуку, как сказать "у меня уже есть данные от позавчера, если они изменились, то пришли мне новую версию, а если нет — то не присылай". Это одно из следствий того, что HTTP не старается изолировать разработчика от факта удаленности вызова. Ни одна реализация RPC не умеет делать такие вещи на уровне протокола.
А что мешает делать это для XML-RPC или SOAP?
E>>Принимать этот компромис или нет -- это проблемы разработчика, но не RPC. S>Ну так мы всё время говорим о разработчике, разве нет?
Я думал, что Спольски говорит об абстракциях, которые не железобетонные. А не о разработчиках.
E>>Ну вот мне не доводилось их находить в его фельетонах. Можешь примеры привести? S>Ну, вот к примеру — закон дырявых абстракций.
Ерунда.
S>Или принципы ценообразования в софте.
На вскидку не помню.
S>Или способы проведения интервью.
Более-менее, как один из возможных подходов.
S>Или то, как выбирать фичи для следующего релиза коробочного продукта.
Не припоминаю.
Ну как-то не очень солидный выхлоп, имхо.
S>Мы всё еще говорим о полезности Спольски для прочтения произвольным разработчиком? Или только о полезности лично для тебя?
Поскольку меня обвиняли в незнании закона, то речь обо мне.
S>Если лично ты не узнаешь ничего нового из его постов, то почему ты берешь на себя наглость критиковать тех, кто узнает?
Я от природы такой.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Есть ситуации когда просто необходимо знать детали, в одно время например, я хоть и писал на C++, но приходилось приличную часть рабочего времени читать ассемблерный выхлоп компиляторов, да еще для двух разных платформ, да из профайлера не вылазить, а потом еще и подробно разбиратся с менеджером памяти под одну из них и писать свой. Притом ничего ничего кроме вполне гражданского кода на C++ я при этом не писал.
Таких ситуаций множество. Но это не повод утвержать, что изначальное знание деталей конкретной платформы (ОС, БД, VM,...) делает одного разработчика эффективнее другого. Хотя бы потому, что:
— эти знания могут не потребоваться при проектировании;
— эти знания могут не потребоваться при реализации (упрется производительность в БД -- и все, нафиг идут знания о стоимости atomic-инструкций в тактах процессора);
— другой разработчик может применить иные алгоритмы реализации, более эффективные, например, с точки зрения большого O;
— другой разработчик может приобрести эти знания быстрее, чем первый получит возможность применить свои знания на практике;
— этот разработчик может не найти общий язык с заказчиком из-за чего в проекте будет реализоваваться не то, за что заказчик захочет платить деньги;
— этот разработчик может не найти общего языка с другими членами команды и общая скорость разработки снизится из-за усилий, прилагаемых для разруливания этих разногласий;
— этот разработчик может углубиться в "вылизывание" какой-нибудь фичи, из-за чего не будет сделана какая-то другая часть функциональности;
— этот разработчик может очень плохо структурировать и документировать свой код, из-за чего другие члены команды будут тратить больше времени на работу с ним, что снизит общую производительность команды;
— и т.д., и т.п.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
S>>Непонятно, на каком основании делается вот это бинарное утверждение. Речь не шла о том, чтобы потребовать знания зонной теории от любого разработчика софта, исполняющегося на полупроводниковой элементной базе. Речь шла о том, что ограничение знания только поверхностью платформы, под которую кодит человек — плохо. E>Речь шла о том, что человек, знающий детали работы нижележащих слоев (т.к. БД, ОС и пр.) будет эффективнее, чем тот, кто этого не знает. Это ерунда на том основании, что "знание деталей" ("понимание сути") это эрудиция + некоторая дельта(реального знания деталей). Причем чем дальше, тем больше становится эта дельта.
Нет, речь шла именно о том, что написал Sinclair.
Выше было, откровенно говоря, лень писать вам такой же многословный ответ, как и ваш вопрос, сейчас вам его уже дали.
E>А мое бинарное утверждение как раз должно было показать, что нельзя меня упрекать в лукавстве, когда я говорю о том, что успешно опираюсь в своей работе на абстракции, детали реализации которых я не знаю. Поскольку это обычное дело и принцип "разделяй и властвуй" еще никто не отменял.
Ваше лукавство проявляется именно в двоичной логике black or white, на деле все в мире сплошь серые полутона. Абстракции не так уж безупречны, как вы тут втираете (но никто не говорит, что они совсем безполезны — прошу, не надо притворяться таким уж примитивным, а также приписывать такую же примитивность собеседникам), а потому готовность и опыт латания дыр абстракций есть необходимый навык успешной работы именно с абстракциями (с чего вы про ассемблер, честно, не понял).
Здравствуйте, rsn81, Вы писали:
S>>>Речь шла о том, что ограничение знания только поверхностью платформы, под которую кодит человек — плохо. R>Нет, речь шла именно о том, что написал Sinclair.
Ok. Тогда можете ли вы привести критерии оценки поверхности и неповерхности платформы?
R>Ваше лукавство проявляется именно в двоичной логике black or white
Моя бинарная логика появилась после вашего обвинения в лукавстве. Как доказательство несостоятельности обвинения.
R>Абстракции не так уж безупречны, как вы тут втираете
Где я это утверждал?
R>(с чего вы про ассемблер, честно, не понял).
Бывает.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ok. Тогда можете ли вы привести критерии оценки поверхности и неповерхности платформы?
Зачем? Признаться, у меня нет общего правила, только частные наблюдения.
E>Моя бинарная логика появилась после вашего обвинения в лукавстве. Как доказательство несостоятельности обвинения.
Нет, до, см. ниже.
R>>Абстракции не так уж безупречны, как вы тут втираете E>Где я это утверждал? Re[9]: О программировании
Здравствуйте, eao197, Вы писали:
E>Про GC не буду спорить, а вот по поводу MSIL твое утверждение не выглядит правдоподобным. Поскольку оно похоже на утверждения, что лучше уж не писать на C++ для Spark Solaris не зная ассемблера Spark
Неверно. Кодогенерация прямо в IL используется в дотнете очень часто. И появление во второй версии LCG тому хорошее подтверждение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Умные указатели — замечательная штука, если не считать того, что они не запрещают использование глупых указателей.
Если нам не помогут, то мы тоже никого не пощадим.
). А вообще логика — железная. Т.е. если человеку довелось поработать админом, то это ему несмываемое клеймо на всю жизнь? Так у меня по трудовой, первая запись — художником-оформителем в течении 5 месяцев, это я еще будучи студентом подрабатывал, в силу своего среднего образования (оно у меня художественное). Это тоже повод ахнуть, "жесть", мол: "фотошопник, ревью кода делает 
"?
