Здравствуйте, a_kutovets, Вы писали:

L>>Это не внутренности CLR. Вполне себе штатные возможности, которые описаны в любом учебнике.

_>простите, но это "штатные возможности" среды, описанные в любом учебнике. или вы считаете, что среду описывают в каких-то мало распространенных талмудах, которые в огранниченны в экземплярах и нужны не всем?

в сообщении выше по ветке речь шла не о среде, о внутренностях среды.
в моем понимании внутренности это как раз что-то, что недостаточно хорошо покрыто основной массой литературы/документации.

_>>>знание, как работает GC пригодиться, знание о поколениях.

L>>Для чего?

_>навскидку, знать хотя бы, что неуправляемые ресурсы освобождать нужно. не говоря уже о ресурсах, к которым происходит обращение из различных участков кода.

Сорри, не совсем внятно написал свой вопрос. Зачем нужно знание о поколениях?

Здравствуйте, a_kutovets, Вы писали:

_>или по вшему мнению, знать, как работают исключения, ref/value types, ч из себя представлют using{...} statements, список можно продолжать до бесконечности... совсем не обязательно?

До бесконечности, говорите. Ну-ну. А как можно иметь знания о бесконечной череде вещей не подскажите?

Продолжая вашу логику можно сказать, что C++ник должен знать каким образом ofstream::write отображается на FileWrite под Windows, и как FileWrite взаимодействует с подсистемой ввода-вывода ОС, и как эта подсистема дергает драйвер, и как драйвер позиционирует головки винчестера, и как их этих головок электроны вырываются, и как они изменяют магнитные поля на поверхности дисков винчестера, и как... А иначе кодер!

Здравствуйте, yumi, Вы писали:

Y>Как практик разрабатывавший бортовые системы навигации скажу, надо тупо следовать спецификации на 100%.

Прошу прощения за оффтоп, но очень интересно -- на каких платформах эти системы навигации строятся и какие языки программирования используются в их разработке?

Здравствуйте, a_kutovets, Вы писали:

Y>>>>Кстати прикладнику не обязательно быть экспертом в внутренностях CLR\JVM Это я так, к слову

_>здесь категорически не соглашусь. знание спецификации и принципов работы среды, в которой выполняется код этого прикладника позволяет писать этот же код лучше, больше соответствовать требованиям.

Быть экспертом в внутренностях CLR/JVM и знание спецификации и принципов работы это две разные вещи. Первое, это знание того, как все устроено изнутри, того, как работает тот или иной механизм. А второе это минимальное и обязательное требование. Как говорится feel the difference.

_>или по вшему мнению, знать, как работают исключения, ref/value types, ч из себя представлют using{...} statements, список можно продолжать до бесконечности... совсем не обязательно?

Как работает механизм исключения внутри самой CLR мне действительно до фени, а вот с точки зрения "пользователя" исключений, того как ими пользоваться, как их генерировать и обрабатывать, да знать надо обязательно. Все то же самое по вашему списку далее.

_>по моему глубокому убеждению, которое подтверждено и собственным опытом работы, и наблюдением за джуниорами в тиме, знать среду ооочень желательно. иначе прикладник тк и останется кодером.

По моему глубокому убеждению, и тот и другой могут быть кодерами, только один будет более продвинутым кодером А тот, у кого отличное фундаментальное образование в CS, способности к инженерному мышлению, опыт работы в разных средах не будет кодером, пусть даже он слабо разбирается в кишках CLR или JVM. Если надо, то он разберется, поверь

Здравствуйте, goto, Вы писали:

G>Мне лично, например, всегда было интересно делать новые проекты, а не поддерживать и развивать уже готовый продукт, пусть даже свой собственный.

Да, разные люди, разные интересы. Если честно, то мне подобный стиль напоминает комманданте Че. Устраивал революции,
и даже успешные, но плодами побед (был министром на Кубе) воспользоваться не захотел, и пошёл делать революции дальше.
Я сам в чём-то такой. Только у меня это выглядит как поэтапное развитие того-же, а не изготовление каждый раз с нуля.
Да, было время, я годами не занимался этим своим. Но постепенно дошёл до места, где на 2-й этап можно потратить
всю жизнь. На том, видимо, и успокоюсь со своими революциями.

M>>ЗЫ Кстати, этот 3-й этап и есть этам настоящего развития. А 2-й — это не развитие, а "экспансия".
M>>Количественный рост, не более того. На развитие он похож только внешне.

G>Почему? Может быть, мы говорим о разных вещах?

G>На 2-м этапе решаются качественно новые задачи. Если обизнесе, то не просто нарабатываются новые связи, а ищутся новые способы, техники, пододы для этого. Если о технологической стороне, то "поднимаются" новые проекты, осваиваиаются или создаются продукты, технологии. Иногда даже выращиваются рынки. А в дальнейшем это все уже в основном равивается количественно и поддерживатеся.

Наверное, всё-ж об одном и том-же. Хотя меня настораживают слова, что в дальнейшем это развивается количественно.
Для меня это — всё тот-же 2-й этап. С ростом размера происходят внутренние трансформации, перед бизнесом
встают новые задачи, они требуют новых (для данного руководства) методов решения.
Вот когда и количественного раста нет — тогда это для меня 3-й этап, этап качественного, а не количественного
развития.
2-й этап — это как-бы период детства, роста. Постоянно всё меняется, постоянно интересно.
А 3-й этап — это как-бы взрослость.
Но с другой стороны — ведь детство было ради взрослости, в детстве мы осваивали для нас новое и
набивали свои шишки — но с точки зрения мира в этом небыло ничего нового. Те-же самые проблемы решали
бесчисленное количество раз до нас. И фирмы строили бесчисленное количество.
А вот когда человек или бизнес стал взрослым — вот тут и может начаться настоящее творчество.
Стабильность — это скучно. Но без этой стабильности невозможно появление более сложных, тонких
вещей. Ну не могут университеты и наука существовать без стабильного города — учёные не производят
продукты непосредственно, надо чтоб их кто-то кормил. Правда, потом учёные изобретают паровые
машины, электричество, ракеты, всё это облегчает жизнь города, он выходит на новый уровень
гомеостаза, потом учёные изобретают генетику, компьютеры, и так далее. А если жизнь не
стабильна — то учёные никому не нужны, есть более насущные задачи выживания и роста.

Не все фирмы и не все люди выбирают творчество на 3-м этапе. Точнее, выбирают его совсем
не многие. Кто не выбрал и доволен стабильным существованием — тот загниёт и подохнет.

Здравствуйте, Lloyd, Вы писали:

L>в сообщении выше по ветке речь шла не о среде, о внутренностях среды.
L>в моем понимании внутренности это как раз что-то, что недостаточно хорошо покрыто основной массой литературы/документации.

в принципе, согласен, запутался в самих формулировках.
о внутренностях вреды в контексте моих сообщений я подрзумеваю понимание, как происходит выполнение кода, написанного программистом.

L>Сорри, не совсем внятно написал свой вопрос. Зачем нужно знание о поколениях?

знать, как происходит сборка мусора. понимать, что некоторые объекты практически никогда не будут убраны (основные формы, например).
понимать/знать, что в некоторых случааях система поколений не работает (очень большие объекты, например).

з.ы. спорить больше не буду, так как кишки устройства среды (вирутальной машины) и впрямь редко необходимо.

Здравствуйте, eao197, Вы писали:

E>Прошу прощения за оффтоп, но очень интересно -- на каких платформах эти системы навигации строятся и какие языки программирования используются в их разработке?

Платформа, это разработка самой компании, свое железо, свой процессор, своя мини-ос, а язык старый добрый Си Был еше какой-то скриптовый язык тоже нашей разработки, для связи с другими устройствами, но я с этой подсистемой и языком слабо знаком.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, a_kutovets, Вы писали:

_>>или по вшему мнению, знать, как работают исключения, ref/value types, ч из себя представлют using{...} statements, список можно продолжать до бесконечности... совсем не обязательно?

E>До бесконечности, говорите. Ну-ну. А как можно иметь знания о бесконечной череде вещей не подскажите?

E>Продолжая вашу логику можно сказать, что C++ник должен знать каким образом ofstream::write отображается на FileWrite под Windows, и как FileWrite взаимодействует с подсистемой ввода-вывода ОС, и как эта подсистема дергает драйвер, и как драйвер позиционирует головки винчестера, и как их этих головок электроны вырываются, и как они изменяют магнитные поля на поверхности дисков винчестера, и как... А иначе кодер!

понимаю ваш сарказм по поводу категоричности моих суждений))) за что и приношу all свои извинения.

но также хочу заметить, что и такие знания нужны при разрботке библиотек, например. другие при разрботке драйверов.

конечно, мы сейчас говорили о прикладниках. им железо, ОС знать не так важно/нужно/совсем не нужно. я утверждаю о знании прикладниками среды выполнения его кода.

Здравствуйте, yumi, Вы писали:

i have already felt the difference)

уже ответил здесь

Автор: a_kutovets
Дата: 07.10.08

Здравствуйте, a_kutovets, Вы писали:

_>но также хочу заметить, что и такие знания нужны при разрботке библиотек, например. другие при разрботке драйверов.

_>конечно, мы сейчас говорили о прикладниках. им железо, ОС знать не так важно/нужно/совсем не нужно. я утверждаю о знании прикладниками среды выполнения его кода.

По моему субъективному мнению даже такие упрощенные требования (не говоря уже о первоначальных высказываниях kochetkov.vladimir: "программист (не кодер), не понимающий сути работы платформ, под которые он пишет код (ОС, СУБД, различные сервера приложений, балансеры, средства виртуализации, и т.п. — не важно), не будет столь же эффективен в процессе разработки, как его коллега, владеющий подобными знаниями.") не соответствуют доминирующему принципу "разделяй и властвуй" при помощи которого и разрабатывается современное ПО. Благодоря слоям абстракций и разделению ПО по этим слоям программистам (обычным людям, не гениям) удается справляться со сложностью современного ПО. Как раз благодоря тому, что прикладник _не знает_, что происходит "под капотом", он имеет возможность забивать свою голову задачами своей предметной области и решать их. Я, например, понятия не имею, как устроен штатный распределитель памяти в моем C++ компиляторе и как мой компилятор реализует обработку исключений. Мне это и не нужно, т.к. я знаю, что кто-то уже озаботился решением этих вопросов на более низком слое абстракции. Более того, я вообще не пытаюсь претендовать на точное понимание того, как работает мой код, поскольку современные оптимизирующие компиляторы и процессоры с переупорядочением инструкций уделывают его как бог черепаху. И ничего, работает.

Разговоры о знании принципов -- это всего лишь разговоры. Например, понимание принципов работы современных СУБД -- это как понимание принципов современной атомной модели: где-то что-то слышал про электроны, протоны и нейтроны. Кто-то из них еще состоит из кварков, которые как-то хитро могут объединяться между собой. Так же и СУБД -- есть анализатор запросов, есть оптимизатор, есть какая-то система хранения, есть write-ahead-log. Практической пользы от этих знаний -- никакой. Людей, понимающих в ядерной физике (и способных извлекать из своих знаний пользу), как и людей, разрабатывающих СУБД -- гораздо меньше, чем тех, кто успешно пользуется результатами их труда не задумываясь о сути происходящего.

Здравствуйте, eao197, Вы писали:

E>По моему субъективному мнению даже такие упрощенные требования (не говоря уже о первоначальных высказываниях kochetkov.vladimir: "программист (не кодер), не понимающий сути работы платформ, под которые он пишет код (ОС, СУБД, различные сервера приложений, балансеры, средства виртуализации, и т.п. — не важно), не будет столь же эффективен в процессе разработки, как его коллега, владеющий подобными знаниями.") не соответствуют доминирующему принципу "разделяй и властвуй" при помощи которого и разрабатывается современное ПО. Благодоря слоям абстракций и разделению ПО по этим слоям программистам (обычным людям, не гениям) удается справляться со сложностью современного ПО.
[skipped]
Мне кажется, вы лукавите. Про закон дырявых абстракций слыхали?

Здравствуйте, yumi, Вы писали:

Y>А в менеджед средах увидеть, то где утечка можно всегда.
Утечек в unmanaged стиле в managed не бывает. О чем ты?

Y>Как будто среди С++ников их меньше.
По моему опыту — сильно меньше. А вот в индусско-американском C# коммюнити такое ощущение что 99% дебилов.

Здравствуйте, rsn81, Вы писали:

R>Мне кажется, вы лукавите. Про закон дырявых абстракций слыхали?

Если я лукавлю, а верите в закон дырявых абстракций, то любимые вами Java-технологии примерами таких абстракций и являются. Ну и как доведенное до апупеоза следствие -- корпоративное ПО можно разрабатывать на ассемблере без всяких там дырявых J2EE.

Здравствуйте, yumi, Вы писали:

E>>Прошу прощения за оффтоп, но очень интересно -- на каких платформах эти системы навигации строятся и какие языки программирования используются в их разработке?

Y>Платформа, это разработка самой компании, свое железо, свой процессор, своя мини-ос, а язык старый добрый Си

Если не секрет: компания Российская? Своя мини-ос полностью своя или же базируется на коде Linux/BSD?

Здравствуйте, CreatorCray, Вы писали:

О том, что если в managed какой-то объект живет дольше, чем мы ожидаем, то можно подробно посмотреть, кто именно его держит.
А в анменеджед нужно искать, кто именно его не удалил.

CC>По моему опыту — сильно меньше. А вот в индусско-американском C# коммюнити такое ощущение что 99% дебилов.
Ничего. Стоит зайти в форум "о жизни" на RSDN — сразу становится понятно, что умственный уровень русскоязычного программистского комьюнити не сильно лучше.

Здравствуйте, 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>Тут самое главное — не перепутать свое субъективное нежелание постоянно перевариавть новое с объективным состоянием индустрии.

Знаешь, новизна, если вдуматься, — понятие по своей природе субъективное. Попробуй перечитать свою фразу с учетом этого. Лично я там вижу штамп, построенный из ненадежных терминов и аксиом. Уж извини.

Здравствуйте, goto, Вы писали:

G>Знаешь, новизна, если вдуматься, — понятие по своей природе субъективное.

А я про новизну ничего и не говорил.

G> Попробуй перечитать свою фразу с учетом этого.

Перечитал. Ничего не изменилось.

G> Лично я там вижу штамп, построенный из ненадежных терминов и аксиом. Уж извини.

Видать, такое у тебя зрение, что на ровном месте штампы кажутся. Уж извини.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, goto, Вы писали:

G>>Знаешь, новизна, если вдуматься, — понятие по своей природе субъективное.

AVK>А я про новизну ничего и не говорил.

Не делай такие невинные глаза . "... переваривать новое" — чье? Таки перечитай, будь добёр. Хотя я не настаиваю на продолжении этой заведомо бесплодной дискуссии .

Здравствуйте, eao197, Вы писали:

E>Если не секрет: компания Российская? Своя мини-ос полностью своя или же базируется на коде Linux/BSD?

Не секрет, компания Российская, но названия здесь публиковать как-то не хочется. Но надо отметить, что наши заказчики забугорные. Мини-ОС полностью своя, но она действительно мини, там реализован именно тот минимум, который необходим нам. Более подробно наверное только в личке.