Re: А кто записался бы в добровольцы?... - Nemerle

Здравствуйте, 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'а? Благо там и макросы какие то есть, и вот патерн матчинг появился.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

Почитай:
.Net – классы, компоненты и контролы
Элементы управления Windows Forms и компоненты

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

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

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

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

Здравствуйте, 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;}}

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, 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>В-четвертых, чем больше конкуренции, тем лучше. Где бы был это самый Бу если бы его авторы не драли мысли из Немерле?
Есть не нулейвой шанс, что они бы сами до этого додумались.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, 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.

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	06.02.09 12:40
Оценка:	1 (1) +2

	От:	Mr.Cat
	Дата:	06.02.09 16:25
	Оценка:

	От:	Mr.Cat
	Дата:	06.02.09 16:48
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	06.02.09 17:48
Оценка:

От:	VladD2	www.nemerle.org
Дата:	06.02.09 18:29
Оценка:

	От:	kitsunekko
	Дата:	07.02.09 09:08
	Оценка:

	От:	dotneter
	Дата:	07.02.09 10:16
	Оценка:

	От:	dotneter
	Дата:	07.02.09 11:13
	Оценка:

	От:	dotneter
	Дата:	07.02.09 11:42
	Оценка: