Книга по программированию для начинающих
SICP
серьезно
книга начинается с самых-самых азов, русский перевод написан очень доступным языком.
и пофик, что он много чего не поймет, особенно ближе к концу. я в таком же возрасте фейнмановские лекции читал, и не смущался, если чего-то не догонял.
серьезно
книга начинается с самых-самых азов, русский перевод написан очень доступным языком.
Мы собираемся изучать понятие вычислительного процесса (computatio-отличное начало для детской книжки
nal process). Вычислительные процессы — это абстрактные существа, которые
живут в компьютерах. Развиваясь, процессы манипулируют абстракциями дру-
гого типа, которые называются данными (data). Эволюция процесса направ-
ляется набором правил, называемым программой (program). В сущности, мы
заколдовываем духов компьютера с помощью своих чар
и пофик, что он много чего не поймет, особенно ближе к концу. я в таком же возрасте фейнмановские лекции читал, и не смущался, если чего-то не догонял.
ага, но это больше для 7 лет подойдет, а не для 14. он оскорбится
Я учился по книге Окулова "Основы программирования на языке Паскаль". В роли первой книги замечательна. А потом можно Вирта почитать, затем Кормена и Кнута. Потом уже стоит переходить к промышленному языку и изучать современные технологии. Effective C++ пойдёт. И самое главное: такая тема уже была в этом разделе и там я отписывался
C++ большой и сложный. да и не нужны ребенку промышленные технологии. ему концептуальное что-то нужно.
ага, но это больше для 7 лет подойдет, а не для 14. он оскорбитсяну яж не стремаюсь. не факт, что каждый взрослый человек, знакомый с программированием, ее полностью освоит.
Мой 14летний брат хочет научиться программироватьСмотря что он под этим понимает.
C++ большой и сложный. да и не нужны ребенку промышленные технологии. ему концептуальное что-то нужно.ты мой пост читал целиком? Если ты не понял, то я предложил знакомиться с паскаля. И по достижению некоторой зрелости (кормена и кнута молодой человек будет долго осваивать) следует от учебных языков переходить к серьёзным
На интуите как раз недавно вышел новый курс
А почему «для гуманитариев»? Пусть человек по существу программированию попробует научиться, а не ознакомительно.
я чо-то не оскорбился, когда читал
очень хорошая книга
не будет читать - дай подзатыльник
очень хорошая книга
не будет читать - дай подзатыльник
> Я учился по книге Окулова "Основы программирования на языке Паскаль".
поэтому ты стал эльфом!?777
поэтому ты стал эльфом!?777
> Подскажите книги, в которых разжевываются элементарные вещи и синтаксис
> какого-нибудь языка подается параллельно с простыми алгоритмами (поиск, сортировка).
сказать по правде мне в 14 ну вобще ни разу не вставляло от слов "поиск" и "сортировка", в том замечательном возрасте мне было куда интереснее как сделать так, чтобы комп пищал и мигал, вобщем-то я и сейчас считаю, что комп должен скорее пищать и мигать чем искать и сортировать
> какого-нибудь языка подается параллельно с простыми алгоритмами (поиск, сортировка).
сказать по правде мне в 14 ну вобще ни разу не вставляло от слов "поиск" и "сортировка", в том замечательном возрасте мне было куда интереснее как сделать так, чтобы комп пищал и мигал, вобщем-то я и сейчас считаю, что комп должен скорее пищать и мигать чем искать и сортировать
поэтому ты стал эльфом!?777не, я soultaker
Дать ему Squeak, ибо это есть самый сильный
усилитель воображения от киберэволюционистов.
---
"The best way to predict the future is to invent it."
усилитель воображения от киберэволюционистов.
---
"The best way to predict the future is to invent it."
Когда я с просьбой, подобной указанной топикстартером, лет в 10 обратился к отцу, мое знакомство с программированием началось с бейсика, а первой литературой были журналы "Радио" и "Наука и жизнь" Ничего, проглотил, и далеко не без пользы (хотя долго не понимал, почему после IF нужно писать THEN, а не TO, ну да это прошло, когда английский начал изучать ). Через год или два - упомянутый выше Вирт, Фаронов, другие книжки по Паскалю, распечатки борландовского описания TP. Кстати, "разжевывания" элементарных вещей особо не требовалось - достаточно было просто грамотного изложения и структурирования материала (ряд мест перечитывались десятки раз, когда дело доходило до решения задач).
Про базовые алгоритмы читалось запоем, ибо это были вещи достаточно понятные (исключение составляли, пожалуй, такие вещи, как быстрая сортировка и хеширование, ну да это со временем тоже усвоилось). Насчет пищалок-мигалок - да, эта тема тоже увлекала, но все-таки она была после начального знакомства.
Еще может быть полезна книжка с кучей разных задачек, причем не только тупых, типа "напишите программу, которая печатает десять чисел в столбик", но и более серьезных. Желательно также, чтобы этими программами можно было и дальше хоть немножко попользоваться (это могут быть, например, простенькие игры, калькулятор, программа для ведения семейного бюджета или расстановки мебели и др.). Можешь предлагать идеи ему и сам, но учти, что идей нужно много (не значит, что все будут решены; скорее всего, большинство будет заброшено).
Вообще, как тут уже было сказано, возраст замечательный в том плане, что если увлекаешься, то можешь быстро усваивать огромные объемы информации, так что не сильно переживай, если дашь "неправильную" книжку - на правильную тоже время найдется.
Ничего, проглотил, и далеко не без пользы (хотя долго не понимал, почему после IF нужно писать THEN, а не TO, ну да это прошло, когда английский начал изучать ). Через год или два - упомянутый выше Вирт, Фаронов, другие книжки по Паскалю, распечатки борландовского описания TP. Кстати, "разжевывания" элементарных вещей особо не требовалось - достаточно было просто грамотного изложения и структурирования материала (ряд мест перечитывались десятки раз, когда дело доходило до решения задач).Про базовые алгоритмы читалось запоем, ибо это были вещи достаточно понятные (исключение составляли, пожалуй, такие вещи, как быстрая сортировка и хеширование, ну да это со временем тоже усвоилось). Насчет пищалок-мигалок - да, эта тема тоже увлекала, но все-таки она была после начального знакомства.
Еще может быть полезна книжка с кучей разных задачек, причем не только тупых, типа "напишите программу, которая печатает десять чисел в столбик", но и более серьезных. Желательно также, чтобы этими программами можно было и дальше хоть немножко попользоваться (это могут быть, например, простенькие игры, калькулятор, программа для ведения семейного бюджета или расстановки мебели и др.). Можешь предлагать идеи ему и сам, но учти, что идей нужно много (не значит, что все будут решены; скорее всего, большинство будет заброшено).
Вообще, как тут уже было сказано, возраст замечательный в том плане, что если увлекаешься, то можешь быстро усваивать огромные объемы информации, так что не сильно переживай, если дашь "неправильную" книжку - на правильную тоже время найдется.
Насчет пищалок-мигалок - да, эта тема тоже увлекала, но все-таки она была после начального знакомства.Я предпочёл бы никогда не увидеть приложение о модуле Crt в книжке по Паскалю: угрохал кучу времени на баловство с текстовыми свистелками-пирделками. Лучше бы я в то-же время поигрался с TurboVision. Однако такова жизнь: сперва тратишь кучу драгоценного времени, а потом понимаешь, как его нужно потратить именно тебе. Так что вряд-ли стоит слишком заранее париться на счёт первых книжек.
Здесь еще фишка в том, что программирование - слишком динамично развивающаяся область, так что неизбежно будут появляться вещи, которые через несколько лет окажутся бесполезными. Имхо, как раз Crt была вполне нормальной библиотекой (для своего времени).
TurboVision - спорный вопрос, учитывая монструозность конструкций, получающихся с ее использованием (кажется, что даже в лиспе столько скобок не нужно). Хотя и этим я тоже поразвлекался
TurboVision - спорный вопрос, учитывая монструозность конструкций, получающихся с ее использованием (кажется, что даже в лиспе столько скобок не нужно). Хотя и этим я тоже поразвлекался
TurboVision - спорный вопрос, учитывая монструозность конструкций, получающихся с ее использованием (кажется, что даже в лиспе столько скобок не нужно). Хотя и этим я тоже поразвлекалсяПо хорошему, вокруг таких монструозных конструкций можно было бы вполне нормальную обёртку сделать, а то подобные конструкции плохо модифицируются.
Я бы был не прочь поразвлечься, но когда я добрался до книжки о TV, у меня было время только на то, чтобы её прочитать и вникнуть в основу. Было даже желание написать в качестве школьного проекта RAD-среду для создания TV-приложения, но не хватало ни времени, ни опыта работы с самой TV.
Когда я прочитал книжку про TV и написал несколько крутых прог (телефонный справочник и еще что-то то узнал про GraphicsVision и понял, что TV сакс .
Такие вещи не понять за первые несколько месяцев самостоятельного обучения программированию. Нужно что-то более простое и базовое.
Да, для начала это всего лишь текстовая консоль и может быть простая графика.
. Такие вещи не понять за первые несколько месяцев самостоятельного обучения программированию. Нужно что-то более простое и базовое.
Да, для начала это всего лишь текстовая консоль и может быть простая графика.
Когда я прочитал книжку про TV и написал несколько крутых прог (телефонный справочник и еще что-то то узнал про GraphicsVision и понял, что TV саксЕсли я правильно понял, у них различное назначение.
новая книжка Андреевой по паскалю:
http://biblio.mccme.ru/node/2177
http://biblio.mccme.ru/node/2177
новая книжка Андреевой по паскалю:на сайте написано, что это для подготовки к ЕГЭ. Так что втопку.
http://biblio.mccme.ru/node/2177
C++ большой и сложный. да и не нужны ребенку промышленные технологии.вот из-за таких как ты дети думают что Си сложный.
По топику:
0) НИ В КОЕМ СЛУЧАЕ ПХП
1) Учиться сразу под Юникс.
2) Учиться с Си.
Это база, иначе вырастет быдлокодер.
вот из-за таких как ты дети думают что Си сложный.Дети не различают С и С++, вот и думают всякие глупости.
Я бы всё-таки рекомендовал осваивать ФЯ как более интересную концепцию. Почему основа всего — С? Много кода уже написано на С, но нового пишется очень мало.
Хотя, действительно, для ознакомления с программированием в целом, тем, как работают ОС и строятся сети, С — наилучший выбор.
2) Учиться с Си.в самом начале топика я сказал, что уже было обсуждение этой проблемы выбора начальных образовательных средств. Видимо всё же нужно дать прямую ссылку, коли искать так и не научились.
Книжка вполне подходит для подготовки к части C ЕГЭ, которая, вообще говоря, не такой уж треш. Можно почитать что там за задачи на http://fipi.ru
Вообще это СУНЦовская книжка, более или менее соответствует началу обучения в информатическом классе.
Вообще это СУНЦовская книжка, более или менее соответствует началу обучения в информатическом классе.
По топику:это база
0) НИ В КОЕМ СЛУЧАЕ ПХП
1) Учиться сразу под Юникс.
2) Учиться с Си.
Это база, иначе вырастет быдлокодер.
иначе не станешь снобом
Я бы всё-таки рекомендовал осваивать ФЯ как более интересную концепцию.надо писать на тех языках, которуе хорошо транслируются в машинный код. Хороший программист должен прежде всего ПОНИМАТЬ как работает компьютер.
ФЯ же такое представление не развивают, они вообще непонятно кому и зачем нужны.
надо писать на тех языках, которуе хорошо транслируются в машинный код.т.е. на Python или Ruby писать нельзя?
т.е. на Python или Ruby писать нельзя?Обучаться точно не стоит на этих языках.
Обучаться точно не стоит на этих языках.почему?
ну т.е. я понимаю, что твой ответ "иначе получится быдло-кодер", но я как раз хочу понять, почему он получится. Чуть более раскрой свой ответ.
вот из-за таких как ты дети думают что Си сложный.по-твоему, он такой простой? Кто говорит "проще чем отнять конфету у ребёнка" никогда не пробовал отнять конфету у ребёнка.
send(int count) {
if (!count) return;
int n = (count + 7) / 8;
switch (count % 8) {
case 0: do { puts("case 0");
case 7: puts("case 7");
case 6: puts("case 6");
case 5: puts("case 5");
case 4: puts("case 4");
case 3: puts("case 3");
case 2: puts("case 2");
case 1: puts("case 1");
} while (--n > 0);
}
}
#define DECLARE int state
#define INIT state = 0
#define BEGIN switch (state) { \
case 0:
#define YIELD(val) do { \
state = __LINE__; \
return val; \
case __LINE__: \
; \
} while (0)
#define END }
const char* next
{
BEGIN;
YIELD("мама");
YIELD("мыла");
YIELD("раму");
END;
return 0;
}
struct list_head {
struct list_head *next, *prev;
};
#define LIST_HEAD_INIT(name) { &(name &(name) }
#define LIST_HEAD(name) \
struct list_head name = LIST_HEAD_INIT(name)
#define INIT_LIST_HEAD(ptr) do { \
(ptr)->next = (ptr); (ptr)->prev = (ptr); \
} while (0)
#define list_entry(ptr, type, member) \
type *char *ptr)-(unsigned long&type *)0)->member
#define list_for_each(pos, head) \
for (pos = (head)->next; pos != (head); pos = pos->next)
ну и вообще, макросы, указатели на функции, низкоуровневая работа с памятью, адресная арифметика - всё это простым не назовёшь.
Мои примеры академические. А если в живые проекты заглянуть на исходники, то там ещё большую жесть найти можно.
почему?плохо начинать со слишком умных языков. Программирование должно первым делом разрушить ожидания от компьютера чуда. И статическая типизация лучше в воспитательных целях. Тут помнится говорили, чтобы избавить от багов типизации в питоне придумали unit тесты. Ты будешь объяснять абсолютному новичку как их писать? мне кажется, что начинать нужно с простых языков. Для разработки можно использовать сложные, потому что они предоставляют больше возможностей. А для обучения - минималистичные, пусть он сначала базовые и самые простые возможности уяснит.
ну т.е. я понимаю, что твой ответ "иначе получится быдло-кодер", но я как раз хочу понять, почему он получится. Чуть более раскрой свой ответ.
А вот есть такое наблюдение, что в воспитательных целях полезно сначала увлечь человека, а потом вовремя направить в верное русло. Т.е. я согласен, что без знания как работает компьютер, нормально программировать скорее всего нельзя. Но самое главное, что нельзя научить программировать, если человек этого сильно не хочет. А желание обычно появляется, когда у человека уже что-то получилось. В этом смысле, лучше нулевым языком выбирать что-то, где написал три строчки и уже "мигает лампочка".
Хороший программист должен прежде всего ПОНИМАТЬ как работает компьютер.Тогда лучше почитать design and implementation какой-нибудь ОС, благо выбор книг есть. Но перед этим скорее всего придётся выучить С, ага.
В этом смысле, лучше нулевым языком выбирать что-то, где написал три строчки и уже "мигает лампочка".поставить ученику какую-нибудь игру на программирование роботов. Например стрельбища танков. Сделать самому большую часть управляющей программы. Запихать её в шаблон. Оставить незаполненной одну-две простые ключевые функции и предоставить ему самому написать их. Например твой шаблон находит полный список целей и их вероятных положений, а ученик всего лишь пишет процедуру, которая выбирает номер цели, за которой нужно гоняться в данный момент.
ну т.е. я понимаю, что твой ответ "иначе получится быдло-кодер", но я как раз хочу понять, почему он получится. Чуть более раскрой свой ответ.Тут уже ответили чуть выше, поэтому ничего нового я не скажу.
Умение программировать — это умение понимать процессы внутри компьютера. Любая попытка «спрятать суть» — это колоссальный, часто непоправимый вред юному мозгу, потому что подменяет понятия, вводит в заблуждения. Человек потом узнает правду, а в подкорке останется неверное мышление. Сравнение привести могу с плаванием: либо ты идёшь в воду и учишься плавать, либо перестаешь мечтать что катание на яхте научит тебя плавать.
Почему Микрософт зло? Прежде всего потому что дает тот самый катер, от которого создается ложное впечатление умения плавать.
Опять же, если ты уже умеешь плавать, тебе можно попробовать что-то другое. Но учиться(!) плавать с катамарана — глупость.
библиотека С и ядро юникс тоже немало сути спрятали, иначе они не были бы такими жирными. При всём моём их почитании, не понимаю, почему же они не попадают под твою критику.
> надо писать на тех языках, которуе хорошо транслируются в машинный код.
> Хороший программист должен прежде всего ПОНИМАТЬ как работает компьютер.
Ни в коем случае нельзя допускать обучение языкам, которые хорошо
транслируются в машинный код. Программист должен быть программистом,
а не придатком к машине.
> ФЯ же такое представление не развивают, они вообще непонятно кому и зачем нужны.
ФЯ развивают представление о том, что такое программирование,
то, что не всегда доступен оптимальный интерпретатор, не должно
останавливать программиста.
---
"Прямая --- короче, парабола --- круче."
> Хороший программист должен прежде всего ПОНИМАТЬ как работает компьютер.
Ни в коем случае нельзя допускать обучение языкам, которые хорошо
транслируются в машинный код. Программист должен быть программистом,
а не придатком к машине.
> ФЯ же такое представление не развивают, они вообще непонятно кому и зачем нужны.
ФЯ развивают представление о том, что такое программирование,
то, что не всегда доступен оптимальный интерпретатор, не должно
останавливать программиста.
---
"Прямая --- короче, парабола --- круче."
Сообщение удалил
> Умение программировать — это умение понимать процессы внутри компьютера.
Знать временные диаграммы просто необходимо.
---
"Математика --- лучший способ водить самого себя за нос."
Знать временные диаграммы просто необходимо.
---
"Математика --- лучший способ водить самого себя за нос."
colobot 
>> Программист должен быть программистом, а не придатком к машине.
> Разверни, пожалуйста.
Улучшением машин занимаются другие люди, программисту незачем
выполнять их работу, ничего особенно хорошего из этого не выходило,
просто из-за того, что невозможно досконально разбираться во всём.
Поэтому незачем "хорошо" разбираться во внутреннем устройстве.
---
"...Физик должен, хотя бы в какой-то мере, быть в здравом рассудке."
> Разверни, пожалуйста.
Улучшением машин занимаются другие люди, программисту незачем
выполнять их работу, ничего особенно хорошего из этого не выходило,
просто из-за того, что невозможно досконально разбираться во всём.
Поэтому незачем "хорошо" разбираться во внутреннем устройстве.
---
"...Физик должен, хотя бы в какой-то мере, быть в здравом рассудке."
Сообщение удалил
Согласен с Контрой.
Программирование - это независимое от исполнителя умение.
Программировать можно разного исполнителя: регистровую машинку, стековую машинку, человека, программируемую матрицу, событийную машинку, машину тьюринга, базу данных и т.д.
и навык программирования один для всего этого.
язык C плох тем, что он сильно завязан на регистровую машинку, и вместо обучения программирования - приходиться обучаться втискиванию программирования в жесткие рамки регистровой машинки - и как правильно заметил Контра - становиться придатком этой машины.
для обучения программирования - да, намного лучше освоить ФЯ.
ps
кроме программирования - есть еще автоматизация, кстати.
Программирование - это независимое от исполнителя умение.
Программировать можно разного исполнителя: регистровую машинку, стековую машинку, человека, программируемую матрицу, событийную машинку, машину тьюринга, базу данных и т.д.
и навык программирования один для всего этого.
язык C плох тем, что он сильно завязан на регистровую машинку, и вместо обучения программирования - приходиться обучаться втискиванию программирования в жесткие рамки регистровой машинки - и как правильно заметил Контра - становиться придатком этой машины.
для обучения программирования - да, намного лучше освоить ФЯ.
ps
кроме программирования - есть еще автоматизация, кстати.
>> Улучшением машин занимаются другие люди,
>> программисту незачем выполнять их работу,
> А ты в компьютерные игры, пардон, играл когда-нибудь?
> Прожорливые такие, фотореалистичные, с большим количеством
> персонажей, я имею в виду?
>> ничего особенно хорошего из этого не выходило,
> Если человек имеет хотя бы минимальные представления, скажем
> о кэше, скорость кода можно повысить очень заметно.
Этим надо заниматься в самую последнюю очередь, когда видно,
что всё возможное сделали, но скорости не хватает. Никакое
знание способов оптимизации доступа к памяти не ускоряет
программы сколь-либо сравнимо с правильным выбором алгоритма.
---
"Прямая --- короче, парабола --- круче."
>> программисту незачем выполнять их работу,
> А ты в компьютерные игры, пардон, играл когда-нибудь?
> Прожорливые такие, фотореалистичные, с большим количеством
> персонажей, я имею в виду?
>> ничего особенно хорошего из этого не выходило,
> Если человек имеет хотя бы минимальные представления, скажем
> о кэше, скорость кода можно повысить очень заметно.
Этим надо заниматься в самую последнюю очередь, когда видно,
что всё возможное сделали, но скорости не хватает. Никакое
знание способов оптимизации доступа к памяти не ускоряет
программы сколь-либо сравнимо с правильным выбором алгоритма.
---
"Прямая --- короче, парабола --- круче."
программы сколь-либо сравнимо с правильным выбором алгоритма.вот решаем мы значит задачу внешней сортировки данных. И есть у нас замечательный отработанный алгоритм, и коэфициент у него низкий, и ассимптотика хорошая - просто идеальный выбор настоящего программиста. А придаток компьютера всего этого не знал, у него алгоритм похуже, зато он знает, что его задача будет считаться на магнитной ленте с последовательным доступом. Как ты думаешь, у кого будет быстрее?
> А придаток компьютера всего этого не знал, у него алгоритм похуже,
> зато он знает, что его задача будет считаться на магнитной ленте
> с последовательным доступом.
Доброе утро! Сегодня --- 25 ноября 2009-го года.
---
...Я работаю антинаучным аферистом...
> зато он знает, что его задача будет считаться на магнитной ленте
> с последовательным доступом.
Доброе утро! Сегодня --- 25 ноября 2009-го года.
---
...Я работаю антинаучным аферистом...
Сообщение удалил
>> Этим надо заниматься в самую последнюю очередь, когда видно,
>> что всё возможное сделали, но скорости не хватает.
> А поконкретнее можно? Что ты имеешь в виду?
Там, чудо, русским языком написано, что имеется в виду,
но поскольку ты запоминаешь только последнее предложение...
У тебя спичек не осталось?
---
...Я работаю антинаучным аферистом...
>> что всё возможное сделали, но скорости не хватает.
> А поконкретнее можно? Что ты имеешь в виду?
Там, чудо, русским языком написано, что имеется в виду,
но поскольку ты запоминаешь только последнее предложение...
У тебя спичек не осталось?
---
...Я работаю антинаучным аферистом...
И есть у нас замечательный отработанный алгоритм, и коэфициент у него низкий, и ассимптотика хорошая - просто идеальный выбор настоящего программиста. А придаток компьютера всего этого не знал, у него алгоритм похуже, зато он знает, что его задача будет считаться на магнитной ленте с последовательным доступом.это стандартная проблема - вида что лучше - быть здоровым или богатым?
и ответ: лучше уметь понимать алгоритмы, уметь их создавать; а также понимать как устроен текущий исполнитель.
если же вопрос: что изучать первым - устройство исполнителя, или умение правильно формулировать и записывать алгоритмы?
то лучше начинать - с умения правильно формулировать и записывать алгоритмы. как минимум из-за того, что за счет правильной записи алгоритма можно получить ускорения даже в миллионы раз, в отличии - от понимания исполнителя - где выигрышь разы, максимум сотни раз.
ps
как пример - задача в соседнем треде про вывод графика.
там правильная постановка задачи дает намного больше, чем знание - как можно быстро вывести точку на экран.
лучше начинать - с умения правильно формулировать и записывать алгоритмы. как минимум из-за того, что за счет правильной записи алгоритма можно получить ускорения даже в миллионы раз, в отличии - от понимания исполнителя
А как без понимания исполнителя правильно оценивать сложность? Напишет человек сортировку массива на РНР, оценит ее сложность как учили и будет полностью неправ, т.к. обращение к массиву в РНР не О(1).
А как без понимания исполнителя правильно оценивать сложность? Напишет человек сортировку массива на РНР, оценит ее сложность как учили и будет полностью неправ, т.к. обращение к массиву в РНР не О(1).для этого часто достаточно метода тыка, итерационного подхода и теоретической оценки.
запустили - посмотрели с какой скоростью оно работает, сделали выводы.
а может лучше обратный подход: сначала читаем спецификации и только потом пишем алгоритм с их учётом? Чем сначала пишем неработающий алгоритм, а потом читаем спеки
а может лучше обратный подход: сначала читаем спецификации и только потом пишем алгоритм с их учётом? Чем сначала пишем неработающий алгоритм, а потом читаем спекитяжело читать спеку, не имея в голове конкретного вопроса. возьмем предыдущий вопрос - в спеке же не будет совета - старайтесь не писать свои сортировки, т.к. php это скриптовый язык.
а вот ответ на вопрос - почему моя сортировка в 100 раз медленнее стандартной - уже по спеке или по гуглу проще искать.
оба подхода работают, но второй подход - при использовании итерационного подхода с малыми итерациями - работает быстрее. т.к. имея на руках пример - который уже как-то работает - можно перейти к задаванию конкретных вопросов, а не абстрактных.
> А как без понимания исполнителя правильно оценивать сложность?
Сложность --- это длина записи программы.
Оценивать время вычислений на первых порах не требуется,
тем более --- правильно оценивать.
> обращение к массиву в РНР не О(1).
Это --- не должно волновать прикладного программиста,
это внутренние проблемы интерпретатора языка.
---
"Контра бы из Ленина цитату подобрал."
Сложность --- это длина записи программы.
Оценивать время вычислений на первых порах не требуется,
тем более --- правильно оценивать.
> обращение к массиву в РНР не О(1).
Это --- не должно волновать прикладного программиста,
это внутренние проблемы интерпретатора языка.
---
"Контра бы из Ленина цитату подобрал."
Чем сначала пишем неработающий алгоритм, а потом читаем спекиво-первых, возьмем еще раз задачку из соседнего треда про график.
какую спеку надо там читать? спеку на opengl? так это и будет premature optimization.
во-вторых, я пока не понимаю - что такое неработающий алгоритм.
если он неработающий - то значит программист не умеет писать алгоритмы - и к пониманию работы исполнителя это никакого отношения не имеет.
алгоритм может быть медленный, использовать ресурсы не оптимально и т.д. - но он работающий.
самое главное - что чем высокоуровнее мы алгоритм запишем на имеющемся языке, тем проще его потом будет оптимизировать.
банальный пример - одно дело наша программа вызывает нашу функцию sort, которая тормозит; другое дело - когда этот сорт тесно в виде спагетти вплетен в код - тут уже что-то сложно оптимизировать.
Си кстати плох тем, что представляет очень мало средств для высокоуровневой записи алгоритма.
Сложность — это длина записи программы.
Большей глупости я не слышал.
Сложность — это оценка ВРЕМЕНИ исполнения программы в шагах в зависимости от исходных данных.
Это — не должно волновать прикладного программиста,
это внутренние проблемы интерпретатора языка.
Это как раз должно волновать программиста, а не волнует это быдлокодеров.
Сложность — это оценка ВРЕМЕНИ исполнения программы в шагах в зависимости от исходных данных.Это терминологический вопрос.
Подведу итог. Все кто считают иначе — тупые мудаки и быдлокодеры.
Учиться начинать надо с фундаментальных вещей, которые не меняются десятилетия. Учить очередную версию .NET — большая глупость, потому что через пять лет о ней не будет уже никто знать. Из этого вытекает простое утверждение: при обучении надо держаться подальше от маркетингового булщита.
Учиться надо фундаментальным вещам:
1) как работает компьютер, какие элементарные операции он умеет делать, а какие нет?
2) классические приемы построения из элементарных операций более сложных: циклы, рекурсия, структуры данных.
3) классические приемы работы с железом на низком уровне. Это очень полезно для развития молодого мозга, какую-нибудь USB-какашку попрограммировать, в идеале что-то типа робота.
4) классические приемы разработки gui: gtk, qt, winapi — всё надо посмотреть, всё опробовать.
5) ознакомиться с потоками. Сейчас у молодёжи часто двухядерные процы, вот пусть и сортировку сделают на два ядра.
6) tcp/ip: постенькие программки, чтобы ещё select/poll в мозг вошел плотно.
7) обязательно в курс обучения включить изучение и улучшение какой-нибудь GPL-программки, например игрушки или screen saver'а. Небольшой патч, который будет принят — хорошее достижение, которым можно гордиться.
Вот примерный список с чем стоит ознакомить школьника. С чем знакомить не надо:
1) Веб-программирование (сам научится, если будет база выше особенно ПХП.
2) Слишком раннее знакомство с ООП нанесёт вред. При обучении я бы избегал ООП где только можно.
3) Ни в коем случае никаких джав, томкатов, аппликейшн серверов, дотнетов и прочего энтерпрайза.
Учиться начинать надо с фундаментальных вещей, которые не меняются десятилетия. Учить очередную версию .NET — большая глупость, потому что через пять лет о ней не будет уже никто знать. Из этого вытекает простое утверждение: при обучении надо держаться подальше от маркетингового булщита.
Учиться надо фундаментальным вещам:
1) как работает компьютер, какие элементарные операции он умеет делать, а какие нет?
2) классические приемы построения из элементарных операций более сложных: циклы, рекурсия, структуры данных.
3) классические приемы работы с железом на низком уровне. Это очень полезно для развития молодого мозга, какую-нибудь USB-какашку попрограммировать, в идеале что-то типа робота.
4) классические приемы разработки gui: gtk, qt, winapi — всё надо посмотреть, всё опробовать.
5) ознакомиться с потоками. Сейчас у молодёжи часто двухядерные процы, вот пусть и сортировку сделают на два ядра.
6) tcp/ip: постенькие программки, чтобы ещё select/poll в мозг вошел плотно.
7) обязательно в курс обучения включить изучение и улучшение какой-нибудь GPL-программки, например игрушки или screen saver'а. Небольшой патч, который будет принят — хорошее достижение, которым можно гордиться.
Вот примерный список с чем стоит ознакомить школьника. С чем знакомить не надо:
1) Веб-программирование (сам научится, если будет база выше особенно ПХП.
2) Слишком раннее знакомство с ООП нанесёт вред. При обучении я бы избегал ООП где только можно.
3) Ни в коем случае никаких джав, томкатов, аппликейшн серверов, дотнетов и прочего энтерпрайза.
Это терминологический вопрос.Нет.
Длинна программы — это размер исходника. Сложность алгоритма — это время выполнения. Связи между ними нет.
>> Сложность — это длина записи программы.
> Большей глупости я не слышал.
Ну да, Колмогоров, Шеннон --- да все они какими-то глупостями занимались.
> Сложность — это оценка ВРЕМЕНИ исполнения программы в шагах
> в зависимости от исходных данных.
Копать с утра и до обеда следующего понедельника это очень-очень сложно.
>> Это — не должно волновать прикладного программиста,
>> это внутренние проблемы интерпретатора языка.
> Это как раз должно волновать программиста, а не волнует это быдлокодеров.
Ты никогда не сталкивался с ошибками в компиляторе?
Все эти вещи с неэффективностью реализации интерпретаторов и
компиляторов должны волновать тех, кому это правда очень важно.
Если у тебя программа почти всё время сидит в select, kqueue,
nanosl, pause и т.п., то она может быть написана хоть на питоне.
---
"Narrowness of experience leads to narrowness of imagination."
> Большей глупости я не слышал.
Ну да, Колмогоров, Шеннон --- да все они какими-то глупостями занимались.
> Сложность — это оценка ВРЕМЕНИ исполнения программы в шагах
> в зависимости от исходных данных.
Копать с утра и до обеда следующего понедельника это очень-очень сложно.
>> Это — не должно волновать прикладного программиста,
>> это внутренние проблемы интерпретатора языка.
> Это как раз должно волновать программиста, а не волнует это быдлокодеров.
Ты никогда не сталкивался с ошибками в компиляторе?
Все эти вещи с неэффективностью реализации интерпретаторов и
компиляторов должны волновать тех, кому это правда очень важно.
Если у тебя программа почти всё время сидит в select, kqueue,
nanosl, pause и т.п., то она может быть написана хоть на питоне.
---
"Narrowness of experience leads to narrowness of imagination."
Это действительно терминологический вопрос. Раньше именно это и называли сложностью алгоритма, сейчас обычно прилагательные привешивают.
Ну да, Колмогоров, Шеннон — да все они какими-то глупостями занимались.
Stop trolling!
На Колмогорова он тут ссылается, ты ещё на Ломоносова сошлись.
Надо тебе еще поучиться.
"Programs must be written for people to read, and only incidentally for machines to execute."
- Abelson & Sussman, SICP, preface to the first edition
> Учиться надо фундаментальным вещам:
> 1) как работает компьютер, какие элементарные операции он умеет делать,
> а какие нет?
Когда-то компьютеры не умели умножать, и подобные тебе идиоты
внушали всем, что умножение --- это очень дорогая операция,
а деление так совсем уж. Соответственно, операций таких не было.
До какого-то времени не было элементарной "call", а потом появилась.
Какие элементарные операции ты считаешь фундаментальными?
Ты, вообще, в курсе, что процессоры бывают не просто "MIPS"
или "ARM", а бывают, например, стековые машины и систолические массивы?
Что бывают вот такие процессоры?
Похожие штуки видел для Smalltalk.
> 2) классические приемы построения из элементарных операций более сложных:
> циклы, рекурсия, структуры данных.
Что ж ты не вспомнил, что рекурсия --- это очень-очень дорого?
> 3) классические приемы работы с железом на низком уровне.
Какие приёмы работы с "железом" ты называешь классическими?
> 6) tcp/ip: постенькие программки, чтобы ещё select/poll в мозг вошел плотно.
То есть, ты не в курсе даже вот этого:
Наверное, ты и TCP считаешь вершиной творения.
> 2) Слишком раннее знакомство с ООП нанесёт вред.
> При обучении я бы избегал ООП где только можно.
Алан Кей, про которого ты ничего не знаешь, придерживается прямо
противоположного мнения, причём он имеет соответствующий опыт.
Можно узнать, сколько ты детей обучал?
---
"Narrowness of experience leads to narrowness of imagination."
> 1) как работает компьютер, какие элементарные операции он умеет делать,
> а какие нет?
Когда-то компьютеры не умели умножать, и подобные тебе идиоты
внушали всем, что умножение --- это очень дорогая операция,
а деление так совсем уж. Соответственно, операций таких не было.
До какого-то времени не было элементарной "call", а потом появилась.
Какие элементарные операции ты считаешь фундаментальными?
Ты, вообще, в курсе, что процессоры бывают не просто "MIPS"
или "ARM", а бывают, например, стековые машины и систолические массивы?
Что бывают вот такие процессоры?
Похожие штуки видел для Smalltalk.
> 2) классические приемы построения из элементарных операций более сложных:
> циклы, рекурсия, структуры данных.
Что ж ты не вспомнил, что рекурсия --- это очень-очень дорого?
> 3) классические приемы работы с железом на низком уровне.
Какие приёмы работы с "железом" ты называешь классическими?
> 6) tcp/ip: постенькие программки, чтобы ещё select/poll в мозг вошел плотно.
То есть, ты не в курсе даже вот этого:
NOTES
It is recommended to use the poll(2) interface instead, which tends to be
more portable and efficient.
Наверное, ты и TCP считаешь вершиной творения.
> 2) Слишком раннее знакомство с ООП нанесёт вред.
> При обучении я бы избегал ООП где только можно.
Алан Кей, про которого ты ничего не знаешь, придерживается прямо
противоположного мнения, причём он имеет соответствующий опыт.
Можно узнать, сколько ты детей обучал?
---
"Narrowness of experience leads to narrowness of imagination."
>> Сложность — это длина записи программы.
> Большей глупости я не слышал.
Ну да, Колмогоров, Шеннон --- да все они какими-то глупостями занимались.
А теперь, умник, давай сюда цитату Колмогорова или Шеннона, где они говорили бы, что сложность алгоритма - "это длина записи программы". А еще расскажи как колмогоровская сложность связана с выражениями в О-нотации от длины исходных данных.
А теперь, умник, давай сюда цитату Колмогорова или Шеннона, где они говорили бы, что сложность алгоритма - "это длина записи программы".вики - первая строчка
Неформально, колмогоровская сложность последовательности из нулей и единиц — это длина самой короткой программы, которая может породить эту последовательность.http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BB%D0%BC%D0%BE%...
простите, что вмешиваюсь, но мне кажется, что
это не то же что,
иными словами, сложность последовательности - это длина программы, генерирующей последовательность.
но сложность самой программы не относится к сложности последовательности каких-то нулей и единиц.
в данных терминах можно говорить что сложность программы_1 - это длина программы_2 которая может породить эту программу_1
что сложность алгоритма - "это длина записи программы".
это не то же что,
сложность последовательности из нулей и единиц — это длина самой короткой программы, которая может породить эту последовательность.
иными словами, сложность последовательности - это длина программы, генерирующей последовательность.
но сложность самой программы не относится к сложности последовательности каких-то нулей и единиц.
в данных терминах можно говорить что сложность программы_1 - это длина программы_2 которая может породить эту программу_1
в данных терминах можно говорить что сложность программы_1 - это длина программы_2 которая может породить эту программу_1если придерживаться формализма, то можно ввести сложность алгоритма как:
сложность алгоритма - это отношение длины записи алгоритма к длине записи минимального(с минимальной слолжностью) алгоритма решающего ту же задачу
тогда получается что все нечерезжопные алгоритмы имеют сложность 1. а все остальные >1. и это получилась мера не сложности, а черезжопности реализации алгоритма.
Это довольно неочевидно. Более длинная реализация может быть более понятной, чем более короткая.
вики - первая строчка
И где там про сложность алгоритмов? Цитату мне, цитату!
если придерживаться формализма, то можно ввести сложность алгоритма как:
сложность алгоритма - это отношение длины записи алгоритма к длине записи минимального(с минимальной слолжностью) алгоритма решающего ту же задачу
Очаровательная глупость, сам придумал?
Т.е. длинные названия переменных увеличивают сложность алгоритмов?
Они же влияют на "длину записи алгоритма". И где взять алгоритм минимальной сложности для заданной задачи? В колмогоровской сложности говорят что-то про "отсутствие вычислимой нижней оценки". Hutter Prize тебя давно ждет.
А уж определение сложности алгоритма через сложность алгоритма - это просто шедевр.
Кстати, поздравляю, ты только что доказал, что Р=NP, т.к. по твоему определению сложность любого алгоритма - константа.
Т.е. длинные названия переменных увеличивают сложность алгоритмов?Вообще в определении КС речь идёт о длине записи алгоритма для МТ. Можно конечно, и сложность на любом тьюринг-полном языке оценивать, но тогда лучшей мерой будет число инструкций (действий а не число символов в программе.
(accidental doublepost, see below)
О, ты видел определение? Может хоть ты дашь ссылку на место, где Колмогоров определяет сложность алгоритмов? (а не сложность строк)
>число инструкций (действий)
Вызов библиотечной функции - это сколько инструкций? Выделение памяти - сколько инструкций? Освобождение ее?
>число инструкций (действий)
Вызов библиотечной функции - это сколько инструкций? Выделение памяти - сколько инструкций? Освобождение ее?
О, ты видел определение? Может хоть ты дашь ссылку на место, где Колмогоров определяет сложность алгоритмов? (а не сложность строк)Действительно, речь идёт о сложности строк. По идее, такую сложность можно использовать для оценки алгоритмов без входных данных.
Вызов библиотечной функции - это сколько инструкций? Выделение памяти - сколько инструкций? Освобождение ее?Если оценивать время выполнения реальной программы, то можно задать некоторые веса для данных высокоуровневых инструкций, ну или разложить всё до инструкций машины (которые тоже работают не всегда одинаково). Это зависит от того, насколько наша абстракция машины приближена к реальности.
Действительно, речь идёт о сложности строк. По идее, такую сложность можно использовать для оценки алгоритмов без входных данных.
Нельзя. Т.е. попытаться можно, но результат будет бредовый.
Если оценивать время выполнения реальной программы
Оценка времени по имеющейся спецификации исполнителя - уже совсем другая задача. Речь-то выше шла об оценке сложности алгоритмов по длине их исходников, без моделирования.
Если оценивать время выполнения реальной программы, то можно задать некоторые веса для данных высокоуровневых инструкций, ну или разложить всё до инструкций машины (которые тоже работают не всегда одинаково). Это зависит от того, насколько наша абстракция машины приближена к реальностиэто уже другая сложность - это сложность исполнения.
по колмогорову - вставка в программу архиватора, которую ее саму разжимает перед исполнением - это уменьшение сложности - хотя с точки зрения исполнения - это увеличение сложности.
все эти веса не нужны, т.к. сложность по Колмогорову очень близка к сложности восприятия программы.
пример: допустим у нас есть исполнитель, который понимает высокоуровневые инструкции:
sort - отсортировать последовательность по возрастанию
take - взять несколько первых элементов.
тогда задача получить 10 минимальных элементов с минимальной сложностью по колмогорову будет:
sort(items).take(10)
а не
var resultLength = 10;
var result = new T[resultLength];
var count = 0;
for (int i = 0; i < items.length; ++i)
{
var item = items[i];
for (int j = 0; j < count; ++j)
{
if (item < result[j])
{
if (count < resultLength)
count++;
for (int k = count-1; k > j; k--)
{
result[k] = result[k-1];
}
result[j] = item;
break;
}
}
}
хотя сложность исполнения второго меньше, чем сложность исполнения первой конструкции (особенно если, во-вторую, еще двоичный поиск воткнуть вместо линейного)
Т.е. длинные названия переменных увеличивают сложность алгоритмов? Они же влияют на "длину записи алгоритма".всегда забывают - что у программы всегда два исполнителя: машина и человек, который ее пишет.
человек - когда пишет программу, он ее неявно проигрывает у себя в голове.
длинные идентификаторы - это для человека;
соответственно - да, заменяя длинные идентификаторы на короткие - ты уменьшаешь сложность по колмогорову, но увеличиваешь сложность восприятия человеком.
И где взять алгоритм минимальной сложности для заданной задачи? В колмогоровской сложности говорят что-то про "отсутствие вычислимой нижней оценки". Hutter Prize тебя давно ждет.это ты с Колмогоровым спорь, т.к. у него уже в определении написано, что мы выписываем все возможные варианты генераторов последовательности, и значит минимальная там тоже есть
Принимая во внимание все возможные программы, которые генерируют последовательность s и выбирая кратчайшую, мы получим минимальное описание последовательности s, обозначаемое как d(s).ps
ты кстати какой-то странный - и пытаешься строить свою аргументацию на том, что действия записанные в определении должны быть практически выполнимы.
с определением интеграла и производной ты тоже споришь?
там в определении того же интеграла тоже написано, что интервал надо устремить к бесконечной малому - что практически невыполнимо.
И где взять алгоритм минимальной сложности для заданной задачи?кстати очевидно, что это делается последовательным перебором программ(алгоритмов) от самых коротких к самым длинным до момента - когда полученный алгоритм будет решать поставленную задачу.
Вообще в определении КС речь идёт о длине записи алгоритма для МТ. Можно конечно, и сложность на любом тьюринг-полном языке оценивать, но тогда лучшей мерой будет число инструкций (действий а не число символов в программе.можно и так, и так
в первом случае - берется длина бинарника,
во втором случае - берется длина программы + длина компилятора.
тогда получается что все нечерезжопные алгоритмы имеют сложность 1. а все остальные >1. и это получилась мера не сложности, а черезжопности реализации алгоритма.в целом, да
т.к. Сложность по колмогорову - это кол-во информации.
введенная мной мера - это фактически отношение кол-ва "воды" к кол-ву сути в записи алгоритма (или более строго - отношение сути+"воды" к сути)
Короче, мы о разных вещах говорим. Ты пытаешься объективно определить субъективную сложность восприятия программы человеком, а не сложность алгоритма как ее обычно понимают в computer science. Но колмогоровскую сложность напрасно сюда приплели, не годится она для этого.
кстати очевидно, что это делается последовательным перебором программ(алгоритмов) от самых коротких к самым длинным до момента - когда полученный алгоритм будет решать поставленную задачу.
кстати, очевидно, что этот процесс незавершим и не дает определенного ответа.
по колмогорову - вставка в программу архиватора, которую ее саму разжимает перед исполнением - это уменьшение сложности
Нет. Ты забыл про минимум в ее определении.
ты кстати какой-то странный - и пытаешься строить свою аргументацию на том, что действия записанные в определении должны быть практически выполнимы.
с определением интеграла и производной ты тоже споришь?
Интеграл и производную можно найти за конечное время и получить конкретный результат. Ты же делишь число на задницу (_|_). Предлагаю еще в определении задействовать "минимальное натуральное число, о котором никто никогда не подумает". Оно тоже существует, и на него можно делить.
а не сложность алгоритма как ее обычно понимают в computer science.еще раз повторю - что в классическом computer science - рассматривается только сложность исполнения, просто потому что классический computer science пришел из 70-х, когда компьютеры были большими, а люди дешевле, чем компьютеры.
но при реальном программировании сегодня - появляется еще куча сложностей - сложность записи, сложность восприятия, сложность анализа и т.д.
и это все выходит на все более важное место - т.к. люди с каждым днем все дороже, чем компьютеры.
ps
и ты кстати понимаешь, что разбиение программы на функции - это ухудшение сложности, которую понимают в computer science? т.к. увеличивается сложность исполнения.
но на функции-то все-таки разбивают - значит сложность исполнения - это не единственный критерий.
и соответственно, ты понимаешь - что сложность из computer science - это далеко не самый важный критерий сегодня? иначе бы все до сих пор в машинных кодах бы и писали.
Интеграл и производную можно найти за конечное время и получить конкретный результат.это все можно сделать с какой-то точностью
также можно получить алгоритм минимальной сложности с какой-то точностью.
Да, все так, это я хорошо понимаю. Потому и написал, что обсуждаемая тобой сложность - другая ("о разных вещах говорим").
минимальное натуральное число, о котором никто никогда не подумаетУже не существует. Я о нем только что подумал
Т.е. длинные названия переменных увеличивают сложность алгоритмов?зависит от того, насколько они длинные, и в каком контексте это происходит
например, если это название низкоуровневого индекса при пробеге по массиву - то замена названия i на более длинное название - index_v_massive_vhodnykh_dannykh - конечно, усложнение.
а вот обратное - замена длинных на короткие - уже более интересна.
возьмем, например, обфускаторы.
одним из методов обфускации - это замена всех названий на максимально короткие -> A, B,C
по колмогорову - эта операция уменьшает кол-во воды в программе.
но почему же ее применяют только для обфускации, а не при обычной записи программы?
да все потому же - что исполнителем программы - является еще человек, а не только машина.
а у человека - ассоциативная память, а не механическая - и поэтому человеку тяжело переключаться между контекстами - если машине легко провести операцию: в данном контексте для удобства: B будет называться, как A, а C будет называться как B - то для человека эта трудно выполнимая операция.
и поэтому для программы, которую явно или неявно выполняется человеком - появляется еще одно требование - даже в разных контекстах одиннаковое должно называться одиннаково, а разное по разному.
отсюда и появляется требование на длинные идентификаторы, и на близость идентификаторов к реальному миру.
Я - топикстартер - в каком то роде пример для моего брата. Ему всегда был интересно, что из себя представляет моя работа. А когда я при нем за час написал решение классического тайского пазла, а он еще и поучаствовал, надиктовывая статические данные и проверяя решение, то загорелся еще больше.
Так что мигалки и пищалки - это не необходимое требование для того, чтобы заинтересовать подростка.
Так что мигалки и пищалки - это не необходимое требование для того, чтобы заинтересовать подростка.
Оставить комментарий
koly
Мой 14летний брат хочет научиться программировать и просит меня дать ему книгу. А я - разработчик с пятилетним стажем - не знаю, что и посоветовать.Подскажите книги, в которых разжевываются элементарные вещи и синтаксис какого-нибудь языка подается параллельно с простыми алгоритмами (поиск, сортировка).