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

AS>Это редкость. По крайней мере в моей практике. Вот, допустим, я первый раз встретил проект на новой работе, где вручную подкручиваются параметры GC. До этого я писал серверные приложения, но мне подкрутка GC (размеры куч 0, 1 поколения) никогда не требовалась.

Редкость ? Гм. Вот тебе пример из структур данных. Вирт в своей книге приводит трюк, позволяющий в однонаправленном списке вставить элемент перед текущим. Собственно, это и не трюк, а просто некая хитрость — вставляем после текущего (а как еще можно ?), пересылаем текущий во вставленный, заполняем бывший текущий.

А теперь представь себе, что я этого не знаю. А вставлять надо именно перед, а никак не после.

2 решения.

1. Сделать список двунаправленным. Дополнительный код, дополнительная память — все зря.
2. Каждый раз начинать с начала списка и искать пред-текущий элемент. Это мои студенты хорошо умеют . На ровном месте задачу O(1) превратили в задачу O(N).

А всего-то трюк...

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

PD>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Это редкость. По крайней мере в моей практике. Вот, допустим, я первый раз встретил проект на новой работе, где вручную подкручиваются параметры GC. До этого я писал серверные приложения, но мне подкрутка GC (размеры куч 0, 1 поколения) никогда не требовалась.

PD>Редкость ? Гм. Вот тебе пример из структур данных. Вирт в своей книге приводит трюк, позволяющий в однонаправленном списке вставить элемент перед текущим. Собственно, это и не трюк, а просто некая хитрость — вставляем после текущего (а как еще можно ?), пересылаем текущий во вставленный, заполняем бывший текущий.

Павел, я тоже могу привести овер 9000 случаев, когда требовалась смекалка. Что теперь, весь софт обязан эти трюки использовать? Почему не взять двунаправленный список? Экономим 4(8) байт на указателе? Ну, удачи. В некоторых случаях это полезно. Процентах в 5-10.

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

PD>Еще раз — я считаю это требование необходимым, но явно не достаточным. Заказчик должен быть доволен, иначе вы понапрасну потратили время и деньги. Всегда должен быть доволен, и если он недоволен — нет качественного продукта. А вот дальше и начинается оценка качества и ее могут провести только профессионалы, а не заказчик.


PD>

PD>if(заказчик доволен)
PD>  if(профессиональный анализ прошел успешно)
PD>   quality = true;
PD>  else
PD>   quality = false;
PD>else
PD> quality = false;  

PD>

Может, так?

 quality = (заказчик доволен) && (профессиональный анализ прошел успешно)

B>>Кстати, смешивать качество продукта с профессионализмом нет особого смысла.
B>>Качество продукта — вещь куда более широкая, чем профессионализм отдельных разработчиков.
PD>Это уж точно. Только вот одно но. Высокопрофессиональные разработчики вполне могут соорудить некачественный продукт. Но вот то, что низкопрофессиональные могу соорудить качественный — извини, не поверю.

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

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>1. Сделать список двунаправленным. Дополнительный код, дополнительная память — все зря.
PD>2. Каждый раз начинать с начала списка и искать пред-текущий элемент. Это мои студенты хорошо умеют . На ровном месте задачу O(1) превратили в задачу O(N).
Круто. А теперь представь, что тебе не повезло, и текущий элемент оказался головой списка. Ничего, что твой трюк "сломает" список?

Сможешь обобщить трюк так, чтобы он не ломал список?
А чтобы сохранял любые указатели снаружи внутрь списка, т.е. обходился без перемещений элементов в адресном пространстве, но все еще без O(N) по коду и без O(N) по памяти?

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

PD>Я, как некоторым здесь известно, по образованию химик. Правда, уже 20 лет никакой химией не занимаюсь и порядком ее подзабыл. Но вот недавно произошло одно событие, заставившее меня кое-что вспомнить и посмотреть на происходящее у нас в ИТ с точки зрения химика (точнее, человека не из ИТ-области). И выводы, к которым я пришел, довольно неприятные.


Компьютерные науки ничем в не отличаются от химии.
Специализация черезмерно узкая. Никаких C++, C#, HTML в науке нет (почти нет)
В некоторых научных областях (особено эксперементальных) недостаточно заниматься узкой областью. Надо еще придерживаться определенных взглядов т.е. принадлежать к одной из научных школ. Иначе — нечего даже жумать о совместной ними работе (трудоустройстве, стажировке).

Не сравнивайте программистов и ученых.
Сравнивайте с инженерами и технологами работающими на заводах. Которые проводят профилактические работы, модернизируют процесс, управляют производством и т.д.
У меня родственник всю жизнь проработал на строительном заводе (сначала управление производством, в последствии просто управление) имея педогогическое образование гуманитарного профиля.

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

PD>Иными словами, в химии царит узкая специализация.

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

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

SB>>> Программисту же никакими такими специфическими качествами, которые трудно развить, обладать не нужно
AVK>>Сие неплохо бы аргументировать.
SB>Ок. Сложно сказать, какие такие специфические качества нужны программисту. На ум приходят только мозги(в смысле — способности мыслить, запоминать, рассуждать, решать и т.д. и т.п.) и желание быть программистом. С желанием все понятно. Но вот мозг, он есть у всех людей и это не является специфичиским качеством. Можно конечно сказать, что у кого-то IQ выше или что кто-то запоминает быстреее или просто сказать, что Вася умнее Пети и поэтому он может стать программистом. Но так ли это? Станет ли Вася лучшим программистом чем Петя? Не факт. Ведь мозги, в отличии от музыкального слуха, легко "тренируются" (чуть было не написал — "что бы стать умнее, особого ума не надо" ). Можно посмотреть на то, сколько людей обучается в музыкальных школах/консерваториях и не становяться музыкантами. Т.е. чего-то им не хватает, иногда желания, а иногда, может быть, этих самых специфических качеств, присущих только музыкантам. Каким же ещё "талантом" должен обладать человек чтобы стать программистом? Может быть нужен особый склад ума или особое чувство юмора? — , не знаю, поэтому сравнение музыкант-программист и показалось интересным.

Я видел вполне умных людей у которых отсутствует "часть мозга отвечающая за понимание указателей", так что специфические способности все-таки нужны. Да и IQ (начиная с некторого минимума) по моему не так важно. И полно программистов страдающих склерозом

FR пишет:

> Я видел вполне умных людей у которых отсутствует "часть мозга отвечающая
> за понимание указателей", так что специфические способности все-таки
> нужны. Да и IQ (начиная с некторого минимума) по моему не так важно. И

У меня отец в упор не понимает указателей. И не хочет. А программист с хрен
знает каким стажем. Просто он писал и пишет на языках, где их (указателей)
нет и не было никогда.

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

MZ>У меня отец в упор не понимает указателей. И не хочет. А программист с хрен
MZ>знает каким стажем. Просто он писал и пишет на языках, где их (указателей)
MZ>нет и не было никогда.

Указатели это образно.

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

PD>Редкость ? Гм. Вот тебе пример из структур данных. Вирт в своей книге приводит трюк, позволяющий в однонаправленном списке вставить элемент перед текущим. Собственно, это и не трюк, а просто некая хитрость — вставляем после текущего (а как еще можно ?), пересылаем текущий во вставленный, заполняем бывший текущий.

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

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

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

G>>Часто объективно хватает тех самых 20% для решения задачи, потому что такие задачи. Да зачем далеко ходить, про 80% людей можно сказать, что они используют 20% своих возможностей (цифры взяты с потолка, из расхожего соотношения). Больше не нужно, все определяется задачей.

PD>Хм. В среднем, может и верно. Но тебе не доводилось попадать в ситуацию, когда использование маленькой-маленькой фичи, о которой где-то на 125 странице 5 строк написано, позволяет создать гораздо более элегантное и оптимальное решение, чем без нее ?

Доводилось. И наоборот тоже доводилось, в лоб, по принципу "знаю мало, но твердо".

Одна из частей задачи — ограниченное время на решение; образование — очень ресурсоемкая штука; от Т-специализации никуда не денешься; не все такие умные — это все объективные вещи.

Когда я был студентом, нам читали спецкурс по всяким авиационным железякам. Преп рассказал нам об очень интересных оценках. В хозяйстве повсеместно используется огромное количество всевозможных турбин и компрессоров, они везде, куда ни плюнь. Вот если бы они все столь же качественно проектировались, оптимизировались, вылизывались, как авиационные турбины и компрессоры, то эффективность этих устройств увеличилась бы в среднем в разы, и экономия энергии в масштабах страны была бы огромной (цифру моя дырявая голова забыла, но там много электростаций можно было бы остановить и не парится). Почему этого практически не делалось, наверное, понятно: качество кадров, научно-техническая база, оргвопросы и т.д.

Я уже как-то пытался вещать о универсализации, стандартизации и избыточности (о набивании текстов на многоядерных "пнях" и метании тысяч икринок ради пары взрослых рыбок). Это приблизительно из этой же оперы. Каковы критерии прогресса, таков и прогресс . Никуда мы от "80 на 20" и увеличения дилетантизма не денемся.

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

PD>Скажу жестче. Массовое распространение профессии программиста привело к резкому понижению профессионального уровня и превалированию дилетантского подхода. На рынок выбрасывается ежегодно большое количество полупрофессионалов, которые на этом рынке начинают задавать тон и определять его поведение.Правила игры в этой полупрофессиональной среде начинают выдаваться за нормы в отрасли, и этому очень трудно противостоять. Трудно говорить «треугольник» , когда тебе показывают треугольник, если 20 человек рядом с тобой кричат при этом «ромб».

PD>Что это ? Незрелость технологии ? Следствие экстенсивного развития в ущерб интенсивному ? Как долго это будет продолжаться ? Или же ИТ действительно отличается от других областей науки и техники ?


Ну так и в советские времена была огромная масса научных работников, которые не особенно разбирались в своей профессии и ходили на работу
как на службу. И были энтузиасты, которые вгрызались в тему.
Этим IT нынешнее ничем не отличается от советской науки. Так всегда было, так и будет.
Паниковать не надо

Отложим химию и IT. Возьмём медицину. В каждой специальности (окулист, отоларинголог, уролог и пр.) разные методики, разные лекарства, всё в общем разное. И это, может быть, правильно. Каждый месяц появляются новые лекарства, а по существующим появляется новая информация (о побочных эффектах, эффективности, дозировке). Из-за этого специальности постоянно делятся, специализируются.

К чему это приводит? К тому, что доктора начинают лечить не пациента, а болезнь. Супер-специалист по воспалению среднего уха излечивает это воспаление в 99% случаев, но при этом в 30% (все цифры условные) прописанные лекарства вызовут проблемы в других органах. Которыми займутся другие супер-специалисты...

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

E>Тогда обязательно будут смеяться над тем, кто называет себя специалистом, но не знает, что такое автомат Мили

Автор: thesz
Дата: 18.03.09

В том примере результат ф-ии вычисления следующего состояния (значения acc) и ф-ии выхода (вход для сумматора) объединены в один тупл. И там не сам автомат, а эти 2 его ф-ии. Автор был не точен только в странной формулировке "функция автомата Мили", без объяснения — какая из 2-х (или сразу 2-в-1 как там), это бессмыслеца.

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


PD>Уф, спасибо за разъяснение. А то мне как-то стыдно стало — ну не знаю я ничего про автомат Мили, но не хочу, чтобы надо мной смеялись. Теперь понял — смеяться не будут. Продолжаю не знать, что же это за автомат такой

Это наиболее общий вид автомата. Есть автомат Милли, а есть Мура, второй — суть "обрезанная" модель первого, т.к. у второго ф-ия выхода зависит только от состояния, в то время как у первого — от входа и состояния. Второй вид популярен в схемотехнике, он обычно проще, в нем более равномерное распространение задержек, и особенно хорош там, где кодированием состояний можно существенно минимизировать (или вообще нивелировать) ф-ию выхода.

Сами термины "автомат Мура/Милли" в IT-специальностях изучаются на 3-м курсе (если склероз не подводит), куча лаб по ним делаются, как на софте, так и на железе (на лабах по схемотехнике), поэтому подразумевается, что все в курсе.

AF>Этим IT нынешнее ничем не отличается от советской науки. Так всегда было, так и будет.
Что было, то и будет; и что делалось, то и будет делаться

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

V>>Если же кто-то является высочайшим специалистом исключительно в области реализации чтения XML средствами VB 6.0, а во всех остальных областях — полный профан, то... удачи ему в поисках места под солнцем.

PD>Увы, да. Сейчас да. И это плохо.

Не согласен! Это очень хорошо, потому что узкая специализация в программировании — признак того, что человек когда-то чему-то из-под палки выучился, и теперь он этим худо-бедно зарабатывает копеечку. Но на самом деле всё богатства нашего ремесла ему строго до одного места, и он уже давно морально готов уйти в менеджеры торгового зала в салон сотовой связи. Куда ему, собственно, и дорога.

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

<skipped>

Читай Вирта. Там все это есть, в том числе вставка в начало.

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

I>Можно два указателя вести -- на текущий и на предидущий элементы.

Можно, конечно, правда, остается выяснить, куда они будут показывать при одном элементе

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

Разумеется. Может и не оказаться. Может этот подход и не годится в данном конкретном случае. Но я ведь не его обсуждаю, а просто сказал, что знание его может сильно упростить решение. Не всегда. Но его незнание — не упростит. Всегда. Так что надо знать.