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

M>>>Например формализованные схемы анализа функции. 25 вопросов на которые надо ответить для ответа на вопрос что дизайн класса не плохой (заметь не хороший а просто не плохой)

I>>Ага, так вот всё просто, ответил на 25 вопросов и получил мега-ответ

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

Время на эти 25 вопросв понадобится примерно на порядок больше, чем профессионалу а ответы у новичка скорее всего будут еще и неправильные.

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

G>Что значит выучить ассемблер? Запомнить все команды cpu\fpu\mmx\sse? А может еще запомнить характеристики количества микроопераций для них всех?
G>Гораздо лучше знать про архитектуру процессора, кеши, понимать что такое SIMD и зачем оно нужно, понимать что такое арифхетика с переполнением и с насыщением, знать как осуществляется работа с переферией.

Ассемблер это язык такой. Атомарными операциями делаются всякие чудеса.

Без знания ассемблера ты просто не сможешь пощупать кеш, вряд ли поймешь что такое SIMD, а про арифметику с переполнением можешь просто забыть.

До периферии просто не доберёшься, потому что здесь как правило надо многие вещи уметь на раз, иначе из ошибки в пол-бита периферия откажется с тобой контактировать.

G>>>Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.
I>>Знание ассемблера дает возможность понять как на самом деле работает процессор тот же.
G>С чего бы? Изучив справочник команд придет понимание? Вряд-ли.

Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.

I>>У тебя был плохой преподаватель
G>У меня его вообще не было.

Ну да, самообучение оно как и самолечение, пробуют все, выживают единицы.

I>>Для этого и нужен ассемблер, только незачем учить все ассемблеры существующие в природе.
G>Не нужен, см выше.
G>Еще раз: знание ассемблера под x86 мне не разу не помогло эффективно использовать ассемблер для другого процессора.

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

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

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

G>>Что значит выучить ассемблер? Запомнить все команды cpu\fpu\mmx\sse? А может еще запомнить характеристики количества микроопераций для них всех?
G>>Гораздо лучше знать про архитектуру процессора, кеши, понимать что такое SIMD и зачем оно нужно, понимать что такое арифхетика с переполнением и с насыщением, знать как осуществляется работа с переферией.

I>Ассемблер это язык такой. Атомарными операциями делаются всякие чудеса.
Глубокая мысль прямол скажем.

I>Без знания ассемблера ты просто не сможешь пощупать кеш, вряд ли поймешь что такое SIMD, а про арифметику с переполнением можешь просто забыть.
С чего бы? я многократно рассказывал людям про архитектуру процессоров без упоминания ассемблерных команд.

G>>>>Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.
I>>>Знание ассемблера дает возможность понять как на самом деле работает процессор тот же.
G>>С чего бы? Изучив справочник команд придет понимание? Вряд-ли.

I>Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.
Ты выше написал что ассемблер — это язык. Язык определяется синтаксисом и семантикой. И то и другое можжно в справочнике команд найти.

I>>>Для этого и нужен ассемблер, только незачем учить все ассемблеры существующие в природе.
G>>Не нужен, см выше.
G>>Еще раз: знание ассемблера под x86 мне не разу не помогло эффективно использовать ассемблер для другого процессора.

I>Тебя испугал сигнальный микропросцессор что ли ?
Ничем не испугал. Просто мои знания ассеблера x86 как языка (со всеми сопуствующими паттернами, архиетктурой) оказались бесполезными.

I>Но сильно думаю, это потому что ассеблера ты и не знал вобщем то.
Да придумывать недостатки оппоненту — это круто.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

"Не всегда хуже" это неинтересно. А "лучше" бывает?

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

НС>>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

M>"Не всегда хуже" это неинтересно. А "лучше" бывает?

Бывает. Все зависит от абсолютной величины константы и величины n.

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

I>>Без знания ассемблера ты просто не сможешь пощупать кеш, вряд ли поймешь что такое SIMD, а про арифметику с переполнением можешь просто забыть.
G>С чего бы? я многократно рассказывал людям про архитектуру процессоров без упоминания ассемблерных команд.

Я выделил глаголы. Предположим, люди тебя слушали раз ты им рассказывал.

Это по твоему то же самое что и пощупать ?

I>>Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.
G>Ты выше написал что ассемблер — это язык. Язык определяется синтаксисом и семантикой. И то и другое можжно в справочнике команд найти.

Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.

;/*
ideal
p286n
model small,C
dataseg
extrn VideoSeg:word
extrn ScrWidth:byte
extrn ScrDoubleWidth:word
extrn CurVidPage:word
codeseg

extrn vidoffset:near

public wintobuffer
proc wintobuffer

ARG @@sx:byte,@@sy:byte,\
@@ex:byte,@@ey:byte,\
@@buf:dataptr

USES si,di,ds

mov dh,[@@sy]
mov dl,[@@sx]
call vidoffset
mov bx,di
mov si,di
xor cx,cx
mov cl,[@@ey]
sub cl,dh
inc cx
mov dh,cl
mov cl,[@@ex]
sub cl,dl
inc cx
mov dl,cl
mov di,[@@buf]
mov [di],dx
inc di
inc di
mov ax,ds
mov es,ax
mov ds,[VideoSeg]
cld

@@nx:
rep movsw
add bx,[es:ScrDoubleWidth]
mov si,bx
mov cl,dl
dec dh
jnz @@nx

ret
endp wintobuffer

end
;*/


Из примера выш функцию можно вызвать вот так

call wintobuffer sx,sy,ex,ey,buf

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

I>>Тебя испугал сигнальный микропросцессор что ли ?
G>Ничем не испугал. Просто мои знания ассеблера x86 как языка (со всеми сопуствующими паттернами, архиетктурой) оказались бесполезными.

архитектура будет бесполезна, это так. Разумеется, все наработки придётся оставить, особенно библиотечки всякие.
Прикинь, при переходе с java на C# или наоборот все точно так же !
Зато опыт, разумеется, никуда девать не надо. Время на адаптацию и вперёд.

I>>Но сильно думаю, это потому что ассеблера ты и не знал вобщем то.
G>Да придумывать недостатки оппоненту — это круто.

Я не придумал, ты свел ассемблер к системе комманд процессора. О чем говорить ?

Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?

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

H>Здравствуйте, Mr.Cat, Вы писали:

MC>>Не объяснишь, как знание математики кореллирует с ведением собственного бизнеса (ака "не работать на дядечку")?

H>Когда чел не креативен и у него нет фундаментальных знаний ИТ (и в их числе математика), то он может лепить только формочки, а это значит, что он будет всю жизнь работать делая рутину в самой низкой иерархии программистов. А возможно даже откроет, когда нибудь собственную быдло конторку по лепки формочек, если его интересуют ТОЛЬКО деньги, а программирование для него ТОЛЬКО способ их срубить с других (с заказчиков), то всё хорошо. Но это уже не тру программист.

H>Когда чел креативен и у него есть фундаметальные знания и практический опыт, то он сможет продвинутся по иерархии ИТ в качестве специалиста и будет очень ценен. В будущем сможет возглавить действительно КАЧЕСТВЕННЫЙ И ИНТЕРЕСНЫЙ проект.

так вот вы куда клоните ... вас интересуют не ТОЛЬКО деньги , а еще и продвижение по службе

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

I>для этих пунктов не надо читать Совершенный код.

I>Я недавно с одним новичков имел как раз такую беседу, он написал метод удаления из дерева длинной ажно в 200 строк два часа долбили её, что бы упростить и уменьшить.

I>п. 1. Я не единожды объяснял и показывал, но читабельность он понимает не так как я.
I>Ему хорошо читать — он считает это хорошей читабельностью.
I>Что бы научить этой читабельности, нужно заставить человека читать этот самый код. И одного-двух прмеров или объяснений тут недостаточно.
I>Мне повезло, что его метод был слишком большой. Через неделю он забыл что и как там происходит и сразу вылезла путаница.

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

I>п. 2 Рефакторинг сложных циклов. Что значт сложный цикл ? Для кого сложный ?
I>Студент пишет сложную логику там где она совершенно не нужна. Обычно это значит, что он пишет так — придумал кусочек, написал. попробовал, не работает, придумал, еще написал.
I>Сразу продумать целиком весь вариант он еще не умеет, это даётся годами тренировок — написание, отладка, переделка своего и чужого кода.
I>Книжкой это заменить нельзя. Мозг устроен вобщем то прмерно как и мышцы(аналогия конечно) — тренировки помноженные на время дают эффект (более подробно про это в теори ВПФ). Время можно уменьшить за счет увеличения интесивности тренировок, правильной нагрузки и правильного отдыха.
I>И обязательно нужен разбор полетов. Точно так же и с мышцами — что бы выполнить сед, нужно хорошо прокачать тягу, иначе во время седа спина будет проседать. Для мозгов нужно найти якорь который мешает понять или продвинуться дальше. Это только у ИТ и ВладД2 все просто другим надо работать что бы подняться на следущий уровень Простоты.

I>п.3 здесь тоже самое что и с п.2. все ветвления и циклы студент понимает как кусочки if else и тд.( Hence the expression — императивный программист.) Опытный девлопер цикл со всеми потрохами видит одной сущностью/явлением.
I>И книжкой это опять же не исправить, масштаб мышления это результат усилий помноженных на время помноженных на понижающий коэффициэнт якоря(ей).

I>п.4. Похоже на п.1, но немного другое. Вот на примере — что такое rdel и ldel ? Сначала это были узлы — rdel значит узел для удаления, который был справа у узла предка, а ldel — слева. Потом в ходе написания кода rdel и ldel стали указывать на поддеревья а не узлы для удаления. Вроде бы тоже самое но чел привык к названиям и они стали для него нормой.
I>И книгами здесь не лечится — спустя неделю я просто попросил объяснть программу (разбор полётв) и как раз выяснилось, что чел ничего в ней не понимает и путается в rdel и ldel. Переименовали все что могли и сразу половина текста в 200 строк стала понятной даже мне

I>п.6 — про классы еще ничего нет, зато есть набор методов, у которых в параметрах может быть черт знает что.
I>Уже на этом уровне случается хаос, который не передать словами — нужно учить как правильно объявлять методы.
I>А это значт, сначала нужно научить как правильно выполнить композицию/декомпозицию — и опять это практика/практика/практика + разборы полётов.
I>в коде например может быть трижды встречаться мега-цикл и новичек не догадается выбросить его за пределы метода или в коде ему окажется очень удобно выводить строчки на экран прямо в методе для удаления.

I>Мега-авторы мега книг пишут так — вот в в методе есть сущность_а и сущность_б — раз эни разные, то логично и разделить на части.
I>Опаньки — сразу скормил новичку готовое решение, "сэкономив" время обучения.
I>+на возможные возражения пишется такое "допустим надо сделать а, б, в и г, что дальше ?" Опаньки — и тут скармиливается готовое решения — автор указывает, что метод с двумя сущностями создаст проблемы.

I>"допустим надо сделать а, б, в и г" — это условие только кажется простым. Рально от человека требуется смоделировать в уме целую систему, поместить в нее метод, который он написать и применить его к ситуациям а, б,в и г. Это как раз то мышление,что в школе практически не прокачивается.

I>Студента нужно этому учить — увидел, что в коде мешанина, нужно предложить доработать программу для случаев а,б, в и г. Пусть работает а за копипейст поставить двойку.

I>Вот студенческий код (1 курс второй семестр последняя лабораторная) — код этот взялся не потому, что студент книгку не может осилить, а потому что еще навыки не прокачаны.

I>Вот например про g_pRoot интересный момент — чел сунул нос в венгерскую нотацию, но до конца не понял что такое глобальные переменные.
I>Или про параметны — сразу видно, книжкой это не лечится, чел в упор не видел что первый параметр не используется и из за этого чуть не поругались.

I>Но вообще программа работает на уровне "показать преподавателю". На потоке только пару человек осилили эту лабу(деревья).

Вообщем нужно И читать И практиковать. Но всё же перед тем как усиленно практиковать (то есть будучи имея небольшую практику) я думаю, что нужно всё таки внимать в то, что пишут.

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

M_>вот уж 9-ый год программлю. За это время первые три года использовал какие-то математические выкладки вроде временной сложности алгоритма поиска или сортировки. Реально нужно было. А вот последние годы просто не сталкиваюсь с подобными задачами. Бывает такое: есть некая процедура (не в смысле процедуры языка, а последовательность определенных действий и реакций). Хочется ее оптимизировать. А потом смотришь — эта процедура будет работать может раз за сутки, или реже. И зачем тратить время на оптимизацию тогда? Уж лучше сделать проще и понятнее для того, кто будет продолжать работу.

M_>Сам любитель оптимизаций, но вот...

Ну так после 9 лет программирования вполне правомерно, чем то пренебрегать, а чем то нет. Но нам новичкам и Вам когда-то всё же ОЧЕНЬ полезно вникать в теорию. Кстати это такой парадокс, человек который когда-то этому учился, потом может сказать что это ему не пригодилось и что практика всё заменила, но спроси его раньше на пару лет, он скажет, что без теории никуда. Без теории он был не стал таким каким есть сейчас.

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

I>>Но вообще программа работает на уровне "показать преподавателю". На потоке только пару человек осилили эту лабу(деревья).

H>Вообщем нужно И читать И практиковать. Но всё же перед тем как усиленно практиковать (то есть будучи имея небольшую практику) я думаю, что нужно всё таки внимать в то, что пишут.

Совершенный код нужно освоить преподавателю. Вот это я считаю обязательно

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

H>Здравствуйте.

H>Заметил, что большинство ИТ-специалистов и программистов с которыми я общался считают, что математика (в частности дискретная математика, которая играет большую роль в теории алгоритмов), теория алгоритмов (в частности асимптотический анализ, конечные автоматы, классы сложности) вообще не нужны современному программисту.

H>Для меня это звучит дико, поскольку считаю, что без глубокого понимания теории невозможно писать качественное ПО, с поддержкой масштабирования, с адекватной производительностью и т.д., если только не идёт речь пожизненном написании быдло-сайтиков или криворукого билинга для какой нибудь шаражки.

H>Нужно ли понимание общих теоретических концепций для тру программирования?

Для умения отличать n^2 от яичницы и базовых алгоритмов вполне достаточно какой-нибудь тонюсенькой книжки типа "Алгоритмы и структуры данных" Вирта. Никому никуда не упало уметь отличать о-большое от омега-малое и нафиг не сдалось знание о недетерминированной машине Тюринга.
Знание же прочего нужно скорее на уровне "оглавления", есло вообще нужно — дескать ну да, бывают графы, бывают грамматики. А необходимость знания каких-либо конкретных алгоритмов на графах, к примеру, встречается, наверное, не чаще чем необходимость знания численного метода Левенберга-Марквардта. Однако его же вы с программистов не требуете?
Вот внезапно понадобится написать парсер, скажете вы, что тогда делать? Да банально писать в гугле "how to write a parser" и уже оттуда выходить на всю теорию. Естественно, есть области где надо знать все гораздо глубже, но в этом случае это просто отдельная узкая специализация типа криптографии или оптимизации запросов на конкретной СУБД — нет никакой необходимости знать это каждому.

Есть, наверное, какой-то перечень фундаментальных знаний, которыми желательно владеть каждому программисту, но туда точно не входят конечные автоматы и умение писать компиляторы)

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

M_>1) именно в этом месте тормозит?
M_>2) сколько процентов времени проводит программа в этом месте?
M_>... ну и прочее.

Θ(n^2) убъёт машину по сравнению с Θ(n), при больших n. Мощности машины можно наращивать, но парабола рано или поздно сведёт на нет вычислительную мощь.

Это в общем случае.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, mymuss, Вы писали:

НС>>>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

M>>"Не всегда хуже" это неинтересно. А "лучше" бывает?

НС>Бывает. Все зависит от абсолютной величины константы и величины n.

Вы уверены, что понимаете, что такое О-большое? При переходе к асимптотике константы теряются. Говорить об O(...) и приплетать сюда константу бессмысленно.

Можно говорить о том, что квадратичная ф-ция f(n) лучше чем линейная g(n) на малых n за счет большой ординаты, но как только перешли к О, все члены низших порядков автоматически потерялись. Поэтому фраза "O(f(n)) лучше чем O(g(n)) за счет константы" это нонсенс.

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

C>так вот вы куда клоните ... вас интересуют не ТОЛЬКО деньги , а еще и продвижение по службе

Надо стремится заниматься интересными вещами, но при этом ещё и получать деньги

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

M>>Тормозит сильно.
M_>)
M_>1) именно в этом месте тормозит?
M_>2) сколько процентов времени проводит программа в этом месте?
M_>... ну и прочее.

1) Вся программа один большой цикл, в котором перебирается много-много записей. (Ну не считая в самом конце крохотной ф-ции, которая генерирует XML/HTML с отчетом)
Нах, спрашивается, вкладывать в него еще один цикл, который в худшем случае будет перебирать то же самое кол-во элементов? Я не уверен, что мне удалось аффтару проги объяснить разницу, точнее я почти уверен, что он продолжает думать что там как было 2*n, так и осталось.

2) Не знаю, 99.999% наверное.

На 200 млн записей разница очень заметна.

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

M>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>Здравствуйте, mymuss, Вы писали:

НС>>>>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

M>>>"Не всегда хуже" это неинтересно. А "лучше" бывает?

НС>>Бывает. Все зависит от абсолютной величины константы и величины n.

M>Вы уверены, что понимаете, что такое О-большое? При переходе к асимптотике константы теряются. Говорить об O(...) и приплетать сюда константу бессмысленно.

M>Можно говорить о том, что квадратичная ф-ция f(n) лучше чем линейная g(n) на малых n за счет большой ординаты, но как только перешли к О, все члены низших порядков автоматически потерялись. Поэтому фраза "O(f(n)) лучше чем O(g(n)) за счет константы" это нонсенс.

Вы всегда с бесконечными n работаете?
Открываем, к примеру, сорцы явы (метод Arrays.sort):

    if (len < 7) {
    //Ба! Так это же сортировка вставкой, энквадрат в чистом виде! Ай-яй-яй!
        for (int i=off; i<len+off; i++)
        for (int j=i; j>off && x[j-1]>x[j]; j--)
            swap(x, j, j-1);
        return;
    }

    // Пошел quicksort
    // Choose a partition element, v
        ...

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

На самом деле O(x) это всего лишь верхняя оценка, поэтому она мало о чём может говорить (ранее использовал обозначение O, так как в лом было искать символ теты). Лучше использовать тету — Θ(x). Это уже не просто потолок, а коридор порядка роста ограниченный двумя константами.

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

НС>>Бывает. Все зависит от абсолютной величины константы и величины n.

M>Вы уверены, что понимаете, что такое О-большое?

Уверен.

M> При переходе к асимптотике

Ну значит стадию перехода от асимптотики к реальному коду ты еще не прошел. Если что, на личности перешел ты первый.

M> константы теряются. Говорить об O(...) и приплетать сюда константу бессмысленно.

Конечно. Но это если говорить об O(...). А если говорить о реальной производительности и масштабируемости, и потом приплетать O(...), то все уже не так вакуумносферично.

M>Можно говорить о том, что квадратичная ф-ция f(n) лучше чем линейная g(n)

Нельзя, пока не определен критерий лучшести.

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

K>Для умения отличать n^2 от яичницы и базовых алгоритмов вполне достаточно какой-нибудь тонюсенькой книжки типа "Алгоритмы и структуры данных" Вирта. Никому никуда не упало уметь отличать о-большое от омега-малое и нафиг не сдалось знание о недетерминированной машине Тюринга.
K>Знание же прочего нужно скорее на уровне "оглавления", есло вообще нужно — дескать ну да, бывают графы, бывают грамматики. А необходимость знания каких-либо конкретных алгоритмов на графах, к примеру, встречается, наверное, не чаще чем необходимость знания численного метода Левенберга-Марквардта. Однако его же вы с программистов не требуете?

То, что тебе лично это не понадобилось, мало что означает. Если конечно ты себя не считаешь эталоном хорошего программиста.

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

k> Вы всегда с бесконечными n работаете?
k> Открываем, к примеру, сорцы явы (метод Arrays.sort):

Напомнило байку про кошку и привязанную к ее хвосту консервную банку