KK>Совсем дикая идея: может денег попросить? Грант какой-нибудь, или у государства — типа инновационный проект и все такое. Назвать язык Nano, например, лол. Проект-то стоящий, не про%бизнес какой-нибудь.
Ага, деньги автоматом означают контроль и ответственность, вот и будет стимул что-то делать.
Только сначала надо общественное движение "За Nemerle" замутить.
Интересно есть среди заинтересованных кто-то из академических кругов. Иначе никаких грантов не будет, имхо. Плюс кризис, у меценатов свои траблы.
И что проект стоящий знает лишь уз. круг огр. людей, иначе все бы уже писали на немерле.
Здравствуйте, kitsunekko, Вы писали:
КЛ>>Я не улавливаю мысль. Сейчас с бутстраппингом все нормально. Что с ним не так?
K>Т_Т K>Ну что может быть "не так" с бутстрапом рабочего компилера? K>Но вы же вроде НОВЫЙ копилер пишете! Того же языка (ну почти). K>Если делать сразу бутстрап (т.е. повторять путь немерлистов), то нельзя использовать фичи языка, еще не реализованные (например нельзя использовать макросы в коде реализации макросов, они просто не скомпилятся, а потом опять по новой переписывать с макросами). K>Вообще, мне казалось, что это очевидные ламерские рассуждения, а тут "не улавливаю мысль"
все. понял. само собой новый никто бутстрапить не будет (до поры до времени). и это настолько ламерские рассуждения, что ты мог и не говорить
КЛ>>Расшифруй, все равно не догоняю. Что не так с синтаксисом вариантов? K>С ним все ОК, все идеально! Но я не могу использовать такой же синтаксис в произвольном классе (ну да, макрос пиши), только в вариантах.
зачем он тебе такой?
КЛ>>ну, это мелочи K>На этих мелочах основан LINQ, и такие "мелочи" кумулятивно уменьшают код.
гм. ты хочешь сказать, что линк поменяли с выходом extension props? Дык extension methods в немерле давно есть
K>>>Оный вишлист в других нереализуем КЛ>>почему же? K>Ты же его не видел. и набивать 10 страниц в лом.
что-то мне подсказывает, что тебе лучше другой язык взять, где набивать не надо.
КЛ>>какая именно? K>Ну например "нелегальное положение" отступов, изобильная скобчатость, необходимость специфицировать все на свете, кроме типов, и то не всегда (нет, я не любитель уток). Еще необходимость приводить тип при любых потенциальных потерях. Точнее, нет директивы "приводи все нафиг, я в своем уме". Жесткая структура файла (например, нельзя using System.Console внутри класса или метода, namespace без скобок). Дальше еще длинный список.
отступы не работают тока в интеграции (мож тебе все-таки в f#? . со скобками вроже тоже все ок (я привык к сишному синтаксису). специфицировать все на свете как раз не нужно. Жесткая структура... В общем, давай конкретный код под конкретную задачу и покажи, что тебе не нравится. а так абстракция получается.
K>Нет, я не жалуюсь, я сожру все, что дадут.
Здравствуйте, VladD2, Вы писали:
VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?
VD>Задачи: VD>1. Переосмыслить фичи Немерле. Оставить только те что не вызывают серьезных конфликтов с другими фичами языка или Интеграции. VD>2. Переписать компилятор Немерле с нуля учитывая требования накладываемые интеграцией, производительности компилятора, модульности, легкой поддержки и т.п. VD>3. Написать Интеграцию языка со студией. VD>4. При всем при этом не наделать ошибок сделанных поляками.
VD>Проект, по моим рассчетам где-то на 4 человекогода (при фул-тайм разработке).
Я бы помог, но такая постановка вызывает большие опасения. Если проект не будет реализован в значительной мере за короткий срок, то он может загнуться, а участники потерять интерес итерес и в первом компиляторе.
Я вот тут о чем еще подумал. Есть на свете очень интересный язык (по крайней мере для меня) Clojure. Так вот, можно было бы потырить некоторые идеи оттуда, то есть, направленность на многопоточное программирование, это STM и Agents. Делать так же как и Clojure, все базовые структуры данных делать immutable (ведь уже так?), а если надо их шарить между потоками, использовать для этого STM.
Это могло быть еще одним фактором для популярности языка, кроме мощных макросов.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Я вот тут о чем еще подумал. Есть на свете очень интересный язык (по крайней мере для меня) Clojure. Так вот, можно было бы потырить некоторые идеи оттуда, то есть, направленность на многопоточное программирование, это STM и Agents.
Как я понял из описания — это диалект Лиспа работающий поверх ява-машины. Что можно взять из Лиспа мне не очень понятно. Все что можно было уже взято (макросы).
STM (software transactional memory) идея очень спорная. Пока что нет четкого мнения по поводу применимости этой идеи в реальных приложениях. Есть реализация STM для дотнета. Только она никуда не годна, так как дико тормозит. Я не думаю, что от языка нужна какая-то поддержка. Все что нужно можно сделать на основе макросов.
Agents — это видимо нечто воде Actors в Скале или процессов Эрланг. Хорошая абстракция, но для ее реализации на уровне Эрланга нужно менять не язык а виртуальную машину. А реализовать ее на уровне Скалы можно просто в виде библиотеки (даже не макро-библиотеки).
В общем, все это можно сделать и на текущей версии Немерле. Затевать ради этого практически новый язык смысла нет.
С другой стороны брать лучшее из других языков вполне возможно и нужно. Главное чтобы новые фичи не конфликтовали с имеющимися.
Y>Делать так же как и Clojure, все базовые структуры данных делать immutable (ведь уже так?), а если надо их шарить между потоками, использовать для этого STM.
К сожалению, в современном компиляторе это не так. Тут и там есть изменяемые поля используемые для оптимизаций (а чаще просто для упрощения изменения кода). На сегодня сам компилятор однопоточен. Одна из задач нового проекта была бы, как раз, переписывание компилятора с рассчетом на параллелизм.
Причем, особого смысла в каких-то специальны средствах распараллеливания нет. Просто отдельные методы нужно компилировать в отдельных же потоках.
Основной проблемой является то, что макросы могут изменять код методов. И то что макросы не чем не контролируются. Остальные проблемы являются чистыми проблемами реализации. Компилятор писали без оглядки на многопоточность.
Y>Это могло быть еще одним фактором для популярности языка, кроме мощных макросов.
Все это можно сделать и сейчас. Было бы кому этим заняться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Совсем дикая идея: может денег попросить? Грант какой-нибудь, или у государства — типа инновационный проект и все такое. Назвать язык Nano, например, лол. Проект-то стоящий, не про%бизнес какой-нибудь.
У кого?
К сожалению, проблема выбивания денег под проект — это отдельная и весьма сложная задача.
Выручить деньги с продажи подобного продукта не реально. Так что это может быть только меценатство основанное на желании людей пропариться или вообще по доброте души.
В общем, если кто-то предложил свою поддержку я бы был только рад. Но в то что такие меценаты найдутся мне совсем не верится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: А кто записался бы в добровольцы?...
От:
Аноним
Дата:
06.02.09 05:37
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?
Надо же! А я все думал, когда-же немерле станет дико популярным, т.е. иначе говоря, загнется? И вот этот момент настал!
Здравствуйте, VladD2, Вы писали:
VD>Как я понял из описания — это диалект Лиспа работающий поверх ява-машины. Что можно взять из Лиспа мне не очень понятно. Все что можно было уже взято (макросы).
Неужели можно так же грациозно оперировать над кодом как в Лиспе? Мне показалось, что писать макросы сложно и запутанно. Правда честно признаться я не углублялся.
В любом случае, основной пойнт сообщения был не в этом.
VD>STM (software transactional memory) идея очень спорная. Пока что нет четкого мнения по поводу применимости этой идеи в реальных приложениях. Есть реализация STM для дотнета. Только она никуда не годна, так как дико тормозит. Я не думаю, что от языка нужна какая-то поддержка. Все что нужно можно сделать на основе макросов.
Неужели? Насчет производительности, естесственно, эта фича не бесплатна, но и при правильной готовке, STM в принципе не так часто нужен (если писать преимущественно в функциональном стиле), но когда нужен, я готов смириться с малой производительностью, лишь бы не тра...я со всеми этим локами и прочими радостями сек... тьфу многопоточного программирования.
Поддержка со стороны языка нужна, всмысле, запретить на уровне языка доступ к данным в обход STM. Нужно ли так делать или нет, тоже вопрос спорный.
VD>Agents — это видимо нечто воде Actors в Скале или процессов Эрланг. Хорошая абстракция, но для ее реализации на уровне Эрланга нужно менять не язык а виртуальную машину. А реализовать ее на уровне Скалы можно просто в виде библиотеки (даже не макро-библиотеки).
Виртуальную машину менять не надо. Вон Clojure, не стали же менять JVM ради этого.
VD>В общем, все это можно сделать и на текущей версии Немерле. Затевать ради этого практически новый язык смысла нет.
Так же можно сказать и про Лисп, что все и так можно сделать на Common Lisp, зачем надо было писать Clojure. Ответ на этот вопрос мне кажется, гармония Мне в последнее время дико нравится Clojure именно тем, что там я ощущаю некую гармонию.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали: Y>Так же можно сказать и про Лисп, что все и так можно сделать на Common Lisp, зачем надо было писать Clojure. Ответ на этот вопрос мне кажется, гармония Мне в последнее время дико нравится Clojure именно тем, что там я ощущаю некую гармонию.
Я в нем, честно говоря, ощущаю желание сделать свой лисп с блекджеком и шлюхами. Только вот зачем человечеству еще один?
Здравствуйте, yumi, Вы писали:
Y>Неужели можно так же грациозно оперировать над кодом как в Лиспе? Мне показалось, что писать макросы сложно и запутанно. Правда честно признаться я не углублялся.
А, не уже ли есть язык на котором писать сложнее и не удобнее чем на Лиспе? На нем и вне макр то читать код не просто. А, читать мета-код еще сложнее.
В общем, лично я писать на Лиспе не буду. А макры прекрасно работают и в языках с синтаксисом (что Немерле и доказываем).
В общем, если у тебя есть желание сделать еще один Лисп, то нам не по пути.
Y>В любом случае, основной пойнт сообщения был не в этом.
А в чем?
VD>>STM (software transactional memory) идея очень спорная. Пока что нет четкого мнения по поводу применимости этой идеи в реальных приложениях. Есть реализация STM для дотнета. Только она никуда не годна, так как дико тормозит. Я не думаю, что от языка нужна какая-то поддержка. Все что нужно можно сделать на основе макросов.
Y>Неужели?
Я это тут даже обсуждать не хочу. Хватает тем обсуждающих это. Считаешь идею правильно? Можешь реализовать на макрах.
Y>Поддержка со стороны языка нужна, всмысле, запретить на уровне языка доступ к данным в обход STM. Нужно ли так делать или нет, тоже вопрос спорный.
Вот именно. Все что можно сделать в языке — это ввести понятие чистой функции. Как это сделать отлично описано в D (Ди).
VD>>Agents — это видимо нечто воде Actors в Скале или процессов Эрланг. Хорошая абстракция, но для ее реализации на уровне Эрланга нужно менять не язык а виртуальную машину. А реализовать ее на уровне Скалы можно просто в виде библиотеки (даже не макро-библиотеки).
Y>Виртуальную машину менять не надо. Вон Clojure, не стали же менять JVM ради этого.
А результат сравним с Эрэангом? Можно на нем запустить тысячи параллельных агентов выполняющих мелкие рассчеты? Что при этом будет с производительностью? Есть сравнения с Эрлангом и Скалой?
VD>>В общем, все это можно сделать и на текущей версии Немерле. Затевать ради этого практически новый язык смысла нет.
Y>Так же можно сказать и про Лисп,
Скажу больше. В приведенном тобой язяке так и сделано. Там тупо реализовано ядро Лисп и на нем уже написаны все расширения. Если это не так, то они просто сумасшедшие.
Y> что все и так можно сделать на Common Lisp, зачем надо было писать Clojure.
А вот это действительно вопрос. Интеграция с Явой у него будет очень плохая. Если Яву из Кложура может и можно будет вызвать, то наоборот будет уже совсем не удобно.
Y> Ответ на этот вопрос мне кажется, гармония Мне в последнее время дико нравится Clojure именно тем, что там я ощущаю некую гармонию.
Ну, так бери его и пользуйся. Следующим шагом будет переход на CL.
Тут же речь идет о создании новой версии Немерла который на 90% по фичам и на 100% по духу будет аналогичен Немерле, но при этом не будет иметь архитектурных проблем присущих текущей реализации.
Несомненно по ходу дела можно и нужно будет внести какие-то изменения. Скажем я бы сделал основным синтаксисом лябды — синтаксис C# 3.0. Далее снял бы ограничения с макросов и позволил бы их применять в любом месте кода и с любым синтаксисом. Скажем само описание макроса я бы описал макросом. Тогда Немерле ни чем бы не уступал Лиспу по возможностям мкросов.
А вот выбрасывать я бы почти ничего не стал бы. Реально мешают только приведение кортеж к списку параметров. Точнее это то, что нельзя объявить кортеж с одним параметром. Это приводит к тому, что Немерле не может отличить функции с двумя параметрами от функции в которой есть один параметр — кортеж.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Согласен, я всегда чувствую неловкость пред коллегами, произнося название этого замечательного языка вслух.
Ого! А теперь представь, что есть люди, знающие ОБЕРОН, ПИТОН, ПАСКАЛЬ и ЯВУ с АДОЙ. Страшно?
Здравствуйте, VladD2, Вы писали:
VD>А, не уже ли есть язык на котором писать сложнее и не удобнее чем на Лиспе? На нем и вне макр то читать код не просто. А, читать мета-код еще сложнее.
Все относительно, я после макросов Лиспа, без слез на макросы Nemerle смотреть не могу.
VD>В общем, лично я писать на Лиспе не буду. А макры прекрасно работают и в языках с синтаксисом (что Немерле и доказываем).
Дык, никто ж тебя не заставляет! Не хочешь не пиши! Насчет прекрасно работают, это спорный вопрос. Весьма весьма спорный. Сам об этом знаешь наверное.
VD>В общем, если у тебя есть желание сделать еще один Лисп, то нам не по пути.
Не по пути, не по пути, не бойся. Но к твоему сведению, сделать еще один Лисп я лично тебе не предлагал и не предлагал из Немерля сделать Лисп.
Y>>В любом случае, основной пойнт сообщения был не в этом.
VD>А в чем?
Читать умеем? STM & Agents, которые я ниже приводил. Ориентированность на облегчение многопоточного программирования.
VD>Ну, так бери его и пользуйся. Следующим шагом будет переход на CL.
Я и так в Clojure пришел из CL. За Erlang-style, но со всей мощью Лиспа.
VD>Тут же речь идет о создании новой версии Немерла который на 90% по фичам и на 100% по духу будет аналогичен Немерле, но при этом не будет иметь архитектурных проблем присущих текущей реализации.
Я всего лишь хотел обратить внимание на те идеи из Clojure, которые возможно стоило бы учесть при переписывании с нуля. У меня не было желания сделать из Немерля Лисп или еще что. А теперь вообще никакого желания учавствовать в этом проекте тоже нет. Если даже просто тупо предложения пользователей так в штыки воспринимаются и даже где-то углядел наезд на Немерле То тут извини меня. Я лично умываю руки. Лучше подумаю над портированием Clojure на .NET
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали: VD>>Agents — это видимо нечто воде Actors в Скале или процессов Эрланг. Хорошая абстракция, но для ее реализации на уровне Эрланга нужно менять не язык а виртуальную машину. А реализовать ее на уровне Скалы можно просто в виде библиотеки (даже не макро-библиотеки). Y>Виртуальную машину менять не надо. Вон Clojure, не стали же менять JVM ради этого.
. Т.е. вроде как сделать concurrency в стиле эрланга — можно и в рамках обычной VM, но добиться всех бенефитов эрланга не получится. Так что тут уже исключительно маркетинговый вопрос — говорить, что многопоточность и actor model поддерживаются "внутрях самого языка" (как в Clojure) или говорить о том, что они прилеплены сбоку (как в Haskell).
. Т.е. вроде как сделать concurrency в стиле эрланга — можно и в рамках обычной VM, но добиться всех бенефитов эрланга не получится. Так что тут уже исключительно маркетинговый вопрос — говорить, что многопоточность и actor model поддерживаются "внутрях самого языка" (как в Clojure) или говорить о том, что они прилеплены сбоку (как в Haskell).
Я читал этот замечательный пост, даже где-то сам ссылку на него приводил. Я в курсе, что нельзя добиться всех бенефитов Эрланга.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Y>Я вот тут о чем еще подумал. Есть на свете очень интересный язык (по крайней мере для меня) Clojure. Так вот, можно было бы потырить некоторые идеи оттуда, то есть, направленность на многопоточное программирование, это STM и Agents. Делать так же как и Clojure, все базовые структуры данных делать immutable (ведь уже так?), а если надо их шарить между потоками, использовать для этого STM.
Если б я писал под яву, точно юзал бы Clojure. И иммутабельность любых базовых типов — прописная истина без всяких "как в", это я как жертва многопоточности давно убедился.
Я видел минимум 3 библиотеки STM для C#, можно просто взять готовую и прикрутить макрос, скажем #pragma threadsafe — завернуть все mutable в транзакции. Или каждую по отдельности.
Только в STM "средствами языка" надо или защищаться от дедлоков по черному или анализировать возможные конфликты, что имхо нереально, даже в своей проге это сложно делать.
Лучше сразу делать иммутабельным все, что можно. Тогда и локи не достают. И разобраться с Parallel FX, раз уж его в .net добавили.
А вот чего не хватает, так это "легковесных процессов", это решило бы все мои проблемы, т.к. мне не нужно использовать вычислительную мощь многоядерного..., а просто запускать параллельные задачи. Блокировки исключаются в принципе — манеджер процессов просто не переключится до завершения транзакции.
Хотелось бы и каких то гарантий риалтайма, но никто не даст. Просто надо "взять мощный компьютер"...
Может стоит "volatile-поля" добавить? а то без них сложно будет что-то поточное прикрутить. или оно уже есть?
И еще, можно как-то перехватить исключение в чужом потоке? А то у меня мелкософтовский SerialPort валил всю прогу (ObjectDisposed в релизе через х дней аптайма)
Y>Это могло быть еще одним фактором для популярности языка, кроме мощных макросов.
Т.е. добавить фичу для галочки, может найдется кому оно нужно?
ИМХО, надо писать только то, что нужно себе. А если найдется нуждающийся в фиче х, он ее сделает в сто раз лучше, т.к. у него есть конкретные задачи, где она нужна, и четко знает что нужно сделать.
VD>>В общем, если у тебя есть желание сделать еще один Лисп, то нам не по пути.
Y>Не по пути, не по пути, не бойся. Но к твоему сведению, сделать еще один Лисп я лично тебе не предлагал и не предлагал из Немерля сделать Лисп.
коллеги, без паники
Y>>>В любом случае, основной пойнт сообщения был не в этом.
VD>>А в чем?
Y>Читать умеем? STM & Agents, которые я ниже приводил. Ориентированность на облегчение многопоточного программирования.
имхо, это все реализуется сбоку, в библиотеках. нет? Главное в языке платформу подготовить.
VD>>Ну, так бери его и пользуйся. Следующим шагом будет переход на CL.
Y>Я и так в Clojure пришел из CL. За Erlang-style, но со всей мощью Лиспа.
VD>>Тут же речь идет о создании новой версии Немерла который на 90% по фичам и на 100% по духу будет аналогичен Немерле, но при этом не будет иметь архитектурных проблем присущих текущей реализации.
Y>Я всего лишь хотел обратить внимание на те идеи из Clojure, которые возможно стоило бы учесть при переписывании с нуля. У меня не было желания сделать из Немерля Лисп или еще что. А теперь вообще никакого желания учавствовать в этом проекте тоже нет. Если даже просто тупо предложения пользователей так в штыки воспринимаются и даже где-то углядел наезд на Немерле То тут извини меня. Я лично умываю руки. Лучше подумаю над портированием Clojure на .NET
Подожди. Дело в том, что язык уже есть. Язык довольно хорошо сбалансирован. Сейчас речь идет не о тотальном пересмотре фич языка. Пока не видно, что полезного можно сташщить из clojure
КЛ>отступы не работают тока в интеграции (мож тебе все-таки в f#? . со скобками вроже тоже все ок (я привык к сишному синтаксису). специфицировать все на свете как раз не нужно. Жесткая структура... В общем, давай конкретный код под конкретную задачу и покажи, что тебе не нравится. а так абстракция получается.
Дай дописать "конкретный код" с желаемым синтаксисом, а то мне не нравится абстрактная необходимость писать перед каждым словом видимость/аттрибуты/макросы и закрывать в скобки каждый одиночный токен.
Мне не нравится именно текущая реализация отступов (блок ничем, кробе табов не выделяется, надо \ юзать) — хочу как в бу: перед отступом обязательно ":" в конце строки (неоднозначности с оператором приведения нет, он бинарный), можно считать безымянным блоком. И исключить отступы на пол-экрана (с namespace ххх; без скобок и т.п.). Попробую подкрутить макрос indent.
"специфицировать все на свете как раз не нужно". это вообще о чем? императивная часть от шарпа ничем в этом плане не отличается, а может еще и хуже (если макросы не учитывать).
Особенно достает override, если я перекрываю виртуальный метод без new, какие еще могут быть варианты Т_Т
И вообще, я только поделился своими хотелками. Я не заставляю тебя их реализовывать, так чего прикопался? Тем более, тебя все устраивает.
Здравствуйте, kitsunekko, Вы писали:
КЛ>>отступы не работают тока в интеграции (мож тебе все-таки в f#? . со скобками вроже тоже все ок (я привык к сишному синтаксису). специфицировать все на свете как раз не нужно. Жесткая структура... В общем, давай конкретный код под конкретную задачу и покажи, что тебе не нравится. а так абстракция получается.
[]
K>"специфицировать все на свете как раз не нужно". это вообще о чем? императивная часть от шарпа ничем в этом плане не отличается, а может еще и хуже (если макросы не учитывать). K>Особенно достает override, если я перекрываю виртуальный метод без new, какие еще могут быть варианты Т_Т
я ошибаюсь, или без override будет name hiding? overload resolution будет по-другому работать и тп? так что тут не так все просто
K>И вообще, я только поделился своими хотелками. Я не заставляю тебя их реализовывать, так чего прикопался? Тем более, тебя все устраивает.
я не прикопался. пытаюсь выяснить, что тебе не нравится
КЛ>я ошибаюсь, или без override будет name hiding? overload resolution будет по-другому работать и тп? так что тут не так все просто
Если мне надо name hiding я напишу new, если перекрываю публичный невиртуальный член — законная ошибка. А в 99.9999...% случаев мне нужно override, и компилер не настолько тупой, чтобы не заметить у предка то же имя и сигнатуру. И я не индус, чтобы не понимать, что компилер будет делать.
C# похоже, писался с учетом опыта индийского подразделения MS — дуракозащищенность потрясающая. Только уже достала.
. со скобками вроже тоже все ок (я привык к сишному синтаксису). специфицировать все на свете как раз не нужно. Жесткая структура... В общем, давай конкретный код под конкретную задачу и покажи, что тебе не нравится. а так абстракция получается.
То тут извини меня. Я лично умываю руки. Лучше подумаю над портированием Clojure на .NET 