Re[12]: Сложность - Образование и наука

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

EP> dot>Видео не смотрел, но по выдержке можно заметить, что могут быть разные цели.
EP> Согласен, но в большинстве случаев не нужно никакого "C first" при обучении.
+1

EP> Об этом кстати и Страуструп говорит, и не только говорит — но ещё и не одну сотню реальных студентов так обучал, и даже книжку по C++ выпустил для новичков в программировании вообще.
Я бы удивился, если бы Страуструп стал проталкивать Питон...

EP> dot>Если учить именно алгоритмам — то лучше взять какой-нибудь более простой язык Питон, какой-нибудь, или даже Яву.
EP> Смешно. На них даже обычный swap это целая проблема.
Прикалываешься что-ли? А что за алгоритм такой — swap?? Не надо путать алгоритмы и детали их реализации на конкретном языке.

EP> dot>А С учат как ассемблер — чтобы было видно как это всё работает на уровне железа.
EP> Для этого учат напрямую ассемблер

Который из?? Их столько, что ну нафиг, слишком много деталей.
А вот с т.з. теории — С вполне работает близко к фон-неймановской модели.

EP> А C++ например учат дизайнеры из "Parsons The New School for Design"
Хых. Зачем дизайнерам плюсы?

avalon/1.0.432

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

EP>> Об этом кстати и Страуструп говорит, и не только говорит — но ещё и не одну сотню реальных студентов так обучал, и даже книжку по C++ выпустил для новичков в программировании вообще.
dot>Я бы удивился, если бы Страуструп стал проталкивать Питон...

Речь не об этом, а том как он обучает — там никакого "C First".

EP>> dot>Если учить именно алгоритмам — то лучше взять какой-нибудь более простой язык Питон, какой-нибудь, или даже Яву.
EP>> Смешно. На них даже обычный swap это целая проблема.
dot>Прикалываешься что-ли? А что за алгоритм такой — swap?? Не надо путать алгоритмы и детали их реализации на конкретном языке.

Простейший алгоритм

Можно взять и не простой — например quicksort для произвольных объектов.

EP>> dot>А С учат как ассемблер — чтобы было видно как это всё работает на уровне железа.
EP>> Для этого учат напрямую ассемблер

dot>Который из?? Их столько, что ну нафиг, слишком много деталей.

Обычно соответствующий используемому железу.

dot>А вот с т.з. теории — С вполне работает близко к фон-неймановской модели.

Он всё же прилично абстрагирует железо.

EP>> А C++ например учат дизайнеры из "Parsons The New School for Design"
dot>Хых. Зачем дизайнерам плюсы?

За производительностью вестимо

A>Молодцы. А кто-то до сих пор учит по Bullshildt'у.

А кто-то в в 2015-ом году Убунту установить не в состоянии.

Оттуда:

Скачал iso, скопировал на флешку — флешка не грузится. Странно, подумал я, для установки win7 достаточно просто скопировать файлы, но тут линух, наверное надо копировать по хитрому.
Нагуглил что есть pendrivelinux.com, скачал оттуда прогу, залил залил ей iso на флешку — флешка не грузится.
Погуглил еще, нашел win32diskimager, записал им iso на флешку — ура! загрузилось.

И там полно еще такой хрени!

Вывод: в чужом глазу соринку видишь, в своем бревна не замечаешь.

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

Можно ещё послушать cppcast с ней же

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

A>·>Видео не смотрел, но по выдержке можно заметить, что могут быть разные цели.
A>Цель — это обучение людей которые будут работать на должности "разработчик С++", или будут поддерживать код на С++.
Как-то банально. Если мы учим на С++-разработчика, то мы должны учить языку С++. А если цель будет "разработчик С"? Да и вообще какая-то странная цель. Скорее должно быть "Разработчик ПО".

A>Речь не идет об обучении программированию вообще, речь о том, чтобы люди могли взять какой-то проект, написанный на современном С++, и прикрутить к нему новую фичу.
A>Типа программист С++ уволился, менеджмент решает что проще научить программиста JS поддерживать оставшийся код на С++. А там всякие "a*", "*b", "b->", "a::", "&b" — C++ такой сложный язык!
A>И Kate Gregory объясняет, что если всё учить в правильном порядке, то оказывается что всё очень просто, можно обойтись без игр "а добавлю-ка я звездочку с этой строны, вдруг соберется"
С и правда на порядки проще, чем С++.

Здравствуйте, Олег К., Вы писали:

A>>Молодцы. А кто-то до сих пор учит по Bullshildt'у.

ОК>А кто-то в в 2015-ом году Убунту установить не в состоянии.
ОК>Вывод: в чужом глазу соринку видишь, в своем бревна не замечаешь.

О как у тебя припекло с Bullshildt'а!
Но какая же у тебя хорошая память, раз ты этот этот топик про убунту вспомнил.

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

A>Посмотрел первые 20 минут, и я подпишусь под каждым словом, которое она говорит.

да, все правильно.
вот только С++ от этого не перестанет быть С-с-костылями и арсеналом для отстреливания ног

поэтому учить надо С# а не членовредительское говно мамонта.
для низкоуровневых вещей — как раз таки чистый С.

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

EP>>> Об этом кстати и Страуструп говорит, и не только говорит — но ещё и не одну сотню реальных студентов так обучал, и даже книжку по C++ выпустил для новичков в программировании вообще.
dot>>Я бы удивился, если бы Страуструп стал проталкивать Питон...
EP>Речь не об этом, а том как он обучает — там никакого "C First".
А, понятно. Типа, если ты хочешь научить С++, то не следует начинать с С? Да, верная мысль.

EP>>> dot>Если учить именно алгоритмам — то лучше взять какой-нибудь более простой язык Питон, какой-нибудь, или даже Яву.
EP>>> Смешно. На них даже обычный swap это целая проблема.
dot>>Прикалываешься что-ли? А что за алгоритм такой — swap?? Не надо путать алгоритмы и детали их реализации на конкретном языке.
EP>Простейший алгоритм

А присвоение значения переменной — тоже алгоритм? Ещё более простейший?

EP>Можно взять и не простой — например quicksort для произвольных объектов.
И чем хуже Питон|Ява в этом случае? Даже swap двух элементов массива можно сделать.

EP>>> dot>А С учат как ассемблер — чтобы было видно как это всё работает на уровне железа.
EP>>> Для этого учат напрямую ассемблер

dot>>Который из?? Их столько, что ну нафиг, слишком много деталей.
EP>Обычно соответствующий используемому железу.
Железо меняется, да даже и обычный современный комп — там и 32 бита, и 64, и всякие simd, и прочее, а некоторые команды так вообще сделаны для эффективной компиляции ЯВУ.

dot>>А вот с т.з. теории — С вполне работает близко к фон-неймановской модели.
EP>Он всё же прилично абстрагирует железо.
Гораздо меньше, чем С++.

EP>>> А C++ например учат дизайнеры из "Parsons The New School for Design"
dot>>Хых. Зачем дизайнерам плюсы?
EP>За производительностью вестимо

Я думал графика в GPU уже переехала. Разве там плюсы?

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

DM>да, все правильно.
DM>вот только С++ от этого не перестанет быть С-с-костылями и арсеналом для отстреливания ног

DM>поэтому учить надо С# а не членовредительское говно мамонта.
DM>для низкоуровневых вещей — как раз таки чистый С.

В идиоматическом С++ ноги отстреливать нечем.
И да, поэтому С++ надо обучать именно с "смотри, это вектор, а это строка", а не с "смотри, это указатель, его можно складывать, а можно принудительно ретипизировать в флоат".

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

A>- при обучении С++, надо учить вещам, которые делают С++ С++

А еще лучше обучать сразу тому, что понадобится в продакшне, ага !

A>- не надо учить новичков сложным и непонятным вещам, по крайней мере не в 1й день обучения — char*, printf("%s%d%c"), etc

Как раз здесь ничего сложного нет.

KG путает две вещи — обучение программированию и обучение С++. Для первого С++ не нужен, слишком много информации и сразу. Для второго, естественно, Си не нужен.

A>- не надо учить Си, если есть более простые вещи в С++

Более краткие и выразительные не значит более простые. Практически всё в С++, что "проще", устроено очень сложно.

Наглядно и просто это две большие разницы.

A>- можно сразу написать vector<int> v; ...; n = count(v.begin(), v.end(), 42);
A> новички сразу поймут что это "вектор интов, мы передаем в count начало и конец v".

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

A> При этом новичкам не надо знать ни шаблоны, ни объекты, ни итераторы. Просто "начало" и "конец" коллекции — это интуитивно понятно.

Первая ошибка компилятора ввергает людей в ступор. Вот это "интуитивно" есть только у людей с опытом. У людей без опыта интуиция подсказывает совсем другое.

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

EP>Согласен, но в большинстве случаев не нужно никакого "C first" при обучении.

Вот дураки в Стенфорде, они прямо противоположный курс взяли.

EP>Об этом кстати и Страуструп говорит, и не только говорит — но ещё и не одну сотню реальных студентов так обучал, и даже книжку по C++ выпустил для новичков в программировании вообще.

Есть мнение, что студентам которых учит Страуструп вообще по барабану, с чего начинать.

dot>>Если учить именно алгоритмам — то лучше взять какой-нибудь более простой язык Питон, какой-нибудь, или даже Яву.
EP>Смешно. На них даже обычный swap это целая проблема.

Ужос, 90% людей в мире учились программированию на языках
1 паскаль
2 питон
3 фортран
4 лисп

Что интересно, это не мешает им переходить в С++ при необходимости и наличии желания. Как то так.

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

LVV>>Подумаешь, открытие...

LVV>>Да мы так уже лет 7-8 учим.

A>Молодцы. А кто-то до сих пор учит по Bullshildt'у.

Шылдт устарел. Нужно учить так, что бы не в консоли колупаться, а получать внятный визуальный результат.

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

EP>>Согласен, но в большинстве случаев не нужно никакого "C first" при обучении.
I>Вот дураки в Стенфорде, они прямо противоположный курс взяли.

Какой?

EP>>Об этом кстати и Страуструп говорит, и не только говорит — но ещё и не одну сотню реальных студентов так обучал, и даже книжку по C++ выпустил для новичков в программировании вообще.
I>Есть мнение, что студентам которых учит Страуструп вообще по барабану, с чего начинать.

В техасском аграрно-механическом какие-то особенные студенты?

dot>>>Если учить именно алгоритмам — то лучше взять какой-нибудь более простой язык Питон, какой-нибудь, или даже Яву.
EP>>Смешно. На них даже обычный swap это целая проблема.
I>Ужос, 90% людей в мире учились программированию на языках
I>1 паскаль
I>2 питон
I>3 фортран
I>4 лисп
I>Что интересно, это не мешает им переходить в С++ при необходимости и наличии желания. Как то так.

К чему это? Как это относится к контексту?

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

>·>Видео не смотрел, но по выдержке можно заметить, что могут быть разные цели.

A>Цель — это обучение людей которые будут работать на должности "разработчик С++", или будут поддерживать код на С++.

Браво — заменить инженеров на разработчиков С++. Добро пожаловать в ПТУ "С++ разработчик"

Поддерживать код — значит работать с имеющимся кодом. С++ в общей массе используется вперемешку с сишным подходом. Так вот сложилось.
Вот типичный плюсовый код — https://github.com/sphinxsearch/sphinx/blob/master/src/indexer.cpp

Ничего военного — сишные конструкции в полный рост. И вот именно с такими вещами и придется работать, ибо такого кода на нынешний день не менее 90%
Все эти новые стандарты пока что только в голове у гиков.

A>И Kate Gregory объясняет, что если всё учить в правильном порядке, то оказывается что всё очень просто, можно обойтись без игр "а добавлю-ка я звездочку с этой строны, вдруг соберется"

Ну да, правильный порядок — предположим, у новичка интуиция работает, как у девелопера с опытом

У неё типичный подход среди контор "С++ за 21 день", эти никогда не утруждали себя базовыми вещами, сразу высокий уровень, сразу абстрации, только хардкор !
На собеседовании оказывается, что реальные задачи вызывают дикий ужас и желание вернуть деньги за обучение.

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

dot>>Я бы удивился, если бы Страуструп стал проталкивать Питон...

EP>Речь не об этом, а том как он обучает — там никакого "C First".

А космонавтов то как готовят ! Вот где надо брать методики по обучению дошколят !!!!111расрас

EP>Простейший алгоритм

EP>Можно взять и не простой — например quicksort для произвольных объектов.

Я видел кучу людей, которых сразу на С++ готовили. Для них swap и квиксорт это нереальной сложности задачи.

dot>>А вот с т.з. теории — С вполне работает близко к фон-неймановской модели.
EP>Он всё же прилично абстрагирует железо.

Минимально. При чем несравнимо лучше любого широко применяемого ЯП, про С++ и говорить не приходится.

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

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

TB>В идиоматическом С++ ноги отстреливать нечем.

В идиоматическом С++ ноги отстреливаются при помощи
1. идиом
2. по ходу освоения идиом

TB>И да, поэтому С++ надо обучать именно с "смотри, это вектор, а это строка", а не с "смотри, это указатель, его можно складывать, а можно принудительно ретипизировать в флоат".

Главное найти студентов, которые будут обладать встроеным знанием, что такое вектор, а что такое строка.

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

EP>>>Согласен, но в большинстве случаев не нужно никакого "C first" при обучении.
I>>Вот дураки в Стенфорде, они прямо противоположный курс взяли.

EP>Какой?

Отказались от булшыта и начали преподавать именно с Си.

I>>Есть мнение, что студентам которых учит Страуструп вообще по барабану, с чего начинать.
EP>В техасском аграрно-механическом какие-то особенные студенты?

Именно !

I>>Что интересно, это не мешает им переходить в С++ при необходимости и наличии желания. Как то так.

EP>К чему это? Как это относится к контексту?

Непосредственно. Начинать с С++ == отстой.

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

I>В идиоматическом С++ ноги отстреливаются при помощи
I>1. идиом
I>2. по ходу освоения идиом

Не понял.

I>Главное найти студентов, которые будут обладать встроеным знанием, что такое вектор, а что такое строка.

Это намного проще, чем "вот указатель на символ, и за ним ещё дофига символов, а потом нолик в конце, а память под все символы надо выделять самому, а сколько — а хрен его знает".

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

dot>>>Я бы удивился, если бы Страуструп стал проталкивать Питон...
EP>>Речь не об этом, а том как он обучает — там никакого "C First".
I>А космонавтов то как готовят ! Вот где надо брать методики по обучению дошколят !!!!111расрас

Когда они были дошколятами их не вертели на центрифугах

EP>>Простейший алгоритм

EP>>Можно взять и не простой — например quicksort для произвольных объектов.
I>Я видел кучу людей, которых сразу на С++ готовили. Для них swap и квиксорт это нереальной сложности задачи.

Уход от темы. Да есть люди которым это всё не особо интересно, но причём тут C++?

dot>>>А вот с т.з. теории — С вполне работает близко к фон-неймановской модели.
EP>>Он всё же прилично абстрагирует железо.
I>Минимально.

Абстрагирует, причём прилично. Нужен минимум абстракций — начинай с nand'ов и триггеров.

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

Ещё раз, проблема не непосредственно в C, а в C first.

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

I>>А космонавтов то как готовят ! Вот где надо брать методики по обучению дошколят !!!!111расрас

EP>Когда они были дошколятами их не вертели на центрифугах

Правильно, подумай об этом. Вещи, которые простые для КГ, с её опытом, совершенно неочевидно, что окажутся простыми для аудитории.
Всё что она сказала это "мне просто, значит и другим просто".

I>>Я видел кучу людей, которых сразу на С++ готовили. Для них swap и квиксорт это нереальной сложности задачи.
EP>Уход от темы. Да есть люди которым это всё не особо интересно, но причём тут C++?

"видел кучу людей, которых сразу на С++ готовили"
Поделись, каким образом ты поставил диагноз "которым это всё не особо интересно" ?

EP>>>Он всё же прилично абстрагирует железо.
I>>Минимально.

EP>Абстрагирует, причём прилично. Нужен минимум абстракций — начинай с nand'ов и триггеров.

Не гони. Ни один из массовых ЯП не дает и близкого уровня абстраций. Если не согласен — назови как в твоём любимом С++ получить сравнимый уровень абстракции.

Ты снова начал передёргивать и увиливать. nand и триггеры это про железо УНУТРЕ. То есть, как оно устроено. Для программирования это точно не нужно, программирование == железо СНАРУЖИ.

Понятна разница ? УНУТРЕ и СНАРУЖИ это вещи прямо противоположные.

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

EP>Ещё раз, проблема не непосредственно в C, а в C first.

Нет такой проблемы.

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

I>>В идиоматическом С++ ноги отстреливаются при помощи
I>>1. идиом
I>>2. по ходу освоения идиом

TB>Не понял.

Идиома — итератор. Ноги отстреливаются при помощи итераторов и по ходу освоения этих итераторов.

I>>Главное найти студентов, которые будут обладать встроеным знанием, что такое вектор, а что такое строка.

TB>Это намного проще, чем "вот указатель на символ, и за ним ещё дофига символов, а потом нолик в конце, а память под все символы надо выделять самому, а сколько — а хрен его знает".

Нет никакого "просто". Есть количество понятий, которое должен освоить и закрепить студент прежде, чем ты расскажешь ему про вектор.
Скажем, в школе ему точно про строки и вектора рассказывают совсем другое. Типичный школьник уверен, что вектор это {x,y} и {x,y,z} и никогда в его опыте не встречалось "вектор переменной длины", "берем компоненту вектора с индексом 0" и тд и тд

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

I>>>А космонавтов то как готовят ! Вот где надо брать методики по обучению дошколят !!!!111расрас
EP>>Когда они были дошколятами их не вертели на центрифугах

I>Правильно, подумай об этом.

Так я и говорю что ~~детей~~начинающим программистам не нужно сразу ~~крутить на центрифугах~~давать C first

I>Вещи, которые простые для КГ, с её опытом, совершенно неочевидно, что окажутся простыми для аудитории.
I>Всё что она сказала это "мне просто, значит и другим просто".

А что трудного в std::vector или std::string? На начальном этапе это такая же магия как и malloc

I>>>Я видел кучу людей, которых сразу на С++ готовили. Для них swap и квиксорт это нереальной сложности задачи.
EP>>Уход от темы. Да есть люди которым это всё не особо интересно, но причём тут C++?
I>"видел кучу людей, которых сразу на С++ готовили"
I>Поделись, каким образом ты поставил диагноз "которым это всё не особо интересно" ?

А каким образом они тогда не осилили swap?

EP>>>>Он всё же прилично абстрагирует железо.
I>>>Минимально.
EP>>Абстрагирует, причём прилично. Нужен минимум абстракций — начинай с nand'ов и триггеров.
I>Не гони. Ни один из массовых ЯП не дает и близкого уровня абстраций. Если не согласен — назови как в твоём любимом С++ получить сравнимый уровень абстракции.

Я не говорил что в других языках такой же уровень абстракции как и в C

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

I>Ты снова начал передёргивать и увиливать.

С тобой как всегда неприятно общаться — сообщения не читаешь, постоянно срываешься на хамство

I>nand и триггеры это про железо УНУТРЕ. То есть, как оно устроено. Для программирования это точно не нужно, программирование == железо СНАРУЖИ.
I>Понятна разница ? УНУТРЕ и СНАРУЖИ это вещи прямо противоположные.

В этом контексте без разницы, совершенно. Под C многокилометровая магия компиляторов, runtime, OS, и т.д. и т.п.

I>>>Собтсвенно это и есть основное достоинство Си — внятное понимание, как работает вычислитель. Именно здесь нарабатывается та интуиция, которая пригодится и в С++, и в джаве, и питоне, и где угдно, дажев CSS
EP>>Ещё раз, проблема не непосредственно в C, а в C first.
I>Нет такой проблемы.

Всё удачи, твои аргументы как всегда весомые, идеи значимые и интересные, мысли трезвые и ясные, а уже манера общения

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

I>У неё типичный подход среди контор "С++ за 21 день", эти никогда не утруждали себя базовыми вещами, сразу высокий уровень, сразу абстрации, только хардкор !
I>На собеседовании оказывается, что реальные задачи вызывают дикий ужас и желание вернуть деньги за обучение.

"Не смотрел но осуждаю", да?
В видео говорилось о том как надо учить в первые дни обучения. О том что первые 10 дней из "21 дня" надо потратить на хороший С++, а потом уже учить плохому.

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

A>"Не смотрел но осуждаю", да?
A>В видео говорилось о том как надо учить в первые дни обучения. О том что первые 10 дней из "21 дня" надо потратить на хороший С++, а потом уже учить плохому.
Смотрел, но осуждаю. Зачем нужны плюсы, если ты не можешь протранслировать свой код в голове от начала до конца? Проще взять другой язык типа питона или явы и наслаждаться.

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

I>Идиома — итератор. Ноги отстреливаются при помощи итераторов и по ходу освоения этих итераторов.

А ок, да, в шарпике нет проблем сохранить ссылку на элемент вектора, а потом добавить в вектор новых элементов, согласен.

I>Нет никакого "просто". Есть количество понятий, которое должен освоить и закрепить студент прежде, чем ты расскажешь ему про вектор.
I>Скажем, в школе ему точно про строки и вектора рассказывают совсем другое. Типичный школьник уверен, что вектор это {x,y} и {x,y,z} и никогда в его опыте не встречалось "вектор переменной длины", "берем компоненту вектора с индексом 0" и тд и тд

Да назови это не "вектор", а "динамический массив", что сложного-то.

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

A>"Не смотрел но осуждаю", да?
A>В видео говорилось о том как надо учить в первые дни обучения. О том что первые 10 дней из "21 дня" надо потратить на хороший С++, а потом уже учить плохому.

Кто эти люди которых нужно учить эти первые дни, кто они ?
Откуда они знают, как работает вычислитель, та самая фон Неймановская архитектура ?

У ней подход "просто покажите и они поймут". Это значит, что она вещает в рассчете на подготовленную аудиторию, при чем довольно высокого уровня.

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

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

EP>Так я и говорю что ~~детей~~начинающим программистам не нужно сразу ~~крутить на центрифугах~~давать C first

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

I>>Вещи, которые простые для КГ, с её опытом, совершенно неочевидно, что окажутся простыми для аудитории.
I>>Всё что она сказала это "мне просто, значит и другим просто".
EP>А что трудного в std::vector или std::string? На начальном этапе это такая же магия как и malloc

Всё трудное — захочешь посмотреть поближе — вагон непонятного. Чуть ошибся — простыни ошибок. Вроде всё "как там" а не работает. А почему ?

I>>"видел кучу людей, которых сразу на С++ готовили"
I>>Поделись, каким образом ты поставил диагноз "которым это всё не особо интересно" ?
EP>А каким образом они тогда не осилили swap?

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

EP>>>Абстрагирует, причём прилично. Нужен минимум абстракций — начинай с nand'ов и триггеров.
I>>Не гони. Ни один из массовых ЯП не дает и близкого уровня абстраций. Если не согласен — назови как в твоём любимом С++ получить сравнимый уровень абстракции.

EP>Я не говорил что в других языках такой же уровень абстракции как и в C

Итак — ты признал что наилучший язык для освоения вычислителя это Си.

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

Начинаем сначала — какой массовый язык даёт лучший уровень абстракции ?

I>>Ты снова начал передёргивать и увиливать.
EP>С тобой как всегда неприятно общаться — сообщения не читаешь, постоянно срываешься на хамство

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

I>>nand и триггеры это про железо УНУТРЕ. То есть, как оно устроено. Для программирования это точно не нужно, программирование == железо СНАРУЖИ.
I>>Понятна разница ? УНУТРЕ и СНАРУЖИ это вещи прямо противоположные.

EP>В этом контексте без разницы, совершенно. Под C многокилометровая магия компиляторов, runtime, OS, и т.д. и т.п.

Разница очевидна — ни в одном ЯП ты не проверишь и не узнаешь, какие триггеры у процессора. Ни компилятор, ни ос, ни даже ассемблер тебе не дадут ответа.

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

I>>Нет такой проблемы.
EP>Всё удачи, твои аргументы как всегда весомые, идеи значимые и интересные, мысли трезвые и ясные, а уже манера общения

Ты заметь — была простая фраза, абсолютно нейтральная, а ты перешел на личности. Ты сам то понял, кто тут хамит ?

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

I>>Идиома — итератор. Ноги отстреливаются при помощи итераторов и по ходу освоения этих итераторов.
TB>А ок, да, в шарпике нет проблем сохранить ссылку на элемент вектора, а потом добавить в вектор новых элементов, согласен.

А при чем здесь `шарпик` ?

I>>Скажем, в школе ему точно про строки и вектора рассказывают совсем другое. Типичный школьник уверен, что вектор это {x,y} и {x,y,z} и никогда в его опыте не встречалось "вектор переменной длины", "берем компоненту вектора с индексом 0" и тд и тд

TB>Да назови это не "вектор", а "динамический массив", что сложного-то.

Слова `динамический` и `массив` им тоже непонятны.

Здравствуйте, С3141566=Z, Вы писали:

A>>В видео говорилось о том как надо учить в первые дни обучения. О том что первые 10 дней из "21 дня" надо потратить на хороший С++, а потом уже учить плохому.
СZ>Смотрел, но осуждаю. Зачем нужны плюсы, если ты не можешь протранслировать свой код в голове от начала до конца? Проще взять другой язык типа питона или явы и наслаждаться.

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

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

I>А при чем здесь `шарпик` ?

А чё?

I>Слова `динамический` и `массив` им тоже непонятны.

Ну на примере std::vector уже можно нормально объяснить.

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

TB>Здравствуйте, Ikemefula, Вы писали:
I>>А при чем здесь `шарпик` ?

TB>А чё?

Непонятна смена темы. Вроде про С++, а ты начал на какой то шарпик нападать. Неужели настолько сильно болит ?

I>>Слова `динамический` и `массив` им тоже непонятны.
TB>Ну на примере std::vector уже можно нормально объяснить.

Вектор это идиома. Рассуждения KG примерно такие "в продакшне весь код идиоматический, потому давайте обучать сразу с идиом".

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

То есть, фактически KG говорит, что С++ слишком сложен, что и его нельзя осваивать иначе, чем с идиом.

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

В других ЯП, а вобщем и языках естественных, путь обучения прямо противоположный — базовые вещи тренируются настолько долго, до автоматизма, что идиомы вырастают сами собой.

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

TB>В идиоматическом С++ ноги отстреливать нечем.

Поддержку любого проекта на С++ с произвольной степенью идеоматичности можно превратить в ад большим количеством способов.
Например, передавать объекты через границу модулей с разными CRT, а потом удалять их; линковать модули, собранные с разными настройками компилятора etc

Я, честно говоря, не знаю, как там в остальных языках с этим, но в душе надеюсь, что где-то есть островки счастья

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

I>Непонятна смена темы. Вроде про С++, а ты начал на какой то шарпик нападать. Неужели настолько сильно болит ?

Где ты видишь нападение? Или ты уже само слово "шарпик" считаешь нападением? У кого болит-то?

I>>>Слова `динамический` и `массив` им тоже непонятны.
TB>>Ну на примере std::vector уже можно нормально объяснить.

I>Вектор это идиома.

Офигеть, массивы в Паскале — тоже идиома, и тоже вредно?

I>В других ЯП, а вобщем и языках естественных, путь обучения прямо противоположный — базовые вещи тренируются настолько долго, до автоматизма, что идиомы вырастают сами собой.

То, что в других ЯП "базовое", в С++ — контейнеры, просто они не жёстко вшиты в язык, а реализованы, но это не значит, что надо начинать с подробностей реализации.

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

I>Вектор это идиома.
Как и void*. Из какой шанс попасть в ногу выше?

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

EP>>>> Об этом кстати и Страуструп говорит, и не только говорит — но ещё и не одну сотню реальных студентов так обучал, и даже книжку по C++ выпустил для новичков в программировании вообще.
dot>>>Я бы удивился, если бы Страуструп стал проталкивать Питон...
EP>>Речь не об этом, а том как он обучает — там никакого "C First".
dot>А, понятно. Типа, если ты хочешь научить С++, то не следует начинать с С? Да, верная мысль.

Да, именно так.

EP>>Можно взять и не простой — например quicksort для произвольных объектов.
dot>И чем хуже Питон|Ява в этом случае? Даже swap двух элементов массива можно сделать.

Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.
Он quick-то во многом благодаря этому, и используется по сей день (пусть и временами внутри introsort).

EP>>>> dot>А С учат как ассемблер — чтобы было видно как это всё работает на уровне железа.
EP>>>> Для этого учат напрямую ассемблер

dot>>>Который из?? Их столько, что ну нафиг, слишком много деталей.
EP>>Обычно соответствующий используемому железу.
dot>Железо меняется, да даже и обычный современный комп — там и 32 бита, и 64,

Пусть меняется, суть-то везде примерно одинаковая, и она ниже уровнем чем C.

dot>>>А вот с т.з. теории — С вполне работает близко к фон-неймановской модели.
EP>>Он всё же прилично абстрагирует железо.
dot>Гораздо меньше, чем С++.

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

EP>>>> А C++ например учат дизайнеры из "Parsons The New School for Design"
dot>>>Хых. Зачем дизайнерам плюсы?
EP>>За производительностью вестимо

dot>Я думал графика в GPU уже переехала. Разве там плюсы?

Там не только чистая графика. Чистая графика, сама по себе, не так часто встречается.

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

I>>Непонятна смена темы. Вроде про С++, а ты начал на какой то шарпик нападать. Неужели настолько сильно болит ?

TB>Где ты видишь нападение? Или ты уже само слово "шарпик" считаешь нападением? У кого болит-то?

Я вижу что в разговоре про С++ ты перешел на обсуждение какого то 'шарпика'. Что это за шарпик и почему ты решил говорить про него, а не про С++ ?

TB>>>Ну на примере std::vector уже можно нормально объяснить.
I>>Вектор это идиома.

TB>Офигеть, массивы в Паскале — тоже идиома, и тоже вредно?

Массивы в паскале встроены в язык.

I>>В других ЯП, а вобщем и языках естественных, путь обучения прямо противоположный — базовые вещи тренируются настолько долго, до автоматизма, что идиомы вырастают сами собой.

TB>То, что в других ЯП "базовое", в С++ — контейнеры, просто они не жёстко вшиты в язык, а реализованы, но это не значит, что надо начинать с подробностей реализации.

Начинать надо не с подробностей, а с базовых конструкций языка. Если это плохой способ, так и говори — С++ настолько всеобъемлющ, что иначе как идиоматически его нельзя даже преподавать.

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

I>>Вектор это идиома.
Ops>Как и void*. Из какой шанс попасть в ногу выше?

void* это никакая не идиома. Эдак у тебя void main(void) {} и вообще любая функция станет идиомой.

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

I>Я вижу что в разговоре про С++ ты перешел на обсуждение какого то 'шарпика'. Что это за шарпик и почему ты решил говорить про него, а не про С++ ?

Для сравнения.

I>Массивы в паскале встроены в язык.

И чо?

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

std::vector — чем не базовая конструкция языка С++? Зачем пудрить мозги тем, что на самом деле это шаблонный класс с перегруженными операторами?

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

I>>Я вижу что в разговоре про С++ ты перешел на обсуждение какого то 'шарпика'. Что это за шарпик и почему ты решил говорить про него, а не про С++ ?

TB>Для сравнения.

Поясни, что за логика, как её трактовать
1 В другом языке есть Х, следовательно в с++ хорошо
2 В другом языке есть Х, следовательно в с++ плохо
3 В другом языке есть Х, следовательно в с++ так же
4 Не знаю С++, потому хочу говорить про другой язык

Итого, чего ты имел ввиду ?

I>>Массивы в паскале встроены в язык.

TB>И чо?

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

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

TB>std::vector — чем не базовая конструкция языка С++? Зачем пудрить мозги тем, что на самом деле это шаблонный класс с перегруженными операторами?

Ты сам себе ответил, чем именно она не базовая. Если цель — подготовка инженера, то надо начинать от базовых к более сложным. Если цель — подготовка `каменщика`, то можно как хочешь давать.

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

I>Итого, чего ты имел ввиду ?

Я имел в виду, что в жаппке (раз у тебя подгорает от слова "шарпик") нету проблем с сохранением ссылок на элементы вектора.

I>Это значит, например, что конских сообщений об ошибках ты не увидишь.

Ну и, ну и?

I>Ты сам себе ответил, чем именно она не базовая.

У него интерфейс точно такой же, как у аналогичной базовой фичи в других языках, какая нахрен разница пользователю до того, что её можно реализовать средствами, если интерфейс тот же? Он будет страдать от сознания, что фича-то на самом деле не встроенная?

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

I>Минимально.

Но абстрагирует. Любой, плотно писавший на asm под что-то, скажет, что Си-это именно высокоуровневый ЯП,
очень сильно абстрагируюший железо, настолько, что и любой другой ЯП кажется не более абстрагирующим это
самое железо чем Си. И вообще, asm изучается для конкретных задач, для конкретных архитектур, решил задачу,
забыл про этот asm. То, что впаривают какие-то куски из каких-то asm-ов каких-то архитектур в учебных целях,
это вообще глупость.

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

I>>Итого, чего ты имел ввиду ?

TB>Я имел в виду, что в жаппке (раз у тебя подгорает от слова "шарпик") нету проблем с сохранением ссылок на элементы вектора.

Непонятно. В С++ чтото меняется, если в 'жаппке' нету какой то проблемы ? Или ты предлагаешь начинать изучение С++ с 'шарпика' и 'жаппки' ?

I>>Это значит, например, что конских сообщений об ошибках ты не увидишь.

TB>Ну и, ну и?

Сообщения об ошибке, как в С++, это один из демотиваторов у начинающих, а вовсе не какие то особые конструкции.

I>>Ты сам себе ответил, чем именно она не базовая.

TB>У него интерфейс точно такой же, как у аналогичной базовой фичи в других языках, какая нахрен разница пользователю до того, что её можно реализовать средствами, если интерфейс тот же? Он будет страдать от сознания, что фича-то на самом деле не встроенная?

Намекаешь, что перед С++ надо освоить парочку других языков или что ? При чем здесь другие языки ?
Говори про С++, не моешь, ничего не говори.
Страдать — будет. Например когда видит сообщения компилятора и не знает, как это понимать.

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

I>Непонятно. В С++ чтото меняется, если в 'жаппке' нету какой то проблемы ? Или ты предлагаешь начинать изучение С++ с 'шарпика' и 'жаппки' ?

В С++ проблема есть. Хранить ссылки на элементы нельзя после того, как с вектором что-то ещё сделали.

I>Сообщения об ошибке, как в С++, это один из демотиваторов у начинающих, а вовсе не какие то особые конструкции.

Даже безо всяких контейнеров (в коде из чисто базовых в твоём понимании вещей) компилятор может высрать 100-строчный бред в ответ на пропущенный знак.

I>Намекаешь, что перед С++ надо освоить парочку других языков или что ?

Как связано? Чем освоение С++ с вектора отличается от освоения паскаля с массива?

I>Страдать — будет. Например когда видит сообщения компилятора и не знает, как это понимать.

Так научить надо понимать. Как и в любом языке.

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

S>Здравствуйте, Ikemefula, Вы писали:
I>>Минимально.

S>Но абстрагирует.

Наверное тебя слово 'минимально' не устраивает, вроде бы согласен, но согласиться не можешь ?

> Любой, плотно писавший на asm под что-то, скажет, что Си-это именно высокоуровневый ЯП,

Я именно такой и есть — писал на асме несколько лет. Ни разу не считал Си высокоуровневым ЯП. Как то так

Для меня было всё прозрачно, один к одному, что в одну сторону, что в другую.

S>очень сильно абстрагируюший железо, настолько, что и любой другой ЯП кажется не более абстрагирующим это

Итого — ты не согласен на счет 'минимально' и хочешь уравнять уровень абстрации Си и любых других языков.
Это в корне неверно, разница Си и Си++, не говоря об управляемых языках, огромна.

В си все что у тебя есть сверху, это функции, операторы и разные конструкции.

Модель памяти — практически тот же ассемблер. Адресация — ровно то же. Более того, когда пишешь на асме, у тебя есть целая куча вещей, что бы сделать код 'как ЯВУ'.
Скажем, вызов ОО-метода с тз си и ассемблера выглядит практически одинаково.
call printout, offset message — вот ассемблер почти 30-тилетней давности, эквивалент printout(message)
В зависимости от модели памяти и тд будет правильный пролог и эпилог. Боле того, ООП тоже поддерживается, скажем, есть и наследование и многие другие вещи.

Кроме того, на асме можно абстрагироваться от многих вещей, как пролог и эпилог функции, порядок аргументов, переенное количество аргументов и тд и тд и тд.

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

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

TB>В С++ проблема есть. Хранить ссылки на элементы нельзя после того, как с вектором что-то ещё сделали.

"В идиоматическом С++ ноги отстреливать нечем" @
Теперь гораздо понянее, почему в ход пошли аргументы `жаппка` и `шарпик`.

I>>Сообщения об ошибке, как в С++, это один из демотиваторов у начинающих, а вовсе не какие то особые конструкции.

TB>Даже безо всяких контейнеров (в коде из чисто базовых в твоём понимании вещей) компилятор может высрать 100-строчный бред в ответ на пропущенный знак.

Даже хуже — я уже забыл, когда последний раз видел код без варнингов на плюсах. Ощущение, что все только говорят об этом на форумах. А стоит качнуть какой нибудь проект больше 10К строчек — опаньки !

I>>Намекаешь, что перед С++ надо освоить парочку других языков или что ?
TB>Как связано? Чем освоение С++ с вектора отличается от освоения паскаля с массива?

Мне непонятно, почему ты переходишь на другие языки.

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

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

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

I>"В идиоматическом С++ ноги отстреливать нечем" @
I>Теперь гораздо понянее, почему в ход пошли аргументы `жаппка` и `шарпик`.

Я сразу признал, что да, это проблема. Тебя так переклинило, что ты воспринял моё сообщение исключительно через призму когнитивного искажения "он не может говорить плохо о С++, наверняка в его сообщении есть скрытый подвох".

I>Даже хуже — я уже забыл, когда последний раз видел код без варнингов на плюсах. Ощущение, что все только говорят об этом на форумах. А стоит качнуть какой нибудь проект больше 10К строчек — опаньки !

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

I>Мне непонятно, почему ты переходишь на другие языки.

Я сравниваю, сравнивать нельзя что ли? Или ты не умеешь в аналогии?

I>В том то и дело, что надо. Вопрос только в том, как и какой должен быть результат.

Почему он будет сильно другой?

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

I>Наверное тебя слово 'минимально' не устраивает, вроде бы согласен, но согласиться не можешь ?

Нельзя быть чуть-чуть беременным. Си именно абстрагирует, а для этого из него выкидывается
всё именно низкоуровневое, что есть в любом asm, но точно то же делается в любом другом ЯП.

I>Итого — ты не согласен на счет 'минимально' и хочешь уравнять уровень абстрации Си и любых других языков.
I>Это в корне неверно, разница Си и Си++, не говоря об управляемых языках, огромна.

Любой высокоуровневый ЯП есть абстрактная вычислительная машина, любой asm есть машина реальная,
по сути можно говорить, что каждый высокоуровневый ЯП есть asm некоторого виртуального процессора.
(про Лисп это почти так и называлось). Си не является asm-ом реального процессора, значит он есть asm
процессора виртуального, как и любой другой ЯП. Так какой ЯП абстрагирует больше и какой меньше, и какой именно
CPU абстрагирует каждый из них? Кароче, высокоуровневый ЯП предназначен для отделения прогера от конкретного языка
конкретного железного CPU, и Си эту задачу выполняет также, как и perl, , то есть, все они абстрагируют железо одинаково.

I>В си все что у тебя есть сверху, это функции, операторы и разные конструкции.... много букофф.

Вы возьмите указатель в Си, что это? А это может быть куча всего в разных CPU. Точно такой же кучей всего
на разных CPU является ссыль в C++. Типы? Они по разному представлены в разных CPU, и в этом плане нет разницы
между Сишным типом long double и типом class Foo. Шаблоны? А чем они отличаются от препроцессора? А ничем кроме религиозных
предубеждений.

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

EP> Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.
EP> Он quick-то во многом благодаря этому, и используется по сей день (пусть и временами внутри introsort).
Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?
А это ты считаешь quicksort-м?

qsort (x:xs) = qsort (filter (<= x) xs) ++ [x] ++ qsort (filter (> x) xs)

EP> dot>>>Который из?? Их столько, что ну нафиг, слишком много деталей.
EP> EP>>Обычно соответствующий используемому железу.
EP> dot>Железо меняется, да даже и обычный современный комп — там и 32 бита, и 64,
EP> Пусть меняется, суть-то везде примерно одинаковая, и она ниже уровнем чем C.
Для курса обучения желательно использовать что-то что не менятеся.

EP> EP>>Он всё же прилично абстрагирует железо.
EP> dot>Гораздо меньше, чем С++.
EP> Допустим, но какая разница насколько меньше? И то и другое для новичка будет являтся магией. Это ты зная что там внутри видишь сколько уровней скрыто и каких, новичок же и там и там стоит на абстракциях за которыми чёрный ящик.
С очень удачный компромисс между железом и структурным программированием. Т.е. можешь вводить какие-то небольшие кусочки кода (функции) и их комбинировать, получая более сложные программы. Ассемблер же это просто команды для процессора — человеку сложно их понимать.
С++ это уже такая свалка всего, что за деревьями леса не видно.
Например. В С пишем "a = b" — это просто mov в железе. А в С++ может быть что угодно.

avalon/1.0.432

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

TB>Я сразу признал, что да, это проблема. Тебя так переклинило, что ты воспринял моё сообщение исключительно через призму когнитивного искажения "он не может говорить плохо о С++, наверняка в его сообщении есть скрытый подвох".

Плохая у тебя телепатия.

I>>Даже хуже — я уже забыл, когда последний раз видел код без варнингов на плюсах. Ощущение, что все только говорят об этом на форумах. А стоит качнуть какой нибудь проект больше 10К строчек — опаньки !

TB>У меня в Студии с w4 варнингов нет. А шизофреничные варнинги гцц исправлять нереально, и будь их аналоги в других языках — было бы то же самое и в других.

Ну да, вот так всегда, 'у меня всё работает'.

I>>Мне непонятно, почему ты переходишь на другие языки.
TB>Я сравниваю, сравнивать нельзя что ли? Или ты не умеешь в аналогии?

Вопрос того совсем не требует.

I>>В том то и дело, что надо. Вопрос только в том, как и какой должен быть результат.
TB>Почему он будет сильно другой?

Смотря кого ты готовить хочешь. Если инженера, который уже умеет программировать, это один вариант. А если студента, который вообще ничего не умеет — другой. Если ты хочешь 'научить что бы смог хоть чтото', еще один. А если "что бы взял ту либину и всунул в этот проект" — еще один.

Я например видел людей которых учили плюсам на этих идиомах, возникло ощущение, что они вообще ничего не умеют, ибо всё оказывается немного не таким, как их учили.

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

I>>Наверное тебя слово 'минимально' не устраивает, вроде бы согласен, но согласиться не можешь ?

S>Нельзя быть чуть-чуть беременным. Си именно абстрагирует, а для этого из него выкидывается
S>всё именно низкоуровневое, что есть в любом asm, но точно то же делается в любом другом ЯП.

Уровень абстракции и беременность для тебя одно и то же ? Браво !
В одном языке куча магии в компиляторе, в другом ничего такого нет — а уровень абстракции одинаковый ! Брависсимо !

I>>Итого — ты не согласен на счет 'минимально' и хочешь уравнять уровень абстрации Си и любых других языков.
I>>Это в корне неверно, разница Си и Си++, не говоря об управляемых языках, огромна.

S>Любой высокоуровневый ЯП есть абстрактная вычислительная машина, любой asm есть машина реальная,

Ты фактически утверждаешь, что раз ассемблер машинно ориентированый, то все остальные одинаково абстрактны.
Собтсвенно это и есть твоя ошибка. Они абстрактны, но уровень абстракции разный.

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

S>Вы возьмите указатель в Си, что это? А это может быть куча всего в разных CPU.

Прямо как в ассемблере

> Точно такой же кучей всего
S>на разных CPU является ссыль в C++. Типы? Они по разному представлены в разных CPU, и в этом плане нет разницы
S>между Сишным типом long double и типом class Foo.

Если речь про классы, то разница конская. С++ прячет столько деталей, что многие до скончания веков даже и не узнают и малой части

>Шаблоны? А чем они отличаются от препроцессора? А ничем кроме религиозных
S>предубеждений.

Шаблоны обладают полнотой по тьюрингу в отличие от препроцессора. Возможности принципиально разные.

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

I>void* это никакая не идиома. Эдак у тебя void main(void) {} и вообще любая функция станет идиомой.

При чем тут void main(void) {}?
А void* — это способ передачи хз чего куда угодно, вполне себе идиома.

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

Ops>При чем тут void main(void) {}?
Ops>А void* — это способ передачи хз чего куда угодно, вполне себе идиома.

эдак у тебя mov ax, bx идиомой станет.

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

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

А вот идиомой в Си будет класс, наследование, полиморфизм и тд. Тот же полиморфизм реализовывается в частном случае через void*.

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

I>А вот идиомой в Си будет класс, наследование, полиморфизм и тд. Тот же полиморфизм реализовывается в частном случае через void*.

Я это и имел в виду. И как тебе такой полиморфизм, полезнее для ног, нежели в плюсах?

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

EP>> Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.
EP>> Он quick-то во многом благодаря этому, и используется по сей день (пусть и временами внутри introsort).
dot>Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?

Полный inplace видимо никак, но будет хотя бы одна индерекция вместо двух.

dot>dot>А это ты считаешь quicksort-м?
dot>

dot>qsort (x:xs) = qsort (filter (<= x) xs) ++ [x] ++ qsort (filter (> x) xs)
dot>

Нет. И даже ортодоксальные ФП'исты это отмечают: Erik Meijer (28:25)

EP>> dot>>>Который из?? Их столько, что ну нафиг, слишком много деталей.
EP>> EP>>Обычно соответствующий используемому железу.
EP>> dot>Железо меняется, да даже и обычный современный комп — там и 32 бита, и 64,
EP>> Пусть меняется, суть-то везде примерно одинаковая, и она ниже уровнем чем C.
dot>Для курса обучения желательно использовать что-то что не менятеся.

Ну и пусть используют ASM под обычный PC — архитектуры меняются редко, не говоря уж о том что старый x32 код работает на x64 процессорах.

dot>С++ это уже такая свалка всего, что за деревьями леса не видно.

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

dot>Например. В С пишем "a = b" — это просто mov в железе. А в С++ может быть что угодно.

1. И что? Некоторые начинают начальное обучение вообще с Python — там ещё дальше от железа.
2. В C++ для регулярных типов, с которых начинается обучение, "a = b" как раз и имеет вполне предсказуемое поведение, например что для int'ов, что для std::vector. Я бы сказал даже самое предсказуемое среди всего мейнстрима, так как value semantics и там и там.

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

EP> dot>Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?
EP> Полный inplace видимо никак, но будет хотя бы одна индерекция вместо двух.
Понятно. Т.е. quicksort невозможно использовать для сортировки строк. Интересно получается...

EP> dot>dot>А это ты считаешь quicksort-м?
EP> dot>

EP> dot>qsort (x:xs) = qsort (filter (<= x) xs) ++ [x] ++ qsort (filter (> x) xs)
EP> dot>

EP> Нет. И даже ортодоксальные ФП'исты это отмечают: Erik Meijer (28:25)
Ты видимо не понял, что он сказал: "This is quicksort expressed in haskell... some people argue that it is really not quicksort... because ...inplace array.... in another hand if you want to understand the algorithm behind quicksort, then this is fabulous description".
Т.е. для понимания самого алгоритма — это то что надо. А inplace, индирекции, эффективный swap — это всё оптимизации — заставить работать некий алгоритм на конкретном железе как можно быстрее.

EP> EP>> EP>>Обычно соответствующий используемому железу.
EP> EP>> dot>Железо меняется, да даже и обычный современный комп — там и 32 бита, и 64,
EP> EP>> Пусть меняется, суть-то везде примерно одинаковая, и она ниже уровнем чем C.

EP> dot>Для курса обучения желательно использовать что-то что не менятеся.
EP> Ну и пусть используют ASM под обычный PC — архитектуры меняются редко, не говоря уж о том что старый x32 код работает на x64 процессорах.
Можно, конечно. Но на асме сейчас вообще никто не пишет.

EP> dot>С++ это уже такая свалка всего, что за деревьями леса не видно.
EP> Поэтому и нужно выбрать правильное подмножество для начального обучения, об этом собственно и топик.
EP> dot>Например. В С пишем "a = b" — это просто mov в железе. А в С++ может быть что угодно.
EP> 1. И что? Некоторые начинают начальное обучение вообще с Python — там ещё дальше от железа.
Потому что питон — проще чем С++, С проще чем С++. Для обучения С++ — хуже. Чем меньше уделять приходится уделять внимание деталям языка — тем лучше.
Скажем, для реализации quicksort совершенно неважно сколько индирекций, что использовать — ссылки, указатели или значения, и т.п.

EP> 2. В C++ для регулярных типов, с которых начинается обучение, "a = b" как раз и имеет вполне предсказуемое поведение, например что для int'ов, что для std::vector. Я бы сказал даже самое предсказуемое среди всего мейнстрима, так как value semantics и там и там.
Зато далеко от железа.

avalon/1.0.432

A>О как у тебя припекло с Bullshildt'а!

Интересно. Ты уже второй раз каверкаешь эту фамилию, а меня припекло?

A>Но какая же у тебя хорошая память, раз ты этот этот топик про убунту вспомнил.

Не жалуюсь.

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

EP>> dot>Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?
EP>> Полный inplace видимо никак, но будет хотя бы одна индерекция вместо двух.
dot>Понятно. Т.е. quicksort невозможно использовать для сортировки строк. Интересно получается...

Использовать нечто похожее можно, здесь вопрос чисто терминологический.

EP>> dot>dot>А это ты считаешь quicksort-м?
EP>> dot>

EP>> dot>qsort (x:xs) = qsort (filter (<= x) xs) ++ [x] ++ qsort (filter (> x) xs)
EP>> dot>

EP>> Нет. И даже ортодоксальные ФП'исты это отмечают: Erik Meijer (28:25)
dot>Ты видимо не понял, что он сказал:

Я прекрасно понял.

dot>"This is quicksort expressed in haskell... some people argue that it is really not quicksort... because ...inplace array....

Там ключевое "an essense of quicksort". То есть "сущность quicksort".

dot> in another hand if you want to understand the algorithm behind quicksort, then this is fabulous description".
dot>Т.е. для понимания самого алгоритма — это то что надо.

Для понимая другого алгоритма. Оригинальный quicksort помимо inplace ещё и ограничивает глубину стэка логарифмом.

dot>А inplace, индирекции, эффективный swap — это всё оптимизации — заставить работать некий алгоритм на конкретном железе как можно быстрее.

А алгоритмы пишутся в том числе для конкретного железа. inplace у quicksort был с самого рождения, и в качестве преимуществ как раз описывается скорость на многоуровневой системе памяти. Что и сейчас актуально, также как и пятьдесят лет назад.

EP>> dot>С++ это уже такая свалка всего, что за деревьями леса не видно.
EP>> Поэтому и нужно выбрать правильное подмножество для начального обучения, об этом собственно и топик.
EP>> dot>Например. В С пишем "a = b" — это просто mov в железе. А в С++ может быть что угодно.
EP>> 1. И что? Некоторые начинают начальное обучение вообще с Python — там ещё дальше от железа.
dot>Потому что питон — проще чем С++, С проще чем С++.

Начальное подмножество C сложнее правильного (сабж) начального подмножества C++.

dot>Для обучения С++ — хуже. Чем меньше уделять приходится уделять внимание деталям языка — тем лучше.

Так на C++ на начальном этапе меньше всяких отвлечений. Взял vector, и заполняй как хочешь. В то время как на C будет куча лишнего кода.

EP>> 2. В C++ для регулярных типов, с которых начинается обучение, "a = b" как раз и имеет вполне предсказуемое поведение, например что для int'ов, что для std::vector. Я бы сказал даже самое предсказуемое среди всего мейнстрима, так как value semantics и там и там.
dot>Зато далеко от железа.

А зачем на начальном этапе близко к железу?

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

·>Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?

А что, для вызова

Swap(string[i], string[j])

требуется одинаковая длина?

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

EP>1. И что? Некоторые начинают начальное обучение вообще с Python — там ещё дальше от железа.

Не любое обучение ЯП есть обучение программированию. Питон используется для обучению программирования с нуля, что бы оставить самый минимум. Вот система типов здесь уже совершенно лишняя.

EP>2. В C++ для регулярных типов, с которых начинается обучение, "a = b" как раз и имеет вполне предсказуемое поведение, например что для int'ов, что для std::vector. Я бы сказал даже самое предсказуемое среди всего мейнстрима, так как value semantics и там и там.

Да, нынче люди уже рождаются со встроеным пониманием stl и разных контейнеров.

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

TB>·>Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?
TB>А что, для вызова
TB>

TB>Swap(string[i], string[j])
TB>

TB>требуется одинаковая длина?
А что, string разве inplace? Посмотри на реализацию ради ликбеза.

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

I>>А вот идиомой в Си будет класс, наследование, полиморфизм и тд. Тот же полиморфизм реализовывается в частном случае через void*.

Ops>Я это и имел в виду. И как тебе такой полиморфизм, полезнее для ног, нежели в плюсах?

Для обучения — полезнее. Ровно самый минимум. На таких примерах и надо показывать, где какие проблемы, откуда берутся, как решаются.
В противном случае вырастает поколение `std::vector это правильно, потому что нам так сказали`

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

·>А что, string разве inplace?

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

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

EP>>> dot>Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?
EP>>> Полный inplace видимо никак, но будет хотя бы одна индерекция вместо двух.
dot>>Понятно. Т.е. quicksort невозможно использовать для сортировки строк. Интересно получается...
EP>Использовать нечто похожее можно, здесь вопрос чисто терминологический.
И как это нечто похожее будет называться? Almost, but not quite, entirely unlike quicksort.

dot>>"This is quicksort expressed in haskell... some people argue that it is really not quicksort... because ...inplace array....
EP>Там ключевое "an essense of quicksort". То есть "сущность quicksort".
Да, т.е. собственно сам алгоритм quicksort, его сущность, а не детали реализации — inplace, indirection, swap, указатели, менеджмент памяти, ассемблеры и прочая левость к quicksort отношения не имеющая.

dot>> in another hand if you want to understand the algorithm behind quicksort, then this is fabulous description".
dot>>Т.е. для понимания самого алгоритма — это то что надо.
EP>Для понимая другого алгоритма. Оригинальный quicksort помимо inplace ещё и ограничивает глубину стэка логарифмом.
Эта хаскелловая имплементация тоже ограничивает, выбор pivot point будет лишь влиять на то, что будет считаться worst case для данной имплементации алгоритма.

dot>>А inplace, индирекции, эффективный swap — это всё оптимизации — заставить работать некий алгоритм на конкретном железе как можно быстрее.
EP>А алгоритмы пишутся в том числе для конкретного железа. inplace у quicksort был с самого рождения, и в качестве преимуществ как раз описывается скорость на многоуровневой системе памяти. Что и сейчас актуально, также как и пятьдесят лет назад.
Актуально для реализации, но мы вроде об обучении.

EP>>> dot>С++ это уже такая свалка всего, что за деревьями леса не видно.
EP>>> Поэтому и нужно выбрать правильное подмножество для начального обучения, об этом собственно и топик.
EP>>> dot>Например. В С пишем "a = b" — это просто mov в железе. А в С++ может быть что угодно.
EP>>> 1. И что? Некоторые начинают начальное обучение вообще с Python — там ещё дальше от железа.
dot>>Потому что питон — проще чем С++, С проще чем С++.
EP>Начальное подмножество C сложнее правильного (сабж) начального подмножества C++.
В каком месте? Единственное что в C сложно — это printf/scanf (хотя стримы в С++ не сильно проще). Но их можно избежать, скажем, через getchar/putchar/fgets/puts.

dot>>Для обучения С++ — хуже. Чем меньше уделять приходится уделять внимание деталям языка — тем лучше.
EP>Так на C++ на начальном этапе меньше всяких отвлечений. Взял vector, и заполняй как хочешь. В то время как на C будет куча лишнего кода.
Если ты знаешь что такое vector.

dot>>Зато далеко от железа.
EP>А зачем на начальном этапе близко к железу?
Чтобы понимать как это работает унутре. Как один из языков, которым нужно обучать, чтобы дать представление о системном уровне.
Для алгоритмов — нужны другие языки, а для С++ места нет.

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

dot>>И чем хуже Питон|Ява в этом случае? Даже swap двух элементов массива можно сделать.
EP>Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.

In-place — это не про то, что перемещаются сами объекты, а не ссылки на них. In-place — это про то, что не требуется большого (больше константного) вспомогательного объёма памяти. Даже в C++ при сортировке строк ты будешь не копировать байтовые массивы туда-сюда, а swap'ать ссылки на них (хотя извне std::string и ведёт себя как value-тип). В этом отношении сортировка в C++ не будет отличаться от сортировки в .NET, и не станет от этого менее in-place.

EP>Оригинальный quicksort помимо inplace ещё и ограничивает глубину стэка логарифмом.

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

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

TB>·>А что, string разве inplace?
TB>Я не распарсил фразу. Поясни, что ты имеешь в виду. Ты хочешь, чтобы сорт переставлял буковки строк, не меняя указатели на буферы? На кой хрен это надо?
Мне ни на кой хрен не надо, это Evgeny.Panasyuk пишет

Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.

И ВНЕЗАПНО оказалось, что строки отсортировать нельзя, ибо перемещаются не сами массивы символов, а ссылки на начало|конец.

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

A>Цель — это обучение людей которые будут работать на должности "разработчик С++", или будут поддерживать код на С++.
Я бы поостерёгся брать человека без хорошего знания чистого C.

A>И Kate Gregory объясняет, что если всё учить в правильном порядке, то оказывается что всё очень просто, можно обойтись без игр "а добавлю-ка я звездочку с этой строны, вдруг соберется"
Дьявол в деталях. Писать код действительно просто. Откомпилировать его может оказаться сложнее. Я практически моментально нахожу причину ошибки компиляции в случае С-кода. В случае C++ иногда приходится напрягаться... А чтобы исправить ошибку в runtime может понадобится умение ковыряться в кишках, а это, большей частью, сишные концепции. К индусской концепции «один пишет, другой фиксит баги» я отношусь настороженно.

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

·>

Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.

·>И ВНЕЗАПНО оказалось, что строки отсортировать нельзя, ибо перемещаются не сами массивы символов, а ссылки на начало|конец.

Ты не понимаешь, что такое "сама структура" в случае строки

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

EP>Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.

Эдак у тебя строки квиксортом сбороть не выйдет.

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

EP>> Он quick-то во многом благодаря этому, и используется по сей день (пусть и временами внутри introsort).
·>Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?

Ахинею он выдал. Inplace это значит,
1 элементы контейнера не пересоздаются, а перемещаются с помощью swap
2 Контейнер не пересоздаётся, перемещаются только элементы унутре контейнера
3 что унутре контейнера — объекты, структуры или ссылки на них — никому не интересно.

То есть, тру квиксорт это жесточайше мутабельный алгоритм.

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

EP>Начальное подмножество C сложнее правильного (сабж) начального подмножества C++.

А правильное оно разумеется потому, что оно проще начального Си.

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

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

LVV>>>Подумаешь, открытие...

LVV>>>Да мы так уже лет 7-8 учим.

A>>Молодцы. А кто-то до сих пор учит по Bullshildt'у.

I>Шылдт устарел. Нужно учить так, что бы не в консоли колупаться, а получать внятный визуальный результат.

Консоль юнит-тестов — что может быть лучше для современного новичка?

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

TB>·>

Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.

TB>·>И ВНЕЗАПНО оказалось, что строки отсортировать нельзя, ибо перемещаются не сами массивы символов, а ссылки на начало|конец.
TB>Ты не понимаешь, что такое "сама структура" в случае строки

Я прекрасно понимаю, что под "сама структура" вы понимаете то, что удобно, чтобы обосновать свой тезис "quicksort это полностью inplace алгоритм".

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

I>>Шылдт устарел. Нужно учить так, что бы не в консоли колупаться, а получать внятный визуальный результат.

MD>Консоль юнит-тестов — что может быть лучше для современного новичка?

Трудно придумать что либо хуже этого

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

EP>>> Он quick-то во многом благодаря этому, и используется по сей день (пусть и временами внутри introsort).
I>·>Гы-гы. Как ты сделаешь inplace quicksort хотя бы массива строк разной длины?
I>Ахинею он выдал. Inplace это значит,
I>1 элементы контейнера не пересоздаются, а перемещаются с помощью swap
I>2 Контейнер не пересоздаётся, перемещаются только элементы унутре контейнера
I>3 что унутре контейнера — объекты, структуры или ссылки на них — никому не интересно.
А если говорить совсем строго, с т.з. теории — то quicksort требует больше памяти, чем константа. Для стека требуется O(log(N)) памяти, в худшем случае O(N).
Т.е. quicksort вообще никаким боком не inplace. Вот bubble sort — да, inplace.

I>То есть, тру квиксорт это жесточайше мутабельный алгоритм.
Поэтому — не обязательно, мутабельность не присуща квиксорту. Да, эффективные реализации скорее всего будут стараться двигать как можно меньше, выделять как можно меньше памяти, распологать байты CPU-cache-friendly, но на O-сложность это никак не влияет.

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

·>Я прекрасно понимаю, что под "сама структура" вы понимаете то, что удобно, чтобы обосновать свой тезис "quicksort это полностью inplace алгоритм".

Если у нас массив указателей на MegaObject, то для тебя инплейс — это когда свапают сами MegaObjectы? Лол)

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

TB>·>Я прекрасно понимаю, что под "сама структура" вы понимаете то, что удобно, чтобы обосновать свой тезис "quicksort это полностью inplace алгоритм".
TB>Если у нас массив указателей на MegaObject, то для тебя инплейс — это когда свапают сами MegaObjectы? Лол)
А если у тебя массив указателей на TinyObject. Это как-то повлияет на inplace-ность? Причём вообще указатели, swap, размер объектов и прочее когда мы говорим о quicksort?

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

·>А если у тебя массив указателей на TinyObject. Это как-то повлияет на inplace-ность? Причём вообще указатели, swap, размер объектов и прочее когда мы говорим о quicksort?

Алгоритм инплейсен относительно того, что непосредственно хранится в массиве, а не того, чего хочешь ты, вот и всё.
А если мы храним в векторе номера файлов в папке, то при свапе надо открывать файлы и переписывать их содержимое, да?

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

A>>И Kate Gregory объясняет, что если всё учить в правильном порядке, то оказывается что всё очень просто, можно обойтись без игр "а добавлю-ка я звездочку с этой строны, вдруг соберется"
M>Дьявол в деталях. Писать код действительно просто. Откомпилировать его может оказаться сложнее. Я практически моментально нахожу причину ошибки компиляции в случае С-кода. В случае C++ иногда приходится напрягаться... А чтобы исправить ошибку в runtime может понадобится умение ковыряться в кишках, а это, большей частью, сишные концепции. К индусской концепции «один пишет, другой фиксит баги» я отношусь настороженно.

Искать ошибки компиляции — это сложно? А ошибки в рантайме, в продакшене, проще чтоли искать?
С++ как раз добавляет много ошибок компиляции, чтобы ошибки ловились на этапе компиляции, а не в рантайме.

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

EP>>Оригинальный quicksort помимо inplace ещё и ограничивает глубину стэка логарифмом.
Q>Оригинальный QuickSort как раз не ограничивает глубину вызовов, поэтому она может вырождаться до эн,

Ограничивает глубину стэка логарифмом. Это явно описано в оригинальной статье Хоара.
И я уже это подробно объяснял:

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

Q>>>Быструю сортировку можно и без рекурсивных вызовов организовать, эмулировав стек, но так обычно не делают в стандартных библиотеках. То есть почему-то не спешат менять потенциальный StackOverflowEcxeption на потениальный OutOfMemoryException. Добавляют при необходимоти guard глубины рекурсии, и живут себе, поди, без штрафов к премиям.

EP>Справедливости ради, в нормальной quicksort глубина стэка гарантированно ограничена O(ln(N)), в worst case.
EP>Там внутри две рекурсии — по левой стороне массива и по правой. Для той у которой размер массива больше — делают ручной tail call. То есть рекурсия происходит всегда в меньшую сторону, причём это может быть как левая, так и правая сторона.
EP>Размер меньшей части гарантированно меньше половины размера исходного массива, то есть рекурсия как минимум делится пополам, что гарантирует логарифмическую глубину.

Q>и общая сложность в худшем случае деградирует до эн-квадрат.

Глубина стэка != сложность алгоритма.

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

TB>·>А если у тебя массив указателей на TinyObject. Это как-то повлияет на inplace-ность? Причём вообще указатели, swap, размер объектов и прочее когда мы говорим о quicksort?
TB>Алгоритм инплейсен относительно того, что непосредственно хранится в массиве, а не того, чего хочешь ты, вот и всё.
Алгоритму quicksort вообще по барабану inplace-ность. Неужели непонятно?

TB>А если мы храним в векторе номера файлов в папке, то при свапе надо открывать файлы и переписывать их содержимое, да?

Если принять за истину это: "Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них." — да, придётся переписывать или признать, что это не quicksort. Номер файла — это же ссылка.
Хотя более рационально признать сказанное Евгением ахинеей.

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

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

I>>>Шылдт устарел. Нужно учить так, что бы не в консоли колупаться, а получать внятный визуальный результат.

MD>>Консоль юнит-тестов — что может быть лучше для современного новичка?

I>Трудно придумать что либо хуже этого

Т.е. надо заставить новичка сначала вбить какой-то boilerplate? В виде UI или ещё чего-то? Не понимаю.

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

EP>Глубина стэка != сложность алгоритма.

А что?
Ради справки: глубина стека включается в размер потребляемой памяти, "algorithm space complexity". Ты, похоже, путаешь с "algorithm time complexity".

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

dot>>>"This is quicksort expressed in haskell... some people argue that it is really not quicksort... because ...inplace array....
EP>>Там ключевое "an essense of quicksort". То есть "сущность quicksort".
dot>Да, т.е. собственно сам алгоритм quicksort, его сущность, а не детали реализации — inplace, indirection, swap, указатели, менеджмент памяти, ассемблеры и прочая левость к quicksort отношения не имеющая.

Не надо фантазировать

из цитаты чётко ясно к чему относится "an essense":

this is not really quicksort, because, you know, an essense is that it takes an array and updates array inplace.

dot>>> in another hand if you want to understand the algorithm behind quicksort, then this is fabulous description".
dot>>>Т.е. для понимания самого алгоритма — это то что надо.
EP>>Для понимая другого алгоритма. Оригинальный quicksort помимо inplace ещё и ограничивает глубину стэка логарифмом.
dot>Эта хаскелловая имплементация тоже ограничивает, выбор pivot point будет лишь влиять на то, что будет считаться worst case для данной имплементации алгоритма.

Каким образом она ограничивает глубину стэка?
Глубина стэка в оригинальном quicksort логарифмическая, независимо от выбора pivot point, даже в worst case. Подробно описал чуть выше.

dot>>>А inplace, индирекции, эффективный swap — это всё оптимизации — заставить работать некий алгоритм на конкретном железе как можно быстрее.
EP>>А алгоритмы пишутся в том числе для конкретного железа. inplace у quicksort был с самого рождения, и в качестве преимуществ как раз описывается скорость на многоуровневой системе памяти. Что и сейчас актуально, также как и пятьдесят лет назад.
dot>Актуально для реализации, но мы вроде об обучении.

Это часть самого алгоритма, так как его описал автор.

EP>>>> dot>С++ это уже такая свалка всего, что за деревьями леса не видно.
EP>>>> Поэтому и нужно выбрать правильное подмножество для начального обучения, об этом собственно и топик.
EP>>>> dot>Например. В С пишем "a = b" — это просто mov в железе. А в С++ может быть что угодно.
EP>>>> 1. И что? Некоторые начинают начальное обучение вообще с Python — там ещё дальше от железа.
dot>>>Потому что питон — проще чем С++, С проще чем С++.
EP>>Начальное подмножество C сложнее правильного (сабж) начального подмножества C++.
dot>В каком месте?

Везде — и обход последовательностей, и работа с контейнерами, и ввод-вывод и т.д. и т.п.

dot>Единственное что в C сложно — это printf/scanf (хотя стримы в С++ не сильно проще). Но их можно избежать, скажем, через getchar/putchar/fgets/puts.

Каким образом будешь числа выводить? itoa? Да уж — поменял шило на мыло

dot>>>Для обучения С++ — хуже. Чем меньше уделять приходится уделять внимание деталям языка — тем лучше.
EP>>Так на C++ на начальном этапе меньше всяких отвлечений. Взял vector, и заполняй как хочешь. В то время как на C будет куча лишнего кода.
dot>Если ты знаешь что такое vector.

Так его и предлагается изучать с самого начала. Страуструп например так и делает

В чём проблема-то?

dot>>>Зато далеко от железа.
EP>>А зачем на начальном этапе близко к железу?
dot>Чтобы понимать как это работает унутре.

Зачем это при начальном обучении? С самых первых дней?

dot>Как один из языков, которым нужно обучать, чтобы дать представление о системном уровне.
dot>Для алгоритмов — нужны другие языки, а для С++ места нет.

Твоё мнение я услышал.

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

EP>>Глубина стэка != сложность алгоритма.
dot>

А что?

Можно иметь квадратичный алгоритм даже при констатнтном размере стэка

В случае же оригинального quicksort, даже в worst case (когда выполняется квадратичное число операций) глубина стэка — логарифмическая, это гарантия.

dot>Ради справки: глубина стека включается в размер потребляемой памяти, "algorithm space complexity". Ты, похоже, путаешь с "algorithm time complexity".

Я не путаю. Я конкретно сказал что ограничивается глубина стэка. Про algorithm time complexity это твои фантазии.

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

EP>>Глубина стэка != сложность алгоритма.
·>:wow: А что?
·>Ради справки: глубина стека включается в размер потребляемой памяти, "algorithm space complexity". Ты, похоже, путаешь с "algorithm time complexity".

Я писал комментарий относительно глубины «логического стэка», которая включает в том числе ручной хвостовой «вызов», и от которой зависит сложность. Но «физический стэк» — да, можно ограничить. Это не влияет на принципиальную логическую структуру вызовов и асимптотическую сложность; но один хвосторекурсивный вызов можно подхачить так, чтоб он не увеличивал глубину реального стека, а переиспользовал «стекфрейм».

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

dot>>>И чем хуже Питон|Ява в этом случае? Даже swap двух элементов массива можно сделать.
EP>>Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них.
Q>In-place — это не про то, что перемещаются сами объекты, а не ссылки на них. In-place — это про то, что не требуется большого (больше константного) вспомогательного объёма памяти.

Да, согласен обычно имеется в виду именно это. Только при этом допускается логарифмический вспомогательный объём. В приведённой же ФП версии нет даже этого.
Но в оригинальном quicksort также описывается что перемещаются сами данные, а разбиение происходит последовательно по памяти с двух концов диапазона, и явно указанно отсутствие random-access.

Q>В этом отношении сортировка в C++ не будет отличаться от сортировки в .NET

Даже тут будет существенное отличие. В .NET/Java элемент массива строк — это по сути указатель на указатель на буфер — двойная индерекция. В C++ же максимум одна, а то и ноль в случае SSO.

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

MD>>>Консоль юнит-тестов — что может быть лучше для современного новичка?

I>>Трудно придумать что либо хуже этого

MD>Т.е. надо заставить новичка сначала вбить какой-то boilerplate? В виде UI или ещё чего-то? Не понимаю.

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

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

·>Если принять за истину это: "Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них." — да, придётся переписывать или признать, что это не quicksort. Номер файла — это же ссылка.

А если эти числа — номера домов на улице, то надо сносить дома и строить их в другом месте?

Жги ещё!

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

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

TB>>·>А если у тебя массив указателей на TinyObject. Это как-то повлияет на inplace-ность? Причём вообще указатели, swap, размер объектов и прочее когда мы говорим о quicksort?
TB>>Алгоритм инплейсен относительно того, что непосредственно хранится в массиве, а не того, чего хочешь ты, вот и всё.
·>Алгоритму quicksort вообще по барабану inplace-ность. Неужели непонятно?

Наоборот. Тот самый квиксорт именно инплейсный, смотри о чем говорит Эрие Мейер.

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

dot>>>>"This is quicksort expressed in haskell... some people argue that it is really not quicksort... because ...inplace array....
EP>>>Там ключевое "an essense of quicksort". То есть "сущность quicksort".
dot>>Да, т.е. собственно сам алгоритм quicksort, его сущность, а не детали реализации — inplace, indirection, swap, указатели, менеджмент памяти, ассемблеры и прочая левость к quicksort отношения не имеющая.
EP>Не надо фантазировать

из цитаты чётко ясно к чему относится "an essense":
EP>

EP>this is not really quicksort, because, you know, an essense is that it takes an array and updates array inplace.

Это не его слова, а цитирование "some people argue this is not really quicksort...", далее он говорит, что та хаскелевая имплементация — именно и есть сам quicksort, дающий понять сущность самого алгоритма.

EP>>>Для понимая другого алгоритма. Оригинальный quicksort помимо inplace ещё и ограничивает глубину стэка логарифмом.
dot>>Эта хаскелловая имплементация тоже ограничивает, выбор pivot point будет лишь влиять на то, что будет считаться worst case для данной имплементации алгоритма.
EP>Каким образом она ограничивает глубину стэка?
EP>Глубина стэка в оригинальном quicksort логарифмическая, независимо от выбора pivot point, даже в worst case. Подробно описал чуть выше.
Ограничение — logN в среднем случае, так называемая наивная реализация quicksort, но quicksort она не перестаёт быть.

EP>>>А алгоритмы пишутся в том числе для конкретного железа. inplace у quicksort был с самого рождения, и в качестве преимуществ как раз описывается скорость на многоуровневой системе памяти. Что и сейчас актуально, также как и пятьдесят лет назад.
dot>>Актуально для реализации, но мы вроде об обучении.
EP>Это часть самого алгоритма, так как его описал автор.
Т.е. если бы автор описал алгоритм на фортране, то единственный способ написать quicksort это фортран?

dot>>>>Потому что питон — проще чем С++, С проще чем С++.
EP>>>Начальное подмножество C сложнее правильного (сабж) начального подмножества C++.
dot>>В каком месте?
EP>Везде — и обход последовательностей, и работа с контейнерами, и ввод-вывод и т.д. и т.п.
А конкретно? Ну кроме printf/scanf?

dot>>Единственное что в C сложно — это printf/scanf (хотя стримы в С++ не сильно проще). Но их можно избежать, скажем, через getchar/putchar/fgets/puts.
EP>Каким образом будешь числа выводить? itoa? Да уж — поменял шило на мыло

А ascii кодировка и десятичное представление чисел — совсем другой вопрос. Железо об этом ничего не знает, нет никаких чисел в железе, только биты-байты.
Написать преобразование int в ascii-символы и обратно — отличная учебная задача.

dot>>>>Для обучения С++ — хуже. Чем меньше уделять приходится уделять внимание деталям языка — тем лучше.
EP>>>Так на C++ на начальном этапе меньше всяких отвлечений. Взял vector, и заполняй как хочешь. В то время как на C будет куча лишнего кода.
dot>>Если ты знаешь что такое vector.
EP>Так его и предлагается изучать с самого начала. Страуструп например так и делает

EP>В чём проблема-то?
Но чем, например, java.lang.ArrayList<> или [] в Питоне хуже? Зато реализация этого самого вектора с использованием malloc/free — гораздо интереснее, чем просто "вот у нас тут туча кода, которая абстрагирует индексируемый контейнер переменной длины".

dot>>>>Зато далеко от железа.
EP>>>А зачем на начальном этапе близко к железу?
dot>>Чтобы понимать как это работает унутре.
EP>Зачем это при начальном обучении? С самых первых дней?
А с самых первых дней С и С++ и не нужны, лучше взять что-то более простое. Java — проще, Python — проще. А с совсем первых дней вообще берут какой-нибудь Scratch

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

I>>3 что унутре контейнера — объекты, структуры или ссылки на них — никому не интересно.
·>А если говорить совсем строго, с т.з. теории — то quicksort требует больше памяти, чем константа. Для стека требуется O(log(N)) памяти, в худшем случае O(N).
·>Т.е. quicksort вообще никаким боком не inplace. Вот bubble sort — да, inplace.

инплейс это про исходный контейнер, а не затраты дополнительной памяти.
Я же объяснил
1 — контейнер не пересоздаётся
2 — элементры не пересоздаются
3 -элементы менаются местами чз swap

Всё. Что тебе непонятно, с чем ты не согласен ?

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

Наоборот. Смотри внимательно: https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional-Programming-Fundamentals/Lecture-Series-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-1

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

EP>>>Глубина стэка != сложность алгоритма.
dot>>

А что?
EP>Можно иметь квадратичный алгоритм даже при констатнтном размере стэка

Квадратичный по времени или памяти?! Сложность алгоритмов всегда состоит из двух компонент.

EP>В случае же оригинального quicksort, даже в worst case (когда выполняется квадратичное число операций) глубина стэка — логарифмическая, это гарантия.
Т.е. по памяти он логарифмической сложности.

dot>>Ради справки: глубина стека включается в размер потребляемой памяти, "algorithm space complexity". Ты, похоже, путаешь с "algorithm time complexity".
EP>Я не путаю. Я конкретно сказал что ограничивается глубина стэка. Про algorithm time complexity это твои фантазии.
Глубина стека определяет сложность алгоритма по памяти. Причём тут ограничивается или нет.

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

dot>А если говорить совсем строго, с т.з. теории — то quicksort требует больше памяти, чем константа. Для стека требуется O(log(N)) памяти, в худшем случае O(N).

В худшем случае log2(N), это явно описано в оригинальной статье Энтони Хоара.

dot>Т.е. quicksort вообще никаким боком не inplace.

Алгоритмы "на Python/Java" изучал?

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

Мутабельность у него в крови.

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

MD>>>>Консоль юнит-тестов — что может быть лучше для современного новичка?
I>Нужен тренажер, возможно с UI. Главное что бы результат был мгновенный, понятный и интересный пользователю. ни разу не видел, что бы новичкам было интересно в консоль втыкать.

Так консоль тест-раннера — это такой тренажёр и есть. UI с красными и зелёными полосками, и деревом разных тестовых методов, мгновенный результат, можно запускать код прям из раннера, смотреть время выполнения, можно выводить в текстовый вывод всякое.

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

·>Сложность алгоритмов всегда состоит из двух компонент.

Иногда больше. Например, временную сложность можно считать по сравнениям, а можно по swap'ам.

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

TB>·>Если принять за истину это: "Оригинальный quicksort это полностью inplace алгоритм — перемещаются сами объекты/структуры, а не ссылки на них." — да, придётся переписывать или признать, что это не quicksort. Номер файла — это же ссылка.
TB>А если эти числа — номера домов на улице, то надо сносить дома и строить их в другом месте?

А куда деваться-то? Ведь "Даже тут будет существенное отличие".

TB>Жги ещё!

Так что ты мне-то пишешь? Это же не моя цитата, пиши это Евгению.

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

EP>>>>Там ключевое "an essense of quicksort". То есть "сущность quicksort".
dot>>>Да, т.е. собственно сам алгоритм quicksort, его сущность, а не детали реализации — inplace, indirection, swap, указатели, менеджмент памяти, ассемблеры и прочая левость к quicksort отношения не имеющая.
EP>>Не надо фантазировать

из цитаты чётко ясно к чему относится "an essense":
EP>>

EP>>this is not really quicksort, because, you know, an essense is that it takes an array and updates array inplace.

dot>Это не его слова, а цитирование "some people argue this is not really quicksort...",

Да, цитирование, которое он не просто так привёл — он прекрасно понимает что вопрос как минимум спорный, и поэтому вполне справедливо привёл это мнение.
И вот это an essense относится именно к "updates array inplace", а не то что ты сказал:

EP>>>>Там ключевое "an essense of quicksort". То есть "сущность quicksort".
dot>>>Да, т.е. собственно сам алгоритм quicksort, его сущность, а не детали реализации — inplace, indirection, swap, указатели, менеджмент памяти, ассемблеры и прочая левость к quicksort отношения не имеющая.

dot> далее он говорит, что та хаскелевая имплементация — именно и есть сам quicksort, дающий понять сущность самого алгоритма.

Нет, он говорит что вот такое описание помогает понять не именно сам quicksort, а некоторые алгоритмические особенности behind quicksort.
В оригинальный же quicksort входит не только сферический inplace, но и вполне конкретный partition.

EP>>>>А алгоритмы пишутся в том числе для конкретного железа. inplace у quicksort был с самого рождения, и в качестве преимуществ как раз описывается скорость на многоуровневой системе памяти. Что и сейчас актуально, также как и пятьдесят лет назад.
dot>>>Актуально для реализации, но мы вроде об обучении.
EP>>Это часть самого алгоритма, так как его описал автор.
dot>Т.е. если бы автор описал алгоритм на фортране, то единственный способ написать quicksort это фортран?

Нет, автор конкретно описал и последовательный доступ по памяти, и отсутсвие random-access, и многоуровневую иерархию памяти.

dot>>>>>Потому что питон — проще чем С++, С проще чем С++.
EP>>>>Начальное подмножество C сложнее правильного (сабж) начального подмножества C++.
dot>>>В каком месте?
EP>>Везде — и обход последовательностей, и работа с контейнерами, и ввод-вывод и т.д. и т.п.
dot>А конкретно? Ну кроме printf/scanf?

Конкретно пример Страуструпа в главе "2. Myth 1: “To understand C++, you must first learn C”" из этой статьи.

dot>>>Единственное что в C сложно — это printf/scanf (хотя стримы в С++ не сильно проще). Но их можно избежать, скажем, через getchar/putchar/fgets/puts.
EP>>Каким образом будешь числа выводить? itoa? Да уж — поменял шило на мыло

dot>А ascii кодировка и десятичное представление чисел — совсем другой вопрос. Железо об этом ничего не знает, нет никаких чисел в железе, только биты-байты.
dot>Написать преобразование int в ascii-символы и обратно — отличная учебная задача.

Отличная, но начинать-то обучение с неё зачем?

dot>>>>>Для обучения С++ — хуже. Чем меньше уделять приходится уделять внимание деталям языка — тем лучше.
EP>>>>Так на C++ на начальном этапе меньше всяких отвлечений. Взял vector, и заполняй как хочешь. В то время как на C будет куча лишнего кода.
dot>>>Если ты знаешь что такое vector.
EP>>Так его и предлагается изучать с самого начала. Страуструп например так и делает

EP>>В чём проблема-то?
dot>Но чем, например, java.lang.ArrayList<> или [] в Питоне хуже?

Я говорю что то что есть в C, либо C-подобном подможестве C++ — вот это хуже, и с этого не нужно начинать обучение. Об этом собственно топик

dot>Зато реализация этого самого вектора с использованием malloc/free — гораздо интереснее, чем просто "вот у нас тут туча кода, которая абстрагирует индексируемый контейнер переменной длины".

Конечно интереснее, и Страуструп именно её и разбирает. Только делает это уже ближе к 600ой странице, в то время как vector был введён и использовался начиная с 100ой страницы.
Об этом и речь, всё это можно изучать — но не с самого начала, никакого "C first".

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

·>А куда деваться-то? Ведь "Даже тут будет существенное отличие".
·>Так что ты мне-то пишешь? Это же не моя цитата, пиши это Евгению.

Зачем писать Евгению, он вроде понимает, что такое инплейс, а ты нет.

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

dot>>А если говорить совсем строго, с т.з. теории — то quicksort требует больше памяти, чем константа. Для стека требуется O(log(N)) памяти, в худшем случае O(N).
EP>В худшем случае log2(N), это явно описано в оригинальной статье Энтони Хоара.
В худшем случае для наивной реализации.

dot>>Т.е. quicksort вообще никаким боком не inplace.
EP>Алгоритмы "на Python/Java" изучал?

Нет.. Когда я их начинал изучать это был ZX Basic. Python/Java ещё не существовало.

I>>>То есть, тру квиксорт это жесточайше мутабельный алгоритм.
dot>>Поэтому — не обязательно, мутабельность не присуща квиксорту.
EP>Мутабельность у него в крови.
Для эффективной реализации на железе.

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

Q>>>>>и общая сложность в худшем случае деградирует до эн-квадрат.
EP>>>>Глубина стэка != сложность алгоритма.
dot>>>

А что?
EP>>Можно иметь квадратичный алгоритм даже при констатнтном размере стэка

dot>Квадратичный по времени или памяти?!

По времени, именно об этой сложности и говорил Qbit86 выше.
Я же вообще напрямую про сложность не говорил, я чётко сказал "глубина стэка".

dot>Сложность алгоритмов всегда состоит из двух компонент.

Не сложность "состоит из", а "у алгоритмов есть разные свойства/характеристики".

EP>>В случае же оригинального quicksort, даже в worst case (когда выполняется квадратичное число операций) глубина стэка — логарифмическая, это гарантия.
dot>Т.е. по памяти он логарифмической сложности.

В случае оригинальной inplace quick sort, да — это ограничивает space complexity.

dot>>>Ради справки: глубина стека включается в размер потребляемой памяти, "algorithm space complexity". Ты, похоже, путаешь с "algorithm time complexity".
EP>>Я не путаю. Я конкретно сказал что ограничивается глубина стэка. Про algorithm time complexity это твои фантазии.
dot>Глубина стека определяет сложность алгоритма по памяти.

Только нижнюю границу, то есть Ω.

dot>Причём тут ограничивается или нет.

Могут быть в том числе алгоритмы с логарифмическим размером стэка но линейным потреблением памяти

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

dot>>А ascii кодировка и десятичное представление чисел — совсем другой вопрос. Железо об этом ничего не знает, нет никаких чисел в железе, только биты-байты.
dot>>Написать преобразование int в ascii-символы и обратно — отличная учебная задача.

EP>Отличная, но начинать-то обучение с неё зачем?

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

Я тебе страшное скажу — если речь просто "дать представление" то можно и без триггеров и логики, тупо на пальцах.

	От:	Abyx
	Дата:	21.10.15 21:08
	Оценка:	52 (7) +3 -1

	От:	LaptevVV
	Дата:	21.10.15 21:22
	Оценка:

	От:	·
	Дата:	21.10.15 21:22
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	21.10.15 21:39
	Оценка:	1 (1)

	От:	Abyx
	Дата:	21.10.15 21:48
	Оценка:	+1

	От:	Олег К.
	Дата:	22.10.15 03:03
	Оценка:	+1 -1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	22.10.15 13:30
Оценка:	+3 -1

От:	С3141566=Z	http://sdeniskos.blogspot.com/
Дата:	22.10.15 15:44
Оценка:	-2

От:	Qbit86	https://twitter.com/qbit86
Дата:	23.10.15 09:03
Оценка:	+1

От:	Mystic	http://mystic2000.newmail.ru
Дата:	23.10.15 09:14
Оценка:

	От:	Mr.Delphist
	Дата:	23.10.15 10:42
	Оценка:	1 (1)