В 14-м году на курсере был классный курс, который я упустил. А сейчас понял что очень хочется его пройти. После гуглежа оказалось, что курс доступен бесплатно без смс прямо на сайте стенфорда.
Вот, выкладываю ссылку (может будет полезно кому-нибудь) https://lagunita.stanford.edu/courses/Engineering/Compilers/Fall2014/
Если есть ещё слоупоки кроме меня, то давайте вместе проходить!
Сегодня знаменательная дата, старейшему после фортрана языку программирования исполнилось 50 лет. Несмотря на столь почтенный для языка программирования возраст, он до сих пор активно развивается, используется в новых проектах и десятилетиями использует концепции, которые в новых языках стали появляться только недавно. Кое-кто считает даже, что когда все остальные языки канут в небытие, LISP останется, потому что это единственный язык, про который можно сказать, что он не придуман, а математически вычислен Джоном Маккарти.
>>> Подробности
Racket — язык, вдохновленный Scheme, а также экосистема для программирования других языков — начал переход на двойное лицензирование Apache 2.0 или MIT в 2017 году и теперь, к версии 7.5, практически все его компоненты завершают этот процесс.
Авторы отмечают две основные причины этого:
Всего несколько небольших компонентов осталось под LGPL из-за того, что их авторы неизвестны либо не ответили на запрос о перелицензировании. Двое разработчиков ответили отказом на подобный запрос, их код и документация уже были удалены или переписаны.
>>> Подробности
Граждане и гражданки ЛОР не дайте свихнуться, а дайте код на Lisp или Scheme
у меня два списка (а1 а2 а3 ... an) (Р0 Р1 Р2 ... Pn)
в первом проходе получаю списки (а1) (Р0) и решение такого ур-ия
M1 = P0 * a1
в втором проходе получаю списки (a1 a2) (P0 P1) и решение такого ур-ия
M2 = P0 * a2 + (P1 * (a2 - a1))
в третьем проходе плучаю списки (a1 a2 a3) (P0 P1 P2) и решение такого ур-ия
M3 = P0 * a3 + (P1 * (a3 - a1) + P2 *(a3 - a2))
ну и т.д.
Общее уравнение
i
Mn = P0 * an + ΣPi * (an - ai)
i=1
мозги колом встали
Комрады. Очень давно тыкал в Cl/SBCL, не так давно написал пару сервисов для этого вашего web’a на Racket.
Вопрос - Common Lisp VS Racket, что более живо для написания web’a, что имеет больше батареек, какая IDE лучше (кроме Emacs), etc.
Здравствуйте ) Я здесь человек новый, но успел почитать некоторые темы и получить представление о стиле общения на этом форуме ) И тем не менее, рискнул зарегистрироваться и создать эту тему, в которой хочется (помимо обычного развития подобных тем здесь )) по-возможности конструктивно обсудить такой вопрос - я потихоньку пишу интерпретатор Лиспа, на Хаскеле. Особых претензий на мировое господство конечно нет, скорость/оптимизации/сборка мусора и т.п. не заботят, практического применения не предусматривается, исключительно учебные/исследовательские задачи. Но хотелось бы реализовать максимально широкий и интересный функционал. Знаю про «схему за 48 часов», какие-то идеи взял оттуда, какие-то не понял, какие-то не понравились как там сделаны и сделал по своему. Что есть сейчас - иерархическое мутабельное дерево окружений (как SICP завещал), функции как полноценные объекты первого класса, простые макросы - раскрываются в рантайме и тоже объекты первого класса, с их помощью реализованы отложенные вычисления и на нем уже ленивые бесконечные списки-потоки. Хотел бы обсудить вопрос - что можно сделать еще, что исправить. Примеры решения простейших задачек - код скрипта и результат могу предоставить, если кому будет интересно. Также постараюсь ответить на вопросы по реализации/возможностям.
RTGC — параллельный сборщик мусора работающий с предсказуемой максимальной паузой в 450 наносекунд за один цикл сборки кучи любого размера.
В качестве теста был пересобран WCL (одна из реализации Common Lisp) за 16 секунд с использованием RTGC.
http://realtimegarbagecollector.com
http://github.com/wadehennessey/rtgc
http://realtimegarbagecollector.com/rtgc-slides.pdf
Лицензия Apache License 2.0
Доброго времени суток. Я для начала начну с вот такой ссылки на прошлое обсуждение, воззвах к 
dave.
Абстракция или костыль?
Абстракция. Есть много интересных применений и не только в хаскеле. В F# они называются computation expressions или workflows. На базе монады continuation строится механизм асинхронных вычислений (the async workflow). Ничего подобного в других языках (общего назначения) даже близко не видел. С такой легкостью задаются сложнейшие параллельные и асинхронные вычисления!
Вот можно поподробнее об этом, не применяя слова «монада» или «функтор». А простым Русским языком. То есть, допустим, я разрабатываю бухгалтескую программу, или веб-сайт, или среду разработки. И например, я так могу объяснить некоторые фичи из языков с точки зрения полезности для пользователя:
Каждое из этих объяснений я могу развернуть дальше, но я хотел показать стиль того, что я хочу услышать.
Вот мне нужно объяснение в том же стиле, а что такого хорошего умеют делать монады. Я уже знаю, что монады позволяют отделить чистое от нечистого. Но они явно должны уметь что-то ещё. Так вот, что они умеют ещё? Но по сути, а не без самого слова «монады», без ссылок на сто книжек, без дзен, и без слов, что я сначала должен изучить хаскель. Т.е., без сектоводства, а чисто по делу.
Допустим, если вы знаете 5 применений монад (кроме оформления императивности), то достаточно 5 фраз.
Common Lisp разрабатывался и используется в предположении, что пользователь программы — программист. Поэтому из языка намеренно исключены сложные для понимания конструкции (пользователь не обязательно квалифицированный программист), поэтому в языке мощнейший отладчик, позволяющий без остановки программы переопределять функции и вообще делать что угодно. Но из-за этого документация по большей части библиотек Common Lisp существует только в виде docstring и комментариев в коде (некоторые вообще считают, что код сам себе документация). Из-за этого обработка ошибок почти всегда оставляется на отладчик (главное сделать рестарт «перезапустить с последней итерации», а там пользователь сам разберётся). Из-за этого в программе проверяется только happy path (пользователь ведь «тоже программист»).
Racket разрабатывался и используется в предположении, что пользователь программы не программист, а задача разработчика написать программу так, чтобы она корректно работала при любых входных данных (если данные некорректны, то сообщала об этом в том месте, где данные были введены). Поэтому в языке эффективная библиотека для написания тестов, система контрактов на уровне модулей, макимально широкий спектр инструментов программирования (разработчик должен быть профессионалом!). Также реализована идея инкапсуляции: считается, что пользователь модуля не должен знать особенности реализации и, более того, не может в своём коде изменить функцию чужого модуля если это явно не разрешено разработчиком того модуля. Исходный код разумеется доступен, но его не требуется смотреть, чтобы использовать модуль. Достаточно документации. Поэтому реализована мощнейшая система документировния Scribble, а при реализации макроса есть возможность обеспечить указание на ошибки в коде, предоставленном макросу пользователем, не показывая потроха макроса.
И поэтому в Racket нет CLOS (есть как минимум две реализации, но не используются) - провоцирует заплаточное программирование (monkey patching), поэтому отладчик намеренно ограничен (если ты отлаживаешь программу, значит ты не знаешь как она должна работать!), поэтому нет разработки в образе (image based) - она провоцирует разработку через отладку (а значит непонимание программы и проверку только happy path).
Таким образом, Racket и Common Lisp несмотря на внешнее сходство являются очень разными языками. И я рекомендую писать на Racket, если только конечными пользователями программы не являются исключительно программисты на Common Lisp.
Взято с http://racket-lang.blog.ru/#post214726099
Хотелось бы знать, что по этому поводу думают пользователи ЛОРа. А также, мне кажется, что для Java и C++ будет где-то такая же разница.
Предлагаю учёным мужам в этом топике собрать и обсудить проблемы в языке Common Lisp. Кому что не нравится?
Мне категорически не нравится реализация методов в CLOS. Метод в нём - это специализированная общая функция (дженерик), просто функций, присущих только данному классу, нет. При создании метода автоматически создаётся дженерик, если он ещё не был создан. Дженерик виден во всём пакете, и все специализации должны соответствовать его сигнатуре. На практике это приводит к тому, что почти сразу появляется проблема несоответствия сигнатур у методов разных классов. Можно, конечно, разнести классы по разным пакетам, но это влечёт за собой больше неудобств, чем решает. Пока весь код - ваш, под вашим контролем, это особой проблемы не представляет, но представьте, что классы плодит куча разных людей?
Не нравится неполная интеграция CLOS в язык: распознавание класса в CLOS для стандартных лисповских типов ещё работает, но не для своих типов, объявленных через deftype.
Ну и вообще CLOS жирноват для 90% задач. Не говоря уж про MOP, который почти никем не используется, а если и используется, то для решения проблем с кривостями CLOS, либо просто книжку AMOP обчитался и повредился умом.
Не нравится реализация пакетов (неймспейсов). Удобно иметь вложенные пакеты, но их нет. Возможность задания никнейма для пакета в самом пакете - членовредительская, ибо каждый гомо сапиенс для своей мегабиблиотеки задаёт двух-, трёхбуквенный никнейм. Букв в общепринятой латинице и так мало (опустим перечень адских пыток, которым после смерти будут подвергнуты те, кто пишет комментарии не на английском языке или вообще использует не-ASCII алфавит для идентификаторов), так ещё количество их кобминаций ограничено любовью человеков к акронимам и красивым сокращениям.
Не нравится отсутствие стандартных средств рефлексии/интроспекции лексического окружения. Лексэнвы эти есть во всех реализациях, но стандартного способа работы с ними нету. Нужда в этой фенечке шкурная, и широкими массами не востребована, но всё же.
loop - какашка. Это не лисп. Точка.
Встроенный макроязык в format - тоже какашка. Я каждый раз после двухдневного перерыва лезу в документацию или старый код, чтобы вспомнить, как форматировать число с плавающей запятой. В общем-то, перенаворочен format. И всякой ерунды в него набито, типа автоматического окончания у числительных, но которое работает только для аглицкого языка.
unwind-protect - хорошо, но от попыток человеком сэмулировать продолжения для CL хочется икать. Такие trade-off вполне понятны, но лучше бы unwind-protect ограничили.
Ну и более мелкие ляпы в стандарте, типа (elt sequence index), но (nth index list).
Да, этот пост написан в Емаксе, запущенно под лисповым оконным менеджером человеком, получающем деньги за написание лиспокода :)
Добрый день дорогие аналитики L0R'a. Ковыряю ракет, пишу на нем клиентскую программу - а пока хочется вот что спросить. Все же что лучше - Racket или Common Lisp? Что более перспективно? Ну и естественно, какие у одного недостатки/преимущества по сравнению с другим?
cl-cont видел: 1. delimited 2. требует перекомпиляции с ним всего, из чего используешь продолжения.
Видел хак для SBCL. С ограничениями: функции должны быть без параметров и связанных переменных.
Есть ли нормально работающая версия (может в расширениях у каких-нибудь коммерческих лиспов)?
Добрый день!
Начал изучать Racket. Пока только позитивные впечатления. Скажите, какие у него есть недостатки по сравнению с tcl, F#, Common Lisp, Haskell, Python3, Rebol3, Erlang?
З.Ы.: Вопрос не ради троллинга, а чтобы сразу знать о недостатках и морально готовиться к тому, чтобы их обходить.
Интересный доклад нашёл: https://github.com/codereport/Talks/tree/master/2020-11-MeetingC%2B%2B/ConceptsTraitsTypeClassesProtocols
Видео выложили: https://youtu.be/Qh7QdG5RK9E
Возможно кому-то на лоре тоже будет интересно почитать небольшое сравнение похожих фич в разных языках.
Привет
Ребята, есть тут кто очень круто шарит в Haskell?
Можете объяснить по какому принципу работает рекурсия в Haskell, и есть ли она там вообще? Если нет, то как тагда вычисляется , к примеру, факториал? Есть ли с стек в Haskell? Пока это основное, что меня интересует. Я только хочу познакомиться с этим языком, конечно же с вашей помощью, если это не идет вразрез с филисофией форума, которая гласит, что никто здесь никому ничего не обязан объяснять.
Свершилось, братие и сестрие!
Долгожданный (кроме шуток - процесс релиза настолько затянулся что про это начали хохмить даже сами разработчики в рассылке emacs-devel) релиз системы исполнения emacs-lisp, реализующей редактор текста, файловый менеджер, почтовый клиент, систему установки пакетов и множество различных функций.
В данном выпуске:
Лично меня особенно радует последний пункт, хотя изменения и не ограничиваются перечисленным.
Ценители архи-боянов приглашаются в комментарии - делать ставки кто первый «пошутит» про отсутствие в GNU/Emacs текстового редактора: когда ещё доведётся услышать шутку, которая старше большинства посетителей ЛОРа?
>>> Подробности
Изначально есть N/x, где N не меняется, а x = 1...n. Это можно свести к 1/x, поэтому далее будет идти речь о нём. Если есть более удачные варианты о них так же можно(и нужно) написать.
Гугл говорит, что основной методикой является это. Оно приспособлено для вычисления произвольного D, где в качестве нулевой итерации используется приближённое значение 1/D. Подобные методы так же предполагают аналогичное.
Я же предполагаю, что можно как-то использовать при вычислении 1/D предыдущие значения(1/(D - 1), 1/(D - 2), …), что должно дать куда более удачный метод, либо как минимум увеличить точно итераций.
Вопрос: Можно ли пользуясь тем, что нужно вычислить результат сразу для всех возможных D, упросить вычисление одного отдельного D.
P.S. чётные D можно не вычислять. Деление лучше вообще не использовать, либо использовать по минимуму.
Уточнение задачи: 1/x, где x целое, 3,5,7...n в диапазон не включены чётные числа.
Может кто-то встречал необычные идеи, концептуальыне проекты, или просто какие-то передовые и непопулярные модификации имеющихся инструментов разработки интерфейсов?
Интерфейсы довольно длительное время были в плену у объектно-ориентированного рака, где у вас есть одна кнопка, одна мышка, и вам нужно нажать мышкой на кнопку — отсюда было шизофреническое разделение интерфейса на независимые сущности, отсюда главный цикл, который обрабатывает эту самую одну мышку (либо кнопку клавиатуры), и объекты GUI как состояния кусков экрана. В Smalltalk/VisualWorks отдельные объекты были более значимо выделены (с возможностью сохранять состояния отдельных объектов), а в современных десктопных GUI весь гуй является одним состоянием, и очередь сообщений у него тоже одна.
Одними из первых от этой модели отказались игроделы, которые смекнули, что рисовать интерфейс можно независимо от расчета логики игры и реакции на ввод. Примерно в этом состоянии и находится индустрия сейчас, как тот же андроид Lollipop, на который неспешно перекатываются девайсы.
Самую-присамую писечеку из рядов массового софтопрома разрабатывает гугл в своем хроме:
https://www.chromium.org/developers/design-documents/compositor-thread-archit...
В хроме поток логики с жавоскриптом остается за главного, однако, часть логики отрисовки блоков перенесена в отдельный поток композитора — за счет чего веб-страница выглядит относительно живо при висящем жавоскрипте. Само наложение текстур блоков с CSS-рюшечками, естественно, делаются уже на видеокарте в отдельном потоке, а композитор только отвечает за «быстрые» прокрутку и изменение размеров. Быстрые — то есть описанных через базовые поддерживаемые концепции HTML/CSS и без задействования JS.
Но даже этого недостаточно для того, чтобы приложения на электроне перестали быть тормозным и жрущим оперативу калом. Но достаточно, чтобы сравниться с приложениями на Java. Это забавно выглядит в 2020 году, когда производительность процессоров растет медленнее, чем растет тормознутость интерфейсов. Сижу я тут, играю в Deus Ex: Mankind Divided, и думаю: а может, и правда, в 2029 году «прогресс» дойдет до того, что интерфейс для ввода четырех циферок будет открываться-закрываться по пять секунд, как в этой игре? И выключатели на тач скринах, которые работают только на «вкл-выкл» — я ванговал в соседнем треде, что на будущих девайсах для прогрессивной молодежи должна быть только одна кнопка.
Объективно, если брать современный GUI iOS/Android, то это упрощение по сравнению с многозадачными интерфейсами десктопов: пониженные требования многозадачности, пониженные требования к отзывчивости, набор доступных действий неочевиден, что идет против концепции GUI «я должен найти все фичи программы просто гуляя по менюшкам» — последняя проблема уже имеет варианты решения в виде Pie/Marking Menus. Да, это частично оправдано малым экраном. Да, эти проблемы со временем можно будет частично решить (если тенденция ухудшения не перевесит тендинцию улучшения). Но в целом, с позиции разработки, программы для тачфонов по прежнему пишутся в стиле однопоточного цикла обработки сообщений, просто сообщения стали несколько другими.
Меня пока что манит идея «скриптовухой» выкидывать описание GUI в какую-то структуру в разделяемой памяти, чтобы потом по этой структуре происходила отрисовка интерфейса, причем, той же «сприптовухой», но параллельно работающей. Вплоть до того, что с разделяемой структурой интерфейса будет работать несколько программ, используя транзакции. Например, у нас есть программа основной логики интерфейса, которая обрабатывает окошечки/кнопочки/поля ввода, и есть задачи фонового скачивания файлов. Фоновое скачивание живет само по себе, обновляет свои специфичные элементы GUI, при этом большую часть времени не взаимодействует с потоком логики, а только взаимодействует с отрисовщиком/композитором/taskname через разделяемую память.
Пишу в dev, а не web-dev потому, что C++ и другие якобы «не вэб языки» здесь в тему.
Буду в одиночку пилить сайт для определённых задач (не на заказ). Бэк, фронт, деплой, сопровождение, бизнес-специфичные занятия - всё своими руками и головой.
Есть некоторый опыт и хорошие впечатления от Django.
Нужны:
Light, zero-dependency и embedded мне безразличны // но рассматривались тожеЛучше советовать не «язык Х» а «язык Х + фреймворк Y».
Также меня царь образумил в том смысле, чтобы делать SPA вместо server side rendering. Ведь перерисовывать ВСЁ по нажатию кнопки - это же антипаттерн отзывчивого интерфейса. Плюс везде, где можно заменю http на websocket - вместо целой страницы по тормозному хттп всего лишь небольшой json по шустрому вебсокету - это сильная разгрузка bottleneck’а на клиенте - обмен данными по сети.
Плюс можно реализовать свою логику на время ожидания ответа от сервера - хоть надпись «подождите», хоть прогрессбар, хоть что угодно, что вписывается в «домохозяйка видит плавный интерфейс».
UPD Решил брать NestJS + React + MobX. Если по ходу дела откажусь, то буду рассматривать Dart + Flutter, Scala + Play, Java/Kotlin + Spring/Boot.
В будущем обязательно поэксперементирую и запилю сайт крупнее хелловорлда на C++ и Rust и поделюсь с вами впечатлениями.
Хочу написать простенькое веб-приложение для личного пользования, серверная часть для меня прозрачна и понятна, а вот с фронтэндом я в современных технологиях вообще не знаком.
Из поверхностного обзора веяний моды в этой области я узнал, что то, что я ищу, описывается термином single page application. В идеале, фреймворк должен взять на себя и визуальную составляющую, но если что, CSS я напишу сам.
Хочется сказать фреймворку: «Положи на DOM 4 кнопки, 2 списка, затем еще 3 кнопки. И пусть оно выглядит не совсем отвратительно.» Для каждого из элементов DOM прописать простенькую логику и повесить на события: сходи на сервер с таким запросом, из ответа возьми данные и замени контент там-то. Часть данных о состоянии для каждого элемента желательно хранить за пределами DOM, они нужны не пользователю, а чтобы составить правильное обращение к бэкэнду. Желательно иметь заготовки для чисто клиентских операций: сортировать список, фильтровать список и т.п.
На моем уровне знаний я бы сгенерировал DOM на стороне сервера, обмазал бы элементы коллбэками и для красоты взял бы CSS от Bootstrap. Но (а) это долго и скучно, (б) в результате получится хрупко и плохо читаемо, (в) я никуда не спешу и поэтому хочу сделать хорошо.
Обзор хелловорлдов для фреймворков из списка «Топ 10 баззвордов чтобы зашибать деньги на фрилансе» показал, что кашу они там заварили знатную, и вот это коричневое в ней - вряд ли шоколад. Поэтому прошу совета, с каким из фреймворков приятнее иметь дело для краткого и довольно дилетантского знакомства?
| ← назад | следующие → |