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

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

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

G>Я уверен что при желании сделать деньги на RSDN и наличии организованности внутри команды у вас бы все получилось — дело скорее в том, что у вас это никому нахрен не надо, и это первично, а не деньги. То есть дело не в деньгах, а в желании.

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

G>Вот я вам, например, предлагал купить лицензию на движок вашего форума.

Ну, и куда ты делся после первого вопроса?

G>И не только я.

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

G>Выяснилось, что сделать это невозможно, и всем похрен.

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

G> При этом, вы жалуетесь на недостаток ресурсов для развития сайта,

Где? Мы не жалуемся.

G>продавать его не хотите, но и в open source вы ни под какой лицензией его класть тоже не хотите — хотя могли бы выложить его под двойной лицензией — GPL + коммерческая.

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

G>Короче, Влад, мне кажется, деньги вам не нужны. И в контексте ситуации вокруг Немерле — это скорее плохо, чем хорошо. Потому, что ваша мотивация не сфокусирована и в большей части определяется сиюминутными интересами учатсников. Хочу подчеркнуть — это мое впечатление, я не собираюсь его никому навязывать и не хочу никого обидеть или обвинять в чем-то. Я в данный момент стараюсь быть честным.

Мне откровенно говоря нечего добавить. Повторюсь еще раз и замнем этот вопрос.
На доводку Немерла до состояния полного конкурента скажем C# нужно не менее $500 000 и год времени. Денег этих у меня нет. Спонсоров тоже на горизонте нет. Хейльберг просто тупо панически боится таких мощьных вещей как макросов. Так боится, что даже посмотреть на Немерле не захотил.

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

G>>>С этим я безусловно согласен. Немерле — это отличный опыт, практически доказывающий, что возможно мягкое введение концепций ФП в мэйнстримовые языки. Примерно, как это было сделано с С, С++, и ООП. Важность Немерле с этой точки зрения сложно переоценить.

VD>>В общем, то концепции ООП он тоже туда вводит. Тут он конечно не один. Есть скала, да и Шарп подтягивается. Но лично мне ждать пока МС или Сан дорастут скажем до паттер-матчинга или сделает чтобы все стрэйтменты можно было в выражениях использовать я не хочу. Боюсь, что столько не проживу.

G>Думаю, кстати, проживешь. Ведь МС зачем-то взял разработчиков Немерле на работу — это не просто так. Языки типа Немерле и Scala являются источником вдохновения для разработчиков C#. Это по сути исследовательские языки, на которых проходят апробацию новые концепции. Единственное — у них есть понятие learning curve. Однако, они теперь могут запускать и параллельные ветки — F# же они включили в список поддерживаемых языков. Я уверен, что Немерле гораздо лучше F# приспособлен к современным реалиям, потому что это не калька с известного языка, а творческая и удачная переработка. По своей значимости он похож на С++ — обеспечивает мягкое введение в новый мир. Однако, без поддержки майкрософта — здесь мне кажется мало что может произойти.

G>То есть, сценария у нас три, и они не являются взаимоисключающими.
G>1) Один из поддерживаемых языков платформы С# или F# приобретает наиболее удачные свойства Немерле, приближаясь к нему.
G>2) Немерле с некоторыми модификациями становится одним из официальных языков платформы .NET
G>3) Про Немерле все забывают. R.I.P.

G>При данном раскладе — я бы просто подождал, что произойдет дальше. А на вашем месте — попытался бы получить финансирование данных работ от Microsoft Research, как они делали с F#. Если вы, конечно, серьезно настроены. Возможно, у вас есть другой план действий — так озвучте его, чтобы народ успокоить, вдохновить, и вселить в их сердца надежду. А пока — как очень метко сказал GlebZ, ваш шкаф зело похож на гроб, а его ручка — на красивую ошибку природы.

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

G>То есть, сценария у нас три, и они не являются взаимоисключающими.
G>1) Один из поддерживаемых языков платформы С# или F# приобретает наиболее удачные свойства Немерле, приближаясь к нему.

F# никогда не будет мыэйнстримом. Ну, разве что Хаскель переплюнет.
С# уже получил огромный пинок в перед. Думаю и дальше будет развиваться. Жаль в нем исходно много ошибок из-за идеологического родстава с С.

G>2) Немерле с некоторыми модификациями становится одним из официальных языков платформы .NET
G>3) Про Немерле все забывают. R.I.P.

Есть еще 4. Будет постепенно развиваться и станет языком для тех кто не так богат чтобы писать на С++ (т.е. годами и с мылом на заднице), но не так глуп чтобы пытаться забороть индокодеров шапкозакидательством.

G>При данном раскладе — я бы просто подождал, что произойдет дальше. А на вашем месте — попытался бы получить финансирование данных работ от Microsoft Research, как они делали с F#. Если вы, конечно, серьезно настроены. Возможно, у вас есть другой план действий — так озвучте его, чтобы народ успокоить, вдохновить, и вселить в их сердца надежду. А пока — как очень метко сказал GlebZ, ваш шкаф зело похож на гроб, а его ручка — на красивую ошибку природы.

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

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

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

AVK>>А native совершенно не обязателен, как показывает практика. Впрочем, mono --aot и флаг вам в руки

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

AVK пропагандирует интерпретируемые языки, вроде Эрланга? Добро пожаловать в клуб, AVK!

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

G>AVK пропагандирует интерпретируемые языки, вроде Эрланга? Добро пожаловать в клуб, AVK!

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

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


G>JIT-компилятор Java на моно, транслирующий java байт-код в CLR? Интересный подход.
G>1) А как у нас, интересно, будет выглядеть интероп с каким-нибудь Java Application Server, где своя VM? Подмена VM не всегда канает.
G>2) Крайне любопытно, правда — неужели там сборщик мусора научился подбирать неиспользуемые Java классы, и у нас будет реально работать свой classloader (гранулярность загрузки/выгрузки — класс)? Что-то сомневаюсь — не умел такого делать CLR by design. А без этой штуки application-сервера и Java приложения с активным скриптингом в продакшне лучше не пускать. А это весьма приятное свойство Java, одно из его основных отличий от .NET.

В дотнете всякие компилируемые скрипты обычно в temporary-доменах гоняют.

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


G>Так что такие разговоры — скорее умный маркетинговый ход. Когда увижу, что джит убедительно обойдет IC++ на приложениях вроде SPEC — тогда можно будет отнестись к тому серьезно. Я думаю, так.

Не обойдёт никогда. Я плотно занимаюсь процессингом сигналов, так вот, .Net сливает заметно. ИМХО, основная причина слива — это постоянная проверка выхода за границы массива. Т.к. вся обработка сигналов — это переливание из буферов в буфера с обработкой, учитывая, что математическая составляющая обработки тривиальна, и не может быть сильно загублена JIT-ом, то вот в этих проверках выхода за пределы и кроется главный тормоз.

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

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

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


K>Мне внутренний голос подсказывает, что за этим майевтическим вопросом последует целый квазиплатоновский диалог, в ходе которого сначала мы придем к выводу о том, что лучше было бы представлять AST в синтаксисах разной степени легковесности, а потом перейдем к обсуждению SymADE. Я правильно догадался?

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

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

V>Кстати, я в курсе про оптимизацию проверки выхода за границу, но прикол в том, что кол-во элементов в буфере, подлежащих обработке, не всегда соответствует размеру буфера, т.е. хранится в доп. переменной, что делает невозможной подобную оптимизацию.

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

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

V>Офигеть, спасибо за упоминание интересного проекта. Еще лет 5 назад с одним известным здесь товарищем пришли к выводу, что программирование должно уходить от конкретных типов в сторону параметризации, от текстового представления в сторону некоего семантического графа.

Эта "гениальная" мысль приходит в голову почти всем программерам поначалу.

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

AVK>Эта "гениальная" мысль приходит в голову почти всем программерам поначалу.
Во-во... только если еще немного подумать понимаешь что текст + IDE которая все парсит на лету заруливают все эти семантические графы на раз.

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

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


G>>JIT-компилятор Java на моно, транслирующий java байт-код в CLR? Интересный подход.
G>>1) А как у нас, интересно, будет выглядеть интероп с каким-нибудь Java Application Server, где своя VM? Подмена VM не всегда канает.
G>>2) Крайне любопытно, правда — неужели там сборщик мусора научился подбирать неиспользуемые Java классы, и у нас будет реально работать свой classloader (гранулярность загрузки/выгрузки — класс)? Что-то сомневаюсь — не умел такого делать CLR by design. А без этой штуки application-сервера и Java приложения с активным скриптингом в продакшне лучше не пускать. А это весьма приятное свойство Java, одно из его основных отличий от .NET.

V>В дотнете всякие компилируемые скрипты обычно в temporary-доменах гоняют.

Я это знаю. А в Java — нет, там можно любой класс подгрузить в динамике. Чем активно пользуются все приложения, которые используют скриптинг. Я бы с удовольствием посмотрел, как такое приложение заработает на .NET-машине. Взять, скажем, веб-браузер какой-нибудь.

Уж не говоря о том, что при отдельном домене мы налетаем на маршалинг данных, что для многих сценариев скриптинга очень дорого.

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


G>Я это знаю. А в Java — нет, там можно любой класс подгрузить в динамике. Чем активно пользуются все приложения, которые используют скриптинг. Я бы с удовольствием посмотрел, как такое приложение заработает на .NET-машине. Взять, скажем, веб-браузер какой-нибудь.

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


G>Уж не говоря о том, что при отдельном домене мы налетаем на маршалинг данных, что для многих сценариев скриптинга очень дорого.

Хе, мы на маршаллинг в любом случае налетаем, т.к. обработка GUI-событий и исполнение скриптов идут в разных тредах. А "внутри" скопиллированного скрипта зачем маршаллинг?

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


V>>Кстати, я в курсе про оптимизацию проверки выхода за границу, но прикол в том, что кол-во элементов в буфере, подлежащих обработке, не всегда соответствует размеру буфера, т.е. хранится в доп. переменной, что делает невозможной подобную оптимизацию.

AVK>Не делает невозможным, а затрудняет. Теоретически JIT вполне может определить, что эта самая переменная внутри цикла не меняется, следовательно можно не проверять каждую итерацию.

Мы экспериментировали с этим, из поля класса копировали значение в локальную переменную, с которой и сравнивали счётчик цикла — практически никаких результатов, т.е. современный runtime к этому не готов, к сожалению. И такая ситуация, насколько я понимаю, продлится как минимум до 4.0, и то неизвестно как подобный момент будет решён. А он, вообще-то, краеугольный в плане быстродействия. Всё, что не касается доступа к массивам, JIT компиллирует вполне оптимально, и только этот момент мешает делать на дотнете адекватные "числодробилки".

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


V>>Офигеть, спасибо за упоминание интересного проекта. Еще лет 5 назад с одним известным здесь товарищем пришли к выводу, что программирование должно уходить от конкретных типов в сторону параметризации, от текстового представления в сторону некоего семантического графа.

AVK>Эта "гениальная" мысль приходит в голову почти всем программерам поначалу.

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

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

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

AVK>>Эта "гениальная" мысль приходит в голову почти всем программерам поначалу.
WH>Во-во... только если еще немного подумать понимаешь что текст + IDE которая все парсит на лету заруливают все эти семантические графы на раз.

Это ты как определил? Тебе уже было с чем сравнить?
Я вот даже с самым крутым IDE не могу избавиться от ощущения постоянной обезъяней работы, причём везде, начиная от проектирования, и заканчивая кодированием.

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

V>Ну... после 12-тилетнего опыта (на тот момент) и двух десятков используемых языков — это мало похоже на начало.

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

V> Оно приходит, когда надоедает чувство постоянного дежавю.

А у меня вот нет такого постоянного чувства. Что я делаю не так?

V>Одно время я плотно проходился по исходникам всякого опен сорса — не мог избавиться от ощущения, что все делают одно и то же, различия лишь на самом высоком уровне и составляют дай бог 10-20 процентов от общих трудозатрат (а то и меньше).

И при чем здесь текстовая форма представления исходников?

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

V>Это ты как определил? Тебе уже было с чем сравнить?

А ты думаешь что такого еще ни разу реализовано не было? Сразу, навскидку — смоллток, GuptaSQL.

V>Я вот даже с самым крутым IDE не могу избавиться от ощущения постоянной обезъяней работы, причём везде, начиная от проектирования, и заканчивая кодированием.

И в этом, конечно, виноваты текстовые исходники. Что то я мысль не уловил.

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


V>>Я вот даже с самым крутым IDE не могу избавиться от ощущения постоянной обезъяней работы, причём везде, начиная от проектирования, и заканчивая кодированием.

AVK>И в этом, конечно, виноваты текстовые исходники. Что то я мысль не уловил.

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

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


V>> Оно приходит, когда надоедает чувство постоянного дежавю.

AVK>А у меня вот нет такого постоянного чувства. Что я делаю не так?

Ну, может умеешь забывать детали прошлых проектов.


V>>Одно время я плотно проходился по исходникам всякого опен сорса — не мог избавиться от ощущения, что все делают одно и то же, различия лишь на самом высоком уровне и составляют дай бог 10-20 процентов от общих трудозатрат (а то и меньше).

AVK>И при чем здесь текстовая форма представления исходников?

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

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

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

Это все понятно, идеал недостижим. Но я все еще про текст vs бинарное AST.

V> Вот и хочется взамен библиотек кода иметь параметризуемые библиотеки идей/шаблонов. (Rational и прочее смотрю регулярно)

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