Oberon space
General Category => Общий раздел => Тема начата: valexey от Февраль 07, 2012, 04:17:42 pm
-
Внезапно на oberoncore появилось ценное свидетельство того, что ни долгие годы самодисциплины, ни мощная идеалогическая основа не спасают от глупых ошибок в циклах: http://forum.oberoncore.ru/viewtopic.php?f=2&t=3824
На обсуждение указанного тормоза, который в линухах вообще не работает, наложилось утреннее зависание ББ (забыл INC в наскоро слепленном цикле) с последующем выискиванием и удалением нескольких временных файлов.
То есть самый общий цикл -- WHILE (и его конструкты вроде цикла Дейкстры) явно и очевидно недостаточен для качественного написания софта. В языке (либо в библиотеке, если язык позволяет это сделать) нужны более частные, узкозаточенные, конструкции которые не позволяют зевающему программисту натворить глупых ошибок. В том числе конструкции не тьюринг-полные. Ну, например тот же foreach (который обычно вшивают в язык императивный), или fold/map (которые обычно в функциональных языка и в виде либы).
Кстати, даже банальный сишный for обычно более багозащищен нежели while. Потому как мгновенно вырабатывается паттерн: for (int i=0; i<len; ++i) и погнали. Это на уровне рефлексов без задействования думалки вообще. Ибо все в одной строчке. А уж про Адский for я вообще молчу - там ошибиться еще сложнее.
Я за последние полгода сам пару раз напарывался на зевок в виде забытого инкремента в while (забывал либо я либо один из коллег). И ни разу этого не было в for. Про foreach я и не говорю даже.
-
Ну, так не даром его Вирт вернул в Оберон-2
-
Ну, так не даром его Вирт вернул в Оберон-2
Я думаю что не Вирт вернул, а скорее всего товарисч Hanspeter Mssenbck. А вот в Oberon-07 уже да, вернул именно Вирт.
-
На соседнем форуме вроде было обсуждение, про расширенные возможности FOR'а
-
На соседнем форуме вроде было обсуждение, про расширенные возможности FOR'а
Гм. В смысле, расширенные?
-
Ну, например тот же foreach (который обычно вшивают в язык императивный), или fold/map (которые обычно в функциональных языка и в виде либы).
Ну, нужен foreach/map, а кто с этим спорит?
Вот сишная конструкция for - редкостное дерьмо. Хотя хорошо работает как костыль.
-
Ну, например тот же foreach (который обычно вшивают в язык императивный), или fold/map (которые обычно в функциональных языка и в виде либы).
Ну, нужен foreach/map, а кто с этим спорит?
Вот сишная конструкция for - редкостное дерьмо. Хотя хорошо работает как костыль.
Ну, оно мгновенно становится дерьмом как только человек прочитает спеку на язык и поймет чего туда можно, на самом деле насувать :-)
-
Ну, так не даром его Вирт вернул в Оберон-2
Я думаю что не Вирт вернул, а скорее всего товарисч Hanspeter Mssenbck. А вот в Oberon-07 уже да, вернул именно Вирт.
А х. толку - for полезен когда известно количество повторений тела цикла, а безопасным он становится, когда заголовок вычисляется ОДИН раз. В Обероне FOR (как я понял) всего лишь надстройка над WHILE
-
Раз в год можно не только INC забыть, но и множество других вещей сделать по усталости. И компилятор съест. Проблема высосана из пальца. Вдобавок, если не руками цикл набирать, то вставленный шаблон может уже содержать INC(XXX), где нужно лишь XXX заменить или удалить всю строку.
-
Раз в год можно не только INC забыть, но и множество других вещей сделать по усталости. И компилятор съест. Проблема высосана из пальца. Вдобавок, если не руками цикл набирать, то вставленный шаблон может уже содержать INC(XXX), где нужно лишь XXX заменить или удалить всю строку.
То же самое можно сказать вообще про всю проблему циклов с такой любовью обсасываемую на оборонкоре :) Включая неприкосновенный цикл Дейкстры. Нет у нормальных людей проблем с циклами, даже если там break стоит. Точнее этих проблем не больше, чем "забытых INC" у адептов идеи всезначимости "правильного" построения.
-
Это точно, "нормальные" люди считают, что у них нет проблем. Иногда, правда, приходится напрячься, ну так можно написать вот такую херню, как эта от микрософтовцев http://forum.oberoncore.ru/viewtopic.php?p=53637#p53637 . Но считать это проблемой просто смешно. Есть вещи поважнее.
А вот интересно, как нормальный человек решит такую задачу: массив заполнен целыми числами от 1 до 3. Нужно отсортировать его по возрастанию.
Точнее, я знаю, как решит нормальный - применит какой-нибудь универсальную сортировку и даже не поморщится.
Но ведь задача-то простая, неужели нельзя самому решить?
Попробуйте, обращаюсь конкретно к vlad'у и всем заинтересованным лицам, и напишите комментарии. Честно говоря, у меня мозги забиты, и я вообще не представляю, как пойдет процесс.
-
Это точно, "нормальные" люди считают, что у них нет проблем. Иногда, правда, приходится напрячься, ну так можно написать вот такую херню, как эта от микрософтовцев http://forum.oberoncore.ru/viewtopic.php?p=53637#p53637 . Но считать это проблемой просто смешно.
Конкретно это херня "ненормальная". Хотя там и есть break :) Хотя бывает и хуже :) Это если интересно мое личное мнение.
Есть вещи поважнее.
А вот интересно, как нормальный человек решит такую задачу: массив заполнен целыми числами от 1 до 3. Нужно отсортировать его по возрастанию.
Точнее, я знаю, как решит нормальный - применит какой-нибудь универсальную сортировку и даже не поморщится.
Но ведь задача-то простая, неужели нельзя самому решить?
Попробуйте, обращаюсь конкретно к vlad'у и всем заинтересованным лицам, и напишите комментарии. Честно говоря, у меня мозги забиты, и я вообще не представляю, как пойдет процесс.
Конкретно я - да, применю стандартную сортировку. Да, я понимаю, что можно заложиться на особенность диапазона и круто соптимизить. Но нах. Сопровождение важнее.
-
А вот интересно, как нормальный человек решит такую задачу: массив заполнен целыми числами от 1 до 3. Нужно отсортировать его по возрастанию
Я сделаю чисто по индусски:
:)
int n1 = 0, n2 = 0, i = 0;
while (i < length)
{
switch (a[i++])
{
case 1: n1++; break;
case 2: n2++; break;
}
}
i = 0;
while (i < n1)
{
a[i++] = 1;
}
while (i < n1+n2)
{
a[i++] = 2;
}
while (i < length)
{
a[i++] = 3;
}
-
Это точно, "нормальные" люди считают, что у них нет проблем. Иногда, правда, приходится напрячься, ну так можно написать вот такую херню, как эта от микрософтовцев http://forum.oberoncore.ru/viewtopic.php?p=53637#p53637 . Но считать это проблемой просто смешно. Есть вещи поважнее.
А вот интересно, как нормальный человек решит такую задачу: массив заполнен целыми числами от 1 до 3. Нужно отсортировать его по возрастанию.
Точнее, я знаю, как решит нормальный - применит какой-нибудь универсальную сортировку и даже не поморщится.
Но ведь задача-то простая, неужели нельзя самому решить?
Попробуйте, обращаюсь конкретно к vlad'у и всем заинтересованным лицам, и напишите комментарии. Честно говоря, у меня мозги забиты, и я вообще не представляю, как пойдет процесс.
Классика жанра - сортировка подсчетом сложность 2*N -первый прогон подсчет количества значений, второй их расстановка в исходном массиве - не фиг думать
-
Вот в один прогон. Вроде, не накосячил. Есть поле для оптимизации.
cl, cr, x, tmp : INTEGER;
x := 0;
cl := 0;
cr := LEN( a );
WHILE x < cr DO
IF a[x] = 1 THEN
tmp := a[cl]; a[cl] := a[x]; a[x] := tmp;
cl := cl + 1;
ELSIF a[x] = 3 THEN
tmp := a[cr]; a[cr] := a[x]; a[x] := tmp;
cr := cr + 1;
END
x := x + 1
END
-
Вот в один прогон. Вроде, не накосячил. Есть поле для оптимизации.
cl, cr, x, tmp : INTEGER;
x := 0;
cl := 0;
cr := LEN( a );
WHILE x < cr DO
IF a[x] = 1 THEN
tmp := a[cl]; a[cl] := a[x]; a[x] := tmp;
cl := cl + 1;
ELSIF a[x] = 3 THEN
tmp := a[cr]; a[cr] := a[x]; a[x] := tmp;
cr := cr + 1;
END
x := x + 1
END
Да поле есть - в частности если в определите массив из четырех чисел temp то подсчет упрощается сводится к INC(TEMP[a]) -- но фиг думать - это классика
-
INC(TEMP[a]) -- но фиг думать - это классика
Вы не о том думаете :) Думать надо о сопровождении. По умолчанию. Потому что сопровождающий программист будет думать о вас очень плохо, когда матерясь будет выхерачивать ваш велосипед и менять его на банальную (без выпендрежа) строчку "std::sort", потому что у кастомера ваш мегакод случайным образом глючит, потому что таки в массиве стали появляться цифры 4 (и это абсолютно валидный случай после того как систему расширили добавив новый тип какой-нибудь херни).
P.S. Конечно если вы пишите на обероне... И вам все равно надо херачить сортировку... То грех не воспользоваться случаем и не написать свою уникальную :) Что, впрочем, не отменяет все тех же проблем при появлении цифры 4 :)
P.S.S. Да, да - ни в одном велосипеде не было соответствующего ASSERT. Что как бы намекает, что думают совсем не о том :)
-
Вы не о том думаете :) Думать надо о сопровождении. По умолчанию. Потому что сопровождающий программист будет думать о вас очень плохо, когда матерясь будет выхерачивать ваш велосипед и менять его на банальную (без выпендрежа) строчку "std::sort", потому что у кастомера ваш мегакод случайным образом глючит, потому что таки в массиве стали появляться цифры 4 (и это абсолютно валидный случай после того как систему расширили добавив новый тип какой-нибудь херни).
P.S. Конечно если вы пишите на обероне... И вам все равно надо херачить сортировку... То грех не воспользоваться случаем и не написать свою уникальную :) Что, впрочем, не отменяет все тех же проблем при появлении цифры 4 :)
P.S.S. Да, да - ни в одном велосипеде не было соответствующего ASSERT. Что как бы намекает, что думают совсем не о том :)
Не надо делать из мухи слона - в данном случае абсолютно стандартная реализация сортировки подсчетом+заведомо тот случай когда ТРЕБОВАЛОСЬ написать УНИКАЛЬНЫЙ вариант -смысл в том, что нефиг думать - классика жанра (стандартное решение БЕЗ мозго-ства).
ЗЫ А вообще - то не фиг вырывать часть фразы из контекста - напрягитесь и прочитайте ее хотя бы С НАЧАЛА до конца (думал Валерий - я ПРОСТО ОТВЕТИЛ на его ОПТИМИЗАЦИЮ стандартным решением) я уж не говорю про сообщение вызвавшее этот OFFSPIN).
-
иронизируя над HOME MADE оптимизациями, показывая что понимание задачи даже на высоком уровне позволяет находить как минимум не уступающие по качеству идеологически более простые решения.
-
Вы не о том думаете :) Думать надо о сопровождении. По умолчанию.
Vlad, это вы не о том думаете. Я предлагаю вам лично решить простую задачу. Без всякого сопровождения. Или вы хотите сказать: "Я крутой чувак, но такую ерунду решить не в состоянии". А самолюбие где?
-
думал Валерий - я ПРОСТО ОТВЕТИЛ на его ОПТИМИЗАЦИЮ
Мотороллер не мой! Я просто разместил объяву (http://lurkmore.to/%D0%9C%D0%BE%D1%82%D0%BE%D1%80%D0%BE%D0%BB%D0%BB%D0%B5%D1%80)
(Извините! Не удержался. :D )
-
Вот в один прогон. Вроде, не накосячил.
Всё же... накосячил... :)
Оператор cr := cr + 1; (строка 12), надо заменить на cr := cr - 1;
-
думал Валерий - я ПРОСТО ОТВЕТИЛ на его ОПТИМИЗАЦИЮ
Мотороллер не мой! Я просто разместил объяву (http://lurkmore.to/%D0%9C%D0%BE%D1%82%D0%BE%D1%80%D0%BE%D0%BB%D0%BB%D0%B5%D1%80)
(Извините! Не удержался. :D )
Да не за что - один черт не понял к чему это. Хотя нет - если ваше сообщение есть демонстрация способностей использования тегов [url /url] - то прощаю (зачетная демонстрация). :)
-
Vlad, это вы не о том думаете. Я предлагаю вам лично решить простую задачу. Без всякого сопровождения. Или вы хотите сказать: "Я крутой чувак, но такую ерунду решить не в состоянии". А самолюбие где?
:( Ловля на "понты" - а с какой стати он ДОЛЖЕН это делать, тем более если вы не удосужились даже толком обьяснить за чем это (то есть увеличить ценность бессмысленной работы).
-
Ну ловля, так затраты-то минимальные. Надо ж все-таки иногда подтверждать свою крутизну.
-
Ну ловля, так затраты-то минимальные. Надо ж все-таки иногда подтверждать свою крутизну.
На таких задачах ? :( , впрочем, каждому свое (если, конечно, на самом деле это не "примитивная" попытка достать человека).
-
На таких задачах ?
Что имеется в виду? Очень простых или очень сложных?
Это, конечно, не попытка "достать" человека. Я к vlad'у отношусь очень хорошо. Еще с тех пор, когда он писал на оберонкоре.
-
Вот в один прогон. Вроде, не накосячил.
Всё же... накосячил... :)
Оператор cr := cr + 1; (строка 12), надо заменить на cr := cr - 1;
Ещё надо в начале cr := LEN(a); заменить на cr := LEN(a) - 1;
А идея классная. Лучше чем мой индусский вариант.
-
Отказ от break/continue - это та самая поддержка и возможность безопасной доработки цикла в будущем. Выгода в ясности/надёжности превосходит время, единожды потраченное на понимание сути техники.
Сортировка массива на Объектном Паскале:
PROCEDURE Sort (VAR Arr: TIntArray; MinValue, MaxValue: INTEGER);
CONST
MAX_RANGE = 1000;
VAR
NumItems: INTEGER;
ItemInd: INTEGER;
Range: INTEGER;
RangeArr: TIntArray;
FillValue: INTEGER;
i: INTEGER;
j: INTEGER;
BEGIN
{!} ASSERT(MinValue <= MaxValue);
Range := MaxValue - MinValue + 1;
{!} ASSERT(Range <= MAX_RANGE);
NumItems := LENGTH(Arr);
IF NumItems > 1 THEN BEGIN
SetLength(RangeArr, Range);
FOR i := 0 TO Range - 1 DO BEGIN
RangeArr[i] := 0;
END; // .FOR
FOR i := 0 TO NumItems - 1 DO BEGIN
{!} ASSERT(Math.InRange(Arr[i], MinValue, MaxValue));
INC(RangeArr[Arr[i] - MinValue]);
END; // .FOR
FillValue := MinValue;
ItemInd := 0;
FOR i := 0 TO Range - 1 DO BEGIN
FOR j := 1 TO RangeArr[i] DO BEGIN
Arr[ItemInd] := FillValue;
INC(ItemInd);
END; // .FOR
INC(FillValue);
END; // .FOR
END; // .IF
END; // .PROCEDURE Sort
-
Вы не о том думаете :) Думать надо о сопровождении. По умолчанию.
Vlad, это вы не о том думаете. Я предлагаю вам лично решить простую задачу. Без всякого сопровождения. Или вы хотите сказать: "Я крутой чувак, но такую ерунду решить не в состоянии". А самолюбие где?
Хорошему программисту самолюбие надо душить, как и чувство перфекционизма :) Именно это я и хотел сказать своим std::sort.
Оригинальный посыл вполне понятен - задача, укладывающаяся в рамки "шаблонного" решения, но имеющая намного более эффективное оригинальное решение (относительно оригинальное, конечно все придумано до нас, хотя лично я решения с подсчетом/приравниванием и не знал, расписываюсь в своей серости).
Если вам хотелось увидеть это оригинальное решение от меня лично - надо было прямо сказать, а не рассуждать про "нормальность" :) Я считаю, что смог бы придумать однопроходный вариант O(n) с перестановками - аналог Valery Solovey. Если у вас есть еще более оригинальное/эффективное решение - можете им похватстать, потому что до него я бы уже вряд ли додумался :)
-
Благодарю всех, кто принял участие в эксперименте.
Это задача Дейкстры о голландском национальном флаге.
http://en.wikipedia.org/wiki/Dutch_national_flag_problem
http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Sort/Flag/
(Dutch - голландский, нидерландский)
Там в решении присутствует swap, который можно заменить двумя присваиваниями, а не тремя, т.к. один элемент известен и не надо его запоминать.
Чтобы не пугать народ, я не сказал про Дейкстру. Ведь задача действительно простая. Это следует хотя бы из размера решения.
Но нормальный программист оказывается здесь безоружным и спотыкается. Он может расчитывать только на озарение и догадку, а они плохо предсказуемы.
Меня лично это не устраивает, я предпочитаю гарантированно переезжать такие задачи как трактор, почти не снижая скорости. Остальные, видимо, смирились с текущим положением. Может быть, хоть сейчас кто-то возмутится и спросит "ДОКОЛЕ?!"
Тут есть еще один интересный момент. Основатель "учения о линейном поиске" Info21, считает что в циклах бывает "либо полный проход, либо линейный поиск, либо аккуратненький Дейкстра. Исключений пока не встречал" http://forum.oberoncore.ru/viewtopic.php?p=59773#p59773
Здесь костыль "линейной поиск" не работает. Info21 не мог не видеть эту задачу в "Дисциплине программирования". Пример когнитивной слепоты, симптомы которой он так ярко сам описал. Еще один повод задуматься о "базовых схемах циклов".
-
Я не понял, в чём был прикол данной задачи.
Никаких ограничений на её решение не возлагалось -- например, не было требования линейного времени сортировки.
А значит: лучшее решение == самое простое.
Что может быть проще, чем вызвать стандартную процедуру сортировки массива?
-
Я всё-таки не вижу, в чём бы не прав info21. Цикл Дейкстры в простейшем случае вырождается в одноветочный while, который сам по себе универсален.
vlad напомнил про развитие и поддержку. Что если цветов уже 4? А если пять? В таком случае проще один раз написать сортировку подсчётом, как золотую середину между конкретной ручной оптимизацией и полностью абстрактным вариантом от содержимого массива, как в случае с использованием библиотечной функции. Разумеется, это если есть подозрение, что мы выиграем хотя бы 10% в ощущаемой скорости программы.
-
подозрение, что мы выиграем хотя бы 10% в ощущаемой скорости программы.
Это стандартная задача на квалификацию ОБУЧЕННОГО программиста (прослушавшего БАЗОВЫЙ курс по алгоритмизации вуза, либо школьника из продвинутого лицея) решение о применении того или иного метода принимается по мере анализа задачи в данном случае мы имеем ЯРКО выраженную "специфичность" задачи (небольшое число различных значений сортируемых элементов идущих друг за другом). Выбор метода однозначен. На ощущения можно и должно ЗАБИТЬ если известен размер сортируемого массива. Все таки 2*N это не Nlog(N). А насчет HANDMADE оптимизаций - ошибки Валерия показывают правоту большинства высказавшихся по этому вопросу - не фиг , если это не АБСОЛЮТНО критично. Что касается использования обычного sort'a - то я не против (а то слишком много развелось конкурентов ) :)
-
Тут есть еще один интересный момент. Основатель "учения о линейном поиске" Info21, считает что в циклах бывает "либо полный проход, либо линейный поиск, либо аккуратненький Дейкстра. Исключений пока не встречал" http://forum.oberoncore.ru/viewtopic.php?p=59773#p59773
Здесь костыль "линейной поиск" не работает.
Зато работает "аккуратненький Дейкстра". ;)
-
Я не понял, в чём был прикол данной задачи.
В исходной постановке определение цвета - очень дорогая операция.
-
Я не понял, в чём был прикол данной задачи.
В исходной постановке определение цвета - очень дорогая операция.
То есть из этого следовало требование проделать всю работу за 1 проход по массиву?
-
А насчет HANDMADE оптимизаций - ошибки Валерия показывают правоту большинства высказавшихся по этому вопросу - не фиг , если это не АБСОЛЮТНО критично.
На моё решение повлияло 2 обстоятельства: 1) его не собирались использовать в реальной жизни; 2) был уже час ночи, и я хотел побыстрее пойти спать. Именно поэтому я написал его, окинул ещё раз взглядом и выбросил сюда. На свежую голову или хотя бы при большем количестве времени я бы ошибки убрал. Так что первое: ошибки - это не правило.
Да, если бы я использовал sort, то ошибок бы не было. Но с чего вы взяли, что задача требовала сортировки?
Увидел массив чисел и быстро вспомнил, что уже умею с этим объектом делать, а потом выбрал для него ту операцию, в пояснении к которой больше слов пересекается с словами из задачи? Это называется "программирование по ассоциациям". Её продуктом становится индусский код. Например, нужно найти минимальное число в массиве. "Так, массив сортируется. Первым его элементом после этого будет тот, который мне нужен" - подумает "индус". И сделал. Циклы? В них же делают ошибки. Не нужны нам эти "оптимизации".
С элементом надо делать не то, что умеем, а то, что требуется. Отсюда следует второе: это была не оптимизация, а решение, ведущее к цели.
-
Вот тут где-то советовали начинающим программистам пользоваться языком без сборки мусора. А что, это его (начинающего) главная цель? Освоить ручное управление памятью.
Я вот думаю, что есть вещи и по-важнее. Например, идя к результату применять операции, которые описывают суть задачи, а не которые успел где-то там на лекциях или в интернете запомнить. Даже если исключить ситуации, когда программисту может попасться задача, решения которой ему не давали (а понять это можно только при взгляде на ответ; при его отсутствии будет выбрано что-нибудь из имеющегося арсенала), то всё равно в реальности простых задач с одним-единственным массивом не бывает. И при наличии некоторого количества массивов вкупе с другими ресурсами выбор необходимых операций, хранящихся у него в голове, может привести его в ступор. А после того, как он определился с операцией нет гарантий, что он сделал правильный выбор.
Умение вручную разместить и убрать переменную из памяти поможет ему? Нет. Можно ли без этого навыка обойтись в программировании? Довольно часто - да.
Умение сначала пытаться усвоить задачу перед её решением поможет ему? Да. Можно ли без него обойтись? Только в простейших случаях.
Усваивать не значит заучить текст и уметь его по памяти слово в слово прочитать его как слева направо, так и справа налево. Это такая вещь, которая может много где пригодиться по жизни. И никакое программирование ей не нужно. А вот обратное - хорошо программировать пренебрегая этой вещью - я думаю, невозможно. И поэтому, это умение должно быть освоено или до начала программирования или вместе с ним. И поэтому преподаватели (конкретно Илья и info21) считают, что
а) любые элементы в зыке программирования лишние, и мешают учиться правильно воспринимать задачу. Но поскольку без элементов не будет формы, в которую можно облекать решение, то пускай хотя бы их будет разумно минимально.
б) требуются задачи, на которых студент учился бы "отпускать" своё сознание для усваивания задачи, а не судорожно бы тыкался по списку запомненных операций над данными.
Хороша ли задача, которую привёл Пётр, чтобы преподаватели использовали её в качестве наработки навыка усваивания (или анализа - так, наверное, правильнее)? Сложный вопрос. Но, думаю, она даётся именно с этой целью. А не чтобы обезьяна нашла, как написать на клавиатуре sort.
-
.....Да, если бы я использовал sort, то ошибок бы не было. Но с чего вы взяли, что задача требовала сортировки?...
С элементом надо делать не то, что умеем, а то, что требуется. Отсюда следует второе: это была не оптимизация, а решение, ведущее к цели.
1. Так поставил ее Петр
2. Да тут я ошибся - думал что вы стали делать этот вариант зная о сортировке подсчетом - в этом случае он выглядел оптимизацией, правильно было hand -made решение.
Уточнение - на фиг hand -made решения и оптимизации без абсолютной необходимости.
-
Вот тут где-то советовали начинающим программистам пользоваться языком без сборки мусора. А что, это его (начинающего) главная цель? Освоить ручное управление памятью.
Не думаю, что такая постановка вопроса является правильной. Главная цель любого обучающегося - научиться... цель начинающего программиста - научиться пользоваться инструментами (см. ниже).
Умение вручную разместить и убрать переменную из памяти поможет ему? Нет. Можно ли без этого навыка обойтись в программировании? Довольно часто - да.
Умение сначала пытаться усвоить задачу перед её решением поможет ему? Да. Можно ли без него обойтись? Только в простейших случаях.
Усваивать не значит заучить текст и уметь его по памяти слово в слово прочитать его как слева направо, так и справа налево. Это такая вещь, которая может много где пригодиться по жизни. И никакое программирование ей не нужно. А вот обратное - хорошо программировать пренебрегая этой вещью - я думаю, невозможно. И поэтому, это умение должно быть освоено или до начала программирования или вместе с ним. И поэтому преподаватели (конкретно Илья и info21) считают, что
а) любые элементы в зыке программирования лишние, и мешают учиться правильно воспринимать задачу. Но поскольку без элементов не будет формы, в которую можно облекать решение, то пускай хотя бы их будет разумно минимально.
б) требуются задачи, на которых студент учился бы "отпускать" своё сознание для усваивания задачи, а не судорожно бы тыкался по списку запомненных операций над данными.
Перечисленные Вами господа учат не программированию, а решению задач. Они просто не различают суть: анализа, проектирования и кодирования. И это скверно... поскольку требования к каждому из этих направлений совершенно разные. Программист должен знать:
- инструменты:
- язык программирования,
- библиотеки и иерархии классов,
- API ОС,
- отладчики и пр.;
- приёмы и методы решения простейших задач (наподобие той, что была приведена ранее);
- правила ведения технической документации;
Хороша ли задача, которую привёл Пётр, чтобы преподаватели использовали её в качестве наработки навыка усваивания (или анализа - так, наверное, правильнее)? Сложный вопрос. Но, думаю, она даётся именно с этой целью. А не чтобы обезьяна нашла, как написать на клавиатуре sort.
И кому нужна "обезьяна"-программист, которая не знает инструмента, не может правильно, в виде программы/подпрограммы записать простые действия?
-
Увидел массив чисел и быстро вспомнил, что уже умею с этим объектом делать, а потом выбрал для него ту операцию, в пояснении к которой больше слов пересекается с словами из задачи? Это называется "программирование по ассоциациям". Её продуктом становится индусский код. Например, нужно найти минимальное число в массиве. "Так, массив сортируется. Первым его элементом после этого будет тот, который мне нужен" - подумает "индус". И сделал. Циклы? В них же делают ошибки. Не нужны нам эти "оптимизации".
Неверно. Правильный "индус" вызовет стандартную процедуру поиска минимального элемента массива, которая решит данную задачу быстрее и надёжнее самопального цикла.
-
Я не понял, в чём был прикол данной задачи.
Никаких ограничений на её решение не возлагалось -- например, не было требования линейного времени сортировки.
А значит: лучшее решение == самое простое.
Что может быть проще, чем вызвать стандартную процедуру сортировки массива?
Если бы я сказал, что это критичный кусок и произодительность стандартной сортировки не устраивает, то единственно правильным решением для программиста любой национальности было бы такое: смотреть справочник алгоритмов. Но тогда нечего было бы обсуждать.
Вот и пришлось давить не на производительность, а на самолюбие ;)
-
Тут есть еще один интересный момент. Основатель "учения о линейном поиске" Info21, считает что в циклах бывает "либо полный проход, либо линейный поиск, либо аккуратненький Дейкстра. Исключений пока не встречал" http://forum.oberoncore.ru/viewtopic.php?p=59773#p59773
Здесь костыль "линейной поиск" не работает.
Зато работает "аккуратненький Дейкстра". ;)
Поначалу не хотел отвечать на дурацкий пост, т.к. чувствую бессмысленность. Все-таки отвечу.
Во-первых, решение можно попытаться переписать, используя ЦД, но это будет не "аккуратненький Дейкстра", а страшный изврат. Подгонка под "учение". Сам Римский Па Дейкстра этого не делает.
(http://s59.radikal.ru/i164/1202/64/6a23e3fe6c27.png)
Во-вторых, и это самое главное, польза от решения применить ЦД не намного больше, чем от совета использовать для записи цикла алфавитно-цифровые символы. С линейным поиском хоть была догма об отрицании второго коньюнктивного члена.
В-третьих, если вы или кто-то соберется опровергать, делайте это примерами.
-
Я не понял, в чём был прикол данной задачи.
Никаких ограничений на её решение не возлагалось -- например, не было требования линейного времени сортировки.
А значит: лучшее решение == самое простое.
Что может быть проще, чем вызвать стандартную процедуру сортировки массива?
Если бы я сказал, что это критичный кусок и произодительность стандартной сортировки не устраивает, то единственно правильным решением для программиста любой национальности было бы такое: смотреть справочник алгоритмов. Но тогда нечего было бы обсуждать.
Вот и пришлось давить не на производительность, а на самолюбие ;)
А в результате каждый начал говорить о том, что болит конкретно у него :-) Например vlad про поддерживаемость (и я его понимаю - в такой большом проекте как у него, за все остальное в большенстве случаев нужно руки отрывать), я вначале подумал тоже про std::sort, потом про рабочекрестьянский метод как у Сергея (с поправкой на сишную специфику - я бы таки memset/memcpy использовал бы для заполнения массива). А потом, параллельно, начал думать
1) о абстрактном решении этой задачи (элементов не 3 типа, а N, причем они не integer'ы а что-то другое (то есть нужно еще было формализовать требования к элементам))
2) о том какой из представленных тут алгоритмов лучше параллелится (ибо у меня это таки больной вопрос) посредством технологии Neon (в arm процессорах).
3) как эти алгоритмы лучше отобразить на msp430.
В общем, постановка задачи во-первых была далека от Дейкстры, и во-вторых давала достаточно простора фантазии для её толкования.
-
А, ну да, в процессе у меня была мысль использовать radix sort.
-
Да, а абстрактное решение естественно все предусловия должно проверять на этапе компиляции.
-
Вот тут где-то советовали начинающим программистам пользоваться языком без сборки мусора. А что, это его (начинающего) главная цель? Освоить ручное управление памятью.
Я вот думаю, что есть вещи и по-важнее. Например, идя к результату применять операции, которые описывают суть задачи, а не которые успел где-то там на лекциях или в интернете запомнить.
Начинающему программисту нужно освоить несколько навыков. В том числе и то что ты описываешь, но, также, ему надо научиться работать с ресурсами, научиться убирать за собой. Память - самый понятный и самый широкораспространенный ресурс. Никакой сборщик мусора не убережет программиста от утечек, скажем, сокетов. Или хэндлов окна. Или иных ресурсов. Его спасет только навык убирать за собой.
ЯП со сборщиком мусора просто не в состоянии приучить к этому. Ибо сокеты и другие ресурсы-"не память" встречаются относительно редко. Но встречаются.
Если угодно, можно относиться к навыку манипулирования ресурсами как к необходимой технике безопасности, которую просто обязательно должен усвоить каждый. Конечно по стройке можно ходить и без каски, и под стрелой можно стоять. И даже довольно долго это может продолжаться без последствий. Но рано или поздно кирпич в голову таки прилетит.
-
Но тогда нечего было бы обсуждать.
Вот и пришлось давить не на производительность, а на самолюбие ;)
Понял - ваша целью было "замутить воду" - одна проблема, обсуждение вызванное таким образом, с высокой степенью вероятности будет не очень полезно.
-
И кому нужна "обезьяна"-программист, которая не знает инструмента, не может правильно, в виде программы/подпрограммы записать простые действия?
Согласен , если под программистом понимаете -"грамотный кодер под конкретный язык". А если выбор последнего допускает вариацию? По поводу "перечисленных господ" - у меня лично сложилось впечатление, что они учат кодированию - и называют это решением задач. Мой опыт говорит о следующем - самое сложное, умение абстрагировать задачу и формулировать ее в терминах моделей информатики и окружения (операционной системы), далее идет -построение алгоритмического решения в терминах использованных моделей. А отображение алгоритма на конкретный ЯП как правило вносит малый вклад в сложность - ее можно понизить взяв ЯП который описывает наиболее просто данные системы (система лежит в области эффективного использования языка), либо взять простой язык (типа ОБЕРОНА) - но в последнем случае можно напороться на сложности связанные с большим обьемом кода, реализующего интересующий нас алгоритм .
-
Вот тут где-то советовали начинающим программистам пользоваться языком без сборки мусора. А что, это его (начинающего) главная цель? Освоить ручное управление памятью.
Конечно не главная. Но иметь представление важно для понимания других вещей. Во всяком случае если речь идет о чем-то более углубленном, нежели школьный курс информатики.
Хороша ли задача, которую привёл Пётр, чтобы преподаватели использовали её в качестве наработки навыка усваивания (или анализа - так, наверное, правильнее)? Сложный вопрос. Но, думаю, она даётся именно с этой целью. А не чтобы обезьяна нашла, как написать на клавиатуре sort.
Конечно, для обучения очень хорошая задачка. Не сложная, допускающая разные решения и понятная. Но в производственном (production) коде использовать для ее решения что-то кроме стандартного sort - просто невежество.
-
Вообще для обучения я бы использовал параллельно 3 курса:
- Работа железки (от триггеров до простейшего АЛУ). В идеале - с проектированием своей простейшей железки и сборкой ее из конструктора (без паялки). И без программирования - просто железныя логика.
- Ассемблер/Си. Можно не погружаться особо в особенности написания программ на ассемблере (ограничиться какими-нибудь очень простыми вычислениям + понятие стека/регистров). Но вот сишные указатели на указатель + адресная арифметика должны быть обязательно усвоены. Тем, кто не усваивает - предлагается еще раз подумать о выборе професии :)
- Оберон/КП и какой-нибудь ФП (скорее хаскель). На примере оберона рассказать про тот же GC и его проблемы, базовое ООП и компоненты. Ну там про циклы, конечно же :) Хаскель - как антикостное средство для мозга :)
После всего это можно уже на рабочем месте изучать всякие жабы с фрэймворками и прочите питоны с жабаскриптами.
-
Конечно, для обучения очень хорошая задачка. Не сложная, допускающая разные решения и понятная. Но в производственном (production) коде использовать для ее решения что-то кроме стандартного sort - просто невежество.
Да ну ;) - невежество использовать sort зная о сортировке подсчетом, невежество - зная ее делать hand-maid. Но если вы не знаете ее - то наколенное решение будет (на мой взгляд) гораздо ближе к тому что затребовал Петр в своей исходной постановке (хотя для чего это ему нужен был это offspin толком не может сказать и он сам).
-
По поводу "перечисленных господ" - у меня лично сложилось впечатление, что они учат кодированию - и называют это решением задач
http://forum.oberoncore.ru/viewtopic.php?f=86&t=3837
Мой опыт говорит о следующем - самое сложное, умение абстрагировать задачу и формулировать ее в терминах моделей информатики и окружения (операционной системы), далее идет -построение алгоритмического решения в терминах использованных моделей. А отображение алгоритма на конкретный ЯП как правило вносит малый вклад в сложность - ее можно понизить взяв ЯП который описывает наиболее просто данные системы (система лежит в области эффективного использования языка), либо взять простой язык (типа ОБЕРОНА) - но в последнем случае можно напороться на сложности связанные с большим обьемом кода, реализующего интересующий нас алгоритм ..
Согласен. Однако в упор не понимаю, почему нельзя заниматься всем этим - и в то же время уметь выдать безупречный программный код.
-
http://forum.oberoncore.ru/viewtopic.php?f=86&t=3837
Замечу, что нехорошо давать ссылку (по которой, видимо, содержится ответ) на ресурс не доступный простым смертным, кроме того, оно не доступно и не очень простым (зарегистрированным там) смертным. Так что советую таки размещать ответы где-нибудь где они будут доступны всегда и всем (не обязательно тут на форуме, можно например на paste.org.ru, можно на https://gist.github.com/ и так далее, если тут размещать их по каким-либо причинам не удобно).
Согласен. Однако в упор не понимаю, почему нельзя заниматься всем этим - и в то же время уметь выдать безупречный программный код.
Лично я в своей жизни еще ни разу не видел безупречного програмного кода :-)
-
http://forum.oberoncore.ru/viewtopic.php?f=86&t=3837
Замечу, что нехорошо давать ссылку (по которой, видимо, содержится ответ) на ресурс не доступный простым смертным, кроме того, оно не доступно и не очень простым (зарегистрированным там) смертным. Так что советую таки размещать ответы где-нибудь где они будут доступны всегда и всем (не обязательно тут на форуме, можно например на paste.org.ru, можно на https://gist.github.com/ и так далее, если тут размещать их по каким-либо причинам не удобно).
Думаю, что в этом весь оберонкоре... Вроде, как "Вы никогда не узнаете, какие мы белые и пушистые", потому что мы Вам не покажем, а если Вы узнаете и засомневаетесь, то мы Вас вычеркнем, затрём и выбросим. Так ведут себя мелкие пакостники... а с них что взять?..
-
Согласен. Однако в упор не понимаю, почему нельзя заниматься всем этим - и в то же время уметь выдать безупречный программный код.
Да можно - и это обычно происходят когда студенты ОСОЗНАЮТ важность его (это происходит при коллективной работе над относительно крупными проектами, когда необходим рефакторинг задачи....) - но да такой степени нужно либо дойти в своем развитии, либо быть ВЫНУЖДЕН в тупую следовать правилам под воздействием ЖЕСТКИХ обстоятельств. Да и мне не нравится "безупречный программный код" отдает дешевыми аннотациями на идиотские книги.
-
Я прошу прощения, что дал ошибочную ссылку.
Вот эта работает:
http://forum.oberoncore.ru/viewtopic.php?f=86&t=3838
Домыслы советую оставить при себе.
-
Думаю, что в этом весь оберонкоре... Вроде, как "Вы никогда не узнаете, какие мы белые и пушистые", потому что мы Вам не покажем, а если Вы узнаете и засомневаетесь, то мы Вас вычеркнем, затрём и выбросим. Так ведут себя мелкие пакостники... а с них что взять?..
Там есть еще один перл. Страница коровской википедии Структурирование "промышленного" цикла
(http://oberoncore.ru/wiki/%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%BD%D0%BE%D0%B3%D0%BE_%D1%86%D0%B8%D0%BA%D0%BB%D0%B0) начинается со ссылки на обсуждение исходного варианта на форуме http://forum.oberoncore.ru/viewtopic.php?p=42396#p42396
Вся(!) эта ветка удалена. Ибо там было вольнодумство.
Все-таки, подзреваю, что в данном случае виновник не Илья, а "человек-в-футляре".
-
Я прошу прощения, что дал ошибочную ссылку.
Вот эта работает:
http://forum.oberoncore.ru/viewtopic.php?f=32&t=3837
Домыслы советую оставить при себе.
Не работает.
-
Я прошу прощения, что дал ошибочную ссылку.
Вот эта работает:
http://forum.oberoncore.ru/viewtopic.php?f=32&t=3837
Домыслы советую оставить при себе.
Да и эта ссылка на закрытый раздел - чувствую там разрабатывалась особо секретная программа ИСТРЕБИТЕЛЬ ПРОГРАММЕРСКОГО НЕВЕЖЕСТВА для ИЗБРАННЫХ ;D ;D ;D ;D
Илья - ну как же тут без домыслов..... :)
-
Да нет. Илья просто дал (по ошибке) вторую ссылку идентичную первой. То есть просто скопипастил неправильно. Правильная, видимо, вот эта: http://forum.oberoncore.ru/viewtopic.php?f=86&t=3838
-
Однако замечу, что в отличае от первой ссылки (которая нынче битая), в письме по новой ссылке не содержится линка на данное обсуждение. Что, кстати, нарушение элементарного сетевого этикета. Если от info21 я этого вполне ожидал, то от Ильи я этого не ожидал никак.
-
В чём можно усмотреть нарушение этикета, если моё сообщение не затрагивает явно никого/ничего отсюда, а посвящено проблеме "вообще"? Вообще, не превращайте в политику техническую тему. Я ответ dizer-у писал как обычную технологическую заметку. В чём любой может убедиться.
-
Однако замечу, что в отличае от первой ссылки (которая нынче битая), в письме по новой ссылке не содержится линка на данное обсуждение. Что, кстати, нарушение элементарного сетевого этикета. Если от info21 я этого вполне ожидал, то от Ильи я этого не ожидал никак.
Вырезано обсуждение с закрытого форума ? - да некоторые вещи не меняются...
-
Вырезано обсуждение с закрытого форума ? - да некоторые вещи не меняются...
В оригинальном ответе Ильи содержался линк на этот форум (oberspace). В правленной и перенесенной версии ответа линка уже нет.
-
Вырезано обсуждение с закрытого форума ? - да некоторые вещи не меняются...
В оригинальном ответе Ильи содержался линк на этот форум (oberspace). В правленной и перенесенной версии ответа линка уже нет.
Да я не про это - у меня его ссылка ведет на ЗАКРЫТЫЙ отстойник, а ваша не содержит обсуждение из этого отстойника.
-
Да я не про это - у меня его ссылка ведет на ЗАКРЫТЫЙ отстойник, а ваша не содержит обсуждение из этого отстойника.
А там (на оберонкоре) и не было никакого обсуждения. Илья завел новую тему в одном из разделов и там написал ответ на то, что обсуждалось тут, у нас. То есть на оберонкоре было ровно одно письмо в одной теме. Почти моментально тема была удалена (видимо "вернули автору на доработку"), после чего в уже доработанном виде (убрали ссылку на наш форум) ответ появился в новой теме в другом разделе.
-
Какая-то идиосинкразия на "режимность" у образованного народонаселения.
Тыкают в ужасе пальцем и кричат на любое вмешательство в "свободу слова".
Интересно, а когда люди к работодателю приходят и подписывают договор о режиме охраны коммерческой тайны, они не бегут кричать, что "цензура в свободном обществе", "позор фирме"? :)
Это я к чему. Дисциплина никому из умных людей никогда ещё не помешала.
А уважение к дисциплине, принятой в том месте, куда человек приходит - тоже часть культуры.
-
В данном случае вопрос не в свободе слова, а вопрос о элементарном удобстве (ссылки должны оставаться валидными и содержимое должно оставаться видимым всем) и о элементарной сетевой этике (перекрестные ссылки).
PS. Дисциплина.. В данном случае это действительно дисциплина (http://en.wikipedia.org/wiki/Discipline_(BDSM)). :-) Некоторые умные люди действительно ей увлекаются.
-
В чём можно усмотреть нарушение этикета, если моё сообщение не затрагивает явно никого/ничего отсюда, а посвящено проблеме "вообще"? Вообще, не превращайте в политику техническую тему. Я ответ dizer-у писал как обычную технологическую заметку. В чём любой может убедиться.
Так это ответ мне ? - спасибо, но я ничего нового не услышал, аргументация мне доступна и понятна - но еще в коровнике я отвечал вам - что это типичная точка зрения "жестянщика" смотрящего на мир через дырки надетой на голову консервной банки, и ЖЕСТКО навязывающей свою точку зрения (за что и был банен) , я даже пояснял причину этого..
Но главное -основную проблему в обучении ( с которой вы согласились) - ваша "наука" - не решает, а насаждение ее на начальном этапе обучения -вредит процессу
-
Однако замечу, что в отличае от первой ссылки (которая нынче битая), в письме по новой ссылке не содержится линка на данное обсуждение. Что, кстати, нарушение элементарного сетевого этикета. Если от info21 я этого вполне ожидал, то от Ильи я этого не ожидал никак.
А мне кажется... что команда работает очень согласовано и слаженно (О! Слово то какое! "Слаженно" - это просто бриллиант... если сквозь него на свет посмотреть) :)
Но текст, по приведённой Вами ссылке, весьма занятный... Хотелось бы у автора теста попросить ссылки на то, где alexus говорил про "ерунду" в контексте "анализа сложных задач"...
По сути текста говорить трудно, поскольку автор допускает только два мнения: своё и неправильное. Но замечу, что я никогда не делил работу на "рутину" и "творчество"... Мало того, я достаточно много раз говорил о том, что важно отношение к работе, что в работу (будь то программирование или обучение) надо вкладывать душу... Само деление на "рутину" и "творчество" я считаю порочным явлением. И много раз свои словоизлияния я сопровождал цитатой из произведения Антуана де-Сент Экзюпери "Планета людей": "Мы хотим свободы. Тот, кто работает киркой, хочет, чтобы в каждом ее ударе был смысл. Когда киркой работает каторжник, каждый ее удар только унижает каторжника, но если кирка в руках изыскателя, каждый ее удар возвышает изыскателя. Каторга не там, где работают киркой. Она ужасна не тем, что это тяжкий труд. Каторга там, где удары кирки лишены смысла, где труд не соединяет человека с людьми. А мы хотим бежать с каторги."
Но автор признаёт деление на "рутину" и "творчество" и, логично, переходит к следующему шагу, исключению "творчества" в любом виде... "обезличивание", борьба с "велосипедостроением"...
Не трудно понять, что следующий шаг: "люди-болтики", "люди-винтики"... есть принятые схемы работы... шаг влево, шаг вправо... расстрел за попытку к бегству.
Мой совет программистам из подобных "контор"... если Вы в себе цените личность, если Вам дорога своя индивидуальность, то бегите оттуда...
Разговоры про анализ "сложных" задач, равно, как и синтез моделей, на основе анализа, равно, как и проектирование я не комментирую, поскольку... у нас с автором совершенно разные понимания сути этих стадий жизненного цикла, и как следствие не сходимость методов.
-
По моему, мы куда-то далеко ушли от циклов :-) Про инженерию кодинга давайте обсудим тут: http://oberspace.dyndns.org/index.php/topic,184.0.html
-
Давайте, если ученик в автошколе хочет нажимать педаль тормоза левой ногой, позволим ему делать. Ведь даже нажатие педали - это не рутина, и здесь есть место для творчества!
Давайте в музыкальной школе не будем мешать ученику держать большой палец сверху "в обхват" грифа. Ведь это так удобно, пока мы играем "дворовыми" аккордами! А аккорды с баррэ мы забудем, как страшный сон.
Давайте в спорте не будем учить правильному дыханию - пусть дышат "творчески".
Давайте...
Давайте будем из года в год считать нажатие педалей и игру дворовыми аккордами - творчеством. Пусть каменщик творчески рубит киркой камень. Мы никогда не признаем это рутиной, не заменим на технологию - и не позволим каменщику стать архитектором и творить что-то большое.
Пусть люди не видят за деревьями леса и проявляют свою индивидуальность в очередном куске кода. Вместо того, чтобы избавиться от необходимости даже думать об этом куске, и заняться действительно интересными задачами, которые ждут своего открывателя.
А борьбой с велосипедостроением всегда занимаются как раз "мейнстримщики", панически боящиеся написания своего сложного кода, вместо применения библиотек, потому что понимают, что он будет содержать море ошибок.
-
Но автор признаёт деление на "рутину" и "творчество" и, логично, переходит к следующему шагу, исключению "творчества" в любом виде... "обезличивание", борьба с "велосипедостроением"...
Не трудно понять, что следующий шаг: "люди-болтики", "люди-винтики"... есть принятые схемы работы... шаг влево, шаг вправо... расстрел за попытку к бегству.
Мой совет программистам из подобных "контор"... если Вы в себе цените личность, если Вам дорога своя индивидуальность, то бегите оттуда...
Не преувеличивайте, ограничение свободы в конторах всего лишь закамуфлированное желание повысить эффективность производства (степень агрессивности зависит от многих условий), под разделением творчество и рутину очень часто понимается этически некорректное , точнее многими моралистами не приемлемое разделение людей по способностям, а так же желание увеличить "эфеективность" конвейера.
-
А борьбой с велосипедостроением всегда занимаются как раз "мейнстримщики", панически боящиеся написания своего сложного кода, вместо применения библиотек, потому что понимают, что он будет содержать море ошибок.
Нет, не поэтому.
-
Давайте, если ученик в автошколе хочет нажимать педаль тормоза левой ногой, позволим ему делать. Ведь даже нажатие педали - это не рутина, и здесь есть место для творчества!
Ох!.. Какой всплеск... Илья, Вы, пожалуйста, не путайте фантазии, тарабарщину, вольнодумие... и... творчество. Мне искренне жаль, что Вы не видите разницы во всём этом. Только помочь Вам разобраться я, увы, ничем не смогу. Ваша проблема, IMHO, что Вы всё постоянно сваливаете в одну кучу (кодирование, проектирование и моделирование, в частности), и потом с пафосом говорите: "Посмотрите, как это сложно!". Ну, конечно, сложно... именно сложно... иначе и быть не может.
-
А там (на оберонкоре) и не было никакого обсуждения. Илья завел новую тему в одном из разделов и там написал ответ на то, что обсуждалось тут, у нас. То есть на оберонкоре было ровно одно письмо в одной теме. Почти моментально тема была удалена (видимо "вернули автору на доработку"), после чего в уже доработанном виде (убрали ссылку на наш форум) ответ появился в новой теме в другом разделе.
Им там надо прописать в правилах "Ссылки на oberspace.dyndns.org будут беспощадно удаляться. Но цитирование разрешено".
Сорри за офтоп.
-
А там (на оберонкоре) и не было никакого обсуждения. Илья завел новую тему в одном из разделов и там написал ответ на то, что обсуждалось тут, у нас. То есть на оберонкоре было ровно одно письмо в одной теме. Почти моментально тема была удалена (видимо "вернули автору на доработку"), после чего в уже доработанном виде (убрали ссылку на наш форум) ответ появился в новой теме в другом разделе.
Им там надо прописать в правилах "Ссылки на oberspace.dyndns.org будут беспощадно удаляться. Но цитирование разрешено".
Сорри за офтоп.
Угу. Чтобы оффтоп не разводить, ответил тут: http://oberspace.dyndns.org/index.php/topic,167.msg3187.html#msg3187
-
Ваша проблема, IMHO, что Вы всё постоянно сваливаете в одну кучу (кодирование, проектирование и моделирование, в частности)
Нет, я просто пытаюсь сначала навести порядок в кодировании, а потом над надёжным процессом кодирования надстраивать всё остальное.
Это как если в строительстве какая-нибудь исследовательская группа на время(!) пренебрегает всем, кроме изучения и внедрения новых конструкционных материалов. А затем свойства этих новых материалов должны позволить значительно изменить проектирование зданий, ввиду, например, возможности делать огромные конструкции без опор... Надеюсь, аналогия понятна?
Ещё можно сказать так, что я мечтаю достичь целей, скажем, 4GL-подходов, совместив 3GL-инструмент с соответствующими методами работы на нём. Т.е. в 4GL: описали высокоуровнево решение задачи - оно работает. Я бы хотел: придумали высокоуровнево решение задачи, без усилий и вариаций закодировали его на 3GL.
4GL имеет недостатком необходимость особого инструмента под каждую сферу применения.
3GL + методика работы с ним этого недостатка лишены.
-
Ваша проблема, IMHO, что Вы всё постоянно сваливаете в одну кучу (кодирование, проектирование и моделирование, в частности)
Нет, я просто пытаюсь сначала навести порядок в кодировании, а потом над надёжным процессом кодирования надстраивать всё остальное.
Рекомендую помнить афоризм К. Пруткова: "Специалист подобен флюсу".
Это как если в строительстве какая-нибудь исследовательская группа на время(!) пренебрегает всем, кроме изучения и внедрения новых конструкционных материалов. А затем свойства этих новых материалов должны позволить значительно изменить проектирование зданий, ввиду, например, возможности делать огромные конструкции без опор... Надеюсь, аналогия понятна?
Угу... понятна... Главное, чтобы заказчики потом не забросали тухлыми яйцами... если вдруг изучение и внедрение затянутся.
Ещё можно сказать так, что я мечтаю достичь целей, скажем, 4GL-подходов, совместив 3GL-инструмент с соответствующими методами работы на нём. Т.е. в 4GL: описали высокоуровнево решение задачи - оно работает. Я бы хотел: придумали высокоуровнево решение задачи, без усилий и вариаций закодировали его на 3GL.
4GL имеет недостатком необходимость особого инструмента под каждую сферу применения.
3GL + методика работы с ним этого недостатка лишены.
И кто же это меня упрекает... за желание "всего и сразу"... :)
-
Вот тут где-то советовали начинающим программистам пользоваться языком без сборки мусора. А что, это его (начинающего) главная цель? Освоить ручное управление памятью.
Конечно не главная. Но иметь представление важно для понимания других вещей. Во всяком случае если речь идет о чем-то более углубленном, нежели школьный курс информатики.
Что значит углублённая? Специализированная, не фундаментальная. И где-то это нужно, конечно, но не везде. И не навсегда. Где теперь перфокарты?
Конечно, для обучения очень хорошая задачка. Не сложная, допускающая разные решения и понятная. Но в производственном (production) коде использовать для ее решения что-то кроме стандартного sort - просто невежество.
А я не уверен пока, что задачка хорошая. Перефразируя то, что я говорил про обучение выше, можно сказать так: если будущий программист получил ответ в виде кода, то это ещё не решение. Решением будет ответ не в виде кода, а в виде чего-то в голове, что можно преобразовать в код.
Схему кода можно запомнить и использовать бездумно, значит, нет гарантии, что имея код, начинающий действительно понимает, что же всё-таки за задача у него была.
А если предоставить решение задачи хотя бы самому себе (и если она довольн сложная, то визуализировать её в коде или графом), то потом не опасно воспользоваться функцией сортировки из стандартной библиотеки: мы убедились, что задача действительно заключена в сортировке.
Пример с сортировкой в реальной задаче несколько надуман, но я постоянно встречаю в нашей команде код, который можно было бы переписасть со стандартных библиотечных вызовов на стандартные же. Причём, неплохо всё бы упростил. Вот, что важно. Почему рождается запутанный код? Маловероятно, что из-за недостаточной сообразительности. Скорее, из-за не до конца решённой подзадачи. Их и вправду не так-то просто решать. Я, например, довольно часто прихожу в последствии к выводу, что и сам не решив задачи бросился её кодировать. И библиотеки не помогут решить задачи, потому что решение появляется не на экране, а в голове. А раз библиотеки не помогают в решении, то и в обучении программированию место найти для их использования проблематично.
Но если Вы всё же найдёте причину использовать библиотеки для решения, то подскажите библиотеку, занимающуюся сбором мусора и таким образом избавляющую программиста от решения этой задачи : ).
-
Рекомендую помнить афоризм К. Пруткова: "Специалист подобен флюсу".
Афоризм обычного сноба, если вдуматься в определения слов с сегодняшней позиции. Это наезд на всех, кто вообще работает.
-
Но если Вы всё же найдёте причину использовать библиотеки для решения, то подскажите библиотеку, занимающуюся сбором мусора и таким образом избавляющую программиста от решения этой задачи : ).
А такие библиотеки, кстати, есть. Но ведь речь не о об этом :-) Речь о навыке убирать за собой. Найдите мне библиотеку, или язык, или фреймворк который будет собирать не только память но и все остальные ресурсы. Своевременно собирать.
-
Рекомендую помнить афоризм К. Пруткова: "Специалист подобен флюсу".
Афоризм обычного сноба, если вдуматься в определения слов с сегодняшней позиции. Это наезд на всех, кто вообще работает.
- Это вообще не наезд, а признание реальных фактов;
- Каждый специалист смотрит на жизнь под определённым углом (в силу специфики своего рода деятельности);
- Снобизм (самодовольство) не имеет отношения к данному афоризму.
-
А я не уверен пока, что задачка хорошая. Перефразируя то, что я говорил про обучение выше, можно сказать так: если будущий программист получил ответ в виде кода, то это ещё не решение. Решением будет ответ не в виде кода, а в виде чего-то в голове, что можно преобразовать в код.
Задача для обучения хорошая - но обучению не кодированию , а анализу ситуации и контролю качества усвоения даваемого теоретического материала.
-
Перефразируя то, что я говорил про обучение выше, можно сказать так: если будущий программист получил ответ в виде кода, то это ещё не решение. Решением будет ответ не в виде кода, а в виде чего-то в голове, что можно преобразовать в код.
Так я вами и продемонстрировал ход мыслей ведущих к ВЫБОРУ, и даже показал что НЕБОЛЬШАЯ ВЫСОКОУРОВНЕВАЯ модификация СТАНДАРТНОГО подхода гораздо нагляднее и ЭФФЕКТИВНЕЕ в смысле производительности (ОДНОПРОХОДНОГО наколенника), а ведь производительность это решение можно улучшить просто перейдя на уровень НИЖЕ (на модели языков СИ|C++) - просто на обратном ходе заполнять непрерывный кусок памяти(выделяемые под массив) - значениями , как предлагал Алексей.
-
Так я вами и продемонстрировал ход мыслей ведущих к ВЫБОРУ, и даже показал что НЕБОЛЬШАЯ ВЫСОКОУРОВНЕВАЯ модификация СТАНДАРТНОГО подхода гораздо нагляднее и ЭФФЕКТИВНЕЕ в смысле производительности (ОДНОПРОХОДНОГО наколенника), а ведь производительность это решение можно улучшить просто перейдя на уровень НИЖЕ (на модели языков СИ|C++) - просто на обратном ходе заполнять непрерывный кусок памяти(выделяемые под массив) - значениями , как предлагал Алексей.
А я ничего против выбора как такового не имел. Лень сейчас искать тот Ваш пост. Помню, что если и не полностью, то хотя бы частично с ним я согласен. Любой инженер должен грамотно подходить к выбору. Проблема с ним только одна: задача выбора - это не исходная задача. А какая исходная? Поиск? Сортировка? Если сортировка, то по возрастанию или в ином порядке (напр, сначала чётные, а потом нечётные)? То есть, сначала нужно с этим разобраться. Потом полученное решение классифицировать и лишь затем переходим к выбору приемлемого решения из данного класса. Каждое из этих действий необходимо. Но только второе и третье обычно идут проще, чем первое.
-
Конечно не главная. Но иметь представление важно для понимания других вещей. Во всяком случае если речь идет о чем-то более углубленном, нежели школьный курс информатики.
Что значит углублённая? Специализированная, не фундаментальная. И где-то это нужно, конечно, но не везде. И не навсегда. Где теперь перфокарты?
Углубленная - значит на выходе будет специалист, имеющий непосредственное отношение к созданию ПО. А что перфокарты? При условии понимании "основ" - про перфокарты и зачем они были нужны можно рассказать глядя на картинку и не вдаваясь в исторические справки :)
Пример с сортировкой в реальной задаче несколько надуман, но я постоянно встречаю в нашей команде код, который можно было бы переписасть со стандартных библиотечных вызовов на стандартные же. Причём, неплохо всё бы упростил. Вот, что важно. Почему рождается запутанный код? Маловероятно, что из-за недостаточной сообразительности. Скорее, из-за не до конца решённой подзадачи.
У меня ощущение, что самой частой причиной рождения запутанного/сложного кода является отсутствие критической обратной связи при его написании. Когда красивую картинку решения в голове пытаются отлить в код, а оно не отливается (становится совсем некрасивым и непонятным). Но вместо того, что сделать шаг назад и подвергнуть критике эту красивую картинку - берут кувалду и таки придают нужную форму изделию. А последующие итерации еще больше цементируют какашку, глядя на которую первоначальную красивую идею через какое-то время не вспомнит даже автор.
-
По-моему, смешиваются две отдельных вопроса: техническое умение строить циклы и все остальное, где можно ошибиться.
-
По-моему, смешиваются две отдельных вопроса: техническое умение строить циклы и все остальное, где можно ошибиться.
Если вы говорите про свою задачу, то в случае стандартного сорта и реализации метода подсчетом ошибиться крайне тяжело. "Техническое " умение строить циклы формально состоит из 2 вещей
1.Выделение тела цикла - повторяющейся последовательности действий.
2.Нахождение условий выхода в из него.
Если вы НЕ ИМЕЕТЕ готового алгоритма, то вы ДОЛЖНЫ построить его на основе понимания задачи , и перевести в инструкции целевого ЯП.
Вот в этом - люди и ошибаются,и ЭТО естественно, потому что зависит от ЗАДАЧИ, и СПОСОБНОСТЕЙ человека.
Это для нормальных людей , но не коровцев
-
"Техническое " умение строить циклы формально состоит из 2 вещей
1.Выделение тела цикла - повторяющейся последовательности действий.
2.Нахождение условий выхода в из него.
Выглядит тоскливо-правдоподобно. Достоинство - что не длинно. Илья бы налил воды минимум в 10 раз больше.
Абсолютно неверно :)
-
"Техническое " умение строить циклы формально состоит из 2 вещей ...
Абсолютно неверно :)
Peter Almazov, Вы постоянно намекаете на то, что все вокруг Вас не умеют строить циклы. Не могли бы Вы написать (если сочтёте возможным) статью "Как правильно строить циклы" и опубликовать её где-нибудь (например, здесь). Было бы очень интересно почитать. :)
-
"Техническое " умение строить циклы формально состоит из 2 вещей
1.Выделение тела цикла - повторяющейся последовательности действий.
2.Нахождение условий выхода в из него.
На мой взгляд, Вы забыли упомянуть о формулировании инварианта цикла - условия, которое остаётся истинным после каждой итерации.
-
А борьбой с велосипедостроением всегда занимаются как раз "мейнстримщики", панически боящиеся написания своего сложного кода, вместо применения библиотек, потому что понимают, что он будет содержать море ошибок.
Совершенно верно, чем меньше лишнего кода, тем меньше ошибок, ибо ошибок не избежать -- безошибочный код слишком дорог, и в обычной промышленности никогда не будет производиться.
-
А борьбой с велосипедостроением всегда занимаются как раз "мейнстримщики", панически боящиеся написания своего сложного кода, вместо применения библиотек, потому что понимают, что он будет содержать море ошибок.
Совершенно верно, чем меньше лишнего кода, тем меньше ошибок, ибо ошибок не избежать -- безошибочный код слишком дорог, и в обычной промышленности никогда не будет производиться.
Пока детали напильниками обтачивали... про идеальность форм, говорили то же самое... потом появились штампы и литьё под давлением... Кому сейчас придёт в голову из листа железа руками делать крыло автомобиля... идеальной формы.
Всему своё время.
-
Не могли бы Вы написать (если сочтёте возможным) статью "Как правильно строить циклы" и опубликовать её где-нибудь (например, здесь). Было бы очень интересно почитать. :)
Да все давно написано. Вот, например: http://forum.oberoncore.ru/viewtopic.php?p=46182#p46182
Переработанный вариант + комментарии здесь: http://habrahabr.ru/blogs/algorithm/91698/
-
"Техническое " умение строить циклы формально состоит из 2 вещей
1.Выделение тела цикла - повторяющейся последовательности действий.
2.Нахождение условий выхода в из него.
Выглядит тоскливо-правдоподобно. Достоинство - что не длинно. Илья бы налил воды минимум в 10 раз больше.
Абсолютно неверно :)
Как скажете ;)
-
Peter Almazov, Вы постоянно намекаете на то, что все вокруг Вас не умеют строить циклы. Не могли бы Вы написать (если сочтёте возможным) статью "Как правильно строить циклы" и опубликовать её где-нибудь (например, здесь). Было бы очень интересно почитать. :)
1. Да мне НАСРАТЬ на это (умеете Вы или нет)- идолопоклонничество из этого процесса делают в коровнике - это НЕ КО МНЕ ;)
2. Не сочту - посмотрите - НА СВОЮ фразу , с которой началась эта возня, из нее СЛЕДУЕТ что вам она (статья) не нужна- вы их (ошибки при написании циклов) не делаете, МНЕ -тоже. А насчет остальных = то из моего сообщения следует ЧТО Я ДЕЛАЮ ОШИБКИ , в ТОМ ЧИСЛЕ и в ЦИКЛАХ. Если у остальных есть желание поучиться писать их безошибочно пусть обращаются к Вам ;D
-
Не могли бы Вы написать (если сочтёте возможным) статью "Как правильно строить циклы" и опубликовать её где-нибудь (например, здесь). Было бы очень интересно почитать. :)
Да все давно написано. Вот, например: http://forum.oberoncore.ru/viewtopic.php?p=46182#p46182
Переработанный вариант + комментарии здесь: http://habrahabr.ru/blogs/algorithm/91698/
Классический пример, когда из частной ситуации делают "НАУКУ" - ;D
-
Вдогонку to Peter Almazov
А если Вам скучно - то посетите коровник и попрыгайте вокруг елки (не забывая страшно выпучивая глаз декламировать принцип Калашникова) - право , нечего напрягать других людей
-
Ну почему же? Статья вроде вполне сносная. По крайней мере не бесполезная - заставляет задуматься о том, что бывают случаи, когда вначале думают, а потом кодят , а не на оборот :-)
-
Ну почему же? Статья вроде вполне сносная. По крайней мере не бесполезная - заставляет задуматься о том, что бывают случаи, когда вначале думают, а потом кодят , а не на оборот :-)
Для Вас может быть, для меня уже лет как 15 - это правило. БЕДА в том, что на ПРАКТИКЕ всякое случается :)
-
БЕДА в том, что на ПРАКТИКЕ всякое случается :)
DIzer, так это как раз то, что нужно. Приводите примеры из практики. Проверим "НАУКУ" на вшивость.
-
Не могли бы Вы написать (если сочтёте возможным) статью "Как правильно строить циклы" и опубликовать её где-нибудь (например, здесь). Было бы очень интересно почитать. :)
Да все давно написано. Вот, например: http://forum.oberoncore.ru/viewtopic.php?p=46182#p46182
Переработанный вариант + комментарии здесь: http://habrahabr.ru/blogs/algorithm/91698/
А, так Вы тоже про инвариант цикла подумали? :)
Спасибо, за ссылки!
-
Peter Almazov, Вы постоянно ...
1. Да мне НАСРАТЬ на это ...
Вы, случайно, лица не перепутали? (Я, вообще-то, не к Вам обращался.)
-
Peter Almazov, Вы постоянно ...
1. Да мне НАСРАТЬ на это ...
Вы, случайно, лица не перепутали? (Я, вообще-то, не к Вам обращался.)
Да, Игорь - перепутал- извините, точнее неправильно отредактировал, уточняю - мне по барабану (насрать), что думает об этом Peter Almazov- то что я хотел сказать, я сказал. Насчет инвариантов - я не вижу того, как они могут помочь человеку непонимающему задачу, правильно ее решить и или он не знает алгоритма ее решения (причем НАСРАТЬ новичок он или "заматеревший")- более того, утверждаю, что подобные статейки и ритуалы проводимые вокруг них вредны для начинающих.
-
Да, Игорь - перепутал- извините, ...
:)
Собственно, по методологии обучения я ни с кем спорить не могу, потому что весьма далёк от этого.
-
Собственно, по методологии обучения я ни с кем спорить не могу, потому что весьма далёк от этого.
C методологией обучения связана ровно одна последняя строчка (имеющая форму утверждения) - все остальное здравый смысл + понимание проблемы не более(на не менее).
-
У меня ощущение, что самой частой причиной рождения запутанного/сложного кода является отсутствие критической обратной связи при его написании.
Что-то в этом есть, да. Только здесь не так просто, как на схеме из курса электронных приборов. Там есть правильный вход, правильный выход и отрицательная обратная связь, стабилизирующая преобразование сигнала. В рограммировании (и много где ещё) выход нам не даётся априори. Мы должны понять, куда прийти.Когда красивую картинку решения в голове пытаются отлить в код, а оно не отливается (становится совсем некрасивым и непонятным). Но вместо того, что сделать шаг назад и подвергнуть критике эту красивую картинку - берут кувалду и таки придают нужную форму изделию. А последующие итерации еще больше цементируют какашку, глядя на которую первоначальную красивую идею через какое-то время не вспомнит даже автор.
Во многом тут виновато поверхностное понимание в начале пути, того, что должно получиться в конце. А чем больше творчества вложено в конкретные детали работы, тем сложнее и (больней : ) проявлять объективость.
При использовании sort - ноль творчества. Поэтому поудалять или перетасовать не жалко. При отсутствии творчества для каждого встречного цикла - то же самое. Минус последнего варианта - больше времени на него уходит. Но он гибче (время от времени это полезно).
-
У меня ощущение, что самой частой причиной рождения запутанного/сложного кода является отсутствие критической обратной связи при его написании.
Что-то в этом есть, да. Только здесь не так просто, как на схеме из курса электронных приборов. Там есть правильный вход, правильный выход и отрицательная обратная связь, стабилизирующая преобразование сигнала. В рограммировании (и много где ещё) выход нам не даётся априори. Мы должны понять, куда прийти.
Можно пояснить, что имелось ввиду, под неизвестностью выхода?.. Если мы пишем программу, то мы должны гарантировать при правильных исходных данных правильный результат.
Когда красивую картинку решения в голове пытаются отлить в код, а оно не отливается (становится совсем некрасивым и непонятным). Но вместо того, что сделать шаг назад и подвергнуть критике эту красивую картинку - берут кувалду и таки придают нужную форму изделию. А последующие итерации еще больше цементируют какашку, глядя на которую первоначальную красивую идею через какое-то время не вспомнит даже автор.
Во многом тут виновато поверхностное понимание в начале пути, того, что должно получиться в конце. А чем больше творчества вложено в конкретные детали работы, тем сложнее и (больней : ) проявлять объективость.
При использовании sort - ноль творчества. Поэтому поудалять или перетасовать не жалко. При отсутствии творчества для каждого встречного цикла - то же самое. Минус последнего варианта - больше времени на него уходит. Но он гибче (время от времени это полезно).
Почему "при использовании sort - ноль творчества"? Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?.. Это напоминает разговор с И. Ермаковым, который тоже как-то одномерно понимает творчество. Если есть хороший/пригодный для данных условий элемент, то его не надо выбрасывать и пересоздавать заново, надо его использовать. Но при этом не надо навсегда закрывать тему разработки этих элементов.
-
Почему "при использовании sort - ноль творчества"? Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?.. Это напоминает разговор с И. Ермаковым, который тоже как-то одномерно понимает творчество. Если есть хороший/пригодный для данных условий элемент, то его не надо выбрасывать и пересоздавать заново, надо его использовать. Но при этом не надо навсегда закрывать тему разработки этих элементов.
А если (как в ДАННОМ случае) мы имеем всего 1 элемент (Sort, причем даже не выбор из некоторого множества стандартных реализаций) - неужели его использование (вызов процедуры) можно считать творчеством.
-
Почему "при использовании sort - ноль творчества"? Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?.. Это напоминает разговор с И. Ермаковым, который тоже как-то одномерно понимает творчество. Если есть хороший/пригодный для данных условий элемент, то его не надо выбрасывать и пересоздавать заново, надо его использовать. Но при этом не надо навсегда закрывать тему разработки этих элементов.
А если (как в ДАННОМ случае) мы имеем всего 1 элемент (Sort, причем даже не выбор из некоторого множества стандартных реализаций) - неужели его использование (вызов процедуры) можно считать творчеством.
Творчество не в вызове sort, а в создании самой программы, которая где-то там внутри имеет вызов sort. Но вполне возможно, что тому, кто пишет программу, пришла в голову идея, как можно заменить стандартный sort... более эффективной конструкцией. Это тоже творчество.
-
Творчество не в вызове sort, а в создании самой программы, которая где-то там внутри имеет вызов sort. Но вполне возможно, что тому, кто пишет программу, пришла в голову идея, как можно заменить стандартный sort... более эффективной конструкцией. Это тоже творчество.
Я намекал на другое , есть определение творчества как определенного рода процесса (которое НЕ ДОЛЖНО завить от понятие СТАНДАРТНЫЙ), а есть использование (довольно общепринятое) этого слова в качестве СУБЪЕКТИВНОЙ ЛИЧНОЙ ОЦЕНКИ.
-
Творчество не в вызове sort, а в создании самой программы, которая где-то там внутри имеет вызов sort. Но вполне возможно, что тому, кто пишет программу, пришла в голову идея, как можно заменить стандартный sort... более эффективной конструкцией. Это тоже творчество.
Я намекал на другое , есть определение творчества как определенного рода процесса (которое НЕ ДОЛЖНО завить от понятие СТАНДАРТНЫЙ), а есть использование (довольно общепринятое) этого слова в качестве СУБЪЕКТИВНОЙ ЛИЧНОЙ ОЦЕНКИ.
Чтобы не запутаться в определениях... лучше исходить из семантики... :) Творчество - творение - созидание, сотворённый - созданный... и т.д.
-
Чтобы не запутаться в определениях... лучше исходить из семантики... :) Творчество - творение - созидание, сотворённый - созданный... и т.д.
:) Я предпочитаю исходить из НАМЕРЕНИЯ -дать определение, либо оценить что -либо, впрочем, каждому свое (С) :D
-
Не в тему но хочется высказаться:
Это напоминает разговор с И. Ермаковым, который тоже как-то одномерно понимает творчество. Если есть хороший/пригодный для данных условий элемент, то его не надо выбрасывать и пересоздавать заново, надо его использовать. Но при этом не надо навсегда закрывать тему разработки этих элементов.
А у меня сложилось впечатление, что Ермаков понимает творчество почти также как Вы. Просто он пытается повысить уровень элементов для творчества. Попробую объяснить, что имею ввиду:
1й уровень: написание какой либо базовой конструкции (к примеру тот же sort). Когда делаешь это в первый раз, то в этом есть элемент творчества. Но после того как это уже отскакивает от зубов и наступает рутина / автоматизм / действия более в режиме подсознания (каждый раз делаешь, одинаково, т.к. уже все продумано до мелочей, и думать над данной конструкцией уже не требуется)
2й уровень: это когда из базовых конструкций производится по сути компоновка и между ними налаживаются связи (т.е. что-то уже похожее на определение "система" или около того). Здесь опять же на каком-то уровне возможен переход к автоматизму (те же паттерны программирования, как пример, если сразу видишь какой из них использовать)
3й уровень: что то еще ...
Так вот, Илья предлагает, максимально уйти от творчества на 1ом уровне. По крайней мере я так его идею понимаю.
И еще хочу сказать защиту Ильи, что его общение на форуме всегда максимально корректное. Ни одного негативного момента за долгое время пребывания на форуме я не видел, Вы первый кто воспринял его крайне негативно. Про и21 того же самого сказать не могу, но вполне могу и его понять, поэтому не отношусь негативно.
-
А у меня сложилось впечатление, что Ермаков понимает творчество почти также как Вы. Просто он пытается повысить уровень элементов для творчества. Попробую объяснить, что имею ввиду:
1й уровень: написание какой либо базовой конструкции (к примеру тот же sort). Когда делаешь это в первый раз, то в этом есть элемент творчества. Но после того как это уже отскакивает от зубов и наступает рутина / автоматизм / действия более в режиме подсознания (каждый раз делаешь, одинаково, т.к. уже все продумано до мелочей, и думать над данной конструкцией уже не требуется)
Вот здесь и не соглашаюсь ни с ним, ни с Вами. Рутина начинается тогда, кода в работу не вкладывают душу (перестают вкладывать, становится не интересно). Но это совсем не означает, что "тема исчерпана", исчерпано определённое видение темы, определённый взгляд на тему. Вполне возможно, что пройдёт какое-то время и... тема раскроется совсем иначе, и то, что казалось незыблемо правильным... вызовет усмешку... над собственной наивностью. Это не означает, что надо всю жизнь посвятить какой-то одной мелкой проблеме, это означает, что рутина - это проблема не темы, а человека. Большое раскрывается в малом... малое в большом... но это надо увидеть.
Так вот, Илья предлагает, максимально уйти от творчества на 1ом уровне. По крайней мере я так его идею понимаю.
И я его также понимаю и... не соглашаюсь с этим. Да, надо переключаться, надо строить разные уровни, но если душа просит... надо найти время и позаниматься старой замшелой задачкой...
И еще хочу сказать защиту Ильи, что его общение на форуме всегда максимально корректное. Ни одного негативного момента за долгое время пребывания на форуме я не видел, Вы первый кто воспринял его крайне негативно.
У нас с ним очень разное мировоззрение... И, если говорить о негативе, то негативно я воспринял действия администрации оберонкоре, его модераторов, куда, как я понимаю, относится и И. Ермаков. Ссылки на незнание и прочее меня не удовлетворяют... я хорошо знаю пословицу: "Ворон ворону глаз не выклюет". Никаких извинений на форуме от лица администрации высказано не было, значит это не является недоразумением, значит это политика, то есть, согласованные действия администрации. Никакого особого мнения И. Ермакова на форуме оберонкоре я тоже не видел... А Вы видели?.. Или Вы считаете действия той администрации правильными?..
Про и21 того же самого сказать не могу, но вполне могу и его понять, поэтому не отношусь негативно.
Это Ваше право понимать или не понимать... относится позитивно или негативно... но, и мне, уж, оставьте право иметь свою точку зрения. На этом, я надеюсь, данный вопрос вопрос закрыт!..
-
Так вот, Илья предлагает, максимально уйти от творчества на 1ом уровне. По крайней мере я так его идею понимаю.
Но почему то он предлагает все это раз за разом писать руками. То есть один раз написать библиотеку алгоритмов (обобщенных) и постепенно ее пополнять, избавив человека таким образом от рутины, он не хочет. Считает что цена такого решения слишком велика.
Ну, то есть экскаватор слишком сложный и не надежный. Ну и вообще в гараже его не каждый повторить сможет, потому котлован будем копать по старинке - кирками и лопатами.
То же, кстати, и паттернов программирования касается. Паттерны начинаются там, где кончается выразительность языка.
-
Языковые эксперименты очень дороги (требуют, фактически, оторваться от других задач и заняться реализацией языка...)
Эксперименты на уровне паттернов, создания каркасов и т.п. - доступны каждому.
Поэтому нужно развивать культуру-опыт решения разных проблем без изменений языка. Любой пример того, как что-то языковое можно сделать достаточно вменяемо без спец. языковых средств, надо считать очень ценным. ("сделать" - имеется в виду реализовать библиотечно-каркасно-паттерново...)
Противоположная точка зрения приводит к поддержанию разрыва между экспериментами и практикой... Есть создатели языков, занимающиеся "высоким", и есть остальные инженеры, ждущие от них "манны небесной". Манна бывает редко, потому что путь языка от лаборатории до практической применимости и достаточной "критической массы" - очень долгий.
-
Не в тему но хочется высказаться:
Спасибо за поддержку. Вы меня правильно поняли.
2 alexus:
По поводу "тема раскроется совсем иначе".
Я ровно это же и говорил где-то тут на форуме. Что всегда, когда фронт интересных задач смещается вперёд, кто-то продолжает заниматься серьёзно и на "старой линии". И там бывают новые открытия.
Но из этого никак не следует, что все должны стоять на старой линии и тратить своё время на решение того, что уже решено... И может быть переведено на автоматизм.
(вот пример "удобства" не модерируемых на разделение тем форумов... фиг найдёшь, где что было сказано).
-
Языковые эксперименты очень дороги (требуют, фактически, оторваться от других задач и заняться реализацией языка...)
Эксперименты на уровне паттернов, создания каркасов и т.п. - доступны каждому.
А при чем тут языковые эксперименты? Берем любой язык высокого уровня и там спокойно пишем обобщенные варианты алгоритмов тех же. И обобщенные каркасы. Языки высокого уровня это позволяют.
-
Пардон, надо было точно процитировать кусок, на который отвечаю:
То же, кстати, и паттернов программирования касается. Паттерны начинаются там, где кончается выразительность языка.
По остальному - дискуссионный вопрос... Лично я пока не готов принять обобщённое программирование, в той форме, как оно имеется. Какой-то минимум выделить если только...
-
Только здесь не так просто, как на схеме из курса электронных приборов. Там есть правильный вход, правильный выход и отрицательная обратная связь, стабилизирующая преобразование сигнала. В рограммировании (и много где ещё) выход нам не даётся априори. Мы должны понять, куда прийти.
Можно пояснить, что имелось ввиду, под неизвестностью выхода?.. Если мы пишем программу, то мы должны гарантировать при правильных исходных данных правильный результат.
Допустим, мы в ситуации, когда мы в состоянии сформировать любой набор входных данных (вход) в зависимости от того, к чему мы должны прийти (выход, резульат). Тогда единственной проблемой в условии является понимание результата. Не всегда с первого или второго раза удаётся понять, что же всё-таки нужно. Для этого делаются прототипы. При работе над ними проясняется ситуация с тем, что должно быть на выходе.
Неизвестность выхода - это, наверно, было слишком грубо. Точнее было бы сказать, что на начальной стадии новой задачи понятие о выходе у разарботчика нечёткое.
Почему "при использовании sort - ноль творчества"? Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?.. Это напоминает разговор с И. Ермаковым, который тоже как-то одномерно понимает творчество. Если есть хороший/пригодный для данных условий элемент, то его не надо выбрасывать и пересоздавать заново, надо его использовать. Но при этом не надо навсегда закрывать тему разработки этих элементов.
Вообще-то я редко когда упускаю возможность решить задачу своими силами, а не стандартными средствами. И уж кто-кто, а я точно не закрываю тему разарботки.
Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?
Нет, не перестаёт. Но у него другая задача. Задача выбора, компоновки и т.д.
Вот, допустим, по конвейеру ползёт печатная плата. На ней не хватает элемента - автоматика его не ставит в виду его специфики. Это делает рабочий. Он ставит элемент на плату и всё, даже пайкой занимается дальше автоматика. Много ли здесь творчества? Как долго он будет считать, что занимается творчеством?
Осознание, что нужна сортировка - это одна задача. Выбор сортировок - другая. Они все решены. Теперь перед программистом задача - задействовать сортировку. Ему нужно написать sort и передать параметры. Или написать mySort и передать параметры. Но чтобы mySort заработал, его сначала нужно написать. Это ещё несколько подзадач, которые могут оказаться весьма творческими (или процесс творчества наложит на программиста эмоциональные отпечатки разной силы). Но процесс написания приводит к прояснению конечного результата. Он становится более чётким, и беспристастный наблюдатель заметит, что процесс создания mySort лишь частично решает задачу, а многие действия по отношению к настоящему итогу бесполезны или даже вредны. Беспристрастный наблюдатель легко откажется от неправльного решения, а тот, кто написал, - будет сопротивляться.
Поэтому весьма желательно, чтобы код сам по вебе не являлся результатом творчества. А лучше бы этим резульатом было нечто, что трансформируется в код. Тогда отказываться от своей реализации чего-то-там будет гораздо проще: результат творчества не уничтожается.
-
Но при этом не надо навсегда закрывать тему разработки этих элементов.
Речь не о закрытии темы. А вот в чём:
Да, надо переключаться, надо строить разные уровни, но если душа просит... надо найти время и позаниматься старой замшелой задачкой...
"Надо переключаться"... Вот что главное. Без этого если программа и выйдет, то работать будет едва-едва.
Фарш в коде, отсутствие чёткой структуры. Думаете, это стоит терпеть, если это становится следствием "душа просит"?
И в отличие от "душа просит" переключениям нужно учить. Без ограничений в этом плане просьбы души будут распространяться во все направления. Как расширение вселенной. Только результат будет не таким организованным...
-
По поводу "тема раскроется совсем иначе".
Я ровно это же и говорил где-то тут на форуме. Что всегда, когда фронт интересных задач смещается вперёд, кто-то продолжает заниматься серьёзно и на "старой линии". И там бывают новые открытия.
Может быть здесь об этом шла речь:
Давайте будем из года в год считать нажатие педалей и игру дворовыми аккордами - творчеством. Пусть каменщик творчески рубит киркой камень. Мы никогда не признаем это рутиной, не заменим на технологию - и не позволим каменщику стать архитектором и творить что-то большое.
Пусть люди не видят за деревьями леса и проявляют свою индивидуальность в очередном куске кода. Вместо того, чтобы избавиться от необходимости даже думать об этом куске, и заняться действительно интересными задачами, которые ждут своего открывателя.
А борьбой с велосипедостроением всегда занимаются как раз "мейнстримщики", панически боящиеся написания своего сложного кода, вместо применения библиотек, потому что понимают, что он будет содержать море ошибок.
:) Если нет потребности "даже думать об этом куске кода"... а надо заняться "действительно интересными задачами", то это нечто противоположное тому, о чём говорю я...
Но из этого никак не следует, что все должны стоять на старой линии и тратить своё время на решение того, что уже решено... И может быть переведено на автоматизм.
Конечно... Проблема многих горе-руководителей в том, что им кажется, что именно то, что интересно им... интересно и полезно всем... И "всех" рано и поздно это "устраивает"... думать о том, что такому руководителю не интересно, иметь свою точку зрения - преступление!.. Что вполне согласуется с логикой... действия администрации... соседнего форума. Согласных (и даже защищающих администрацию) не в пример больше, чем несогласных. Для людей "нетворческих" важен порядок... а люди творческие всегда были "возмутителями спокойствия"... Антуан де Сент-Экзюпери замечательно сказал: "Жизнь творит порядок, но порядок жизнь не творит".
(вот пример "удобства" не модерируемых на разделение тем форумов... фиг найдёшь, где что было сказано).
Как видите... нашёл... легко... в этом же топике... А вот там где поделили... времени на поиск уходит куда больше.
-
Я ровно это же и говорил где-то тут на форуме. Что всегда, когда фронт интересных задач смещается вперёд, кто-то продолжает заниматься серьёзно и на "старой линии". И там бывают новые открытия.
Но из этого никак не следует, что все должны стоять на старой линии и тратить своё время на решение того, что уже решено... И может быть переведено на автоматизм.
(вот пример "удобства" не модерируемых на разделение тем форумов... фиг найдёшь, где что было сказано).
http://oberspace.dyndns.org/index.php/topic,184.msg3197.html#msg3197
Нашлось легко :-)
Та тема не перегружена совершенно. Странно что ты там свое же высказывание не смог найти. (а вот если слить все ветки похожего в одну тему - то получим тему страниц на 15ть. оно нам надо?). Вообще, если кажется что мысль ценная, и затеряется в потоке обсуждаемого, то берешь самостоятельно, и оформляешь новую тему (со ссылками и цитатами на сообщения к которые послужили первоисточником/подтолкнули/на которые отвечаешь). Не вижу проблем :-)
Да, а нянек тут нет. Никто сопли утирать не будет. Это вам не детский сад или школа, это заведение для более взрослых индивидумов ;-)
-
Неизвестность выхода - это, наверно, было слишком грубо. Точнее было бы сказать, что на начальной стадии новой задачи понятие о выходе у разарботчика нечёткое.
Для этого и существуют стадии моделирования (в том числе, и прототипирование) и проектирования. К моменту начала разработки/создания программы неясности должны быть устранены и общее видение решения должно быть закреплено в документах (приложениях к техническому заданию, решениях согласительных комиссий и т.п.).
Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?
Нет, не перестаёт. Но у него другая задача. Задача выбора, компоновки и т.д.
Вот, допустим, по конвейеру ползёт печатная плата. На ней не хватает элемента - автоматика его не ставит в виду его специфики. Это делает рабочий. Он ставит элемент на плату и всё, даже пайкой занимается дальше автоматика. Много ли здесь творчества? Как долго он будет считать, что занимается творчеством?
Это очень простой вопрос... Дело не в работе, дело в человеке, в его отношении к работе. Помните героя Алексея Владимировича Баталова в фильме "Москва слезам не верит"... Георгия Ивановича (он же Гоша, он же Гога...). Вроде бы слесарь... какое творчество у слесаря... но он единственный на всю Москву... И к делу он подходит не так, как все, и за женщиной ухаживает, как-то не совсем... "стандартно"... И Ваш монтажник может позёвывая взять очередную плату и полусонно поводить паяльником... а может очередную "блоху подковать". Нет не творческой работы, есть не творческое или рутинное отношение к работе.
Осознание, что нужна сортировка - это одна задача. Выбор сортировок - другая. Они все решены. Теперь перед программистом задача - задействовать сортировку. Ему нужно написать sort и передать параметры. Или написать mySort и передать параметры. Но чтобы mySort заработал, его сначала нужно написать. Это ещё несколько подзадач, которые могут оказаться весьма творческими (или процесс творчества наложит на программиста эмоциональные отпечатки разной силы). Но процесс написания приводит к прояснению конечного результата. Он становится более чётким, и беспристастный наблюдатель заметит, что процесс создания mySort лишь частично решает задачу, а многие действия по отношению к настоящему итогу бесполезны или даже вредны. Беспристрастный наблюдатель легко откажется от неправльного решения, а тот, кто написал, - будет сопротивляться.
Откажется - не откажется... это не имеет отношения к творчеству. Я часто сначала пишу сам, даже зная, что есть под рукой хорошие алгоритмы/компоненты. Потом, когда уже написано, когда есть удовлетворение от хорошо сделанной работы... я смотрю на другие варианты и восхищаюсь, либо тем, что сделано другими, или тем, что сам сделал. Пока сам не прочувствуешь материал, душу в него не вложишь, понять и оценить любое решение невозможно... можно только поверить... на слово.
Поэтому весьма желательно, чтобы код сам по вебе не являлся результатом творчества. А лучше бы этим резульатом было нечто, что трансформируется в код. Тогда отказываться от своей реализации чего-то-там будет гораздо проще: результат творчества не уничтожается.
Был у меня один программист... интересный парень. Задачу ему поставишь, объяснишь... согласуешь. И он уходит. На следующий день проходишь мимо, он с задумчивым видом в потолок смотрит. Спрашиваю: "Чем занимаешься? Почему не пишешь? Вроде мы всё уже обсудили, да, и сроки поджимают...". А он отвечает: "Имя для переменной придумываю...". И может так долго придумывать... но код у него получался... хоть на выставку посылай... Такой код автоматически получить никогда не получится...
-
Был у меня один программист... интересный парень. Задачу ему поставишь, объяснишь... согласуешь. И он уходит. На следующий день проходишь мимо, он с задумчивым видом в потолок смотрит. Спрашиваю: "Чем занимаешься? Почему не пишешь? Вроде мы всё уже обсудили, да, и сроки поджимают...". А он отвечает: "Имя для переменной придумываю...". И может так долго придумывать... но код у него получался... хоть на выставку посылай... Такой код автоматически получить никогда не получится...
Да, ситуация знакомая-умение ВИДЕТЬ довольно редкое и крайне плохо развивается- да и с точки зрения управляемости , такие кадры не очень ценны :) -возни как с группой , выхлоп нерегулярный...
-
Был у меня один программист... интересный парень. Задачу ему поставишь, объяснишь... согласуешь. И он уходит. На следующий день проходишь мимо, он с задумчивым видом в потолок смотрит. Спрашиваю: "Чем занимаешься? Почему не пишешь? Вроде мы всё уже обсудили, да, и сроки поджимают...". А он отвечает: "Имя для переменной придумываю...". И может так долго придумывать... но код у него получался... хоть на выставку посылай... Такой код автоматически получить никогда не получится...
Да, ситуация знакомая-умение ВИДЕТЬ довольно редкое и крайне плохо развивается- да и с точки зрения управляемости , такие кадры не очень ценны :) -возни как с группой , выхлоп нерегулярный...
Был у меня в жизни человек... Директор проектной организации, они оснастку делали для строителей... Имели много наград, государственных, в том числе (точно знаю, что премия КабМина СССР у них была). Так вот там только такие "нестандартные" и приживались. Но и сам директор был совсем не стандартный. Такой организации творческого процесса больше я нигде не видел. Описывать долго, но... я к тому, что управлять можно и творческим процессом. Правда, понятие "управлять" требует другого взгляда... не одномерное оно... В том смысле, что управлять и командовать - это не синонимы... и руководитель не всегда начальник...
-
В том смысле, что управлять и командовать - это не синонимы... и руководитель не всегда начальник...
А кстати, да. Ведущий разработчик - он именно что ведущий, а не командующий. Я бы даже сказал - вдохновляющий.
-
В том смысле, что управлять и командовать - это не синонимы... и руководитель не всегда начальник...
А кстати, да. Ведущий разработчик - он именно что ведущий, а не командующий. Я бы даже сказал - вдохновляющий.
Тут много вариантов. Ведущий разработчик по должности, может быть один человек, а по факту совсем другой (и это совсем не то, что понимается под лидером, скажем в ИСО:9000). В хорошей команде важны не должности, а роли... В разных хороших командах роли могут совсем разными. И попытки "втиснуть" человека в роль... обречены.
-
Языковые эксперименты очень дороги (требуют, фактически, оторваться от других задач и заняться реализацией языка...)
Эксперименты на уровне паттернов, создания каркасов и т.п. - доступны каждому.
Не совсем правда. Языковые эксперменты тоже дешевы в том смысле, что уже существуют разные ЯП дошедшие до практической применимости и достаточной "критической массы". Понятно, что сходу взять и скобмбинировать не получится. Но тем не менее. Имея опыт и с тем и с другим можно достаточно легко оценивать вновь появляющиеся. И более смело экспериментировать со своим "идеальным ЯП". Уже не раз говорил - Вирту, по моему мнению, очень не хватает знакомства с современными языками за пределами паскаль линейки и за пределами их синаксиса. Не потому, что он сразу бы нафаршировал свой оберон. Просто была бы какая-то вероятность качественного скачка в другую "оптимальную точку".
-
Я сомневаюсь, что Вирт не знаком с новыми языками.
Просто уже не тот возраст на "скачки". Он предоставил ядро определённого класса, дальше всё в наших руках...
Насколько можно следить за его интересами, на пенсии его интересуют ПЛИС, генерация топологий и soft-CPU.
-
Я сомневаюсь, что Вирт не знаком с новыми языками.
Есть ссылки, где он отзывается о других языках за пределами их синтаксиса? Я ни разу не видел. Либо говорится об опыте Модулы и более древних ЯП (когда он начинал), либо придирки к "=" vs ":=" и т.п. "corrupted syntax".
Просто уже не тот возраст на "скачки". Он предоставил ядро определённого класса, дальше всё в наших руках...
Насколько можно следить за его интересами, на пенсии его интересуют ПЛИС, генерация топологий и soft-CPU.
Ну я себе тоже так и представляю, судя по его последним работам...
-
Насколько можно следить за его интересами, на пенсии его интересуют ПЛИС, генерация топологий и soft-CPU.
Обероноподобный язык смог бы реализовать свой потенциал полностью, как часть триединой системы ЦПУ-ОС-ЯП. Сделать бы проц по типу эльбруса, который вместо С исполнял бы Модула-2/Оберон - низкоуровневые инструкции аппаратно + ОС типа голубой бутылки - получилось бы самое оно.
-
Обероноподобный язык смог бы реализовать свой потенциал полностью, как часть триединой системы ЦПУ-ОС-ЯП. Сделать бы проц по типу эльбруса, который вместо С исполнял бы Модула-2/Оберон - низкоуровневые инструкции аппаратно + ОС типа голубой бутылки - получилось бы самое оно.
Собственно, Вирт это и делает, как я понял. Только оно узкоспециализировнное получается. А вам для чего? :)
-
Собственно, Вирт это и делает, как я понял. Только оно узкоспециализировнное получается. А вам для чего? :)
Могло бы быть и широкоспециализированным. Есть универсальный язык для программирования, начиная от системного и заканчивая скриптами, среда ОС и процессор, непосредственно аппаратно исполняющий языковые инструкции - имхо, именно так должна выглядеть идеальная система и только Оберон годится для ее построения, а не, прости господи , всякие NET'ы.
-
Собственно, Вирт это и делает, как я понял. Только оно узкоспециализировнное получается. А вам для чего? :)
Могло бы быть и широкоспециализированным.
Так не бывает :) Или монстр, который пытается уметь все, или что-то узкоспециализированное (и, возможно, простое). Виртовский оберон - это болванка для будущего узкоспециализированного (т.е. простое и без специфики). Берем железку под задачу, узкоспециализируем оберон, получаем профит! :)
-
Виртовский оберон - это болванка для будущего узкоспециализированного (т.е. простое и без специфики). Берем железку под задачу, узкоспециализируем оберон, получаем профит! :)
Точнее - РАСШИРЯЕМ (понижать некуда)в желаемую область ...
-
Языковые эксперименты очень дороги (требуют, фактически, оторваться от других задач и заняться реализацией языка...)
Эксперименты на уровне паттернов, создания каркасов и т.п. - доступны каждому.
Поэтому нужно развивать культуру-опыт решения разных проблем без изменений языка. Любой пример того, как что-то языковое можно сделать достаточно вменяемо без спец. языковых средств, надо считать очень ценным. ("сделать" - имеется в виду реализовать библиотечно-каркасно-паттерново...)
Противоположная точка зрения приводит к поддержанию разрыва между экспериментами и практикой... Есть создатели языков, занимающиеся "высоким", и есть остальные инженеры, ждущие от них "манны небесной". Манна бывает редко, потому что путь языка от лаборатории до практической применимости и достаточной "критической массы" - очень долгий.
И тут на помощь страждущим приходят...
Правильно! МАКРОСЫ!!!
-
Насколько можно следить за его интересами, на пенсии его интересуют ПЛИС, генерация топологий и soft-CPU.
Обероноподобный язык смог бы реализовать свой потенциал полностью, как часть триединой системы ЦПУ-ОС-ЯП. Сделать бы проц по типу эльбруса, который вместо С исполнял бы Модула-2/Оберон - низкоуровневые инструкции аппаратно + ОС типа голубой бутылки - получилось бы самое оно.
Был подобный проект у того же Интела -- "Ада-процессор" http://ru.wikipedia.org/wiki/Intel_iAPX_432
Ну и куча разных микроконтроллеров со встроенной ява-машиной тоже есть...
-
Был подобный проект у того же Интела -- "Ада-процессор" http://ru.wikipedia.org/wiki/Intel_iAPX_432
Ну и куча разных микроконтроллеров со встроенной ява-машиной тоже есть...
Как впрочем и java - процессор...