YS
А кто-нибудь читал Dragon Book на русском? Нормальный перевод?
Да и да. Не без "особенностей" в переводе терминов, кажется, но где их нет. ;)
Size: a a a
2020 April 10
PS
Все три «книги дракона» имеют вполне приличный перевод.
AK
у меня вторая редакция от 2008 года - перевод вполне приличный
LH
Спасибо!
LH
Все три «книги дракона» имеют вполне приличный перевод.
Три издания?
EO
А кто-нибудь читал Dragon Book на русском? Нормальный перевод?
Лично мне понравилось
PS
Три издания?
Ага. "Предтеча драконов", "Тот самый дракон" и "Сумасшедший-дракон-мутант-который-лучше-бы-не-появлялся".
DP
Ага. "Предтеча драконов", "Тот самый дракон" и "Сумасшедший-дракон-мутант-который-лучше-бы-не-появлялся".
в последнем что-то про реализацию Datalog вроде было для анализа типов?
YR
Про образование. Проблема в том, что каждый конкретный программист biased к своим любимым языкам, к своим любимым парадигмам, и считает, что учить надо именно так, чтобы максимизировать вовлечённость ученика в этот конкретный язык и парадигмы. Ответственный учитель должен абсолютно на 100% осознавать то, что он biased. Более того, он должен на 100% осознавать, почему он biased именно так, как biased, а не по-другому. Почему именно Haskell, а не Oberon. Иногда ответ может не понравится, но его нужно осознавать, чтобы своими ложными представлениями не заразить ученика. Ну, конечно, если у учителя уже нет тёплого местечка для таких учеников, которых он готовит под себя. Но тогда учитель должен честно объявлять о своих целях.
Например, если Вы начинаете учить человека со Схемы или Хаскеля, или Java, или Python, то он гарантированно получит огромные проблемы в понимании того, как работает железо, и для него работа на микроконтроллерах (а тема модная) будет очень долго казаться магией. У нас в универе такой эксперимент ставят на учащимися, и результат плачевен (с моей профессиональной точки зрения: люди могут идти в банки и кодить там, но запрограммировать простейший процесс на микроконтроллере или оптимизировать цикл для них - неподъёмная задача).
По мне так нормальное обучение программированию должно идти не от языков и их возможностей, а от практических задач и средств их решения. Кнут в этом смысле идеален, как форма представления материала.
Мы ставим конкретную задачу, выбираем алгоритм решения, кодируем. При этом, нужно понимать, что для кодирования простых алгоритмов, и ассемблер может быть эффективным инструментом. Программистам обязательно нужно показывать, как именно работает машина.
Си - это не плохой язык программирования, это язык, абстрагирующий ассемблерные парадигмы программирования. И тем он хорош. Если бы я учил людей программированию с нуля, и если бы у меня была задача научить хорошего программиста, а не адепта своей Схемо-секты, я бы поступил так:
1. Изучение архитектуры машины и API операционки (занатия 3-4) и простейшие алгоритмы на ассемблере. Благо, есть QEMU, есть Dos-Box, можно запускать код.
2. Изучение более сложных алгоритмов: сортировка там, поиск в ширину, может быть (занятия 3-4). Программирование на Си со словами: вот смотрите, у нас в простых алгоритмах возникали циклы, ветвления, процедуры и подпрограммы. Смотрите, как это поднимается на уровень выше в удобном синтаксисе. Считайте, что после этого у человека сразу отпадают проблемы с кучей языков императивного семейства, потому что идиомы примерно одинаковы. Синтаксис не важен!
3. Дальше можно ветвиться (на ФП или на ООП, кому как нравится; благо JS позволяет писать в обоих стилях), поднимая степень сложности задач. Здесь бы я прошёл SICP уже на том языке, на котором нравится учителю. SICP прекрасен тем, что он учит кодировать различные алгоритмические структуры (может и HtDP учит, но я не читал).
Со словами: вот видите, как мы на Си уделяли кучу времени деталям управления памятью, бла-бла-бла, но это не всегда рационально. Если нужно разработать сложную систему, можно взять более мощный язык, с более мощными парадигмами, и писать гораздо более сложный код быстрее. При чём, парадигмы нужно объяснять с переводом на ассемблер, чтобы люди понимали, насколько так или иная конструкция дорогая и уместная. Чтобы, например, не было иллюзий, что ленивый map (без оптимизаций) быстрее, чем энергичный map через reverse (без оптимизаций).
Но таких курсов особо нет. Поэтому, по моему разумению, если человек вынужден сам учиться программировать, то надо взять книгу "Секреты программирования игр", которая закрывает пункты 1, 2 более или менее, а потом надо взять SICP и порешать её на любом языке, который захочется освоить.
Например, если Вы начинаете учить человека со Схемы или Хаскеля, или Java, или Python, то он гарантированно получит огромные проблемы в понимании того, как работает железо, и для него работа на микроконтроллерах (а тема модная) будет очень долго казаться магией. У нас в универе такой эксперимент ставят на учащимися, и результат плачевен (с моей профессиональной точки зрения: люди могут идти в банки и кодить там, но запрограммировать простейший процесс на микроконтроллере или оптимизировать цикл для них - неподъёмная задача).
По мне так нормальное обучение программированию должно идти не от языков и их возможностей, а от практических задач и средств их решения. Кнут в этом смысле идеален, как форма представления материала.
Мы ставим конкретную задачу, выбираем алгоритм решения, кодируем. При этом, нужно понимать, что для кодирования простых алгоритмов, и ассемблер может быть эффективным инструментом. Программистам обязательно нужно показывать, как именно работает машина.
Си - это не плохой язык программирования, это язык, абстрагирующий ассемблерные парадигмы программирования. И тем он хорош. Если бы я учил людей программированию с нуля, и если бы у меня была задача научить хорошего программиста, а не адепта своей Схемо-секты, я бы поступил так:
1. Изучение архитектуры машины и API операционки (занатия 3-4) и простейшие алгоритмы на ассемблере. Благо, есть QEMU, есть Dos-Box, можно запускать код.
2. Изучение более сложных алгоритмов: сортировка там, поиск в ширину, может быть (занятия 3-4). Программирование на Си со словами: вот смотрите, у нас в простых алгоритмах возникали циклы, ветвления, процедуры и подпрограммы. Смотрите, как это поднимается на уровень выше в удобном синтаксисе. Считайте, что после этого у человека сразу отпадают проблемы с кучей языков императивного семейства, потому что идиомы примерно одинаковы. Синтаксис не важен!
3. Дальше можно ветвиться (на ФП или на ООП, кому как нравится; благо JS позволяет писать в обоих стилях), поднимая степень сложности задач. Здесь бы я прошёл SICP уже на том языке, на котором нравится учителю. SICP прекрасен тем, что он учит кодировать различные алгоритмические структуры (может и HtDP учит, но я не читал).
Со словами: вот видите, как мы на Си уделяли кучу времени деталям управления памятью, бла-бла-бла, но это не всегда рационально. Если нужно разработать сложную систему, можно взять более мощный язык, с более мощными парадигмами, и писать гораздо более сложный код быстрее. При чём, парадигмы нужно объяснять с переводом на ассемблер, чтобы люди понимали, насколько так или иная конструкция дорогая и уместная. Чтобы, например, не было иллюзий, что ленивый map (без оптимизаций) быстрее, чем энергичный map через reverse (без оптимизаций).
Но таких курсов особо нет. Поэтому, по моему разумению, если человек вынужден сам учиться программировать, то надо взять книгу "Секреты программирования игр", которая закрывает пункты 1, 2 более или менее, а потом надо взять SICP и порешать её на любом языке, который захочется освоить.
Я пришел к похожим выводам и одна из моих идей это начинать учить с MMIX, он хорош как условный ассемблер и был придуман что показать работу над алгоритмами. Я даже хотел курс начать по нему делать.
А следущий курс, как осцилляцию, по TLA+
А следущий курс, как осцилляцию, по TLA+
AT
Я пришел к похожим выводам и одна из моих идей это начинать учить с MMIX, он хорош как условный ассемблер и был придуман что показать работу над алгоритмами. Я даже хотел курс начать по нему делать.
А следущий курс, как осцилляцию, по TLA+
А следущий курс, как осцилляцию, по TLA+
При всём уважении к опыту предыдущих ораторов и при всей моей любви к ФП, да и к железу тоже, остаюсь при своём мнении.
Моё мнение таково: основой всего и любого программирования является так называемое "алгоритмическое мышление", иначе известное как "моделирование" и "абстрагирование". Именно ему и следует обучать, поскольку именно с этим пунктом возникают самые серьёзные проблемы, при этом не только у начинающих программистов, но и у многих продолжающих.
А для того чтобы промоделировать вычислительные процессы, и, соответственно, построить алгоритмы решения каких-то "прикладных" задач, необходима модель вычислений. И именно ей необходимо обучать начинающих. Не так уж важно, что именно это за модель. Я лично считаю, что лямбда-исчисление наиболее доступно именно для непосвящённых в программирование благодаря ссылочной прозрачности и семантике переписывания, которую реально можно проводить руками на бумажке. Но машина Тьюринга тоже подойдёт, как и её вариации в виде разных упрощённых учебных процессоров. А вот реальные процессоры "замусорены" слишком большим количеством усложнений связанных с соображениями производительности и историческими причинами.
Опять же, при наличии чётко определённой вычислительной модели можно предметно говорить о корректности алгоритмов и программ. А при желании и возможности — преподавать средства доказательства корректности.
Моё мнение таково: основой всего и любого программирования является так называемое "алгоритмическое мышление", иначе известное как "моделирование" и "абстрагирование". Именно ему и следует обучать, поскольку именно с этим пунктом возникают самые серьёзные проблемы, при этом не только у начинающих программистов, но и у многих продолжающих.
А для того чтобы промоделировать вычислительные процессы, и, соответственно, построить алгоритмы решения каких-то "прикладных" задач, необходима модель вычислений. И именно ей необходимо обучать начинающих. Не так уж важно, что именно это за модель. Я лично считаю, что лямбда-исчисление наиболее доступно именно для непосвящённых в программирование благодаря ссылочной прозрачности и семантике переписывания, которую реально можно проводить руками на бумажке. Но машина Тьюринга тоже подойдёт, как и её вариации в виде разных упрощённых учебных процессоров. А вот реальные процессоры "замусорены" слишком большим количеством усложнений связанных с соображениями производительности и историческими причинами.
Опять же, при наличии чётко определённой вычислительной модели можно предметно говорить о корректности алгоритмов и программ. А при желании и возможности — преподавать средства доказательства корректности.
YR
Именно поэтому MMIX (не замусорен "реальной жизнью") и TLA+ (как увидеть алгоритмы в проекции состояний)
YR
А оттуда дальше выплывает TLC (model checking) и иногда даже TLAPS (proofs) для особо заинтересованых
YR
В сумме, что-то типа такой важной комбинации даёт общее понимание как вообще что-то работает на более низком уровне (ниже можно, но менее практично) и как вообще писать алгоритмы которые приводят к нужным результатам
YR
Но это все просто личное мнение :)
EM
пощадите людей, им ещё потом работу искать
AT
Evgenii Moiseenko
пощадите людей, им ещё потом работу искать
Если всё хорошо у них сложится, то им и через 20 лет понадобится работу искать. Кому сечас нужны технологии 20 летней давности? Как с таким багажом искать работу?
Вот даже COBOL, оказывается, нужен, а COM+ — нет. 🤷♀️
Вот даже COBOL, оказывается, нужен, а COM+ — нет. 🤷♀️
PS
Именно поэтому MMIX (не замусорен "реальной жизнью") и TLA+ (как увидеть алгоритмы в проекции состояний)
Так ведь MMIX как раз сильно и "замусорен реальной жизнью". Он интересен в историческом смысле — как обобщенный взгляд на настольные архитектуры 90-х.
YR
В этом смысле, да, конечно
YR
Но по крайней мере он идёт с хорошим учебником :)
YR
Как по мне, он даёт неплохой взгляд на то, во что приблизительно вообще код компилируется, концептуально. Что такое циклы даже...