LINUX.ORG.RU

Есть ли альтернатива SICP?

 ,


8

5

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

Первое, не самое важное, но тем не менее. Авторы взяли в качестве ЯП scheme, мотивируя это тем, что синтаксис очень прост для освоения новичком. Синтаксис то да, прост, но семантика не так уж и проста, и совершенно непонятно, почему было не взять любое другое подмножество лиспа, или даже бейсика, ведь для демонстрации принципов о которых там рассказывается вовсе не требуется сомнительное «волшебство» замыканий и продолжений. На одном синтаксисе далеко не уедешь, а семантику scheme (до глав о метаяз. абстракции) там не рассматривают вообще, и при этом заявляется, что низкий порог вхождения гарантирован. Это, мягко говоря, неправда.

Но самое главное — там слишком много воды. Для рассмотрения достаточно простых вещей, там берутся сложные, избыточные примеры. Например, главы о банковских счетах. Ведь основная мысль там — проблема разделения ресурса. Нахрена спрашивается было городить левые процедуры, вроде withdraw, get-money, put-money и проч. (названия там другие, но не суть), если для демонстрации идеи достаточно было change-balance и check-balance. Ведь основная проблема - в том чтобы посмотреть, а потом снять, чтобы другой объект не изменил в промежутке между двумя операциями. Вместо того, чтобы концентрироваться на основной вычислительной проблеме, на нас выливают тонны воды, в которой расмотреть основную мысль не очень то и просто.

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

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

UPD Забыл сказать, что я в корне не принимаю такие подходы, как «Структурное программирование», что-то в стиле «Something considered harmful» «не отстрели себе яйца», и языки заточенные под компиляцию. Поэтому подобные вещи не предлагать:)



Последнее исправление: phill (всего исправлений: 3)

«Understanding Computation».
«Computer Science Programming Basics in Ruby».

msray
()

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

Да, существует. Но ты должен понимать, что после столь огромного количества Lisp-срачей и Lisp-троллетредов на ЛОРе столь жирный вброс как твой уже не вызывает желаемой автором реакции. Как правило.

anonymous
()
Ответ на: комментарий от anonymous

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

phill
() автор топика
Ответ на: комментарий от vertexua

Я старым книгам больше доверяю, они дельше от мейнстрима и его влияния. Но это, собственно, не обязательно.

phill
() автор топика
Ответ на: комментарий от phill

А мне уже интересно как вы собрались концентирироваться на программиировании без программирования? Нет есть, конечно, вариант в виде алгорифмы Маркова, машина Тьюринга, но все равно они уже больше теоретическая computer science, которая все равно приходит, ВНЕЗАПНО, к вопросу реализации твоих умопостроений и здесь, ВНЕЗАПНО, возникает ЯП. Определитись что интересует из СS, а то может хватит pascal, так как алгоритмические курсы часто строют на его основе(например такой)

pylin ★★★★★
()
Ответ на: комментарий от phill

Я старым книгам больше доверяю, они дельше от мейнстрима и его влияния. Но это, собственно, не обязательно.

Вас ждет эта книга(нестарая, однако автор относительно мейнстрима вполне ясно выразился): Шень А. Программирование. Теоремы и задачи 2-е издание

pylin ★★★★★
()
Последнее исправление: pylin (всего исправлений: 3)
Ответ на: комментарий от pylin

А мне уже интересно как вы собрались концентирироваться на программиировании без программирования

Не ну я знаю некоторые ЯП чуток. Если в книге описан некий алгоритм или проблема, попробовать то можно на чем угодно. На крайняк - на бумаге, это же не главное, главное — понимание:)

phill
() автор топика
Ответ на: комментарий от phill

Я старым книгам больше доверяю, они дельше от мейнстрима и его влияния

думаете они дальше от мейнстрима ихнего периода?

а тред интересный, что там еще насоветуют

umren ★★★★★
()
Ответ на: комментарий от phill

Налетай, МЦНМО раздает бесплатно: http://www.mccme.ru/free-books/

Там просто есть еще несколько книг ближе к фундаментальной СS чем к прикладным вопросам информатики

pylin ★★★★★
()
Последнее исправление: pylin (всего исправлений: 1)
Ответ на: комментарий от unsigned

Спасибо, глянул содержание, вроде то что надо, на первый взгляд.

phill
() автор топика

Забыл сказать, что я в корне не принимаю такие подходы, как «Структурное программирование», что-то в стиле «Something considered harmful» «не отстрели себе яйца», и языки заточенные под компиляцию. Поэтому подобные вещи не предлагать:)

Ты еще не заслужил право привередничать.

Дейкстра «Дисциплина программирования»

Грис «Наука программирования»

tailgunner ★★★★★
()

аутоматизируй

уибирай:

Unix -среда программирования (книжка от создателей awk и golang)

алгоритмы вводный курс Кормен (!!! не его талмуд , а чиста введение(отдельный буклет подчёркивающий , что как всякая инженерная дисциплина(дальше см буклет))).

http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute

Alan Kay — The Computer Revolution Hasn't Happened Yet http://www.youtube.com/watch?v=oKg1hTOQXoY

зы. учитывая нонешнеи скорости , важно хоть на vba реализовать инструмент для конечного хомячка, тюнить же произодительность(переточкой алго либо снижением уровня(абстракции) языка) после некоторой(n много больше 1) итерации денег за.

http://vladimir-vg.github.io/blog/2012/04/02/five-rules/

qulinxao ★★☆
()
Последнее исправление: qulinxao (всего исправлений: 1)

Concepts, Techniques, and Models of Computer Programming (Peter Van Roy)

anonymous
()
Ответ на: комментарий от tailgunner

Дейкстра «Дисциплина программирования»

Не, дейкстра точно нет. Я прочитал пару его бумаг, это просто тот путь, по моему, по которому не стоит ходить (и по которому, ксожалению, пошла индустрия). Вместо понимания процессов - используйте сахар. Прямой путь в индусню.

phill
() автор топика

языки заточенные под компиляцию

пиши на баше , тот ещё макропроцессор подстановок.

а когда надоесть , возвращайся ходить по воде и писать на rc

qulinxao ★★☆
()
Ответ на: аутоматизируй от qulinxao

Спасибо, особенно кей интересует. У него, к сожалению, наверное, нет полноценного учебника, а позиции его, точка зрения на программирование - это просто идеальный взгляд. Сюда же и Хьюита я бы отнес. Но Хьюита сразу читать без подготовки мне трудновато пока. А не знате ли какого-нибудь легкого введения - учебника в стиле Кея или Хьюита для новичков?

phill
() автор топика

Забыл сказать, что я в корне не принимаю такие подходы, как «Структурное программирование»<...>

Зашёл на ЛОР с работы. Теперь на лужу жира под моим монитором недоумённо смотрят коллеги. Спасибо за ценный урок.

userid2
()
Ответ на: комментарий от userid2

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

phill
() автор топика
Ответ на: аутоматизируй от qulinxao

Alan Kay — The Computer Revolution Hasn't Happened Yet

1997

Сейчас бы он наверное сказал: компьютерная революция УЖЕ произошла и завела индустрию в тотальное гавно. И говорит, собственно.

anonymous
()
Ответ на: комментарий от phill

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

Ну ахренеть вообще.

tailgunner ★★★★★
()
Ответ на: комментарий от phill

Так и Дейкстра не навязывает вам структурирование, хотите месево, их есть у меня для вас, никто тебе не мешает затолкать всю логику в один блок программы, другое дело что за такие вещи надо убивать:) А так в структурном программировании, особенно у языков с нормальными стандартными библиотеками ты и выражаешь свои мысли.

Вместо понимания процессов - используйте сахар. Прямой путь в индусню

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

pylin ★★★★★
()

«Структурное программирование» --- это термин из 80-х годов, как противопоставление лапше из GOTO и кучи глобальных переменных, принятых тогда повсеместно. Сейчас такой подход встречается разве что в самом индусском коде, так что структурное программирование, можно сказать, победило.

Я SICP не читал, только просмотрел бегло, он мне показался слишком примитивным, но хочу сказать насчёт всех этих withdrawal и put-money: они могут быть там для того, чтобы показать, что функции используются не только для разбиения программы на составные части в соответствии с принципом «Do Not Repeat Yourself», но и для создания проблемно-ориентированной терминологии, использующейся потом непосредственно в коде. То есть, авторы SICP готовят читателя к идее рассматривать любую программу как [embedded] domain-specific language ([e]DSL), на котором и записывается решение проблемы. ...хотел дать почитать статью на эту тему, но не смог найти её в гугле. Могу посоветовать разве что первую главу On Lisp.

anonymous
()
Ответ на: комментарий от pylin

ты и выражаешь свои мысли

Выражаешь, причем именно так, как хотели бы [чтобы ты их выражал] Дейкстра и Вирт.

anonymous
()
Ответ на: комментарий от pylin

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

С чего Вы взяли, что сахар как-то связан с уровнем языка, а не с его синтаксисом?

anonymous
()
Ответ на: комментарий от anonymous

Сейчас такой подход встречается разве что в самом индусском коде

Такой подход ты можешь встретить у таких индусов как Кнут и Товальдс, весь вопрос в том, что называть лапшой (и главное — кто будет называть).

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

Это правда, и неудивительно.

anonymous
()
Ответ на: комментарий от anonymous

Выражаешь, причем именно так, как хотели бы [чтобы ты их выражал] Дейкстра и Вирт.

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

pylin ★★★★★
()
Ответ на: комментарий от anonymous

С чего Вы взяли, что сахар как-то связан с уровнем языка, а не с его синтаксисом?

С того что все высокоуровневые языки программирования с точки зрения аппаратуры машины самый настоящий сахарок, все программы ЯВУ проходят преобразование ЯВУ ->(ассемблер) ->машкод

pylin ★★★★★
()

Еще один несчастный повелся на борщепропаганду местных скорбных аутистов.

Забудь про SICP. Читай «Алгоритмы и структуры данных» Вирта, читай Седжвика и Кормена, читай Кнута, в конце концов. Там есть все.

anonymous
()
Ответ на: комментарий от anonymous

Сними крестик или надень трусы.

Какая разница для аппаратуры между концепциями Кея или Дейкстры ?

pylin ★★★★★
()
Ответ на: комментарий от pylin

все программы ЯВУ проходят преобразование ЯВУ ->(ассемблер) ->машкод

токмо копулируемые.

при интерперетации же просто программа чтец меняет состояние одной глобальной переменной.

qulinxao ★★☆
()
Ответ на: комментарий от pylin

Какая разница для аппаратуры между концепциями Кея или Дейкстры ?

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

anonymous
()
Ответ на: комментарий от anonymous

Читай «Алгоритмы и структуры данных» Вирта

Вот честно, дерьмо дерьмом. Не столько по содержанию, сколько по изложению и листингам (Паскаль и Оберон слишком «низкоуровневы» по сравнению со Схемой, много деталей требуют, за ними (деталями) суть теряется).

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

Так что «КПД» у СИКП получается выше. Если б они еще макросы там описали, для stream-cons, например, вместо представления этого как данность, было бы вообще отлично.

korvin_ ★★★★★
()
Ответ на: комментарий от qulinxao

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

pylin ★★★★★
()
Ответ на: комментарий от anonymous

хм хм.

если заблюрить , что идея Кея это в некотором смысле Акторы Хьюита , то вполне живо в контексте распределённых систем.

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

при интерперетации же просто программа чтец меняет состояние одной глобальной переменной.

Тред не читал, но ляпну что интерпретатор это тоже программа которая выполняет другую программу. Для проца ничего не меняется, верно?

true_admin ★★★★★
()
Ответ на: комментарий от pylin

С того что все высокоуровневые языки программирования с точки зрения аппаратуры машины самый настоящий сахарок, все программы ЯВУ проходят преобразование ЯВУ ->(ассемблер) ->машкод

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

(let((a 1)) a)
в точности соответствует:
((lambda(a) a)1)
тот же самый while/break/continue это сахар для гоуту. Тут, наверное важно, чтобы программист не забывал, что есть что, что тут, так-сказать, первично, чтоб он не думал, как-бы, что булки растут на деревьях. А это происходит при дейкстра-стайл подходе, неизбежно. Программист пишет конструкцию, не задумываясь о природе вычислений, ему кажется, что while - это примитив, тогда как while — всего лишь синтаксис, не имеющий ничего общего с вычислениями. Из этого порочного подхода вырастают программисты-секретарши, которые думают, что интерфейс нарисован карандашом на бумаге. В этом и есть основное зло подхода Дейкстры.

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

phill
() автор топика
Ответ на: комментарий от unlog1c

Что это за волшебное преобразование, научи.

Не знаешь разницы между ассемблером и машинным кодом? Почитай, какие сложные вещи приходится в рамках этого преобразования делать: http://eli.thegreenplace.net/2013/01/03/assembler-relaxation/

anonymous
()
Ответ на: комментарий от phill

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

Рассмотрим инструкцию addq %rax, %rbx, программист пишет эту инструкцию не задумываясь о микрокоде, ему кажется, что addq - это примитив, тогда как addq - всего лишь синтаксис, не имеющий ничего общего с вычислениями.

Begemoth ★★★★★
()

книжка о программировании (и только о нем — не о типах)

без типов ты, мягко говоря, ограничен в абстракции

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

Вот есть у меня программа, где определен тип: мужик. у него есть руки ноги и прочие прибамбасы. Понадобился мне например объект: спортсмен. Казалось бы, я могу взять мужика на эту роль. Я могу абстрагироваться от того, что его тип мужик, и считать его спортсменом. Могу, но только если мне не мешают жестко прописанные типы.

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

phill
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.