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

S>для них действительно не нужна- им поэтому и светит всю жизнь работать на дядечку и делать однотипные задачи.

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

RO>И в формочках можно ухитриться применить алгоритм Шлемиэля. Например, при реализации какого-нибудь перетаскивания элементов.

Только поддерживать и модифировать этот код потом нормальным людям как?

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

M>>>Не согласен , и новичкам Мега пгипер полезна и опытным лишней не будет

I>>Что же там гипер-полезного, покажешь на примере ?

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

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

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

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

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

Вот после этого уже можно смотреть в книгу и читать там умные слова или, например, сравнивать решение с тем, что в книге. Только загвоздка в том, что это задача уровня профессионала. Хорошо, если студент продумает одно решение до конца, про остальное и говорить не приходится.

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

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

H>ИМХО: если человек знаком с основами дискретной математики (на самом деле любой математики), то его программы будут качественней, чем у человека который вообще не знаком с математикой.

Не обязательно. Способности к математике и способности к программированию вещи совершенно разные, и человек с хорошими математическими способностями может быть очень паршивым программистом, несмотря на отличное знание дискретки.

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

G>А попробуйте свои знания ассемблера применить для программирования вычислений на шейдерах.

Я применял, в чем проблемы

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

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

G>>Всех будущих пилотов F1 обязавтельно на пару месяцев пересадить за руль запорожца
I>Ассемблер тебе все равно придется выучить. Правда уровень ассемблера тоже растет со временем, как и уровень промышленных языков.

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

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


G>>Мне как-то раз мое знание ассемблера стало боком. Я пытался на ассемблере писать для DSP процессора. Даже близкого к оптимальному коду там не получилось. И только через несколько месяцев писания на C и ковыряния получившегося ассемблерного кода я смог обогнать код, который генерит компилятор.
I>У тебя был плохой преподаватель
У меня его вообще не было.

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

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

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

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

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

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

L>Нет, из этого не следует тот вывод, который вы сделали.

Почему не следует?

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

I>Это книга как раз такая, что новичкам еще без толку, а профессионалам уже без толку.

Не согласен, так как будучи новичком прочитав _отдельные_ главы этой книги стал намного лучше писать. Там вводятся такие понятия как:

1) правильно оформлять код, чтобы был читабельным
2) делать рефакторинг сложных циклов, чтобы они легко читались тебе и были легко прочитаны другими
3) делать рефакторинг сложных if конструкций, чтобы они легко читались тебе и были легко прочитаны другими
4) делать читабельные имена переменных и функций
5) правильно группировать части кода, например, временную переменную вводить рядом с циклом, где она используется
6) писать самодостаточный интерфейс классов

В книге "Совершенный код" всё это излагается на пальцах для новичков!!!

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

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

RO>>И в формочках можно ухитриться применить алгоритм Шлемиэля. Например, при реализации какого-нибудь перетаскивания элементов.

Y>Только поддерживать и модифировать этот код потом нормальным людям как?

http://www.joelonsoftware.com/articles/fog0000000319.html

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

G>Всех будущих пилотов F1 обязавтельно на пару месяцев пересадить за руль запорожца

Ты меня не совсем верно понял. Всех будущих пилотов F1 обязательно на пару месяцев заставить ездить БЕЗ автоматической системы корректировки на F1 (у лучшие гонщики любяит управлять машиной своими руками, хотя когда надо включают автоматическое управление F1).

G>Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.
G>Мне как-то раз мое знание ассемблера стало боком. Я пытался на ассемблере писать для DSP процессора. Даже близкого к оптимальному коду там не получилось. И только через несколько месяцев писания на C и ковыряния получившегося ассемблерного кода я смог обогнать код, который генерит компилятор.
G>А попробуйте свои знания ассемблера применить для программирования вычислений на шейдерах.
G>К чему это все... К тому что лучше вместо знания конкретных ассемблеров понимать общие принципы работы процессоров (разных процессоров с разной архитектурой).

Знание ассемблера, точнее даже не знание ассемблера, а его понимание, понимание принципов и основ ОЧЕНЬ помогает. Более того иногда очень полезно (особенно на стадии изучения C) понимать и видеть как компилятор языка C генерирует некоторые конструкции на ассемблере. Например, в некоторых особенно сложных задачках из http://www.gowrikumar.com/c/ просмотр сгенерированного компилятором С ассемблерного кода открывает в тебе более глубокое понимание языка.

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

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

G>>Всех будущих пилотов F1 обязавтельно на пару месяцев пересадить за руль запорожца

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

Какое еще автоматическое управление на F1

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

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

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

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

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

НС>Видишь ли какое дело. Математика, она разная бывает. То, что называют дискретной, прикладной математикой, computer science — оно, безусловно, очень нужно, если не индусякод плодить.
НС>Но, справедливости ради, математика эта весьма специфична и довольно далеко отстоит от математики классической.

+1 Да, я и не говорю быть супер продвинутым математиком, но чтение Кнута и аналогичных ему трудов даёт очень хорошие прикладные (_именно в ИТ_) математические знания.

Когда я начал изучать математику исключительно для ИТ, то в скоре я понял, что математика при должном понимании едина. Можно понять основные положения математического анализа и как это не странно становится легче понять дискретную математику, верно и обратное, и вообще для любой области в математики. Математика даёт образ мышления, который при должном прикладном подходе даёт мощный толчок в понимании комбинаторных алгоритмов, деревьев и оценки производительности алгоритма.

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

Тут кто-то в этой ветке не понял, почему хуже n^2 переборов, чем n. Ёлки палки, когда буду руководителем на собеседовании этот вопрос первым буду задавать. Если чел не может параболу от прямой отличить, то это АХТУНГ!!!

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

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

A>>Для тех, кто формочки клепает — не нужна.

RO>И в формочках можно ухитриться применить алгоритм Шлемиэля. Например, при реализации какого-нибудь перетаскивания элементов.

Ну вот — стало быть и им нужна

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

___>Какое еще автоматическое управление на F1

http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D0%BF%D1%80%D0%BE%D0%B1%D1%83%D0%BA%D1%81%D0%BE%D0%B2%D0%BE%D1%87%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0

На счёт формулы 1 ошибся, так как "Позднее стала широко применяться в обычных серийных машинах, а в 2008 году была запрещена в Формуле-1.", но суть не меняется. Например, в одном из многочисленных выпусков Top Gear ведущий сначала обсирал машину, как он обычно любит это делать, а потом отключил подобную систему (я не специалист, но насколько знаю, там несколько видов автоматического управления) и показал настоящие возможности машины. Вообщем поищи Top Gear в youtube.

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

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

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

H>Из этого утверждения следует, что следующие труды (несмотря на то, что это бестселлеры и написаны ИТ-гуру) абсолютно бесполезны для программистов и утверждения авторов этих трудов о том, что данные знания нужны для всех кто серьёзно изучает информатику, неправильны:

H>Серия книг Д.Э. Кнута "Исскуство программирования" и отдельный труд посвящённый математическому введению "Конкретная математика;
H>Алгоритмы: построение и анализ. Томас Х. Кормен, Чарльз И. Лейзерсон, Рональд Л. Ривест, Клиффорд Штайн;
H>Введение в теорию автоматов, языков и вычислений. Джон Хопкрофт, Раджив Мотвани, Джеффри Ульман;

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

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

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

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

M>>>Млин, как же меня достали программисты, не понимающие почему перебирать n^2 элементов массива хуже чем n.
MC>>Действительно, а почему?

M>Тормозит сильно.

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

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

H>Тут кто-то в этой ветке не понял, почему хуже n^2 переборов, чем n.

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

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

I>>Это книга как раз такая, что новичкам еще без толку, а профессионалам уже без толку.

H>Не согласен, так как будучи новичком прочитав _отдельные_ главы этой книги стал намного лучше писать. Там вводятся такие понятия как:

H>1) правильно оформлять код, чтобы был читабельным
H>2) делать рефакторинг сложных циклов, чтобы они легко читались тебе и были легко прочитаны другими
H>3) делать рефакторинг сложных if конструкций, чтобы они легко читались тебе и были легко прочитаны другими
H>4) делать читабельные имена переменных и функций
H>5) правильно группировать части кода, например, временную переменную вводить рядом с циклом, где она используется
H>6) писать самодостаточный интерфейс классов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...
g_pRoot = DeleteInfo(find_tree,input);
...


MyTree* DeleteInfo(MyData Info,int i_info)
{
 MyTree* del;
 MyTree* ancestor_del=NULL;
 MyTree* rdel;
 MyTree* ldel;
 MyTree* place;
 bool yes_to_go = true;
 bool yes;

 del =g_pRoot;
 ancestor_del = NULL;

 //поиск удаляемого элемента
 while (del != NULL && del -> Info.key != i_info)
 {
  ancestor_del = del;

  if (del->Info.key > i_info)
  {
   del = del->left;
  }

  else
  {
   del = del->right;
  }
 }

 if (del == NULL)
  {
   ShowMessage ( "Element does not exist!");
   return g_pRoot;
  }

 rdel = del->right;
 ldel = del->left;

//ниодного листа

 if((ldel == NULL) && (rdel == NULL))
 {
     //если захотели удалить вершину
     if(del == g_pRoot)
     {
      ShowMessage("MyTree root is deleted!");
      Form1->Memo1->Clear();
      delete g_pRoot;
      return NULL;
     }

     if((ancestor_del->right) == (del))
     {
      ancestor_del->right = NULL;
     }

     else
     {
       ancestor_del->left = NULL;
     }
    yes_to_go = false;
 }

 //только правый или левый
 else
 {

 //левый
   if(rdel == NULL)
   {   //если захотели удалить вершину
       if(del->Info.key == g_pRoot->Info.key)
       {
        ShowMessage("MyTree old root is deleted!\n Here is a new one!");
        g_pRoot = ldel;
        Form1->Memo1->Clear();
        ReviewMyTree(g_pRoot,0);
        Form1->Memo1->Lines->Add("-=Новая вершина=-!");
        return g_pRoot;
       }

       if(rdel == NULL && (ancestor_del->Info.key > del->Info.key))
       {
        ancestor_del->left = ldel;
       }

       else
       {
        ancestor_del->right = ldel;
       }

    yes_to_go = false;
   }

 //правый
   if(ldel == NULL)
   {   //если захлтели удалить вершину
       if(del->Info.key == g_pRoot->Info.key)
       {
        ShowMessage("MyTree old root is deleted!\n Here is a new one!");
        g_pRoot = rdel;
        Form1->Memo1->Clear();
        ReviewMyTree(g_pRoot,0);
        Form1->Memo1->Lines->Add("-=Новая вершина=-!");
        return g_pRoot;
       }

       if(ldel == NULL && (ancestor_del->Info.key > del->Info.key))
       {
        ancestor_del->left = rdel;
       }

       else
       {
        ancestor_del->right = rdel;
       }
      yes_to_go = false;
   }

 }

 //левый и правый
 if(yes_to_go)
 {
   //если зазхотели удалить вершину
   if(del->Info.key == g_pRoot->Info.key)
   {
    ShowMessage("MyTree old root is deleted!\n Here is a new one!");
    g_pRoot = rdel;

    if(rdel->left == NULL)
    {
     rdel->left = ldel;
    }

    else
    {
     place = rdel->left;
     while(place->left != NULL)
     {
      place = place->left;
     }
     place->left = ldel;
    }

    Form1->Memo1->Clear();
    ReviewMyTree(g_pRoot,0);
    Form1->Memo1->Lines->Add("-=Новая вершина=-!");
    return g_pRoot;
   }

  if(ancestor_del->Info.key > del->Info.key)
  {
   ancestor_del->left = rdel;
   place = rdel;

   //ищем самый левый в правом поддереве удаляемого элемента
   if(place->left == NULL)
   {
    rdel->left = ldel;
   }

   else
   {
    place = rdel->left;
    while(place->left != NULL)
    {
     place = place->left;
    }
    place->left = ldel;
   }

  }
  //если предок меньше,чем удаляемый
  else
  {
   ancestor_del->right = rdel;
   place = rdel;

   //ищем самый левый в правом поддереве удаляемого элемента
   if(place->left == NULL)
   {
    rdel->left = ldel;
   }
   else
   {
    place = rdel->left;
    while(place->left != NULL)
    {
     place = place->left;
    }
    place->left = ldel;
   }

  }

 }
  delete del;
  return g_pRoot;
}