LINUX.ORG.RU

Яр 0.4.0 разочаровывающий

 ,


2

4

Выложил очередной релиз Яра, «разочаровывающий». Дело идёт к заморозке проекта, работаю над ним до 1 февраля, а потом хлеб насущный буду зарабатывать. Найти спонсора за два года не удалось. Видимо, дело в недостаточной вере в успех, т.е. в отсутствии ощущения зрелости проекта, при которой можно называть сроки и нести за них ответственность.

Из последних конвульсий: теперь clcon поддерживает также CCL, а не только SBCL. Ну и Яр, соответственно, собирается и запускается под CCL под Linux и Windows. Зато я что-то сломал и образ SBCL под линуксом не сохраняется. С точностью до системы знаю. Впрочем, не суть важно.

Правы были те, кто говорил, что не нужно пытаться менять CL. Он хорошо защищён от изменений частоколом из грабель: если делаешь не совсем общепринятые вещи даже в рамках стандарта, например, свою readtable, проблем огребёшь по полной, и я их огрёб, и на них был истрачен ценный трудовой ресурс. А без всяких улучшений он слишком скучен для меня.

Если вдруг кому интересно, за последние месяцы немного поразбирался в SBCL, и пришёл к тому выводу, что можно наляпать много нового и интересного, но поскольку там всё внутри черт-те в каком состоянии, причём хронически, то по сути дела работать ничего не будет. Красивую показуху сделать можно. Я сделал черновик иммутабельных хеш-таблиц и струтур с рассуждениями о типах в них, а также сильно улучшил пошаговую отладку. После этого я пообщался с одним из разработчиков и, оказывается, они тоже мечтают про отладчик а-ля Visual Basic, но сделать его быстро не могут, т.к. примитивы, на которых он должен быть построен, низкокачественные. Сейчас, судя по коммитам, они их начали исправлять. Дай Бог, чтобы у них получилось. Однако я не вижу причины, по которой не может существовать инструментирующий отладчик для CL. Более того, он уже существует и называется lispdebug-0.92 - жаль, что лицензия подкачала.

Также отчасти разобрался в работе вывода типов. Там есть два механизма - собственно type inference и constraint propagation. Если о первом я имею кое-какое представление, то второй - вообще тёмный лес. Потому и захотел отладчик, чтобы лазить туда не с голыми руками, а вооружившись удобным инструментом. Но - не склалось у меня с SBCL.

В итоге теперь у Яра нет отладчика и не на что опереться в плане вывода типов. Может быть, попробую сделать «Яр на базе Typescript», хотя при отсутствии материальных ресурсов думается на эту тему тяжело - ясно, что создать серьёзный ЯП с инфраструктурой - это достаточно трудоёмко. Более трудоёмко, чем казалось сначала по факту написание за две недели транслятора с 1С 7.7 в CL.

Тем не менее, задел есть, можно продолжать потихоньку в хоббийном режиме. Правда, нафиг оно нужно, не совсем ясно, когда рядом ходят монстры типа JetBrains со своими Kotlin-ами.

Просто по темпам развития понятно, что они меня съедят в любом случае. Ну и честно говоря, я ожидал, что меня будут смешивать с говном на форумах за идею русскоязычного языка программирования. Но то, что к этой идее окажутся холодны Росатом, ФПИ, Касперский, 1С и фонд «Русский Мир» - к этому я был морально несколько не готов. Такое чувство, что никто не догоняет, что за вытеснением из обихода «неэффективного» русского языка может произойти и вытеснение с территории и самого населения, говорящего на «неэффективном» языке. Вроде как и Казахстан уже на латиницу переходит, и на Украине черт-те что. Нет, Россия спит. Впрочем, в одном месте мне указали на соседний вход и сказали, что нужно обязательно писать заявку на грант, но почему-то моральных сил пока нет. Может быть, через некоторое время появятся.

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

★★★★★

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

Rust совершенно точно начинался не для защиты Родины. И не для горячей замены кода (хотя она была, ЕМНИП). А разработка Rust заняла несколько лет у группы очень квалифицированных людей и велась in the open.

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

PicoLisp, Factor, ...

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

Кстати, посмотрел на репозиторий Factor - 80 контрибьюторов.

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

гм. спасибо за ответ.

Выходит, горячей замены нет? Т.е. если выгружать, то надо выгружать assembly. А затем загружать ассембли. А обычно это весь код, собственно.

Видно какой то фанат говорит что есть, имея ввиду замену ассембли?

Но в таком случае они просто не считают это ценной фичей.

Как у вас в дотнете со временем компиляции?

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

Но jrebel решает - заменяется лишь небольшая часть кода и всё это работает быстро. Это единственная фича горячей замены которой я пользовался (в языках общего назначения, по-моему).

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

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

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

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

Ребром встаёт вопрос на сколько это (горячая замена) нужна, чтобы заморочиться.

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

Если речь про декстоп-приложения, в которых основным тормозом является пользователь, то накладные расходы, связанные с горячей заменой кода, может быть и не важны. А вот если брать те же SQL-сервера, то здесь совсем другие расклады. И ни Erlang, ни Lisp-ы в этой нише себя как-то не показали. И не покажут, что характерно.

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

Что ты имеешь против защиты Родины?) Вот сейчас ТС найдет единомышленников и запилят пацаны убийцу раста.

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

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

Глобально да: человек скрывает «гениальные идеи потому что их украдёт майкрософт»... и поэтому у него нет ин одного конрибьютора кроме него, потом «ай-ай - дяди денег не дали, Родине не надо».

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

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

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

Вы бы еще задались вопросом того, как это сказывается на скорости выполнения кода.

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

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

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

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

tailgunner ★★★★★
()

Такое чувство, что никто не догоняет, что за вытеснением из обихода «неэффективного» русского языка может произойти и вытеснение с территории и самого населения, говорящего на «неэффективном» языке.

Я всё-таки думаю, что

русский язык != ЯП с русскоязычным синтаксисом

Я не слышал про распространённые ЯП с французскими или немецкими ключевыми словами (конечно, «не слышал» не означает, что их нет). Но на традиционно высокий патриотизм самих французов по отношению к своему языку это вроде бы не влияет.

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

Выходит, горячей замены нет? Т.е. если выгружать, то надо выгружать assembly. А затем загружать ассембли. А обычно это весь код, собственно.

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

Касательно ассемблей, как я уже сказал, их можно делать прямо в рантайме, хоть по одной на класс, с использованием System.Reflection.Emit, например, и это довольно быстро. Такие т.н. Dynamic Assemblies широко используются в ASP.NET всяких в т.ч. для сериализации, для динамических проксей итд. Оверхед минимальный. Полноценная компиляция и подгрузка Dll дороже, ессно, но тоже так... Скажем любой Python скрипт загружается дольше чем известные мне примеры C#-скриптов и подобного. Надо сказать, кстати, что в отличие от жабки, в .NET нет центрального класслоадера, у каждого ассембли свой, это тоже дает плюс к производительности.

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

Назвал уже как минимум три широкоиспользуемые фичи. Компилирующие темплейт-движки, компилируемые динамические прокси сервисов, компилируемые динамические сериализаторы. Ну и да, вот то что умеет jrebel, умеет и Visual Studio.

Но в хаскеле например, это нивилируется реплом.

Нет, не нивелируется, совершенно разного порядка вещи. Тем более, в хаскеле репл куцый. В случае когда весь «проект» - REPL, разработка совершенно по-другому идет, по сравнению с тем как если просто иногда тыкать какие-то мелочи в командной строке.

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

Что ты имеешь против защиты Родины?)

Это странная мотивация для разработки ЯП.

Вот сейчас ТС найдет единомышленников и запилят пацаны убийцу раста.

Если найдет, проект перейдет из категории «разрабатываемых в одно лицо» в категорию «разрабатывается командой». Но, судя по тому, что появляется на ЛОР, команду автор не соберет.

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

Erlang медленный потому, что интерпретатор байткода.

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

Вроде как это сам Джо Армстронг описывал в истории создания Erlang-а.

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

Тем более, в хаскеле репл куцый. В случае когда весь «проект» - REPL, разработка совершенно по-другому идет, по сравнению с тем как если просто иногда тыкать какие-то мелочи в командной строке.

В IDE Leksah и получается весь проект REPL. Там в отдельном окне работает ghci в который он скармливает все открытые модули (и синхронизирует с текущим окном). Можно написав очередную функцию тут же потестировать, то ли получилось.

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

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

Это да. Но, тем не менее, динамическая Julia, говорят, быстрая. И она компилируется в машкод.

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

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

Так сам пишешь «посмотрел на репозиторий Factor - 80 контрибьюторов». Разве не широко?

Кстати, посмотрел на репозиторий Factor - 80 контрибьюторов.

Это сейчас. А изначально был «язык Славы Пестова». У PicoLisp сейчас тоже контрибуторов хватает.

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

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

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

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

а, я не понял этого, спасибо. ну тогда минимум возможна.

Ну и да, вот то что умеет jrebel, умеет и Visual Studio.

И даже реализована.

Получается нет у Яра этого преимущества. Чего там майкрософт украсть может..

Назвал уже как минимум три широкоиспользуемые фичи. Компилирующие темплейт-движки, компилируемые динамические прокси сервисов, компилируемые динамические сериализаторы.

Нет, не нивелируется, совершенно разного порядка вещи. Тем более, в хаскеле репл куцый. В случае когда весь «проект» - REPL, разработка совершенно по-другому идет, по сравнению с тем как если просто иногда тыкать какие-то мелочи в командной строке.

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

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

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

Производительность Erlang VM такая не потому, что горячая замена кода там, а потому что байткод, счетчик редукций, а это потому, что гринтреды специфического вида, которые можно миллионами плодить. И то, вон на каждом митапе Макс Лапшин рассказывает про свой Flussonic (напомню, видеостриминг сервер на чистом эрланге), и про то, как был рад выкинуть из него последнюю строчку на сишечке. Так что смешно слышать про «приходится писать на си ажно так тормозит» от того, кто видимо, ни строчки кода в жизни на Э. не написал.

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

Бред какой. Собственно, лиспы, во-первых, показывали(да и продолжают показывают, взять тот же datomic, пусть и не SQL), во-вторых, все SQL RDBMS уже настолько древние и поросшие легаси, что с сишечки их никто переписывать не будет просто потому что лень, и ни у кого столько сил нет. А на сишечке их когда-то, в мохнатых годах, писали потому, что просто тогда все писали на сишечке, все подряд, и даже небо, и даже аллаха(да и системные ресурсы были не в пример сегодняшним, в первую очередь ресурсы памяти).

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

SQL RDBMS уже настолько древние и поросшие легаси, что с сишечки

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

так что минимум исторически неточно, вообще то весьма неоднозначно. однозначно - то что лисп себя в этой сфере показал чуть более чем никак.

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

Для души из похожих занятий - музыка, а программирование - это музыка 4-го сорта.

В квотезы!

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

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

Так сам пишешь «посмотрел на репозиторий Factor - 80 контрибьюторов». Разве не широко?

Тонко. Для протокола: Rust, который пока не используется широко, имеет 1990 контрибьюторов только основного репозитория, и 20k подписчиков на reddit. Factor, соответственно, 80 и 182.

А изначально был «язык Славы Пестова».

А сейчас это «язык, который когда-то делал Слава Пестов». Для тех, кто знает Славу - наверное, это что-то значит.

У PicoLisp сейчас тоже контрибуторов хватает

Не хватает людей, которым он интересен на практике.

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

Получается нет у Яра этого преимущества. Чего там майкрософт украсть может..

ТС из-за своего своеобразного стиля мышления не понимает простой вещи: как только он реализует свой ноу-хау и выложит продукт с этим ноу-хау, Майкрософт легко может просто скопировать, при этом еще и творчески переосмыслив. ТС еще не успеет толком свой «продукт» прорекламировать, а уже самые ценные идеи оттуда (давайте поверим ТС-у и предположим, что оные вообще в природе существуют) уже будут скопированы всеми, кому это будет интересно.

Так что надувать щеки и многозначительно намекать на что-то, что есть уникальное в Яре, бесполезно. Но ТС слишком упорот, чтобы это осознать.

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

давайте поверим ТС-у и предположим, что оные вообще в природе существуют

провокационно ))

А так да, согласен по всем пунктам, кажется.

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

не? был адепт оракла который меня в этом убеждал. я не проверял.

АПД. погуглил, спасибо.

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

И то, вон на каждом митапе Макс Лапшин рассказывает про свой Flussonic (напомню, видеостриминг сервер на чистом эрланге), и про то, как был рад выкинуть из него последнюю строчку на сишечке. Так что смешно слышать про «приходится писать на си ажно так тормозит» от того, кто видимо, ни строчки кода в жизни на Э. не написал.

Ну вы бы почитали ЖЖ того же Лапшина, о том, как он жаловался на неожиданные подарки производительности от Erlang-а.

А так же о том, кто там у него IO обрабатывает: Erlang или нижележащий слой на чистом C.

И почему тот же Лапшин софт для камер и для дохлых устройств пишет не на Erlang-е, а на C и на Rust-е.

Бред какой

Сказал lovsan-чег и написал бредятину.

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

Я с ним бухал вроде даже, не то что ЖЖ читал, так что уж знаю от него лично что да как.

А так же о том, кто там у него IO обрабатывает: Erlang или нижележащий слой на чистом C.

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

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

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

Это да. Но, тем не менее, динамическая Julia, говорят, быстрая. И она компилируется в машкод.

И там есть горячая замена кода?

Нет, насколько я знаю. Это просто пример, что динамически типизированный язык не обязательно компилировать в байткод. В общем, SBCL тоже такой пример, и заодно он показывает, что для горячей замены кода интерпретатор байт-кода не нужен.

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

Я с ним бухал

Щас-то хоть в трезвом уме?

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

Мозги пропили? Когда вы в Erlang-е IO-операцию инициируете, она что на чисто-Erlang-овском коде выполняется или это чистый C, как в самой Erlang VM, так и в нижележащем Linux-е?

Erlang там, как и в хваленых роутерах от Ericsson-а играет роль клея для функциональности, реализованной на низкоуровневых языках.

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

Erlang там, как и в хваленых роутерах от Ericsson-а играет роль клея для функциональности, реализованной на низкоуровневых языках.

«Erlang - это telecommunication platform со своим DSL» (ц)

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

Давай еще раз: в Erlang-е динамическая типизация, ФП и байт-код, в том числе, и из-за горячей замены кода. В итоге Erlang один из самых медленных языков.

То, что можно сделать по другому — это вообще не вызывает сомнений. Но в Erlang-е сделали именно так.

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

То, что можно сделать по другому — это вообще не вызывает сомнений

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

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

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

Могу в пример еще и Ruby привести. Так так же горячая замена кода есть. Он так же не блещет производительностью.

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

Горячая замена кода там сбоку припека, ее мало кто использует. Там основная фича это массовый параллелизм и concurrency.

Ах да, на эрланге тоже есть СУБД, называется Riak, очень крутая.

И да, внезапно, со включенным HiPE (Jit такой) он перестает как-то быть «одним из самых медленных»: https://benchmarksgame.alioth.debian.org/u64q/binarytrees.html

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

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

Вы это ТС-у расскажите, а то у него горячая замена кода — это киллер-фича с Erlang-ом в качестве одного из доказательств.

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

посгрес, по словам дениса, отказался от лиспа

Он никогда полностью на лиспе и не был.

https://www.postgresql.org/message-id/200001112225.OAA19318@busytown.parc.xer...

from the beginning until late 1989, the system was divided into two parts: one written in C, the other written in franz lisp. the line was drawn below the traffic cop, query executor and query optimizer;

С другой стороны, хорошо что Денис невнимательно читал историю создания PostgreSQL

The POSTGRES project, led by Professor Michael Stonebraker, was sponsored by the Defense Advanced Research Projects Agency (DARPA), the Army Research Office (ARO)

Так бы еще и Министерство Обороны спамил своим Яром

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

Назвал уже как минимум три широкоиспользуемые фичи. Компилирующие темплейт-движки, компилируемые динамические прокси сервисов, компилируемые динамические сериализаторы. Ну и да, вот то что умеет jrebel, умеет и Visual Studio.

Нет, не нивелируется, совершенно разного порядка вещи. Тем более, в хаскеле репл куцый. В случае когда весь «проект» - REPL, разработка совершенно по-другому идет, по сравнению с тем как если просто иногда тыкать какие-то мелочи в командной строке.

Вообще конечно ответить легко на всё, кроме темплейт-движков которые мне как веб-программисту кажутся интересной фичей на вскидку.

Да, фичи которые ты назвал иногда бывают нужны. Но это нужно сильно менее чем в 1% случаев, наверное. Так что назвать «динамический прокси для сервиса» и «компилирующийся динамический сериализатор» широко используемыми на практике как то язык не поворачивается.

Когда это (динамические изменения сервисов) предполагается, это можно сделать архитектурно - типа выбрал - они изменился. Поэтому фича вообще кажется костылём (как и всё в динамических языках, если честно). А когда не предполагается - ну придётся перезапустить сервис, что делать.

Да, иногда круто иметь возможность создать динамический прокси для сервиса. Но «сильно менее 1%» это как раз и есть то что называется «десять рад подумать прежде чем делать и плюнуть в итоге». Компилируемые динамические сериализаторы из той же серии.

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

По поводу нивелируется - не нивилируется, я вообще не понял. Ну загрузи в репл главный модуль (где мейн) и ещё кучу модулей. Дёргай функции. Надо - перезагрузи (один) модуль. Чего там куцего то? То ли я чего не понял, то ли я не знаю.

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

Т.е. 1С - это в России язык программирования N1

Это ж бейсик-уродец. Что на нем можно написать, кроме проводок в бухгалтерии.

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

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

В дотнете они повсюду. Поясню.

Например, про сериализаторы. Мы в дотнете пишем контроллеры Web API вот так:

[HttpPost]
MyOutputDto DoSomething(MyInputDto args)
{
   ...
}
Как сериализовать dto мы не пишем, вообще нигде. Но как их, получается, тогда транслировать, в тот же JSON, и наоборот? Можно юзать рефлекшн(тормозит, и вообще). Можно генерить прокси при компиляции, но это муторно, и потом их надо поддерживать в актуальном состоянии, мержить в гите, и вообще. Но можно при старте приложения, или там, отложенно, при первом вызове метода, генерировать классы-трансляторы для каждого из таких dto-классов, и компилировать их, и потом использовать; получится и быстро, и актуальность всегда будет поддерживаться.

Примерно то же для проксей. На клиенте, точно так же, у нас скажем есть интерфейс (который мы вообще можем шарить с сервисом на сервере), мы делаем proxyGenerator.GetOrGenerateProxy<IMyService>() и получаем скомпилированную проксю, которую вызываем потом как обычный класс. Прокся сама все парсит, делает вызовы HTTP или чего там, но при этом скомпилированная, как будто мы ее сами написали, а не через тормозной рефлекшн.

Я делал еще более забавные вещи, например генерацию моделей из базы от и до, в рантайме. Добавил табличку - появились методы CRUD, а внутри оно само все, и скомпилено, со всякой метаинформацией и прочим, а не через Dictionary. А на клиенте соответственно, из автоматических проксей автоматически генерировались датагриды, например, и некоторые другие контролы.

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

По поводу нивелируется - не нивилируется, я вообще не понял. Ну загрузи в репл главный модуль (где мейн) и ещё кучу модулей. Дёргай функции. Надо - перезагрузи (один) модуль. Чего там куцего то? То ли я чего не понял, то ли я не знаю.

Дергать функции в отдельном окне, в строчке REPL, это не то же самое, что скажем, навести курсор на функцию, что-то поменять в ней, нажать C-c C-e, и функция внезапно меняется во всей системе. Без перекомпиляции всего модуля, и тому подобного. Или точно так же, в файле написать что-то для выполнения, выполнить через комбинацию клавиш и стереть. Вообще, это часть идеологии разработки в образе, чтобы в нее врубиться надо попробовать просто.

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

Поставь DCEVM - там все это есть.

В JVM встроенный дебаг-интерфейс. Первая часть стандартная - смотрим переменные, гуляем по коду, вторая часть позволяет замену кода. Только Оракл говорит: дело это сложное, неочевидное, так что мы даем только самые простые вещи: удалить метод или заменить его тело.

Если добавить аргумент к функции, то получится новая функция с другой сигнатурой, так делать нельзя.

Но есть патч на JVM, зовется Dynamic Code Evolution Virtual Machine , http://ssw.jku.at/dcevm/ . Делался то ли одним человеком, то ли небольшой группой - т.е. на боевой сервер лучше не ставить, но для разработки и дебага - самое оно.

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

Нельзя только менять дерево наследования: был class Bender extends Robot, а нужен class Bender extends Ostap - вот так нельзя.

И все это автоматом доступно из Идеи, и, скорее всего, Нетбинса и Эклипса, т.к. дебаг-интерфейс-то стандартный.

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

рефлекшн действительно тормозит. а вот чем отличается генерирование при компиляции от того что вы делаете, я честно говоря не понимаю. в хаскеле (с использованием aeson и derivegeneric) это будет одна строка instance MyClass FromJSON. Аргумента про «быстро и актуально и всегда будет поддерживаться» по сравнению с компил-таймом не понял. По сравнению с рефлекшном ясно. Но с компил-таймом? «просто» - у вас как то сложнее это в компил-тайме? если нет - тогда про простоту не совсем уловил, если разница в одну строку, то может и проще, но не шибко. Не уверен что разменял бы «явно» на такую «простоту».
«всегда поддерживаться» - в том смысле что прямо в компилятор вшито, а не сторонняя либа?
«быстро» - как может быть быстрее чем заранее скомпилированный код?

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

Примерно то же для проксей. На клиенте, точно так же, у нас скажем есть интерфейс (который мы вообще можем шарить с сервисом на сервере), мы делаем proxyGenerator.GetOrGenerateProxy<IMyService>() и получаем скомпилированную проксю, которую вызываем потом как обычный класс. Прокся сама все парсит, делает вызовы HTTP или чего там, но при этом скомпилированная, как будто мы ее сами написали, а не через тормозной рефлекшн.

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

Я делал еще более забавные вещи, например генерацию моделей из базы от и до, в рантайме. Добавил табличку - появились методы CRUD, а внутри оно само все, и скомпилено, со всякой метаинформацией и прочим, а не через Dictionary.

ну на php оно так легко и непренуждённо делается (рефлекшином, но кого это на php волнует). но смысл типизации то в статической проверке модели. поэтому не уверен что я могу это считать за преимущество. может быть есть случаи когда это работает (для конечного клиента), но обычно информацию надо выводить не в банальном гриде, а в более сложной форме. Вряд ли автогенерация покроет серьёзный процент запросов. А за маленький процент я бы не то тчо писать, даже разбираться с этим не стал бы скорее всего. Хотя конечно зависит от того на сколько маленький.

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

В целом я понимаю, ты говришь «если есть горячая замена - можно автогенерить, автогенерить и автогенерить». Но автогенерить можно и без замены, рефлекшин, темплейты, просто хитрые типы, автодерайвинг.

В целом всё что ты назвал - делается без горячей замены. Может иногда хуже, но я не уверен что оно того стоит. Для предложенных целей я бы кажется использовал твой подход только в последнюю очередь. Но хорошо когда он есть в запасе. В конце концов иногда и банальный дикшинари выручает, хоть и не очень хорошо с точки зрения поддержки такого решения.

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

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

например, в вебе - как от вашей горячей замены станет легче? ко мне пришёл запрос, я его обработал. ну сделал я C-c C-e, так запрос надо опять посылать. толку от того что оно «наживую». А заменил ли ты в «живой» системе или «в мёртвой», почти пофиг если приложение не стартует долго,конечно, как ява. Но я уже упоминал что как раз там горячая замена с моего угла зрения, скорее похожа на сглаживание недостатка, чем на фичу.

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

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

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

Или точно так же, в файле написать что-то для выполнения, выполнить через комбинацию клавиш и стереть.

А это основной аргумент против разработки в образе. Удалённая из файла функция не удаляется из образа. А если это не функция, а метод CLOS, то легко при тестах наткнуться на код из предыдущей версии.

Поэтому уж лучше подход Racket (и, если я правильно понял, C#), когда можно перегрузить только модуль целиком.

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

Бред какой. Ну остается и остается. Можно сделать fmakunbound.

А если это не функция, а метод CLOS, то легко при тестах наткнуться на код из предыдущей версии.

Высосанная из пальца проблема.

Поэтому уж лучше подход Racket (и, если я правильно понял, C#), когда можно перегрузить только модуль целиком.

Ага, а лучше уж подход C++, когда намертво сконпилил, и вообще ничего менять нельзя даже если хочется. Сарказм.

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

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

Но с компил-таймом?

Ну а здесь мы постепенно переходим собственно к лиспу. В компайл-тайме, безусловно все это дело делать лучше. Только вот нормально оно в компайл-тайме делается только в лиспе, и я даже скажу, нормальнее всего - в Common Lisp, по ряду причин(lisp-2, полноценные макросы с четкой семантикой, eval-when, macrolet, etc).

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

«всегда поддерживаться» - в том смысле что прямо в компилятор вшито, а не сторонняя либа?

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

Вряд ли автогенерация покроет серьёзный процент запросов.

Для энтерпрайз-приложений покрывает достаточно большой процент.

Понятно что когда у тебя хипстерский сервер для хипстеров, с тремя с половиной сущностями в БД, то оно не надо.

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

Btw, про производительнось - вот мнение что оно не надо, в вебе, ошибочное. Когда сколько-нибудь больше количество сущностей, и сколько-нибудь большая нагрузка, все эти руби-пхп-питоны с их рефлекшном и прочим, встают раком, и вынуждают клиентов крыть разработчиков матюками, и разработчиков либо выкидывать их нахер, либо изобретать какие-нибудь поделия аля hip hop php.

В целом я понимаю, ты говришь «если есть горячая замена - можно автогенерить, автогенерить и автогенерить».

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

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