Посоветуйте материалы по cозданию парадигм программирования, дизайну синтаксиса, влиянию языков программирования на мышление

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

Посоветуйте хорошие материалы (книги/видео/статьи), которые посвящены:
— Созданию парадигм программирования; (Completed)
— дизайну синтаксиса языка программирования; (Completed)
— влиянию языков программирования на мышление. (Completed)

PS. Мне для «немного почитать/разобраться на выходных».

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

«Структура и интерпретация компьютерных программ», авторы Абельсон,Сассман: balka-book.com/...​programm_2_e_izdanie-5508

— Созданию парадигм программирования;

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

дизайну синтаксиса языка программирования;

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

Например, найти и почитать работы Джона Маккарти (создатель Лиспа) — в них наверняка будут излагаться какие-то концепции, которые повлияли на лисп и на его синтаксис. Ну или Кернигана и Ритчи (если у них есть какие-то работы, касающиеся не основ программирования на Си, а истории его создания и всей поднаготной с этим связанной).
Будет яркий пример, как создавали тот или иной язык из первых уст. ;)

влиянию языков программирования на мышление.

а вот это уже сугубо философское, ИМХО.

А с твоей точки зрения это было правильное решение (взятие концепций из других языков и присоединение его к макроассемблеру)? Или может нужно было так и оставить?

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

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

так последний вопрос был о влиянии языков, а не о процессе их изучения. Или я что-то недопонял...

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

Книга Programming in Scala від Martin Odersky, автора мови Scala, і його курси на Coursera є такими.

Автор розказує не тільки про те, як програмувати на Scala, але і які альтернативні рішення він міг прийняти при створенні мови, їхні мінуси і, якщо є, плюси.

Это философия, честно. От чтения можно насладиться потоком мыслей, жвачкой для мозгов, но не пытайся что-то из этого вынести.

В действительности имеет место обычное столкновение маркетинга. Почитай про Qwerty VS Dvorak, поймёшь в чём собственно грабельки. И почему люди с пеной у рта будут защищать даже бочку дерьма, если они к ней привыкли. А уж если мало кому нравится её содержимое — делает защитников буквально элитарным клубом.

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

С моей точки зрения [не соглашайся, проверь] самым уййбищным способом кодирования являются регулярные выражения. Прекрасные своей краткостью в миниатюрных задачах, становятся дамокловым мечом для желающих постичь фильтры в серверных пакетах. Достаточно сказать что регулярку невозможно полностью покрыть тестами, никогда не знаешь что где вылезет.

С силой привычки и маркетингом частично согласен.

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

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

Но по мере написания количества кода, и ещё большего количества прочтённого кода — мозг понимает что всего не освоит никогда, и перестаёт пользоваться долговременной памятью без веских на то причин, позволяя компьютеру делать то с чем он справится намного лучше.

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

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

ЧСВ я во внимание не беру. Хотя факт, что именно ЧСВ сильно портит способность к обучению. Но это уже вторая производная, и меняется по мере нарушения баланса спрос/предложение на рынке труда.

Как можешь догадаться, научных книг о том чего нет — нет. А философия — оно тебе надо?

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

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

Как думаешь, если транслировать инструкции этого метода на человеческий язык, то как это будет выглядеть (в виде текста)?
Можно ли считать возникновение ассоциации у читателя, что автор комментария — говнокодер, как результат влияния программирования на мышление?

Учитывая, что ты сам захардкодил return в последнем предложении, я просто оставлю здесь рекурсию :)

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

Потому что код после return’а не выполняется.

Це у якій мові програмування? :)
У Python, Java, Scala, взагалі кажучи, це невірно. ;) Можеш переконатися, скопіювавши в REPL:

Python

def someMethod():
  try:
    print("Before return.")
    return
  finally:
    print("After return.")
someMethod()

Java

void someMethod() {
  try {
    System.out.println("Before return.");
    return;
  } finally {
    System.out.println("After return.");
  }
}
someMethod();

Scala

def someMethod(): Unit = {
  try {
    println("Before return.")
    return
  } finally {
    println("After return.")
  }
}
someMethod()

Класс, только в байткоде код из finally окажется перед return’ом.

У байткоді так, як і в машинному коді та реальному порядку виконання інструкцій (який в загальному випадку може відрізнятися від порядку розміщення інструкцій машинного коду через особливості моделі пам’яті Java).

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

Якщо на співбесіді сказати, що код після return ніколи не виконується, інтерв’юер може задуматися: не виключено, що програміст напише код, який буде виконуватися не так, як автор думав. ;-)

ни разу не слышал чтобы кто-то спрашивал такую дичь

Не делай ложных утверждений на основе фрагмента текста, заменяя изначальный контекст собственным. Этот топик не для интервьюверов или поиска роботы. Для меня твои старания напрасны, потому что мне известны такие простые вопросы. Я никогда такой порядок выполнения не создавал, потому что считаю его плохой практикой. (:

И даже в том извращенном контексте, который ты навязываешь, если дописать в try после return’а вывод в консоль, то получишь совсем другой результат, который вполне удовлетворит твоего интервьвера (после утверждения того, что код после return’а не выполняется).

А если тебя смущает название «байт-код» — что это не совсем язык программирования, то в .net существует Сommon Intermediate Language — и подобная конструкция в нем будет иметь подобное поведение что и в Java байт-коде.

Вообще есть языки где нет реализации try/catch/finally (реализация С/С++ для микроконтроллеров) и твой полурабочий фокус там не прокатит. Ну и по такому же принципу можно создать новый язык в котором будет только то, что задумал автор.

* Concepts in Programming Languages by John C. Mitchel
tomassetti.me/...​te-programming-languages

Підписатись на коментарі