Здравствуйте, gandjustas, Вы писали:
M>>Сегодня вот обнаружил String.equals(""+char). Только вот в очень вложенном цикле... Само по себе фигня вроде... G>1)Какой процент времени занимает это сложение? G>2)Если меньше 1% то нафига ты туда лазил? У тебя более важных дел не нашлось?
Иногда приходится оптимизировать и Equals и GetHashCode оптимизировать, когда числодробилки пишешь и больше оптимизировать уже негде
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, alpha21264, Вы писали:
T>>>>
Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
DR>— Brian W. Kernighan.
DR>>>Интересно, в чём измеряется сложность отладки, в чём написание, и какое это имеет отношение к сообразительности?
A>>Например числом переменных, которые вы одномоментно должны держать в памяти.
DR>То есть, во время отладки, в памяти необходимо держать вдвое больше переменных? Понятно, человек хотел сказать: "писать трудноотлаживаемый код — плохо." Но манеру выражения он выбрал пафосную и бессмысленную.
Ну типа да. Потому что обычно отладка это поиск какого-то сайд-эффекта. Что-то происходит за пределами твоего куска.
И тебе нужно зарезервировать часть мозгов, которая будет держать в поле зрения дополнительные сущности сайд эффекта.
А Керниган как раз очень хорошо умел выражался. Понятно и однозначно.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, alpha21264, Вы писали:
A>>А Керниган как раз очень хорошо умел выражался. Понятно и однозначно.
N>Почему "умел"? Он живой и не собирается пока сдаваться
Это я с прямым углом перепутал.
N>Но этот вывод мне не нравится. Мол, пишите тупо, тогда хватит мозгов на отладку.
Пишите просто — будет работать надежно. Это не значит тупо.
Автомат Калашникова простой. Но не тупой.
Здравствуйте, Osaka, Вы писали:
VD>>То есть, дело в тупом руководстве? O>В мировоззрении. (И чаще всего это "дороже денег" (не знаю насчёт зарубежа, но в России да)) O>"Нам не нужны умные, нам нужны верные" O>"Главное — добросовестность" O>В более тяжёлых случаях — "В настоящей жизни всё настоящее даётся только через напряжение, а этот не хочет делать так как трудно, всё придумывает как бы посачковать и позаниматься чем ему интересно, вместо того чтобы пахать как раб на галере. Вон все студенты пашут принятой в компании технологии и не жалуются что у них плуг между досок застревает"
Очередной мля непризанный гений. Я таких нах увольняю. Нафиг мне человек супер-пупер прогер, если на него нельзя положится — он ломает все планы. Толку от его гениальности — если он завалит проект по срокам, т.е. в итоге результат 0.
___>Очередной мля непризанный гений. Я таких нах увольняю.
butthurt detected
>Нафиг мне человек супер-пупер прогер, если на него нельзя положитЬся — он ломает все планы.
Нафиг мне ножик, если на него нельзя положиться — он всё режет.
Для чего нужны "супер-пупер прогеры" и как обходить их ограничения, уже много писалось, у того же Джоэла например.
>Толку от его гениальности — если он завалит проект по срокам, т.е. в итоге результат 0.
А заранее согласовать сроки с запасом — вера не позволяет? Хотя, кто у нас способен планировать на долгосрочную перспективу...
M>Во-первых, любая контора берёт ЛУЧШИХ, но чтобы они писали в пределах корпоративной культуры и архитектуры. Во-вторых, нет таких коллективов, где нет хороших прогеров. Они составляют "мозг проекта", а вокруг них можно нанимать хоть негров — они одинаково эффективно решат _разложенные_по_полочкам_ задачи. Не надо думать, что проекты — это сплошь шахматы и ребусы, подавляющая их часть — РУТИНА, оформленная в красивые модули и стрелочки.
Прежде всего хотелось бы отметить что за любой корпоративной структурой стоят либо экономика, либо предпочтения/знания конкретных людей. К тому же эта логика не объясняет контор в которых "эти треугольные скобочки" (дженерики, C#2), запрещены корпоративным стандартом. Даже для лидов. Просто потому что у них ставка на студентов, по $400 за пучок, и на соответствующие задачи.
M>Ясный код понимаем любым. Плохой не понимаем даже специалистами. Так что нет "специального кода для обезьян" — есть "обезьяний код".
Не надо общих фраз про любых. У меня есть кусок чисто математического кода, который совершенно прост, нет ни однй иерархии, ни одного даже виртуального метода. Чисто 5-мерные массивы туда-сюда, и операции все простейшие. Ясный, простой код на уровне как раз простого C. Хрен поймёт человек без ТЗ, сопровождающих док-файлов, и файлов матлаба. Профильное образование — обязательно. И дальше упростить некуда...
M>Можем, но только решения, проверенные практикой. Опять же, повторюсь: НЕТ столько головоломок, сколько немерлисты хотят решить своими макросами — и без немерли, и даже без жабы/сишарпа писались многомиллионные проекты НА ПРОСТОМ СИ — _тем_ танцорам язык не мешал. Почему? Потому что "эффективность — она в головах", а не синтаксисе.
Опять красочно, но что-то не вяжется с реальностью. Я помню проекты 10 летней давности. Редактор DSL-скрипта с подсветкой синтаксиса, автокомплитом и хелпом тогда был задачей на человеко-год и выделялся в отдельный проект. Сейчас это 3 недельки, параллельно с самим DSL и простеньким отладчиком. Эффективность — она скорее в голове * интструмент. Приблизительный пруф — рассмотрим пределы: голова 0, инструмент 100% — результат 0. Голова 100% инструмента нет вовсе — результат тот же 0.
M>Для этого есть "мозг проекта", но и тут выплывает ещё один плюс "средних решений" — они _понимаемы_всеми_ членами команды, т.е. имеем бенефит коллективного разума. Более того — "средние решения" легче модернизировать в силу их "незаумности".
Что такое средние решения? Как меняется со временем мощность среднего решения? Какой график зависимости экономической эффективность команды от выбранного среднего решения? Для .NET стоит ли выбирать за среднее C#1, C#2, 3 или 4?
M>Среди профи и бизнесменов — 100%.
Вот так, опять за всех и бескопромисно. Даже не 99.95? Жаль только Ericsson который выдумывал заумный Erlang явно от недостатка профи и бизнесменов в топ-менеджменте.
Кустари оперируют понятиями "а помните у нас ведущий уволился, и потом никто там ничё три месяца не понимал, а найти того кто бы понял мы не могли". А профи и бизнесмены — такими вещами как риски и оценки. Разработка $x, замена ключевых разработчиков $y, опоздание с выходом на рынок (вылет за дедлайн) $z, спрыгивание клиента из-за подковёрных интриг $t, и т.п. И это всё в табличку по технологиям.
Ты же старательно завышаешь одни риски, и понижаешь значимость других. И при этом совершенно серьёзно говоришь за 100% профи и бизнесменов.
Здравствуйте, Osaka, Вы писали:
___>>Очередной мля непризанный гений. Я таких нах увольняю. O>butthurt detected
Не следует выдавать желаемое за действительное.
>>Нафиг мне человек супер-пупер прогер, если на него нельзя положитЬся — он ломает все планы. O>Нафиг мне ножик, если на него нельзя положиться — он всё режет.
Аналогия ваще не в кассу. Чушь короче. Вобщем охарактеризовал ты себя отсутствием логики.
Здравствуйте, iyura, Вы писали:
I>ИМХО, речь идет о том, что программирования из высокотехнологического инженерного процесса пытаются превратить в ремесло
Ты чего то путаешь. Это как раз ремесло отличает сильная зависимость результата от таланта мастера.
Здравствуйте, gandjustas, Вы писали:
G>Рутина есть везде, вопрос только в относительном объеме рутины. В автоматизации бизнеса процент близок к 100, в какой-нить разработке компилятора — на порядок меньше.
Здравствуйте, Madruel, Вы писали:
M>2. O <= o (Иначе код С не так уж хорошо архитектурно продуман)
Далеко не всегда, чем больше лишнего кода/абстракций, тем больше тестов и отладки.
M>Откуда следует: M>3. O/C < o/c
M>Что противоречит следствию из исходного утверждения
Исходное допущение как бы среднее по палате, а ты лишь показал девиацию. Перечитай, исходное утверждение содержало лишь следующее:
O+C > o+c
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, March_rabbit, Вы писали:
M_>>1) Насколько полно и точно будет в памяти вся эта теория, когда она все же пригодится (если пригодится)? WH>Не важно.
M_>>2) (основываясь на вопросе 1)Есть ли смысл учить ее в универе, так "шоб на всю жись", если когда ты все же с ней столкнешься — у тебя будет возможность с нуля ее освоить? WH>Есть. Хотябы за тем чтобы когда понадобится вспомнить что они вообще есть, а не начать изобретать колесо.
Можешь с ходу сказать, сколько колец безопасности было в защищенном режиме процессора i486? И сколько их в i7 к примеру? И где задается кольцо текущего процесса? Или ты никогда не слышал о защищенном режиме работы процессора?
Здравствуйте, _d_m_, Вы писали:
___>Очередной мля непризанный гений. Я таких нах увольняю. Нафиг мне человек супер-пупер прогер, если на него нельзя положится — он ломает все планы. Толку от его гениальности — если он завалит проект по срокам, т.е. в итоге результат 0.
Так это не он завалил. Это ты завалил. Тебя и увольнять надо.
Здравствуйте, _d_m_, Вы писали:
___>Очередной мля непризанный гений. Я таких нах увольняю. Нафиг мне человек супер-пупер прогер, если на него нельзя положится — он ломает все планы. Толку от его гениальности — если он завалит проект по срокам, т.е. в итоге результат 0.
Что значит "положиться"?
Ты ему называешь сроки и он не выполняет?
Или ты спросил у него о сроках, он сказал и не выполнил в срок?
Недооценка постоянная? Если да, то почему ты её не учитываешь?
Если сроки называются исполнителями от фонаря, то почему не пытаешься в причинах разобраться? Может недостаток информации или слишком общее\слишком расплывчатое задание?
Я понимаю проблемы могут быть когда работа удаленная, но когда человек сидит рядом, в том же офисе, то всегда можно поговорить и выяснить причины.
Здравствуйте, gandjustas, Вы писали:
G>Я понимаю проблемы могут быть когда работа удаленная, но когда человек сидит рядом, в том же офисе, то всегда можно поговорить и выяснить причины.
А если удаленная, то "поговорить и выяснить причины" уже нельзя?
Здравствуйте, VladD2, Вы писали:
VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
Кстати, неплохая альтернативная расшифровка для MDD (model-driven development).
Здравствуйте, irium, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Я понимаю проблемы могут быть когда работа удаленная, но когда человек сидит рядом, в том же офисе, то всегда можно поговорить и выяснить причины.
I>А если удаленная, то "поговорить и выяснить причины" уже нельзя?
