Здравствуйте, dotneter, Вы писали:

D>Почему это нельзя сделать опционально? Если я хочу помощи от компилятора то пишу override, а если не хочу то меня к этому никто не принуждает.

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

Здравствуйте, kitsunekko, Вы писали:

КЛ>>я ошибаюсь, или без override будет name hiding? overload resolution будет по-другому работать и тп? так что тут не так все просто

K>Если мне надо name hiding я напишу new, если перекрываю публичный невиртуальный член — законная ошибка. А в 99.9999...% случаев мне нужно override, и компилер не настолько тупой, чтобы не заметить у предка то же имя и сигнатуру. И я не индус, чтобы не понимать, что компилер будет делать.

K>C# похоже, писался с учетом опыта индийского подразделения MS — дуракозащищенность потрясающая. Только уже достала.

Явные override и new помогают читаемости программ, также как и ref и out (сам бы компилер мог догадаться по сигнатуре).
наверное не стоит предлагать делать Write Only язык

Здравствуйте, VladD2, Вы писали:

[]

За деньги я бы и фултайм поработал

Здравствуйте, dotneter, Вы писали:

VD>>Тогда бы он мог нам на мыло что-то написать.
D>Ну а вы бы писал письма тем у кого столько потырил? =)

Он прежде чем потырил даже ругался, что мол макры — это перебор...

VD>>На много? Я оцениваю это "много" как ~0.
D>Google
D>Boo language 9 380 000
D>Nemerle language 29 400

Это как-то обсуждалось на форумах. Там какие-то размноженные цетирования. К тому же если ты хочешь найти два слова, то их в кавычках надо указывать.

В общем — это не показатель. Запрос со скобками ("Boo language") дает 3 260 вхождений. А на "Lisp language" 50 700. При этом я бы не сказал, что Лисп реально популярен.

VD>>Сложно и то, и то. Но создать хороший язык не под силу даже владельцам миллиродов вроде MS, Sun и IBM.
D>Думаю за миллиарды можно было нанять на работу кого нибудь из создателей OCaml'а или Haskell'а. Но мейнстрим к этому просто не был готов, поэтому взяли Хейлсберга.

Мэйнсттим они сами и готовят. Потому взяли они того чьи знания находились на их уровне.
Собственно то что мы сейчас наблюдаем (введение фП в Щарп) хороший показатель. Люди ведь другими не стали. Но концепции ФП они приняли весьма легко.

В общем, дайте мне денег которых хватит на 5-6 фул-тайм программистов и двух-летнию мартетинговую программу и через три года про Шарп начнут говорить в прошедшем времени.

offtopic rant follows:
Одного прошу, переименуйте его, а? Хотел попробовать его, но не могу я пользоваться ЯП с таким названием.
Может, так и назовете, N?

Здравствуйте, Mr.Cat, Вы писали:
MC>Так скоро алфавит закончится. В ход пойдут греческие буквы.

Кстати, хорошая идея:
Νεμερλε

Здравствуйте, VladD2, Вы писали:

VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?

VD>Задачи:
VD>1. Переосмыслить фичи Немерле. Оставить только те что не вызывают серьезных конфликтов с другими фичами языка или Интеграции.
VD>2. Переписать компилятор Немерле с нуля учитывая требования накладываемые интеграцией, производительности компилятора, модульности, легкой поддержки и т.п.
VD>3. Написать Интеграцию языка со студией.
VD>4. При всем при этом не наделать ошибок сделанных поляками.

VD>Проект, по моим рассчетам где-то на 4 человекогода (при фул-тайм разработке).

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

Здравствуйте, 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. Далее снял бы ограничения с макросов и позволил бы их применять в любом месте кода и с любым синтаксисом. Скажем само описание макроса я бы описал макросом. Тогда Немерле ни чем бы не уступал Лиспу по возможностям мкросов.

А вот выбрасывать я бы почти ничего не стал бы. Реально мешают только приведение кортеж к списку параметров. Точнее это то, что нельзя объявить кортеж с одним параметром. Это приводит к тому, что Немерле не может отличить функции с двумя параметрами от функции в которой есть один параметр — кортеж.

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, Константин Л., Вы писали:

[]

все ясно. не хочешь вести разговор в нормальном ключе, не надо

КЛ>>Поиск "boo" на rsdn

КЛ>>1. net — результата
КЛ>>2. declarative ~5
КЛ>>3. philosophy ~15
КЛ>>3. о жизни — 0
КЛ>>4. ку — 0

КЛ>>и это при том, что у него коммьюнити, и лет ему уже прилично. что из этого следует и так ясно, надеюсь

Y>Да что ты ограничился этим rsdn'ом. Выше же привели подсчеты ссылок с гугла. Более репрезентативная выборка. А то и я тут каждый день могу про Boo на rsdn'е фразу говорить, скажешь Boo здесь популярен станет?

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

КЛ>>>>кстати, при чем здесь популярность бу? в чем поинт?

Y>Пойнт еще раз, вот он:
Y>>>Пойнт был в том, что кое-кого не будем показывать пальцами, совсем ослепил фанатизм, что кое-кто не в состоянии воспринять тот факт, что Nemerle менее популярен, чем Boo и Lisp. Все.

КЛ>>скажем так, они все очень непопулярны, и зачем это тереть на протяжении всего топика не ясно. Какой в этом глубокий смысл?

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

к сожалению, критики то и нет. есть непонятные обиды на то, что либо на кложур не смотрим, либо не хотим бросать проект и не бежим к бу. никто из вас не сказал, что есть проблема с макрами, которые чуть-ли не самая вкусная фича, зато начали про stm/agents которые вообще мимо кассы.

Здравствуйте, VladD2, Вы писали:

VD>Вот что ты в этот форум ходишь? Какой смысл? Сам Немерле вроде бы использовать не хочешь. Другим помочь не можешь. Но приходишь сюда и тролишь, тролишь, тролишь...

Так после всех споров и войн Немерле для нас как родной
Надо еще eao197 сюда позвать

Y>Я вот тут о чем еще подумал. Есть на свете очень интересный язык (по крайней мере для меня) Clojure. Так вот, можно было бы потырить некоторые идеи оттуда, то есть, направленность на многопоточное программирование, это STM и Agents. Делать так же как и Clojure, все базовые структуры данных делать immutable (ведь уже так?), а если надо их шарить между потоками, использовать для этого STM.

Если б я писал под яву, точно юзал бы Clojure. И иммутабельность любых базовых типов — прописная истина без всяких "как в", это я как жертва многопоточности давно убедился.
Я видел минимум 3 библиотеки STM для C#, можно просто взять готовую и прикрутить макрос, скажем #pragma threadsafe — завернуть все mutable в транзакции. Или каждую по отдельности.
Только в STM "средствами языка" надо или защищаться от дедлоков по черному или анализировать возможные конфликты, что имхо нереально, даже в своей проге это сложно делать.
Лучше сразу делать иммутабельным все, что можно. Тогда и локи не достают. И разобраться с Parallel FX, раз уж его в .net добавили.
А вот чего не хватает, так это "легковесных процессов", это решило бы все мои проблемы, т.к. мне не нужно использовать вычислительную мощь многоядерного..., а просто запускать параллельные задачи. Блокировки исключаются в принципе — манеджер процессов просто не переключится до завершения транзакции.
Хотелось бы и каких то гарантий риалтайма, но никто не даст. Просто надо "взять мощный компьютер"...

Может стоит "volatile-поля" добавить? а то без них сложно будет что-то поточное прикрутить. или оно уже есть?

И еще, можно как-то перехватить исключение в чужом потоке? А то у меня мелкософтовский SerialPort валил всю прогу (ObjectDisposed в релизе через х дней аптайма)

Y>Это могло быть еще одним фактором для популярности языка, кроме мощных макросов.

Т.е. добавить фичу для галочки, может найдется кому оно нужно?
ИМХО, надо писать только то, что нужно себе. А если найдется нуждающийся в фиче х, он ее сделает в сто раз лучше, т.к. у него есть конкретные задачи, где она нужна, и четко знает что нужно сделать.

Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?

Задачи:
1. Переосмыслить фичи Немерле. Оставить только те что не вызывают серьезных конфликтов с другими фичами языка или Интеграции.
2. Переписать компилятор Немерле с нуля учитывая требования накладываемые интеграцией, производительности компилятора, модульности, легкой поддержки и т.п.
3. Написать Интеграцию языка со студией.
4. При всем при этом не наделать ошибок сделанных поляками.

Проект, по моим рассчетам где-то на 4 человекогода (при фул-тайм разработке).

Здравствуйте, VladD2, Вы писали:

VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?

VD>Задачи:
VD>1. Переосмыслить фичи Немерле. Оставить только те что не вызывают серьезных конфликтов с другими фичами языка или Интеграции.
VD>2. Переписать компилятор Немерле с нуля учитывая требования накладываемые интеграцией, производительности компилятора, модульности, легкой поддержки и т.п.
VD>3. Написать Интеграцию языка со студией.
VD>4. При всем при этом не наделать ошибок сделанных поляками.

VD>Проект, по моим рассчетам где-то на 4 человекогода (при фул-тайм разработке).


Я бы поучаствовал, но а) не знаю Nemerle и б)фуллтайм для меня нереально

PS. Назовите язык N#

G>Я бы поучаствовал, но а) не знаю Nemerle и б)фуллтайм для меня нереально

Раз пошла такая пьянка, я тоже могу вписаться, с теми же оговорками, что и у gandjustas'а. Плюс ещё один момент, можно ли будет использовать свой кусочек проекта как тему дипломной работы? ;)

G>PS. Назовите язык N# ;)

Не катит, аллюзия с музыкальной нотацией пропадает (нет такой ноты N, тем более N#).

У меня к названию языка претензий нет, только к логотипу

Автор: Qbit86
Дата: 17.12.08

:)

Здравствуйте, Ka3a4oK, Вы писали:

KK>Согласен, я всегда чувствую неловкость пред коллегами, произнося название этого замечательного языка вслух.

Что ещё за комплексы? Это пусть коллеги неловкость чувствуют.

Здравствуйте, yumi, Вы писали:
Y>Так же можно сказать и про Лисп, что все и так можно сделать на Common Lisp, зачем надо было писать Clojure. Ответ на этот вопрос мне кажется, гармония Мне в последнее время дико нравится Clojure именно тем, что там я ощущаю некую гармонию.

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

Здравствуйте, yumi, Вы писали:
VD>>Agents — это видимо нечто воде Actors в Скале или процессов Эрланг. Хорошая абстракция, но для ее реализации на уровне Эрланга нужно менять не язык а виртуальную машину. А реализовать ее на уровне Скалы можно просто в виде библиотеки (даже не макро-библиотеки).
Y>Виртуальную машину менять не надо. Вон Clojure, не стали же менять JVM ради этого.

На эту тему есть замечательный пост: http://rsdn.ru/forum/message/2261047.aspx

Автор: Lazy Cjow Rhrr
Дата: 12.12.06

. Т.е. вроде как сделать concurrency в стиле эрланга — можно и в рамках обычной VM, но добиться всех бенефитов эрланга не получится. Так что тут уже исключительно маркетинговый вопрос — говорить, что многопоточность и actor model поддерживаются "внутрях самого языка" (как в Clojure) или говорить о том, что они прилеплены сбоку (как в Haskell).

Здравствуйте, yumi, Вы писали:

[]


VD>>В общем, если у тебя есть желание сделать еще один Лисп, то нам не по пути.

Y>Не по пути, не по пути, не бойся. Но к твоему сведению, сделать еще один Лисп я лично тебе не предлагал и не предлагал из Немерля сделать Лисп.

коллеги, без паники

Y>>>В любом случае, основной пойнт сообщения был не в этом.

VD>>А в чем?

Y>Читать умеем? STM & Agents, которые я ниже приводил. Ориентированность на облегчение многопоточного программирования.

имхо, это все реализуется сбоку, в библиотеках. нет? Главное в языке платформу подготовить.

VD>>Ну, так бери его и пользуйся. Следующим шагом будет переход на CL.

Y>Я и так в Clojure пришел из CL. За Erlang-style, но со всей мощью Лиспа.

VD>>Тут же речь идет о создании новой версии Немерла который на 90% по фичам и на 100% по духу будет аналогичен Немерле, но при этом не будет иметь архитектурных проблем присущих текущей реализации.

Y>Я всего лишь хотел обратить внимание на те идеи из Clojure, которые возможно стоило бы учесть при переписывании с нуля. У меня не было желания сделать из Немерля Лисп или еще что. А теперь вообще никакого желания учавствовать в этом проекте тоже нет. Если даже просто тупо предложения пользователей так в штыки воспринимаются и даже где-то углядел наезд на Немерле То тут извини меня. Я лично умываю руки. Лучше подумаю над портированием Clojure на .NET

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

Здравствуйте, dotneter, Вы писали:

D>А какова глобальная цель и смысл данного проекта?

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

вообще, вопрос довольно провокационный, учитывая сказанное здесь ранее

D>Допустим что с ним станет если завтро в F# появятся макросы?

f# все так-же будет меня отталкивать синтаксисом. что будет с остальными? хз

D>Или например есть язык Boo и Rodrigo B. De Oliveirа, который я думаю не боится в случае чего остаться один и в дальнейшем развивать язык. С другой стороны есть VladD2, который не хотел бы работать над языков в одиночку. Так может имело бы смысл примкнуть к разработчикам Boo и донести до них идеи Nemerle'а? Благо там и макросы какие то есть, и вот патерн матчинг появился.

1. синтаксис
2. про бу услышал только тут. надо сказать, я интересуюсь новыми веяними. казань брал, эрланг брал, хаскел брал, скалу брал, бу не брал . так что там с популярностью бу?

Здравствуйте, Аноним, Вы писали:

А>"language boo" — 4350
А>"language nemerle" — 2450
А>"language lisp" — 33700

А>Думаю, такое соотношение очень трудно оспорить

Их и оспаривать бессмысленно. Это просто ничто.

Здравствуйте, Константин Л., Вы писали:

Y>>rsdn это лишь малая часть русскоязычного коммьюнити, да и то оно тут мелькает благодаря кое-кому. А вне rsdn'a, где Nemerle? Ну на хабре пару статей видел, и все...

КЛ>ссылки на обитание большей части русскоязычного коммьюнити плиз.

Имелось ввиду все IT community в целом. Не только русскоязычное. Среди русскоязычных, для примера есть habrahabr.ru, sql.ru, livejournal.ru.

КЛ>кстати, при чем здесь популярность бу? в чем поинт?

Пойнт был в том, что кое-кого не будем показывать пальцами, совсем ослепил фанатизм, что кое-кто не в состоянии воспринять тот факт, что Nemerle менее популярен, чем Boo и Lisp. Все.

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, Константин Л., Вы писали:

Y>>>rsdn это лишь малая часть русскоязычного коммьюнити, да и то оно тут мелькает благодаря кое-кому. А вне rsdn'a, где Nemerle? Ну на хабре пару статей видел, и все...

КЛ>>ссылки на обитание большей части русскоязычного коммьюнити плиз.

Y>Имелось ввиду все IT community в целом. Не только русскоязычное. Среди русскоязычных, для примера есть habrahabr.ru, sql.ru, livejournal.ru.

стоп. то-есть фраза "rsdn это лишь малая часть русскоязычного коммьюнити" не несет никакого смысла, верно?

Поиск "boo" на rsdn

1. net — результата
2. declarative ~5
3. philosophy ~15
3. о жизни — 0
4. ку — 0

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

КЛ>>кстати, при чем здесь популярность бу? в чем поинт?

Y>Пойнт был в том, что кое-кого не будем показывать пальцами, совсем ослепил фанатизм, что кое-кто не в состоянии воспринять тот факт, что Nemerle менее популярен, чем Boo и Lisp. Все.

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

Здравствуйте, Константин Л., Вы писали:

КЛ>ссылки на обитание большей части русскоязычного коммьюнити плиз.

русскоязычное коммюнити вполне себе обитает в оффлайне

Здравствуйте, Tissot, Вы писали:

T>Здравствуйте, Константин Л., Вы писали:

КЛ>>ссылки на обитание большей части русскоязычного коммьюнити плиз.

T>русскоязычное коммюнити вполне себе обитает в оффлайне

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

Здравствуйте, yumi, Вы писали:

Y>Такой слепой фанатизм трудно оспорить, бесмыссленно


У меня своя голова не плечах и когда я вижу черное, то называю это черным, а когда вижу белое, называют это белым. Если кто-то думает, что это фанатизм, ну и бог с ним. Слепой, так слепой. Фанатизм, так фанатизм.

Здравствуйте, yumi, Вы писали:

Y>Пойнт был в том, что кое-кого не будем показывать пальцами, совсем ослепил фанатизм, что кое-кто не в состоянии воспринять тот факт, что Nemerle менее популярен, чем Boo и Lisp. Все.

Это называется расхождение во мнениях.

Поясню свою точку зрения (в последний раз).

Лисп несомненно имеет большую популярность чем Бу и Немерле (даже вместе взятые). Объясняется это очень просто. Это знаковый язык породивший целую парадигму (а то и две). Причем язык с пятидесятилетней историей. Было бы странно если при этом язык не имел довольно много ссылок на себя в Интернет. Как минимум любой обсуждение в котором он упоминается дает такие ссылки.

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

Немерле же и Бу вообще находятся еще в дорелизной стадии. Их только пробуют на зуб. И пробуют самые неординарные и пытливые люди. Массового использования у них нет и не может быть.

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

Если говорить о новых идеях, то их нет ни Немерле, ни, тем более, в Бу. Точнее скажем так. Новая идея Немерле — скрестить в одном языке ООП в стиле С++/C#/Java с ФП в стиле ML и МП в стиле LISP. Попытка оказалась на удивление удачна, но к сожалению первая версия компилятора писалась в весьма наивной манере и не учитывала множество аспектов (как то поддержка IDE, многопоточная компиляци, легкость в равитии). Компилятор оброс хаками и имеет очень сильную связанность.
Авторы языка признались, что когда они взялись за компилятор ООП они не знали в приципе и изучали его в процессе работы над языком.

Мое мнение, что в языке есть все что нужно если говорить о концептуальном уровне. Главная фича — это макросы. Однако некоторые не доработки не дают исползовать макры так же широко как Лиспе, а проблемы компилятора затрудняют его рефакторинг и как следствие доработку той же макросистемы до уровня близкого к идеальному.

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

Кстати, перепичканность фичами — это тоже очень плохо. Вспомним PL1...
Макры же — это ответ на все вопросы. Только макры безкомпромисными. Чтобы на них можно было делать почти все.

Ну, а Бу... В нем есть только одна свежая идея. Скрестить динамику и статику. Мне эта идея не интересна.

Здравствуйте, Константин Л., Вы писали:

КЛ>>>ссылки на обитание большей части русскоязычного коммьюнити плиз.

T>>русскоязычное коммюнити вполне себе обитает в оффлайне

КЛ>и вы, видимо, пили с ними со всеми чай и точно знаете, что бу среди них популярен, так?

Перечитай сообщение на которое я отвечал.

Здравствуйте, VladD2, Вы писали:

VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?

То есть решили пойти той же дорожкой что и D?
У них это прилично затянулось от планировавашегося.

Здравствуйте, VoidEx, Вы писали:

VE>И интересно, со своей манерой поведения ты многих таки склонишь помогать тебе?

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

VE>У меня подозрение, что то, что "все нихрена не делают, только я", это закономерность, не в обиду.

Закономерности тут нет. Закономерность была бы, если бы набралась хоть сотня RSDN'овцев, каждый из которых попытался бы организовать коллектив для создания нетривиального проекта (игра, графический редактор, компилятор, etc). Чтобы регулярно делались релизы, писались бы статьи в журнал, создалось бы комъюнити c вопросами/ответами. Можно было бы из этой сотни брать хоть какую-то статистику и говорить о закономерностях. Вот если б оказалось, что проект, например, VoidEx'а и 90 других организаторов гремит на весь мир, а проект Влада ни шатко ни валко прозябает — тогда твоё «не в обиду» менее походило бы на попытку намеренно уязвить.

Здравствуйте, Ka3a4oK, Вы писали:

KK>Согласен, я всегда чувствую неловкость пред коллегами, произнося название этого замечательного языка вслух.

Это фигня.. ты лучше представь как себя чувствуют те, кто работают с Zope?

Здравствуйте, VladD2, Вы писали:

VD>Задачи:
VD>1. Переосмыслить фичи Немерле. Оставить только те что не вызывают серьезных конфликтов с другими фичами языка или Интеграции.
VD>2. Переписать компилятор Немерле с нуля учитывая требования накладываемые интеграцией, производительности компилятора, модульности, легкой поддержки и т.п.
VD>3. Написать Интеграцию языка со студией.
VD>4. При всем при этом не наделать ошибок сделанных поляками.

Я бы с удовольствием поучавствовал бы в пунктах 1 и 2. Интеграция меня не особо интересует. Давно у меня зреет сумасшедшая идея, создать нечто вроде Nemerle light, облегченную версию, грубо говоря убрав все то, чего я все равно никогда не использую. Правда, опять же проблема со временем, которого никогда не хватает ни на что... Ближайшие пару месяцев я никак не смогу принять участие, возможно после я подтянусь. Но обязательно хотелось бы поучавствовать в таком проекте.

Здравствуйте, jartur, Вы писали:

J>Одного прошу, переименуйте его, а? Хотел попробовать его, но не могу я пользоваться ЯП с таким названием.

А чем тебе не нравится название?
И какие названия тебе нравятся?

Здравствуйте, VladD2, Вы писали:

VD>1. Переосмыслить фичи Немерле. Оставить только те что не вызывают серьезных конфликтов с другими фичами языка или Интеграции.
VD>2. Переписать компилятор Немерле с нуля учитывая требования накладываемые интеграцией, производительности компилятора, модульности, легкой поддержки и т.п.
VD>3. Написать Интеграцию языка со студией.
VD>4. При всем при этом не наделать ошибок сделанных поляками.

Если будет переписываться с нуля, то я бы подписался.

Здравствуйте, gandjustas, Вы писали:
G>Я бы поучаствовал, но а) не знаю Nemerle и б)фуллтайм для меня нереально
Аналогично.

G>PS. Назовите язык N#
Так скоро алфавит закончится. В ход пойдут греческие буквы.

Текущая ситуация: авторы немерль дропнули и теперь его судьба зависит от RSDN?
А если еще и Влад дропнет? Кранты?

"4 человекогода при фул-тайм" это сколько при частичной? Если поделить на 1 человека, я столько не проживу.

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

Bootstrap-самоцель? Т.е. будем писать в том, что наваяли, или пока на немерле? Хотелось бы второе.

То, что очень хочется, но нет в немерле.
1. public override ToString():string {x} на фоне {_+_} воспринимается как издевательство. Компилер мог бы выводить много чего, кроме типа переменных. Например при вызове fun1(enum1.v1) можно пропустить enum1. если тип параметра известен. И монстрячить лес классов на C# лишь немногим сложней немерля,надо упростить синтаксис
Пример: "| ИмяКласса" внутри класса Х -> "public class ИмяКласса : X" -> варианты — частный случай
2. 100% ковариантность обобщений в любых случаях. Компилер должен приводить тип к базовому как угодно, хоть через рефлексию, но не прикидываться шарпом. Лучше сразу ориентироваться только на CLR 4.
3. Добавление, переименование и замена свойств, конструкторов, вложенных классов, статических членов, переименование и сокрытие членов при наследовании, добавка интерфейсов (сейчас есть только расширения методов).
Пример: x=null; x.ToString() -> "null"
4. Прикрутить Parallel FX. Мне производительность до лампочки, а вот полное отсутствие потокобезопасности в CLR убивает.

Полный вишлист 10 страниц мелким шрифтом займет, заземлюсь.
Такое впечалнение, что забиваю гвозди микроскопом, пытаясь городить классы в функциональном языке. Когда маленькая замкнутая лямбда решает проблему.

Есть еще дикая идея: edit-time macros, т.е. код пользовательской сборки, который может выполнятся IDE (и доступны ее потроха и редактируемый проект)
Пример: класс может обьявить дизайнер самого себя (как дизайнер WinForm и т.п.) — навороченный редактор DSL с подсветкой синтаксиса, редактор графов для визуализации состояний, рендерилку кода как в Fortress или вообще заменить "стандартный редактор" для проекта. Рефакторинг (в стандартных IDE все не предусмотришь), редактирование БД вместе с биндингом, сборка инсталлятора и заливка на сервер. Или просто кастомный IntelliSense и отображение свернутых кусков кода.
И желательно, чтобы API макросов был абстрагирован от VS, т.е. содержал лишь "обобщенное окно редактора", "доступный для редактирования кусок кода" (типа #region Designer Generated) и т.п.
Конечно, написание и отладка редакторов еще сложней, чем макросов компилятора, но зато можно сделать "языково-ориентированный" и "визуальный" язык.
Насколько это сложно, в простейшем варианте?

Может стоит сообщить про "проект Nemerle2" англоязычным, вдруг кто еще откликнется?

Да, N# звучит куда приличней для конкурента F. Надо застолбить, пока алфавит не кончился, а то пропадет.

Здравствуйте, kitsunekko, Вы писали:

[]

K>Bootstrap-самоцель? Т.е. будем писать в том, что наваяли, или пока на немерле? Хотелось бы второе.

А что с ним не так?

K>То, что очень хочется, но нет в немерле.
K>1. public override ToString():string {x} на фоне {_+_} воспринимается как издевательство. Компилер мог бы выводить много чего, кроме типа переменных. Например при вызове fun1(enum1.v1) можно пропустить enum1. если тип параметра известен. И монстрячить лес классов на C# лишь немногим сложней немерля,надо упростить синтаксис
K>Пример: "| ИмяКласса" внутри класса Х -> "public class ИмяКласса : X" -> варианты — частный случай

Вот этого не надо, спасибо.

K>2. 100% ковариантность обобщений в любых случаях. Компилер должен приводить тип к базовому как угодно, хоть через рефлексию, но не прикидываться шарпом. Лучше сразу ориентироваться только на CLR 4.
K>3. Добавление, переименование и замена свойств, конструкторов, вложенных классов, статических членов, переименование и сокрытие членов при наследовании, добавка интерфейсов (сейчас есть только расширения методов).
K>Пример: x=null; x.ToString() -> "null"

Прости, может я не настолько продвинут, но можно все что выше еще раз, но по-русски?

K>Полный вишлист 10 страниц мелким шрифтом займет, заземлюсь.

гм. может тебе это, на другой язык уйти?

K>Такое впечалнение, что забиваю гвозди микроскопом, пытаясь городить классы в функциональном языке. Когда маленькая замкнутая лямбда решает проблему.

[]

А что тебе хочется выкинуть из языка? Мне пока только определенности с макрами не хватает.

K>>Bootstrap-самоцель? Т.е. будем писать в том, что наваяли, или пока на немерле? Хотелось бы второе.
КЛ>А что с ним не так?

Просто, пока "оно" не станет лучше немерля нет смысла на него переходить. А когда оно сможет нормально скомпилить свои исходники (это ж компилер немерля, верно?) и нестрашно глючить, тогда полномасштабно перейти.

K>>Пример: "| ИмяКласса" внутри класса Х -> "public class ИмяКласса : X" -> варианты — частный случай
КЛ>Вот этого не надо, спасибо.

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

КЛ>Прости, может я не настолько продвинут, но можно все что выше еще раз, но по-русски?
x[T] -> x[object] ковариантность (или это контра-? неважно)
http://en.wikipedia.org/wiki/Extension_method
В C# 4.0 еще и свойства расширяемые. в Лиспе вроде все, что угодно.

КЛ>гм. может тебе это, на другой язык уйти?
Оный вишлист в других нереализуем

КЛ>А что тебе хочется выкинуть из языка? Мне пока только определенности с макрами не хватает.

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

Здравствуйте, kitsunekko, Вы писали:

K>>>Bootstrap-самоцель? Т.е. будем писать в том, что наваяли, или пока на немерле? Хотелось бы второе.
КЛ>>А что с ним не так?

K>Просто, пока "оно" не станет лучше немерля нет смысла на него переходить. А когда оно сможет нормально скомпилить свои исходники (это ж компилер немерля, верно?) и нестрашно глючить, тогда полномасштабно перейти.

Я не улавливаю мысль. Сейчас с бутстраппингом все нормально. Что с ним не так?

K>>>Пример: "| ИмяКласса" внутри класса Х -> "public class ИмяКласса : X" -> варианты — частный случай
КЛ>>Вот этого не надо, спасибо.

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

Расшифруй, все равно не догоняю. Что не так с синтаксисом вариантов?

КЛ>>Прости, может я не настолько продвинут, но можно все что выше еще раз, но по-русски?
K>x[T] -> x[object] ковариантность (или это контра-? неважно)

вроде ко-

K>http://en.wikipedia.org/wiki/Extension_method
K>В C# 4.0 еще и свойства расширяемые. в Лиспе вроде все, что угодно.

ну, это мелочи

КЛ>>гм. может тебе это, на другой язык уйти?
K>Оный вишлист в других нереализуем

почему же?

КЛ>>А что тебе хочется выкинуть из языка? Мне пока только определенности с макрами не хватает.

K>Мне ничего не хочется выкинуть, а просто не нравится, как реализованы отдельные куски языка, особенно содранная с C# часть синтаксиса — целиком и полностью. Может из-за макросов так сделали, не знаю.

какая именно?

Здравствуйте, VladD2, Вы писали:

Я бы тоже с удовольствием поучаствовал, но с фултаймом никак — работа,
смог бы выделять на проект часов 15-20 в неделю.

Здравствуйте, jartur, Вы писали:

J>offtopic rant follows:
J>Одного прошу, переименуйте его, а? Хотел попробовать его, но не могу я пользоваться ЯП с таким названием.
J>Может, так и назовете, N?

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

Совсем дикая идея: может денег попросить? Грант какой-нибудь, или у государства — типа инновационный проект и все такое. Назвать язык Nano, например, лол. Проект-то стоящий, не про%бизнес какой-нибудь.

Здравствуйте, Ka3a4oK, Вы писали:

KK>Здравствуйте, jartur, Вы писали:

J>>offtopic rant follows:
J>>Одного прошу, переименуйте его, а? Хотел попробовать его, но не могу я пользоваться ЯП с таким названием.
J>>Может, так и назовете, N?

KK>Согласен, я всегда чувствую неловкость пред коллегами, произнося название этого замечательного языка вслух.

А что с названием-то не так? Мне кажется абсолютно нормальным.

КЛ>Я не улавливаю мысль. Сейчас с бутстраппингом все нормально. Что с ним не так?

Т_Т
Ну что может быть "не так" с бутстрапом рабочего компилера?
Но вы же вроде НОВЫЙ копилер пишете! Того же языка (ну почти).
Если делать сразу бутстрап (т.е. повторять путь немерлистов), то нельзя использовать фичи языка, еще не реализованные (например нельзя использовать макросы в коде реализации макросов, они просто не скомпилятся, а потом опять по новой переписывать с макросами).
Вообще, мне казалось, что это очевидные ламерские рассуждения, а тут "не улавливаю мысль"

КЛ>Расшифруй, все равно не догоняю. Что не так с синтаксисом вариантов?
С ним все ОК, все идеально! Но я не могу использовать такой же синтаксис в произвольном классе (ну да, макрос пиши), только в вариантах.

КЛ>ну, это мелочи
На этих мелочах основан LINQ, и такие "мелочи" кумулятивно уменьшают код.

K>>Оный вишлист в других нереализуем
КЛ>почему же?
Ты же его не видел. и набивать 10 страниц в лом.

КЛ>какая именно?
Ну например "нелегальное положение" отступов, изобильная скобчатость, необходимость специфицировать все на свете, кроме типов, и то не всегда (нет, я не любитель уток). Еще необходимость приводить тип при любых потенциальных потерях. Точнее, нет директивы "приводи все нафиг, я в своем уме". Жесткая структура файла (например, нельзя using System.Console внутри класса или метода, namespace без скобок). Дальше еще длинный список.

Нет, я не жалуюсь, я сожру все, что дадут.

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, Вы писали:

Я вот тут о чем еще подумал. Есть на свете очень интересный язык (по крайней мере для меня) Clojure. Так вот, можно было бы потырить некоторые идеи оттуда, то есть, направленность на многопоточное программирование, это STM и Agents. Делать так же как и Clojure, все базовые структуры данных делать immutable (ведь уже так?), а если надо их шарить между потоками, использовать для этого STM.

Это могло быть еще одним фактором для популярности языка, кроме мощных макросов.

Здравствуйте, yumi, Вы писали:

Y>Я вот тут о чем еще подумал. Есть на свете очень интересный язык (по крайней мере для меня) Clojure. Так вот, можно было бы потырить некоторые идеи оттуда, то есть, направленность на многопоточное программирование, это STM и Agents.

Как я понял из описания — это диалект Лиспа работающий поверх ява-машины. Что можно взять из Лиспа мне не очень понятно. Все что можно было уже взято (макросы).

STM (software transactional memory) идея очень спорная. Пока что нет четкого мнения по поводу применимости этой идеи в реальных приложениях. Есть реализация STM для дотнета. Только она никуда не годна, так как дико тормозит. Я не думаю, что от языка нужна какая-то поддержка. Все что нужно можно сделать на основе макросов.

Agents — это видимо нечто воде Actors в Скале или процессов Эрланг. Хорошая абстракция, но для ее реализации на уровне Эрланга нужно менять не язык а виртуальную машину. А реализовать ее на уровне Скалы можно просто в виде библиотеки (даже не макро-библиотеки).

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

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

Y>Делать так же как и Clojure, все базовые структуры данных делать immutable (ведь уже так?), а если надо их шарить между потоками, использовать для этого STM.

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

Y>Это могло быть еще одним фактором для популярности языка, кроме мощных макросов.

Все это можно сделать и сейчас. Было бы кому этим заняться.

Здравствуйте, Ka3a4oK, Вы писали:

KK>Совсем дикая идея: может денег попросить? Грант какой-нибудь, или у государства — типа инновационный проект и все такое. Назвать язык Nano, например, лол. Проект-то стоящий, не про%бизнес какой-нибудь.

У кого?
К сожалению, проблема выбивания денег под проект — это отдельная и весьма сложная задача.
Выручить деньги с продажи подобного продукта не реально. Так что это может быть только меценатство основанное на желании людей пропариться или вообще по доброте души.

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

Здравствуйте, VladD2, Вы писали:

VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?

Надо же! А я все думал, когда-же немерле станет дико популярным, т.е. иначе говоря, загнется? И вот этот момент настал!

Здравствуйте, VladD2, Вы писали:

VD>Как я понял из описания — это диалект Лиспа работающий поверх ява-машины. Что можно взять из Лиспа мне не очень понятно. Все что можно было уже взято (макросы).

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

В любом случае, основной пойнт сообщения был не в этом.

VD>STM (software transactional memory) идея очень спорная. Пока что нет четкого мнения по поводу применимости этой идеи в реальных приложениях. Есть реализация STM для дотнета. Только она никуда не годна, так как дико тормозит. Я не думаю, что от языка нужна какая-то поддержка. Все что нужно можно сделать на основе макросов.

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

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

VD>Agents — это видимо нечто воде Actors в Скале или процессов Эрланг. Хорошая абстракция, но для ее реализации на уровне Эрланга нужно менять не язык а виртуальную машину. А реализовать ее на уровне Скалы можно просто в виде библиотеки (даже не макро-библиотеки).

Виртуальную машину менять не надо. Вон Clojure, не стали же менять JVM ради этого.

VD>В общем, все это можно сделать и на текущей версии Немерле. Затевать ради этого практически новый язык смысла нет.

Так же можно сказать и про Лисп, что все и так можно сделать на Common Lisp, зачем надо было писать Clojure. Ответ на этот вопрос мне кажется, гармония Мне в последнее время дико нравится Clojure именно тем, что там я ощущаю некую гармонию.

Здравствуйте, Ka3a4oK, Вы писали:

KK>Согласен, я всегда чувствую неловкость пред коллегами, произнося название этого замечательного языка вслух.
Ого! А теперь представь, что есть люди, знающие ОБЕРОН, ПИТОН, ПАСКАЛЬ и ЯВУ с АДОЙ. Страшно?

Здравствуйте, Блудов Павел, Вы писали:

БП>Ого! А теперь представь, что есть люди, знающие ОБЕРОН, ПИТОН, ПАСКАЛЬ и ЯВУ с АДОЙ. Страшно?

«Ты так говоришь, будто это что-то плохое» ☺

Здравствуйте, VladD2, Вы писали:

VD>А, не уже ли есть язык на котором писать сложнее и не удобнее чем на Лиспе? На нем и вне макр то читать код не просто. А, читать мета-код еще сложнее.

Все относительно, я после макросов Лиспа, без слез на макросы Nemerle смотреть не могу.

VD>В общем, лично я писать на Лиспе не буду. А макры прекрасно работают и в языках с синтаксисом (что Немерле и доказываем).

Дык, никто ж тебя не заставляет! Не хочешь не пиши! Насчет прекрасно работают, это спорный вопрос. Весьма весьма спорный. Сам об этом знаешь наверное.

VD>В общем, если у тебя есть желание сделать еще один Лисп, то нам не по пути.

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

Y>>В любом случае, основной пойнт сообщения был не в этом.

VD>А в чем?

Читать умеем? STM & Agents, которые я ниже приводил. Ориентированность на облегчение многопоточного программирования.

VD>Ну, так бери его и пользуйся. Следующим шагом будет переход на CL.

Я и так в Clojure пришел из CL. За Erlang-style, но со всей мощью Лиспа.

VD>Тут же речь идет о создании новой версии Немерла который на 90% по фичам и на 100% по духу будет аналогичен Немерле, но при этом не будет иметь архитектурных проблем присущих текущей реализации.

Я всего лишь хотел обратить внимание на те идеи из Clojure, которые возможно стоило бы учесть при переписывании с нуля. У меня не было желания сделать из Немерля Лисп или еще что. А теперь вообще никакого желания учавствовать в этом проекте тоже нет. Если даже просто тупо предложения пользователей так в штыки воспринимаются и даже где-то углядел наезд на Немерле То тут извини меня. Я лично умываю руки. Лучше подумаю над портированием Clojure на .NET

Здравствуйте, Mr.Cat, Вы писали:

MC>На эту тему есть замечательный пост: http://rsdn.ru/forum/message/2261047.aspx

Автор: Lazy Cjow Rhrr
Дата: 12.12.06

. Т.е. вроде как сделать concurrency в стиле эрланга — можно и в рамках обычной VM, но добиться всех бенефитов эрланга не получится. Так что тут уже исключительно маркетинговый вопрос — говорить, что многопоточность и actor model поддерживаются "внутрях самого языка" (как в Clojure) или говорить о том, что они прилеплены сбоку (как в Haskell).

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

КЛ>отступы не работают тока в интеграции (мож тебе все-таки в 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 — дуракозащищенность потрясающая. Только уже достала.

Здравствуйте, gandjustas, Вы писали:
G>Явные override и new помогают читаемости программ

Тут как с фломастерами. Кому-то нравится так, а кто-то хочет, чтобы все функции были виртуальными сразу.

Здравствуйте, yumi, Вы писали:

Y>Все относительно, я после макросов Лиспа, без слез на макросы Nemerle смотреть не могу.
Увы, в немерле код не выражается в виде удобной структуры данных. Зато скобкофобы не возмущаются.

Y>Я и так в Clojure пришел из CL. За Erlang-style, но со всей мощью Лиспа.
Кстати, а как у кложура с паттерн-матчингом? Я как-то не нашел на сайте ничего про это. Если бы у него была совместимая со scheme или CL система макросов — можно было бы портировать оный (а она вроде несовместимая?).

Y>Я всего лишь хотел обратить внимание на те идеи из Clojure, которые возможно стоило бы учесть при переписывании с нуля.
Вообще, я и многие, кого я спрашивал, не вполне понимают идею, заложенную в clojure. Т.е. с одной стороны есть агенты и стм, есть замашки на полиморфизм, и все классно, с другой — собственно язык наполнен непонятными решениями, начиная с recur и заканчивая желанием натащить в язык много всего и сразу.

Здравствуйте, yumi, Вы писали:

Y>Читать умеем? STM & Agents, которые я ниже приводил. Ориентированность на облегчение многопоточного программирования.

По этим вопросам я уже ответил. Агенты/Акторы идея хорошая, но реализуемая на имеющемся языке. Первая идея тоже реализуемая, но весьма спорная.

Но зачем мне повторять одно и то же? Я же уже это говорил.

VD>>Ну, так бери его и пользуйся. Следующим шагом будет переход на CL.

Y>Я и так в Clojure пришел из CL. За Erlang-style, но со всей мощью Лиспа.

Ну, так в чем тебя не удовлетворил мой ответ? Идея реализации Эрланговских процессов мне нравится. Реализовать их так же эффективно как в Эрнланге без изменения ВМ не удастся. Реализовать их как в Клозюре или Скале можно хоть сейчас.

Вот я уже повторился третий раз.

VD>>Тут же речь идет о создании новой версии Немерла который на 90% по фичам и на 100% по духу будет аналогичен Немерле, но при этом не будет иметь архитектурных проблем присущих текущей реализации.

Y>Я всего лишь хотел обратить внимание на те идеи из Clojure, которые возможно стоило бы учесть при переписывании с нуля. У меня не было желания сделать из Немерля Лисп или еще что. А теперь вообще никакого желания учавствовать в этом проекте тоже нет. Если даже просто тупо предложения пользователей так в штыки воспринимаются и даже где-то углядел наезд на Немерле То тут извини меня. Я лично умываю руки. Лучше подумаю над портированием Clojure на .NET

Какие штыки? Я тебе объяснил свою точку зрения. Описанные идеи далеко не в Кложуре появились. Поддерживать их на уровне языка при наличии макросов смысла нет. Тот же Кложур нибось тоже все это на макрах реализовал.

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

Здравствуйте, kitsunekko, Вы писали:

K>Текущая ситуация: авторы немерль дропнули и теперь его судьба зависит от RSDN?

Они не то чтобы дропнулись, но в реальном развитии проекта не участвуют. Только советами и мелкой административной помощью.

Так что судьба проекта действительно зависит от РСДН.

K>А если еще и Влад дропнет? Кранты?

Ну, Влад дропнется только если все совсем плохо будет (со мной).

K>"4 человекогода при фул-тайм" это сколько при частичной? Если поделить на 1 человека, я столько не проживу.

Ну, это мой расчет в котором я исходил из того, что в два раза вру со сроками. Так что оптимистичный рассчет — это 1-2 года. А вот соклько это будет в не фултаймах сказать трудно. Ведь один может по 4 часа в день плить. А другой по 4 часа в год. Если взяться скопом то может и быстро получится. Но получится ли скопом?

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

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

Надо понимать, что кому-то фичи не нужны тебе нужны, а нужные не нужны.

В прочем, список нужных и не нужных фич приветствуется!

K>Только, имхо, ничего не сдвинется, пока Влад и Ко не разберут по косточкам текущий компилятор (идеально бы припахать поляков) и распишут что и как должен делать каждый кусок.

Ну, то что делает каждый кусок и так известно.
1. Первой задачей создания нового проекта будет рефактринг исходного.
1.1. Каждый тип (кроме type и делегатов) должны уехать в отдельные файлы или даже каталоги (для partial-типов).
1.2. Должен быть произведен рефакторинг имен, чтобы в коде было проще разбираться.
1.3. Изменяем и упорядочиваем форматирование кода.

2. Далее полной определенности нет. Но есть два пути:
2.1. Берем все типы начиная с лексера и загрузчика библиотек и начинаем переписывать так как считаем нужным.
2.2. Пытаемся рефакторить по месту.

Проблема первого подхода — проект долго нельзя будет собрать сам на себе (он просто не будет компилировать код до какого-то момента).
Проблема второго подхода — сложность и связанность текущего проекта затрудняет рефакторинг и процесс рефакторинга может затянуться.

Вроде как первый подход перспективнее. Но нужно все еще раз обсудить всем миром.

K> Чтобы даже чернорабочий кодер вроде меня не плодил детских архитектурных ошибок, а взял в зубы ТЗ и не мог ничего завалить не нарушая его.
K>У меня крайне смутные представления о написании компиляторов, вам такие надо?

У всех по началу были крайне смутные сомнения. Это вопрос времени.
Кстати, есть у нас люди хорошо разбирающиеся в логике и алгоритмах используемых в Прологе? Солвер основан на них. И ешл поддержкой и развитием должен заниматься человек шарящий в этом деле.

K>Bootstrap-самоцель? Т.е. будем писать в том, что наваяли, или пока на немерле? Хотелось бы второе.

Bootstrap — это очень важно. Но при выборе пункта 1.1. бетстрапиться язык будет только после завершения всего цикла переписывания и даже позже когда код специально будет переписан с учетом изменений.
Во втором случае bootstrap будет обеспечен автоматом, но при этом резко возрастет сложность рефакторинга.

K>То, что очень хочется, но нет в немерле.
K>1. public override ToString():string {x} на фоне {_+_} воспринимается как издевательство.

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

K>Компилер мог бы выводить много чего, кроме типа переменных. Например при вызове fun1(enum1.v1) можно пропустить enum1. если тип параметра известен. И монстрячить лес классов на C# лишь немногим сложней немерля,надо упростить синтаксис
K>Пример: "| ИмяКласса" внутри класса Х -> "public class ИмяКласса : X" -> варианты — частный случай
K>2. 100% ковариантность обобщений в любых случаях. Компилер должен приводить тип к базовому как угодно, хоть через рефлексию, но не прикидываться шарпом. Лучше сразу ориентироваться только на CLR 4.
K>3. Добавление, переименование и замена свойств, конструкторов, вложенных классов, статических членов, переименование и сокрытие членов при наследовании, добавка интерфейсов (сейчас есть только расширения методов).
K>Пример: x=null; x.ToString() -> "null"

Скрывать видимые члены базовых классов не позволит дотнет. Так что не прокатит.

K>4. Прикрутить Parallel FX. Мне производительность до лампочки, а вот полное отсутствие потокобезопасности в CLR убивает.

Он и так работает.

Короче, смотри выше.

K>Полный вишлист 10 страниц мелким шрифтом займет, заземлюсь.

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

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

K>Есть еще дикая идея: edit-time macros, т.е. код пользовательской сборки, который может выполнятся IDE (и доступны ее потроха и редактируемый проект)

Это и сегодня так. Макрос работает и в компайлтайме, и в дизайнт-тайме.
Как раз одна из задач проекта — сделать так, чтобы макрос не видел разницы между ними. Если макросу нужно узнать в каком режиме он запущен, он может проверить определенное свойство. Так что даже диалог он сможет запустить, если надо.

K>Пример: класс может обьявить дизайнер самого себя (как дизайнер WinForm и т.п.) — навороченный редактор DSL с подсветкой синтаксиса, редактор графов для визуализации состояний, рендерилку кода как в Fortress или вообще заменить "стандартный редактор" для проекта. Рефакторинг (в стандартных IDE все не предусмотришь), редактирование БД вместе с биндингом, сборка инсталлятора и заливка на сервер. Или просто кастомный IntelliSense и отображение свернутых кусков кода.

Не надо мешать дизайнеры форм и компонентов для которых МС описала специальные интерфейсы и макры. Макра — это средство генерации кода. Она должна читать только исходники. Вот дизайнер для исходников может быть. Пример тому дизайнер ресурсов и макра генерирующая типизированную обертку для файла ресурсов.

K>И желательно, чтобы API макросов был абстрагирован от VS, т.е. содержал лишь "обобщенное окно редактора", "доступный для редактирования кусок кода" (типа #region Designer Generated) и т.п.

Это уже не макрос, а какой-то дизайнер компонентов.

K>Конечно, написание и отладка редакторов еще сложней, чем макросов компилятора, но зато можно сделать "языково-ориентированный" и "визуальный" язык.

Это и так можно сделать. Просто надо понять простой принцип. Редакто или дизайнер читает данные из некоторого формата (это может быть код, ХМЛ или еще что-то) и предоставляет ГУИ. Далее он записывает изменения в файл. Ну, а макрос читает данные из файла и делает свою работу — генерирует код. И при этом никакой визуальности быть не должно. Ведь макра работает во время компиляции когда никаких дизайнеров нет.

K>Насколько это сложно, в простейшем варианте?

См. выше.

K>Может стоит сообщить про "проект Nemerle2" англоязычным, вдруг кто еще откликнется?

Обязательно. Но с начало нужно зарелизить то, что есть и вообще решиться на это.

K>Да, N# звучит куда приличней для конкурента F. Надо застолбить, пока алфавит не кончился, а то пропадет.

Мне кажется, что # тут лишний. Проект уже частенько называют N. Так что или назвать его Nemerle 2.0 или просто N указав, что это диалект Nemerle.
В прочем название — это самое малое и не самое важное.

Здравствуйте, kitsunekko, Вы писали:

K>Особенно достает override, если я перекрываю виртуальный метод без new, какие еще могут быть варианты Т_Т

Знамо какой — ты случайно перекрыл метод. Частая ошибка в С++ и Яве.

Здравствуйте, kitsunekko, Вы писали:

K>C# похоже, писался с учетом опыта индийского подразделения MS — дуракозащищенность потрясающая. Только уже достала.

Ошибаются не только индусы. Так что дуракозащищенность — важная фича хорошего языка.

Здравствуйте, VladD2, Вы писали:

VD>Ошибаются не только индусы. Так что дуракозащищенность — важная фича хорошего языка.

И я бы подписался. Только опыта написания компиляторов нету.

G>Явные override и new помогают читаемости программ, также как и ref и out (сам бы компилер мог догадаться по сигнатуре).

new, ref, out — очень даже помогают, сам факт использования — событие, которое надо ометить. override ОК, всячески приветствуется, но только если компилер сам подставляет видимость/сигнатуру предка (если нет перегрузок) и т.п. балшыт. Т.е. если все чисто и потенциальных траблов не замечено компилер молчит, если замечены — предупреждение, но никак не отказ компилить. Закончу прототипирование — все почищу.

А вообще я лучше компилера знаю, что мне надо специфицировать обязательно (потому что эти спецификации для человека а не для компилера). Оптимально, чтобы обязательная спецификация включалась аттрибутом, как [CLSCompliant], а остальное на произвол кодера.

G>наверное не стоит предлагать делать Write Only язык

какой Write Only? неужели шарп возможно читать? один осмысленный токен на 10 мусора (осторожная оценка)

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

я попробую что-то сделать для себя.
ну, например

class x {y : int; z : string}  
...
def a = x(1,"abc");

нет конструктора, нет открытых членов. что это может быть, кроме как [Record]?

желаемый синтаксис

namespace n;
class x:
   this (y : int, z : string): //конструктор открытый по умолчанию
       this._y=y; this._z=z;

   _y : int; _z : string;

   public y : int:
       _y
   public z : string {_z}
   //get в топку если нет set

   override ToSring():
       $"y=$y; z=$z"

или

public:
   x, y : int;
   z : char; //тоже public
   a = 1; //тип очевиден
   ...

virtual v(){ "" } //ну я же не хочу private virtual?

XML документацию немерлисты не используют из принципа?

///ёжикоферма
class hedgehogs
{
   public this(
      h1 : string, ///имя ёжика 1
      h2 : string, ///имя ёжика 2
   )
   ...
   public CombineHedgehogs() ///сложить ежиков
   {
       ...
       /// throws ЁжикиНесовместимыException
       throw...
   }
}

а писать summary не надо

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

match e //если скобок нет, может параметр единственный?
...
def fun1()
{
   using System.Console;
   ...

зачем | не в вариантах, реальный пример...

class DataChannel
{
  |Analog
     {
         Value:double?;
         MeasUnit : string;
         override ToString() : string:
             if (Value.HasValue) $"$Value $MeasUnit"
             else "-"
         |GenericVoltage {this(v){base(v,"V")}}
         |Temperature {this(_){base(_,"*C")}}
         |Humidity {this(_){base(_,"%")}}
         .... //еще дофига
     }
  |Digital
     {
         Value:int?;
         States : array [string];
         override ToString() : string:
             if (Value.HasValue) States[Value:int]
             else "-"
         |GenericSwitch {this(_){base(_,array["on","off"])}}
         |Fan {this(_){base(_,array["stopped","forward","backward"])}}
         |Screen {this(_){base(_,array["opened","closed"])}}
         ....
     }
}

это только 3 уровня. и можно вместо class написать variant, если угодно.
конечно, можно еще 1 спецмакрос добавить, но так был бы универсальный паттерн.
а, это был просто пример, варианты — случайная жертва

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

VD>Ошибаются не только индусы. Так что дуракозащищенность — важная фича хорошего языка.

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

VD>Надо понимать, что кому-то фичи не нужны тебе нужны, а нужные не нужны.
Ну я в том смысле, что если их выкинут, мне все равно.

VD>Ну, то что делает каждый кусок и так известно.
Только тебе

K>>1. public override ToString():string {x} на фоне {_+_} воспринимается как издевательство.
VD>Не понял. Но первая задача — это не изменить язык, а сделать компилятор более модифицируемым и понятным. Так что по фичи будут добавляться или убираться толькоё если они повлияют на архитектуру и их трудно будет реализовать (удалить) потом.

расшифровываю: предусмотреть вывод сигнатур членов класса (и остального, что захочется выести). это влияет на архитектуру?
Извиняюсь, не умею внятно описывать что думаю.
из "остального" например

class a{b,c} //[Record]
class a{b()}; class c:a{b()} //b - public virtual
class a{abstract b():string}
->[ОбязателеноеПерекрытие] public virtual b(){default(string)}

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


VD>Скрывать видимые члены базовых классов не позволит дотнет.
А что, разве он остальное позволяет, кроме методов? я имел в виду средствами языка. И скрытие мне не надо, просто ради комплексного подхода. а вот переопределение методов и свойств надо (идеально чтоб на детей распространялось) — для фич типа

x:string = null; x.Length == 0;

расширений методов вполне хватает для остального.

K>>4. Прикрутить Parallel FX.
VD>Он и так работает.
Может добавить в листы и т.п. параллельные версии методов?
А может просто макросов для оберток будет достаточно. или лямбды и сами в делегаты конвертятся? тогда можно и так, мне больше и не надо.

VD>Это и сегодня так. Макрос работает и в компайлтайме, и в дизайнт-тайме.
это когда? при "микрокомпиляциях" при изменении кода (не знаю как это правильно назвать)

ладно, "макросом" это нельзя называть, я имел в виду совсем не те макросы, а аналог макроса VS.

VD>Это уже не макрос, а какой-то дизайнер компонентов.

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

VD>Это и так можно сделать. Просто надо понять простой принцип. Редакто или дизайнер читает данные из некоторого формата (это может быть код, ХМЛ или еще что-то) и предоставляет ГУИ. Далее он записывает изменения в файл. Ну, а макрос читает данные из файла и делает свою работу — генерирует код. И при этом никакой визуальности быть не должно. Ведь макра работает во время компиляции когда никаких дизайнеров нет.

Я ж как раз и хотел искореть подобный подход, неправильно только это описал.

скажем, есть свойство какого-то экзотического типа, а в описании оного типа указано, что его надо редатировать в редакторе свойств оределенным ниже редактором (уфф...)
тогда компилер автоматом подставляет свойству аттрибут
[Editor("сборка...", typeof(...Editor))]
ну или для класса — дочки дизайнабельного типа
[Designer("сборка...", typeof(...Designer))]
обязательна ли регистрация этих дизайнеров в ВС? и если да, то можно ли сделать "обобщенные редакторы", которые регистрируются с немерлем, а при вызове находят реальный редактор и предоставляют ему свои потроха?

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

или автоматом откомпилить включенные в проект файлы .cs в отдельную сборку и подключить к основной

короче, макросы для "интеграции"

такая либа может не иметь к немерлю никакого отношения, но в немерле ее проще всего написать и использовать (макросы, уже настоящие)

А какова глобальная цель и смысл данного проекта?
Допустим что с ним станет если завтро в F# появятся макросы?
Или например есть язык Boo и Rodrigo B. De Oliveirа, который я думаю не боится в случае чего остаться один и в дальнейшем развивать язык. С другой стороны есть VladD2, который не хотел бы работать над языков в одиночку. Так может имело бы смысл примкнуть к разработчикам Boo и донести до них идеи Nemerle'а? Благо там и макросы какие то есть, и вот патерн матчинг появился.

Здравствуйте, kitsunekko, Вы писали:

VD>>Ошибаются не только индусы. Так что дуракозащищенность — важная фича хорошего языка.

K>Избыточная делает дураком меня.

Защита не бывает избыточной. Главное чтобы она не мешала. Не думаю, что дно ключевое слово может помешать.
Отсутствие override в С++ довольно часто приводит к ошибкам. Это проверенный на большом количестве людей факт.
Самое же неприятное тут заключается в том, что такая ошибка может появиться в уже написанном коде. Достаточно переименовать базовый метод и все методы наследников переопределявшие его разом станут обычными (не меняющими поведения наследников). Это серьезные грабли которые с успехом обходятся введением явного переопределения.

Так что этот аспект 100% в языке останется.

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

K>И это немерль дуракозащищенный (выводит типы и находит несоответствия), а шарп просто непробиваемо тупой.

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

K>И немерль кое-где ему подражает (или я просто нецелево использую функциональный язык?)

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

K>Просто, когда я решил переехать на немерль, я понимал процесс как "перенести лес классов", отсюда и вопли в тональности "шарп 2". Сейчас уже понял, что страдаю фигней.

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

Здравствуйте, VladD2, Вы писали:

VD>Это серьезные грабли которые с успехом обходятся введением явного переопределения.

Почему это нельзя сделать опционально? Если я хочу помощи от компилятора то пишу override, а если не хочу то меня к этому никто не принуждает.

Здравствуйте, kitsunekko, Вы писали:

Почитай:
.Net – классы, компоненты и контролы

Автор(ы): Владислав Чистяков
Дата: 09.05.2003
Создание ПО из компонентов подразумевает, что компоненты будут добавляться к проекту во время разработки. При этом будет производиться их начальная настройка. Компоненты как таковые не подразумевают (вернее сказать, не обязаны иметь) пользовательского интерфейса (ни для программиста, ни для конечного пользователя). В этом качестве выступают части IDE и дополнительные программные дизайнеры. Первой компонентной средой был продукт, купленный Microsoft на заре своего существования. Впоследствии на его базе родился VB. Далее была Delphi… в общем, к концу двадцатого века компоненты стали поддерживаться почти везде (даже в Visual C++, хотя он и по сей день не очень-то визуальный).

Элементы управления Windows Forms и компоненты

Автор(ы): Илья Рыженков
Дата: 16.10.2004
Краткое руководство по созданию собственных WinForms-контролов.

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

Здравствуйте, VladD2, Вы писали:


VD>Ты хочешь, Вася не хочет. Что это будет за язык? Вместе с исходником прийдется передавать набор опций компиляции что ли, чтобы его понять можно было?
Вася написал код

class A {public virtual int Value {get;set;}}
class B:A {public override int Value {get;set;}}

Вася внес изменение

class A {public virtual int ValueNew {get;set;}}
class B:A {public override int Value {get;set;}}

Компилятор сказал Васе, что он не прав.

Я написал код

class A {public virtual int Value {get;set;}}
class B:A {public int Value {get;set;}} //override по умолчанию

Я внес изменение

class A {public virtual int ValueNew {get;set;}}
class B:A {public int Value {get;set;}}

Компилятор молчит, так как считает что я знаю что делаю.

Здравствуйте, dotneter, Вы писали:

D>А какова глобальная цель и смысл данного проекта?

1. Устранить архитектурные ошибки компилятора.
2. Сделать так чтобы компилятор проще поддавался развитию и рефакторингу, т.е. уменьшить связанность, разбить проект на модули, структурировать файлы проекта, убрать хаки.
3. Структурировать АПИ компилятора и привести имена в порядок.
4. Сделать компилятор многопоточным и ускорить его работу.

D>Допустим что с ним станет если завтро в F# появятся макросы?

F# на мой взгляд один фиг язык не для масс. Его система жизни с дотнетом совместима очень плохо. Так что я не верю, что он пойдет в массы.
Ну, а добавят в него макры, ну и что? Это будет доказательством правильности нашего пути. Потом это не такая простая задача. Сейчас, после того как Немерле и его мары сущетствуют уже 4 года мы знаем, что за проблемы там есть и как их решать. В новой версии мы их решим. А F#-щики пойдут по граблям первого Немерле. Ну, или F# превратится в Немерле, что тоже не плохо .

D>Или например есть язык Boo и Rodrigo B. De Oliveirа, который я думаю не боится в случае чего остаться один и в дальнейшем развивать язык.

Я знаю только Буу. Он, кстати потихоничку тырит из Немерле идеи, и потому прогрессирует. Его проблема в том, что он давно развивается эволюционно. А значит у него огромный груз совместимости и противоречивости.

Что такое Rodrigo B. De Oliveirа?

При весьма посредственной реализации Немерле не утратил главного — идейной целостности и чистоты. Это же есть у F#-а, но про него я уже говорил.

D> С другой стороны есть VladD2, который не хотел бы работать над языков в одиночку. Так может имело бы смысл примкнуть к разработчикам Boo и донести до них идеи Nemerle'а? Благо там и макросы какие то есть, и вот патерн матчинг появился.

Во-первых, они эти идеи и так тырят по чем зря. Их прогресс за последние годы явно зависит от потыреных идей. Погляди на их макры...

Во-вторых, мне не нравится сам язык. В Немерле на мой взгляд все довольно стройно и чисто.

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

В-четвертых, чем больше конкуренции, тем лучше. Где бы был это самый Бу если бы его авторы не драли мысли из Немерле?

Здравствуйте, VladD2, Вы писали:

VD>1. Устранить архитектурные ошибки компилятора.
VD>2. Сделать так чтобы компилятор проще поддавался развитию и рефакторингу, т.е. уменьшить связанность, разбить проект на модули, структурировать файлы проекта, убрать хаки.
VD>3. Структурировать АПИ компилятора и привести имена в порядок.
VD>4. Сделать компилятор многопоточным и ускорить его работу.
Нет, это все частности. Я хотел услышать что нибуть типа "Я и все кто будут участвовать в данном проекте, хотим потратить лет пять на написания языка с нуля для того что бы ..."

VD>F# на мой взгляд один фиг язык не для масс.
Но думаю верояные пользователи его и Nemerle сильно пересекаются.
VD>Ну, а добавят в него макры, ну и что?
Ну то что Nemerle никому не будет нужен, так как я сильно сомниваюсь что кто то препочтет фигурные скобки, продукту МС.


VD>Что такое Rodrigo B. De Oliveirа?
Это автор Boo.

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

VD>И это при том, что в наших готовый язык который перегнал Бу на много лет.

Зато по популярности Бу на много лет перегнал Nemerle. При этом еще нужно подумать что сложнее, добавить в язык фичи или добиться его популярности.
VD>В-четвертых, чем больше конкуренции, тем лучше. Где бы был это самый Бу если бы его авторы не драли мысли из Немерле?
Есть не нулейвой шанс, что они бы сами до этого додумались.

Здравствуйте, dotneter, Вы писали:

VD>>1. Устранить архитектурные ошибки компилятора.
VD>>2. Сделать так чтобы компилятор проще поддавался развитию и рефакторингу, т.е. уменьшить связанность, разбить проект на модули, структурировать файлы проекта, убрать хаки.
VD>>3. Структурировать АПИ компилятора и привести имена в порядок.
VD>>4. Сделать компилятор многопоточным и ускорить его работу.
D>Нет, это все частности. Я хотел услышать что нибуть типа "Я и все кто будут участвовать в данном проекте, хотим потратить лет пять на написания языка с нуля для того что бы ..."

Я 5 лет тратить не собирался. То что есть, то изложил. Для чего я уже раз 100 скзал. Чтобы иметь не глючынй и легко модифицируемый компилятор, плюс такую же интеграцию к нему.

Что забыл сказать, так это — "1. При переписывании надо учитывать, что код может использоваться в интеграции.".

VD>>F# на мой взгляд один фиг язык не для масс.
D>Но думаю верояные пользователи его и Nemerle сильно пересекаются.

Если Nemerle станет популярным, то вряд ли кому прийдет в голову переходить на F#. Если нет, то они будут одинаково не популярны .

VD>>Ну, а добавят в него макры, ну и что?
D>Ну то что Nemerle никому не будет нужен, так как я сильно сомниваюсь что кто то препочтет фигурные скобки, продукту МС.

А я сильно сомневаюсь, что кто-то как раз предпочтет синтаксис ОКамла. Таковые давно предпочли ОКамл или даже Хаскель.

VD>>Что такое Rodrigo B. De Oliveirа?
D>Это автор Boo.

Хм. А почему тогда "и"? (т.е. "Boo и Rodrigo").

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

Тогда бы он мог нам на мыло что-то написать.

VD>>И это при том, что в наших готовый язык который перегнал Бу на много лет.

D>Зато по популярности Бу на много лет перегнал Nemerle.

На много? Я оцениваю это "много" как ~0.

D>При этом еще нужно подумать что сложнее, добавить в язык фичи или добиться его популярности.

Сложно и то, и то. Но создать хороший язык не под силу даже владельцам миллиродов вроде MS, Sun и IBM. А вот раскрутить что-то имеющееся за деньги можно.

VD>>В-четвертых, чем больше конкуренции, тем лучше. Где бы был это самый Бу если бы его авторы не драли мысли из Немерле?
D>Есть не нулейвой шанс, что они бы сами до этого додумались.

Шанс есть всегда. Вопрос только сколько лет нужно было бы провести доходя до этого эволюционным путем.
В том же C#, авторы которого упорно не хотят смотреть по сторонам это появится еще лет через 5-7.

Здравствуйте, VladD2, Вы писали:


VD>Хм. А почему тогда "и"? (т.е. "Boo и Rodrigo").
Похоже я дальше хотел использовать выражение Nemerle и VladD2, но потом передумал.

VD>Тогда бы он мог нам на мыло что-то написать.
Ну а вы бы писал письма тем у кого столько потырил? =)

VD>На много? Я оцениваю это "много" как ~0.
Google
Boo language 9 380 000
Nemerle language 29 400

VD>Сложно и то, и то. Но создать хороший язык не под силу даже владельцам миллиродов вроде MS, Sun и IBM.
Думаю за миллиарды можно было нанять на работу кого нибудь из создателей OCaml'а или Haskell'а. Но мейнстрим к этому просто не был готов, поэтому взяли Хейлсберга.

Здравствуйте, kitsunekko, Вы писали:

VD>>Ошибаются не только индусы. Так что дуракозащищенность — важная фича хорошего языка.

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

Извините, не ужержался.
Зачем компилеру языка в IL инлайнить функции? этим и JIT неплохо занимается.
Вы видимо слишком много на C++ писали, в нем уж точно много всего неявно задается.

K>И немерль кое-где ему подражает (или я просто нецелево использую функциональный язык?)
И правильно подражает. На C# тяжело написать код, который непонтятно как работает.

Здравствуйте, VladD2, Вы писали:

VD>Проект, по моим рассчетам где-то на 4 человекогода (при фул-тайм разработке).

Я записался бы, но я ничего не умею.

VD>Ты хочешь, Вася не хочет. Что это будет за язык? Вместе с исходником прийдется передавать набор опций компиляции что ли, чтобы его понять можно было?

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

Здравствуйте, kitsunekko, Вы писали:

K>у меня перестала интеграция глючить, плюс я забыл обьекты как страшный сон (сегодня ни одного не добавил)

Что?

Здравствуйте, VladD2, Вы писали:

D>>Boo language 9 380 000
D>>Nemerle language 29 400

VD>Это как-то обсуждалось на форумах. Там какие-то размноженные цетирования. К тому же если ты хочешь найти два слова, то их в кавычках надо указывать.

VD>В общем — это не показатель. Запрос со скобками ("Boo language") дает 3 260 вхождений. А на "Lisp language" 50 700. При этом я бы не сказал, что Лисп реально популярен.

"language boo" — 4350
"language nemerle" — 2450
"language lisp" — 33700

Думаю, такое соотношение очень трудно оспорить

Здравствуйте, VladD2, Вы писали:

А>>"language boo" — 4350
А>>"language nemerle" — 2450
А>>"language lisp" — 33700

А>>Думаю, такое соотношение очень трудно оспорить

VD>Их и оспаривать бессмысленно. Это просто ничто.

Такой слепой фанатизм трудно оспорить, бесмыссленно

Здравствуйте, yumi, Вы писали:

[]

Y>Такой слепой фанатизм трудно оспорить, бесмыссленно

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

Здравствуйте, yumi, Вы писали:

А>>>"language boo" — 4350
А>>>"language nemerle" — 2450
А>>>"language lisp" — 33700

А>>>Думаю, такое соотношение очень трудно оспорить

VD>>Их и оспаривать бессмысленно. Это просто ничто.

Y>Такой слепой фанатизм трудно оспорить, бесмыссленно

Про Boo уже книги есть, например Building Domain Specific Languages in Boo. А по Немерлу, увы и ах.

Здравствуйте, Константин Л., Вы писали:

КЛ>так почему этот замечательный язык вообще никак не мелькает на rsdn? ну то-есть вообще? где популярность то?

rsdn это лишь малая часть русскоязычного коммьюнити, да и то оно тут мелькает благодаря кое-кому. А вне rsdn'a, где Nemerle? Ну на хабре пару статей видел, и все...

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, Константин Л., Вы писали:

КЛ>>так почему этот замечательный язык вообще никак не мелькает на rsdn? ну то-есть вообще? где популярность то?

Y>rsdn это лишь малая часть русскоязычного коммьюнити, да и то оно тут мелькает благодаря кое-кому. А вне rsdn'a, где Nemerle? Ну на хабре пару статей видел, и все...

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

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

Здравствуйте, Константин Л., Вы писали:

Y>>Имелось ввиду все IT community в целом. Не только русскоязычное. Среди русскоязычных, для примера есть habrahabr.ru, sql.ru, livejournal.ru.
КЛ>стоп. то-есть фраза "rsdn это лишь малая часть русскоязычного коммьюнити" не несет никакого смысла, верно?

Стоп, у кого-то плохо с логикой. Пусть все сообщество IT есть множество A. Пусть все рускоязычное множество IT есть множество B. Пусть все множество RSDN есть множество R. Очевидно, что B есть подмножество A, а в свою очередь R есть подмножество B. Я утверждал, что Nemerle "популярен" только среди множества R. Я выше приведенной фразой хотел сказать именно это, формально, то что R есть подможноство A, и B в частности.

КЛ>Поиск "boo" на rsdn

КЛ>1. net — результата
КЛ>2. declarative ~5
КЛ>3. philosophy ~15
КЛ>3. о жизни — 0
КЛ>4. ку — 0

КЛ>и это при том, что у него коммьюнити, и лет ему уже прилично. что из этого следует и так ясно, надеюсь

Да что ты ограничился этим rsdn'ом. Выше же привели подсчеты ссылок с гугла. Более репрезентативная выборка. А то и я тут каждый день могу про Boo на rsdn'е фразу говорить, скажешь Boo здесь популярен станет?

КЛ>>>кстати, при чем здесь популярность бу? в чем поинт?

Пойнт еще раз, вот он:
Y>>Пойнт был в том, что кое-кого не будем показывать пальцами, совсем ослепил фанатизм, что кое-кто не в состоянии воспринять тот факт, что Nemerle менее популярен, чем Boo и Lisp. Все.

КЛ>скажем так, они все очень непопулярны, и зачем это тереть на протяжении всего топика не ясно. Какой в этом глубокий смысл?

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

Здравствуйте, Константин Л., Вы писали:

КЛ> так что там с популярностью бу?
Например мне, далекому от бу человеку, известно что он используется в Castle Project, есть ViewEngine в MVC Contrib, есть поддержка в SharpDevelop, и есть книжка. Про Nemerle я слышал раз в 10 больше, но единственно что могу сказать что у него есть интеграция.

Здравствуйте, VladD2, Вы писали:

VD>У меня своя голова не плечах и когда я вижу черное, то называю это черным, а когда вижу белое, называют это белым. Если кто-то думает, что это фанатизм, ну и бог с ним. Слепой, так слепой. Фанатизм, так фанатизм.
Дальтонизм, так дальтонизм...

Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Константин Л., Вы писали:

КЛ>> так что там с популярностью бу?
D>Например мне, далекому от бу человеку, известно что он используется в Castle Project, есть ViewEngine в MVC Contrib, есть поддержка в SharpDevelop, и есть книжка. Про Nemerle я слышал раз в 10 больше, но единственно что могу сказать что у него есть интеграция.

Ну, дык у одного есть поддержка в ШарпДевелоп у другого в Студии. У одного есть статьи, у другого книжка.
Дай денег и я тебе тоже книжку издам.

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

Здравствуйте, VoidEx, Вы писали:

VD>>У меня своя голова не плечах и когда я вижу черное, то называю это черным, а когда вижу белое, называют это белым. Если кто-то думает, что это фанатизм, ну и бог с ним. Слепой, так слепой. Фанатизм, так фанатизм.
VE>Дальтонизм, так дальтонизм...

Да хоть в лоб, хоть пол лбу.

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

Вот что ты в этот форум ходишь? Какой смысл? Сам Немерле вроде бы использовать не хочешь. Другим помочь не можешь. Но приходишь сюда и тролишь, тролишь, тролишь...

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, VoidEx, Вы писали:

VD>>>У меня своя голова не плечах и когда я вижу черное, то называю это черным, а когда вижу белое, называют это белым. Если кто-то думает, что это фанатизм, ну и бог с ним. Слепой, так слепой. Фанатизм, так фанатизм.
VE>>Дальтонизм, так дальтонизм...

VD>Да хоть в лоб, хоть пол лбу.
Не, ну если ты что-то видишь белым, зовёшь белым, а оно не белое, то проблемы явно не у других

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


VD>Вот что ты в этот форум ходишь? Какой смысл? Сам Немерле вроде бы использовать не хочешь. Другим помочь не можешь. Но приходишь сюда и тролишь, тролишь, тролишь...
Наблюдаю. У меня такое времяпрепровождение вместо просмотра фильма. Кстати, если бы на работе сказали "писай на шарпах", я бы таки взял Немерле (хотя в скором времени уже скорее F#), так что мало ли. И интересно, со своей манерой поведения ты многих таки склонишь помогать тебе? У меня подозрение, что то, что "все нихрена не делают, только я", это закономерность, не в обиду.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, VoidEx, Вы писали:

Возможно, даже соглашусь.
Правда RSDN'ом мир не кончается, но за его пределами видно лишь то, что не затухло, а более-менее пробилось.

K>>у меня перестала интеграция глючить, плюс я забыл обьекты как страшный сон (сегодня ни одного не добавил)
VD>Что?
Ничего, все идеально, только неудобно списки кортежей использовать. Или безымянные классы надо добавить, или имена в кортежах. А в идеале указывать имена при обьявлении типа

list[time:TimeSpan*text:string] //безымянный класс

и чтобы кортежи автоматом приводились

VD>Только я считаю, что для языка намного важнее иметь полноценную и безглючную реализациию. Люди отваливают от языка не потому, что про него нет книжек, а потому, что им не удается формочку склепать на нем, в отладчике проблемы и Интеграция глючит.
кстати, о формочках. при попытке использовать скрипты в асп <%...%> компилер говорит, что он такого не умеет.
никому не надо было или уперлось в траблы?

Здравствуйте, kitsunekko, Вы писали:

K>кстати, о формочках. при попытке использовать скрипты в асп <%...%> компилер говорит, что он такого не умеет.
K>никому не надо было или уперлось в траблы?

Вроде все ок. Опиши более детально.

A>Вроде все ок. Опиши более детально.
Parser Error: Snippet Statements are not supported in Nemerle language
это асп выдает при запуске

<form id="menuform" method="get" action="Search.aspx" >
<a href="Default.aspx">Home</a>
<span  style="white-space: nowrap;  " >
<input id="SearchField" type="text" name="q" value="<%=FillSearchBox()%>" class="search" />
<input type="submit" value="Search" id="Search1" class="submit" />
</span>            
</form>

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

Здравствуйте, Блудов Павел, Вы писали:
здесь

Автор: kitsunekko
Дата: 09.02.09

нарисовалась ошибка с ASP.Net.

    <%=DateTime.Now %>

Parser Error Message: Snippet Statements are not supported in Nemerle language.

Насколько я помню это к тебе.

Здравствуйте, FR, Вы писали:

FR>То есть решили пойти той же дорожкой что и D?
FR>У них это прилично затянулось от планировавашегося.

Как раз наоборот. Задача не рефакторинг языка, а рефакторинг компилятора.

Здравствуйте, kitsunekko, Вы писали:

K>Ничего, все идеально, только неудобно списки кортежей использовать. Или безымянные классы надо добавить, или имена в кортежах. А в идеале указывать имена при обьявлении типа
K>

K>list[time:TimeSpan*text:string] //безымянный класс
K>

K>и чтобы кортежи автоматом приводились

Собственно вопрос где хранить такие имена. С анонимными типами проблема одна — они будут локальны для каждой сборки. Отсюда, как и в Шарпе их нельзя будет экспортировать.

VD>Собственно вопрос где хранить такие имена.
Хотелось бы чтобы так

[Record]class _c123 {time:...}

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

VD>С анонимными типами проблема одна — они будут локальны для каждой сборки. Отсюда, как и в Шарпе их нельзя будет экспортировать.
Это как раз и отлично, пускай будут internal. не могу придумать, зачем может понадобиться их экспортировать.
А еще можно инициализаторы объектов как в шарпе, типа такого?

def tb = TextBox()
{
    Text = "abc";
    ...
}

Здравствуйте, alvas, Вы писали:

A>Насколько я помню это к тебе.
Asp.Net никогда толком не работал. Если довести до ума FileCodeModel (дед бил-бил, баба била) то он заработает на том уровне, на котором работает IronPython.
Не ахти, но лучше чем ничего. В VS2010 обещали сделать нормальную поддержку asp.net для 3r party languages.

Здравствуйте, Блудов Павел, Вы писали:

БП>Не ахти, но лучше чем ничего. В VS2010 обещали сделать нормальную поддержку asp.net для 3r party languages.

Можно ссылочку?

Здравствуйте, VladD2, Вы писали:

VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?

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

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

Здравствуйте, VladD2, Вы писали:

VD>Можно ссылочку?
Поищу. На вскидку это было в форуме мычб народ спрашивал почему у питона так плохо с asp.net, им ответили что на сегоняшний момент лучше не получится.

Здравствуйте, Блудов Павел, Вы писали:

БП>Поищу. На вскидку это было в форуме мычб народ спрашивал почему у питона так плохо с asp.net, им ответили что на сегоняшний момент лучше не получится.

У вроде все ок. здесь

<p><%= "Hello World from an inline Boo expression!" %></p>

<p>3*4 is: <b><%= 3 * 4 %></b></p>

Здравствуйте, alvas, Вы писали:

У boo вроде все ок.

Здравствуйте, VladD2, Вы писали:

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

Здравствуйте, SergASh, Вы писали:

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

В этом нет никаких сомнений. К тому же автры никуда не пропали. Да и трудные для понимания вещи неплохо описаны в статьях.

Здравствуйте, kitsunekko, Вы писали:

VD>>Собственно вопрос где хранить такие имена.
K>Хотелось бы чтобы так
K>

K>[Record]class _c123 {time:...}
K>

Это описание полноценного класса. Это и так есть.

K>Для кортежей наверно неудобно имена использовать, если они в 5 местах из функции возвращаются. А в типе функции наверное можно обьявить имена, и чтоб возвращаемые кортежи приводились.

VD>>С анонимными типами проблема одна — они будут локальны для каждой сборки. Отсюда, как и в Шарпе их нельзя будет экспортировать.
K>Это как раз и отлично, пускай будут internal. не могу придумать, зачем может понадобиться их экспортировать.

Многие будут удивлены тем, что они могут создать internal и private метод, а public и protected не могут.

K>А еще можно инициализаторы объектов как в шарпе, типа такого?
K>

K>def tb = TextBox()
K>{
K>    Text = "abc";
K>    ...
K>}
K>

Это можно сделать макросом. Например, можно сделать макрос with:

def tb = with (TextBox())
{
    Text = "abc";
    ...
}

Но тут есть один идеологический аспект. Это будет провцировать людей создавать изменяемые (императивные) типы. В Nemerle намного удобнее описать объект через конструктор. При этом можно задачать имена параметров.

Здравствуйте, VladD2, Вы писали:

VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?

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

Здравствуйте, goosevan, Вы писали:

G>Я бы подписался но, к сожалению, не фулл-тайм. И в текущем коде, надо признаться, разбираюсь слабо.

Фулл-тайм без денег вообще не реально. Тут все, как говорится, без отрыва от стужи (с) Райкин.

Здравствуйте, VladD2, Вы писали:

VD>Если бы вдруг открылась запись в добровольцы на проект Nemerle2 или сокращенно "N", то кто бы подписался участвовать в нем?

VD>Задачи:
VD>1. Переосмыслить фичи Немерле. Оставить только те что не вызывают серьезных конфликтов с другими фичами языка или Интеграции.
VD>2. Переписать компилятор Немерле с нуля учитывая требования накладываемые интеграцией, производительности компилятора, модульности, легкой поддержки и т.п.
VD>3. Написать Интеграцию языка со студией.
VD>4. При всем при этом не наделать ошибок сделанных поляками.

VD>Проект, по моим рассчетам где-то на 4 человекогода (при фул-тайм разработке).

Тема еще жива?

Здравствуйте, eag, Вы писали:

eag>Тема еще жива?

Жива.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eag, Вы писали:

eag>>Тема еще жива?

VD>Жива.

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

Здравствуйте, eag, Вы писали:

eag>Тогда я заинересован. Могу бы взять небольшую задачку для пробы, так сказать

Тогда лучше всего связаться со мной по Skype и обсудить этот вопрос. Мое имя в скайпе VladD2.

Здравствуйте, VladD2, Вы писали:

БП>>Не ахти, но лучше чем ничего. В VS2010 обещали сделать нормальную поддержку asp.net для 3r party languages.
VD>Можно ссылочку?

Вот ссылка http://www.asp.net/DynamicLanguages/whitepaper/ на проблемы IronPython

Здравствуйте, VladD2, Вы писали:

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

Если б кое-кто не брезговал простыми ГНУтыми вещами вроде ШарпДевелоп, то может быть эти люди с самого начала изучали бы не Бу, а Немерле.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Если б кое-кто не брезговал простыми ГНУтыми вещами вроде ШарпДевелоп, то может быть эти люди с самого начала изучали бы не Бу, а Немерле.

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

Здравствуйте, VladD2, Вы писали:

ВВ>>Если б кое-кто не брезговал простыми ГНУтыми вещами вроде ШарпДевелоп, то может быть эти люди с самого начала изучали бы не Бу, а Немерле.
VD>Никто и не брезгует.

А мне казалось, что ты его просто не любишь

VD>Просто я не стожильный, чтобы взваливать на себя еще один проект.

Это я понимаю. Просто при всей своей, скажем так, "недо-студийности" #D хорош наличием определенного комьюнити. Т.е. интеграция со студией — это бесспорно хорошо, но благодаря ней народ о Немерле не узнает. Ибо чтобы узнать об интеграции, надо сначала узнать о Немерле. А вот с шарп-девелопом не так — скачал новую версию, смотришь, а там язык новый добавился — 99% хотя бы из любопытства создадут тестовый проект. А там уж как пойдет.
Я вот, например, таким образом узнал о Бу.

VD>Сама интеграция пишется, так чтобы ее было максимально просто перенести на другие IDE.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А мне казалось, что ты его просто не любишь

Я им просо не пользуюсь потому-что пользуюсь студией.

VD>>Просто я не стожильный, чтобы взваливать на себя еще один проект.

ВВ>Это я понимаю. Просто при всей своей, скажем так, "недо-студийности" #D хорош наличием определенного комьюнити. Т.е. интеграция со студией — это бесспорно хорошо, но благодаря ней народ о Немерле не узнает. Ибо чтобы узнать об интеграции, надо сначала узнать о Немерле. А вот с шарп-девелопом не так — скачал новую версию, смотришь, а там язык новый добавился — 99% хотя бы из любопытства создадут тестовый проект. А там уж как пойдет.

У меня даже нет особых сомнений, что кто хотел уже узнал о Немерле. Вопрос скорее в другом. Почему толпы народу на него не переходят. На то есть много разных ответов. Это и отсутствие волосатой лапы (багатой), и отсутствие релиза, и отсутствие устойчивой и качественной IDE, и отсутствие исчерпывающей спецификации и мгого чего еще. Я по мере своих сил способствую устранению некоторых из причин.

ВВ>Я вот, например, таким образом узнал о Бу.

Здорово. Пишешь на нем что-нибудь?

ЗЫ

Взял бы да помог прикрутить Немерле к ШарпДевелоп-у. Я бы мог объяснить куда копать...

Здравствуйте, VladD2, Вы писали:

VD>У меня даже нет особых сомнений, что кто хотел уже узнал о Немерле.

На РСДН — да. А за пределами РСДН — откуда?

VD>Вопрос скорее в другом. Почему толпы народу на него не переходят. На то есть много разных ответов. Это и отсутствие волосатой лапы (багатой), и отсутствие релиза, и отсутствие устойчивой и качественной IDE, и отсутствие исчерпывающей спецификации и мгого чего еще. Я по мере своих сил способствую устранению некоторых из причин.
ВВ>>Я вот, например, таким образом узнал о Бу.
VD>Здорово. Пишешь на нем что-нибудь?

Да не особо. Как-то он не впечатлил меня сильно. С другой стороны если бы он мне попался *до* Немерле интереса могло бы быть и побольше.

VD>ЗЫ
VD>Взял бы да помог прикрутить Немерле к ШарпДевелоп-у. Я бы мог объяснить куда копать...

Честно, не могу обещать. Времени свободного сейчас очень мало. Но надо посмотреть. У меня почему-то сидит в мозгах мысль, что биндинги для языков в ШарпДевелопе довольно просто делаются.

Здравствуйте, Воронков Василий, Вы писали:

VD>>У меня даже нет особых сомнений, что кто хотел уже узнал о Немерле.

ВВ>На РСДН — да. А за пределами РСДН — откуда?

Сходи на Хабр, поиск по ключевому слову 'nemerle'.