Здравствуйте, LaptevVV, Вы писали:
LVV>Это говорит о двух вещах: LVV>- о несоответствия архитектуры фон Неймана лямбда-исчислению (функциональное программирование)
Скорее, гарвардская архитектура не соответствует, но её можно рассматривать как фон-неймановскую на этапе, когда писать в часть "ленты" уже не требуется.
А так-то абстракция стек-машинки вполне ложится на лямбда-исчисление.
(разве что размеры стека ограничены, ну да раскрутка хвостовой рекурсии в помощь)
И эта абстракция реализована в опкодах большинства исторически бывших или ныне популярных архитектур.
LVV>- о том, что руководство МИТ следует моде
Вернее, исходит из того, что есть.
Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Мне тут говорят — а ты на haskell, на Хаскель смотри. ЭФ>Не будешь его использовать, не будет никакого автоматического распараллеливания ЭФ>и не возьмут тебя огромные суперкомпьютеры программировать.
Вот кстати сценарий, наверное не слишком реалистичный, но чем чёрт не шутит.
Хаскель ведь известен тем, что если программа скомпилировалась, значит в ней багов нет. Это, конечно, шутка, но с долей правды.
Сейчас есть некоторый тренд на генерацию программ с помощью LLM. И если сравнить, скажем, питон и хаскель, то сгенерированную программу на питоне надо как минимум запустить, и даже это не гарантирует, что в ней всё правильно, возможно в первом запуске не все пути выполнения отработали. Т.е. программу нужно сгенерировать и далее тщательно протестировать все варианты входных данных.
На хаскеле же ИИ имеет все шансы убрать множество багов до первого запуска.
Поэтому я может ставить на этот вариант развития событий и не буду, может быть для ИИ проще написать сто тестов, чем одну программу. Но в целом не слишком удивлюсь, если завтра GPT 5 выпустят с модулем программирования на хаскеле, который будет на голову выше всех остальных альтернатив.
Здравствуйте, LaptevVV, Вы писали:
ЭФ>>Если бы математики были бы правы, то лисп бы всех зарулил. Но нет, его в курсах MIT заменили на Python. ЭФ>>Это о многом говорит. Или должно говорить. LVV>Это говорит о двух вещах: LVV>- о несоответствия архитектуры фон Неймана лямбда-исчислению (функциональное программирование) LVV>- о том, что руководство МИТ следует моде
Архитектура фон Неймана говорит о том, что программа должна храниться в той же памяти, что и данные.
Во времена фон Неймана это было смело потому, что этой памяти было очень мало и она была люто, бешено дорогая. Это было непростое решение, использовать эту память для хранения программ.
Зато это открыло дорогу к программам для работы с программами — компиляторам, линкерам, загрузчикам и т.д. Что для одной программы данные, для другой программы — ее собственный код.
Ламбда-исчислению это не противоречит от слова совсем.
В LISP-е основная структура данных — это односвязанный список. Каждый узел списка состоит из двух указателей: на следующий элемент списка и на данные, которые хранятся в данном узле. Эти указетели традиционно называются CAR и CDR — по именам регистров той машины, на которой LISP был первоначально реализован. Именно эти регистры использовались при исполнении программ на LISP-е, программа, как несложно догадаться, тоже была списком.
В обшем, лямбда-исчисление не чуждо понятному железу
Здравствуйте, vdimas, Вы писали:
V>Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем.
Python хорош, на мой взгляд. Двигать черепашку командами легко и весело.
Посмотрел бы я, сколько труда пришлось бы вложить в такое в реализации на С/С++
(это я про обучение детей программированию,если что, а не студентов MIT)
Здравствуйте, vsb, Вы писали:
vsb>Хаскель ведь известен тем, что если программа скомпилировалась, значит в ней багов нет. Это, конечно, шутка, но с долей правды.
Может в какой-то части и так, но что есть баг? Результат ошибочно реализованного алгоритма — баг?
Здравствуйте, wl., Вы писали:
wl.>Python хорош, на мой взгляд.
Для изучающих профессию он тупиковый.
ИМХО, его надо давать в разделе языков сценариев, посвятить пару занятий от силы, как и башу, CMD, REXX.
wl.>Двигать черепашку командами легко и весело.
))
wl.>Посмотрел бы я, сколько труда пришлось бы вложить в такое в реализации на С/С++
Это надо брать любую интерпретирующую среду.
На Форте это было бы примерно пол-дня работы.
На JS — чел говорит, что накатал за пару дней: https://bztsrc.github.io/jslogo/
wl.>(это я про обучение детей программированию,если что, а не студентов MIT)
Да понятно.
Студенты должны через несколько занятий написать саму библиотеку черепашки для того же Питона.
А на 3-м курсе полноценный парсер-интерпретатор LOGO безо-всякого Питона. ))
Как раз на небольшой курсовичок труда.
Кстате, вспомнил про язык R.
Его можно считать Питоном с человеческим лицом. ))
Есть список/словарь/объект как в JS и Питоне, но есть и более эффективные типы данных: вектора, матрицы, многомерные массивы и таблицы (в таблице каждый столбец может быть разного типа, но в столбце все значения одного типа).
ЭФ> зачем изучать λ-синтаксис, если ЭФ> в реальности используется другой синтаксис — синтаксис языка программирования? ЭФ> TODO:>>> Привести пример из стандарта на Java
2014-04-12, начались боевые действия на территории Донецкой и Луганской областей.
TODO:>>> «straw-man examples»
Знание синтаксиса никак не добавляет мне знания причин, которые привела к формированию такого подхода/стиля/метода программирования.
«I’d been thinking about a simplified closures proposal for several months, but without a specific syntax.»
Я по-прежнему не знаю, для чего нужны лямбда-выражения.
«programming in a multicore environment» пишут они.
А какая связь между синтаксисом и железом? Где они там синхронизационные примитивы впихивают?
«support for writing scalable parallel programs using bulk-data APIs such as parallel arrays» пишут они.
Казалось бы, какая связь между синтаксисом анонимных методов и обработкой массивов? Там же даже синхронизация не нужна.
Может дело в автоматизации распараллеливания?
«The existing proposals are ... either too simple or too complex.
CICE only goes part-way toward making the parallel-array API easy to use,
while BGGA and FCM contain more features than are needed to address that key use case.»
Тогда об этом надо рассказывать.
2014-10-13, Maurice Naftalin, Mastering Lyambdas. Java Programming in a Multicore World (1-st Edition)
ISBN-10: 9780071829625, ISBN-13: 978-0071829625
Конечно мотивация "каждый орёл в твоей команде будет это использовать, а ты не впишешься" имеет смысл для собеседования,
но правильно ли поступают орлы? Может они все ошибаются?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы.
Функциональное программирование часто используется именно с такой целью
Лямбда-счисление это теория на основе которой вы можете построить внятные синтаксический анализатор. Например, вычислять что угодно — тип результата, сам разультат, время, побочные эффекты, структуру самих вычислений итд.
Т.е. не просто вычислить, а еще и доказать что это будет именно так.
На основе машины Тьюринга вычислить такое не получится, она непрозрачна для таких вычислений. Все что вам может выдать машина Тьюринга это сам результат.
Вы сможете выдать кое что сверх этого, но никакими доказательствами это подкреплено не будет.
ЭФ>лямбда-выражения ЭФ>это компактный синтаксис, заимствованный из λ-исчисления, ЭФ>это анонимный (без имени) класс или метод, для передачи кода в качестве параметра в другой код. ЭФ>т.е. его "компактность" в том, что можно обойтись без имени функции.
ЭФ>но зачем изучать λ-синтаксис, если ЭФ>в реальности используется другой синтаксис — синтаксис языка программирования? ЭФ>Сдаёшь на собеседование знание λ-исчисления, а потом никогда, никогда это не используешь в работе.
IMHO, лямбды в C#/Java это синтаксический сахар. Конечно можно передавать функцию как параметр в виде объекта, реализующего некий интерфейс и обходится без всяких лямбд.
Как оно изначально в Java и было (плюс возможность создавать анонимные классы). В C# делегаты — тоже на мой взгляд лишняя сущность.
На практике основную пользу от лямбд я вижу в захвате контекста. Т.е. видимость локальных переменных метода и членов класса.
В случае класса-обёртки контекст пришлось бы передавать "вручную".
Отмечу, что в Java захват контекста работает по-другому чем в C#.
Вот пример темы, где обсуждается задача, где применяются лямбды, и сравниваются возможности Java и C#: https://rsdn.org/forum/java/8360114?tree=tree
ЭФ>Мне "для понимания темы" нехватает каких-то общих соображений.
ЭФ>Если я не пишу пользовательский интерфейс, то зачем мне "асинхронное программирование"?
Странный вопрос. Любые CPU/IO-bound операции в идеале должны иметь возможность прерывания.
IO-bound операции не должны требовать создания тяжеловесных потоков.
Впрочем в Java некоторое время назад реализовали virtual threads.
Подробнее обсужали тут: https://rsdn.org/forum/philosophy/8521125?tree=tree
Т.е. это абсолютно не обязательно UI, а например веб-сервер.
ЭФ>Если я знаю, что такое "замыкания", как мне это поможет? Мне чихать на yield, я им всё равно не пользуюсь.
А не важно, что ты этим не пользуешься. Тебе может достаться на поддержку код, где всё это есть в избытке.
ЭФ>Без этих "общих соображений" у меня нет мотивации к изучению.
Мне не может достаться на поддержку код. Потому что это означает, что уволили человека, который его разрабатывал. А зачем мне такой руководитель, который успешных разработчиков увольняет? Если же разработчик не был успешным, значит и код плохой, и его надо переписать =)
Здравствуйте, Эйнсток Файр, Вы писали:
M>> Тебе может достаться на поддержку код
ЭФ>Мне не может достаться на поддержку код. Потому что это означает, что уволили человека, который его разрабатывал. А зачем мне такой руководитель, который успешных разработчиков увольняет? Если же разработчик не был успешным, значит и код плохой, и его надо переписать =)
Так у нас же не Япония, где работают от поступления до самой смерти в одном месте. Кстати говоря, программистам рекомендуется менять место работы раз в 3-5 лет, чтобы не заржаветь и не стать разработчиком одного продукта.
Так что программист может и сам уйти
LVV>>- о несоответствия архитектуры фон Неймана лямбда-исчислению (функциональное программирование) V>Скорее, гарвардская архитектура не соответствует, но её можно рассматривать как фон-неймановскую на этапе, когда писать в часть "ленты" уже не требуется. V>А так-то абстракция стек-машинки вполне ложится на лямбда-исчисление. V>(разве что размеры стека ограничены, ну да раскрутка хвостовой рекурсии в помощь)
Да, конечно.
Просто давно это было, и я подзабыл, что в серии МО ЭВМ выходила книжка по функциональному программированию
Там и описывалась стек-машина, на которой все работало.
НО это было еще в СССР и я тогда не сильно интересновался ФП. LVV>>- о том, что руководство МИТ следует моде V>Вернее, исходит из того, что есть. V>Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем.
На мой взгляд есть, как минимум 2 языка для обучения
1. Оберон
2. Go
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Privalov, Вы писали:
P>Я суперкомпьютеров не видел. Зато начинал на ЕС ЭВМ сменным инженером. Шумные — да. Особенно когда АЦПУ работают. Громоздкие — возможно. В шкафу памяти на ЕС-1033 можно было поспать. Память, правда, была не ферритовых сердечниках. ЕС-1036 была намного компактнее. P>Но пыльные... Категорически не согласен. В машзал мы всегда заходили в халатах. У меня был синий. И я упоминал как-то: однажды я пинками выгнал из зала взвод курсантов, которых на наш ВЦ на экскурсию привели, и они пытались зайти в зал в шинелях. А диски в отдельной зоне вообще стояли. P>Неужели суперкомпьютеры пыли не боятся?
Я в СССР поработал немного оператором ЭВМ на СМ-4. В машзал мы заходили покурить. Потому что кроме нас туда никто не заходил.
Здравствуйте, LaptevVV, Вы писали:
V>>Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем. LVV>На мой взгляд есть, как минимум 2 языка для обучения LVV>1. Оберон
Без обид, но Алгол/Паскаль выглядели сильно устаревшими уже когда я учился на первом курсе ВУЗ-а в 89-м.
Единственное преимущество Паскаля было в наличии среды Турбо-Паскаля, где компиляция-запуск были мгновенны в сравнении с другими более-менее приличными языками.
Сегодня этот фактор нивелирован.
Я рассмотрел модернизированный Фортран стандартов 2008 и 2018 — официально эти стандарты так и не вышли.
В общем, язык избавили от атавизмов/неудобств, на которые пеняли последние лет 40, теперь это вполне себе несложный и достаточно удобный + безопасный язык для начала обучения программированию, а так же для реализации произвольных расчётов/матана.
Будь моя воля, я бы голосовал за шлифовку и выпуск современных стандартов этого легендарного языка с последующим возвращением его в "обойму" мейнстрима.
LVV>2. Go
Этот сильно нишевый.
Для обучения хотелось бы нейтральный, у которого будет поменьше возникающих у адекватного новичка "WTF???" ))
Здравствуйте, Pzz, Вы писали:
Pzz>Я в СССР поработал немного оператором ЭВМ на СМ-4. В машзал мы заходили покурить. Потому что кроме нас туда никто не заходил.
Противоожарная система сработать могла. У нас один раз такое случилось. Два этажа затопило углекислым газом, еле успели убежать.
С курением у нас было строго. В здании ВЦ не курил никто.