Здравствуйте, eao197, Вы писали:
E>По поводу смерти какого-либо языка я вообще не испытываю радости. Т.к. за этим стоит работа по переносу продуктов, написанных на этом языке, на другие платформы. Мы вынуждены повторять функциональность вместо того, чтобы развивать ее.
Для сарказма — нет смайлика
E>Меня интересует другое. Когда Nemerle дойдет до состояния, после которого на нем можно будет писать код коммерческих продуктов? Не получится ли так, что написав для версии 0.9.2 пару сотен килобайт макросов, я обнаружу, что половина из них требует переделки в версии 0.10.3.
E>Другой вопрос: будет ли Nemerle одинаковым под .NET от MS и Mono? Кроссплатформенность для меня важна.
E>Без ответов на эти вопросы разговоры о Nemerle -- это академические рассуждения.
ИМХО — без десятка использований в коммерческих продуктах, или гораздо большего кол-ва в опен соурс — ИМХО это Академические рассуждения.
Ибо разработчики языка — должны свыкнутся с ыслью, что их чудесный язык используется в коммерческих целях.
Здравствуйте, Programmierer AG, Вы писали:
VD>>Кстати, а как у Хаскелевского подхода с модульносью и компонентностью? PA>Честно говоря, не копенгаген. Есть интеграция с COM и C: PA>http://www.haskell.org/hdirect/
Да фиг бы с ней, с интеграцией. Я вообще о компонетном подходе. О динамической загрузке молулей. О возможности создавния на безе Хаскеля визуальных редакторов. О плагинах и т.п...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Понятно, что это в Ruby с динамической типизацией возможно сменить в inject-е тип объекта с Hash на Array и не заметить этого. Но, если бы был inject([]), то тогда вообще несоответствия типов не обнаружилось бы.
Видимо фигово понятно. Ты же программировал на С++ и должен уметь предстваить, что будет когда в действительно статически типизированном языке в одном месте не врено меняется тип. Ведь на тип влияет не одно место. Такая ошибка обязательно где-нибудь вылезет!
К тому же в Немерле ты сразу получишь как минимум предеждение еще в первой версии, так как в нем нельзя совмещать присвоение котормы делается помещение в хэш таблицу и возврат значения. Но это уже так... дополнительный контроль. А вот выод типов действительно рулит.
VD>>Хм. А если ты для объявленной ранее переменной такую же фигню сморозить, то разбираться тебе не прийдется? Так же пойдешь искать источник проблемы.
E>Нет, не пойду, компилятор мне точное место укажет.
А какое из них ошибка? Может ты как раз забыл ко всему прочему еще и тип переменной сменить?
Кстати, а если тпип typedef-ом задан?
E>Мне интересно, как поведет себя Nemerle, если я допущу ошибку в реализации макроса.
Смотря какую. Думаю можно найти место в котором он очень нехорошо себя поведет. Уж больно мощьные возможности он предоставляет. Но тут надо понимать, что чересь за макросы ты становишся соавтором компилятора. А так же то, что ты все равно в лучших условиях чем когда пыташся заняться метапрограммированием скажем на шаблонах С++.
E>4. Люди, не доверяющие массированной рекламе и думающие, что серебрянной пули не существует.
Это как раз я. Но такие люди умеют отбросить свои предрассутки и оценить прогрессивное новое. Или ты все о тех кто вообще ничему новому не доверяет?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Да хотя бы тем, что в нем есть практически все, что есть в C# 2.0, много чего из языков семейства ML, да еще и макросы.
За исключением Nulable-типов на сегодня есть вроде бы все. Так что можно опускать слово "практически".
Сделали даже итерататоры хотя в языке и так уже была линивая семантика передачи параметров.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И не нужно забывать, что Нэмерл впитал в себя все антиграбельные технологии C#. А так же умудрился избавиться от некоторых грабель C#. Так финалайзер в Нэмерле, слава богу, объявляется как простой виртуальный метод без вызова потомков и синтаксиса дестркутора С++. Так что никого не смутит, то что он допускает вызов виртуальных метдов и глупые вопросы больше не будут звучать.
Так же устранена проблема с неоднозачностью if-ов. Но она не очень то и мешала.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Да, есть такое дело, согласен. Но мне кажется, что это автоматическое выведение типов будет доступно только в очень ограниченных контекстах. Внутри функций, например. При выходе за пределы метода описания типов лучше все-таки делать полными.
Нэмерл заставляет объявлять типы явно всему что глобально-доступно.
Причем не потому, что нельзя вывести типы и для глобальных вещей, а в виду того, что он учитывает печальный (ща набегут фанаты МЛ-я ) опыт МЛ-подобных языков в которых это допустимо, но нет пергрузки функций, есть проблемы с обнаружением ошибок и есть огромные проблемы со скоростью компиляции. Кстати, компилятор Нэмерла тоже загружается не быстро. Надеюсь, что это не связано с выводом типов, так как работает он вроде как довольно быстро.
E>Вот, кстати, о макросах. Хочу воспользоваться твоим знанием языка Nemerle и спросить: как эти макросы отлаживать?
Это просто код на Нэмерл. Плюс есть возможность заставить компилятор выдать деревья продукций грамматики чтобы обнаружить ее конфликты.
E> Есть ли какой-то механизм unit-тестинга?
Сделашь — будут.
E>И вообще, если есть какой-то опыт создания макросов Nemerle, то интересно было бы послушать о впечатлениях.
Я вот могут только чесно, скзать, что они выглядят в большинстве случаев лучше чем правила R#. Сам не писал... пока.
VK>>3. многочисленные элементы ФЯ, включая алгебраические типы, паттерн-мэтчинг, лямбду, list comprehensions, кортежи
E>По-твоему, все эти механизмы снижают вероятность ошибок в программах?
Декларировать всегда проще чем указвать последовательность действий.
Кстати list comprehensions похоже тоже на макросах сбацали.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, srggal, Вы писали:
S>ИМХО — без десятка использований в коммерческих продуктах, или гораздо большего кол-ва в опен соурс — ИМХО это Академические рассуждения.
S>Ибо разработчики языка — должны свыкнутся с ыслью, что их чудесный язык используется в коммерческих целях.
Дык в том-то, имхо, и проблема данного обсуждения Nemerle в том, что часть участников увидила Nemerle и радостно заявляет "Nemerle рулит!". Другие участники (и я в том числе) начинают прикидывать, как можно рулезный Nemerle использовать в своей работе. И отсутствие IDE с комплитом и рефакторингов -- это второстепенные (если не третьестепенные) препятствия. Более интересно представить что же реально получится из Nemerle в постоянной работе. И здесь лично у меня отношение к заявленным преимуществам Nemerle слегка скептическое. Но боюсь, здесь ни у кого опыта нет практического опыта работы на Nemerle, а становиться первопроходцем не очень хочется.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Дык в том-то, имхо, и проблема данного обсуждения Nemerle в том, что часть участников увидила Nemerle и радостно заявляет "Nemerle рулит!". Другие участники (и я в том числе) начинают прикидывать, как можно рулезный Nemerle использовать в своей работе. И отсутствие IDE с комплитом и рефакторингов -- это второстепенные (если не третьестепенные) препятствия. Более интересно представить что же реально получится из Nemerle в постоянной работе. И здесь лично у меня отношение к заявленным преимуществам Nemerle слегка скептическое. Но боюсь, здесь ни у кого опыта нет практического опыта работы на Nemerle, а становиться первопроходцем не очень хочется.
Это Вы описали так называемые "личные половые трудности", которые соотносятся лично ч разработчиком, я же нрил о вещах более серьёзных, соотносимых с проектом в целом. Хотя одно с другим слишком тесно переплетается так что +1.
На форуме просто есть романтики от программирования и есть люди с практичным складом ума ( я грю исключительно в приложении к программированию ). Первые радуются всему новому, а вторые ждут когда новое обкатается. Ничего нет в этом ни страшного — ни удивительного.
Кроме того, на тезис "Nemerle рулит!" можно выдвинуть след. тезис "Куда рулит Nemerle ?":
Здравствуйте, VladD2, Вы писали:
E>>Понятно, что это в Ruby с динамической типизацией возможно сменить в inject-е тип объекта с Hash на Array и не заметить этого. Но, если бы был inject([]), то тогда вообще несоответствия типов не обнаружилось бы.
VD>Видимо фигово понятно. Ты же программировал на С++ и должен уметь предстваить, что будет когда в действительно статически типизированном языке в одном месте не врено меняется тип. Ведь на тип влияет не одно место. Такая ошибка обязательно где-нибудь вылезет!
Вылезет где-нибудь, а не там где нужно было бы.
VD>А какое из них ошибка? Может ты как раз забыл ко всему прочему еще и тип переменной сменить?
Так в том-то и дело, что компилятор будет указывать на новую строку.
VD>Кстати, а если тпип typedef-ом задан?
Без разницы.
VD>Смотря какую. Думаю можно найти место в котором он очень нехорошо себя поведет. Уж больно мощьные возможности он предоставляет. Но тут надо понимать, что чересь за макросы ты становишся соавтором компилятора.
Ну вот, например, при генерации вспомогательных методов для сериализации у меня генерируется целая куча кода
. Как проверять, что в каких-то случаях какой-нибудь if в сгенерированном коде забыт?
А становиться соавтором компилятора мне не интересно, так же, как и думать о том, во что превратятся мои макросы, если разработчики компилятора внесут в него слишком много изменений.
VD>Или ты все о тех кто вообще ничему новому не доверяет?
Если это доверие требует принятия какого-либо ответственного решения с моей стороны (например, выбор языка для перевода на него программного продукта), то не доверяю.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
E>>Другой вопрос: будет ли Nemerle одинаковым под .NET от MS и Mono? Кроссплатформенность для меня важна.
Д>под Моно он уже работает
Я знаю.
Мне интересно будет ли он под Mono точно таким же, как под .NET? Всегда?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Я знаю. E>Мне интересно будет ли он под Mono точно таким же, как под .NET? Всегда?
А мне интересней дойдет ли он до уровня когда на нем можно будет писать не опасаясь что завтра авторы потеряют к нему интерес, то есть выедет ли хоть на какой-то массовый уровень. Боюсь что он может судьбу D повторить.
Здравствуйте, FR, Вы писали:
FR>А мне интересней дойдет ли он до уровня когда на нем можно будет писать не опасаясь что завтра авторы потеряют к нему интерес, то есть выедет ли хоть на какой-то массовый уровень. Боюсь что он может судьбу D повторить.
VladD2 и Дарней не позволят
Да и у D, я думаю, все не так плохо. Об этом лучше у c-smile спросить.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Работает — Да. Широко применятся? Вот это вряд ли. Если реально поглядеть, то мест в которых это надо раз два и обчелся. Я вот во всю программирую на C# где "это" тоже нельзя напрямую заполучить, но как-то особо не напрягаюсь по этому поводу. Зачем обобщенно складывать что-то? Рельно семантика сложения общая только у числовых данных.
Это очень широко применяется в разных числодробительных задачах. Просто ты такими вещами не занимаешься по этому и потребности нету.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, srggal, Вы писали:
S>>А может эти макросы — это и есьти сермяжная правда ?
E>Все в истории развивается по спирали. Подобные вещи уже были. E>Сейчас вот у некоторых есть уверенность что уж в этот раз все будет хорошо. E>Поживем, увидим. На самом деле, если Nemerle позволит легко ввести в язык конструкции, которые позволят поддерживать возможности SObjectizer
, то я возьмусь за портирование SObjectizer под .NET на Nemerle. Однако, для этого нужны не только красивые глаза самого Nemerle, но и его благосклонное приятие сообществом разработчиков (а здесь все может быть не так радужно).
S>>То, о чём твердят большевики с завидной переодиностью в лице (eao197 С++ + Ruby )? S>>Так сказать шампунь 2в одном, вместо прикручивания внешних тулзов для кодогенерации имеем встроенную возможность.
E>У внешних тулзов есть два очень больших, имхо, преимущества: E>-- легкость освоения скриптовых языков (Perl, Python, Ruby), большое количество существующей документации и готовых программистов; E>-- возможность автономной отладки. Написать unit-тесты, которые проверяют корректность кодогенератора на Ruby не сложно. Насколько просто это будет делать в макросах Nemerle -- вопрос открытый.
E>По крайней мене об отладке и тестировании макросов Nemerle здесь разговор пока не заходил. А для меня привлекательность Nemerle как раз в макросах и состоит.
Я не знаю насколько большА поддержка в этом общества — (хотя бы) RSDN есть? но я например порядка 5 небольших проектов под него переделал...
Притом 3 из них пришлось переделывать даже не с С#, а со Scala-ы — я думал что на него перейду... тоже неплохие возможности.
но есть различия..
и, хотя, на мой взгляд в Scala-е, есть и функциональное пограммирование и объектное программирование с их trait-ами и т.д. которого я кроме как чего-то похожего, в D (хотя и не много похожего) нигде не видел (Ковариантность, инвариантность и т.д. в таком простом и удобном виде)....
Пробовал также переписывать их на Chrome (это своего рода Delphi, но под VS 2005) — текст получался меньше не намного (не слишком), но было лучше и удобнее чем в Delphi... и проектировать интерфейс и пмсать текст — конечно же — у Chrome есть польностью интегрируемая "добавка" в MS VS 2005, с полностью интегрируемым синтаксисом и "изменениями в языке"... ( получилось так, что большой выгоды от использования этого нового синтаксиса не получилось (Virtual Properties, Asynchronous Methods, Inline variable declarations/initializers, Class Contracts, Generics) — хотя и выглядело для меня — как первоначально программиста — Delphi неплохо...)
Но такой простоты и удобности в программирование, как в Nemerle, (написании программ) я не увидел нигде...
проекты конечно небольшие и для "служебного", т.е. моего личного и утилитарного (пользования моими сотрудниками) пользования...
Но программы получилсь в 2 короче чем на C# и где-то в 5 раз короче (и быстрее в написании) чем на Delphi (на коем они и были написаны первоначально), хотя в связи с поддержкой Oracle, пока не удалось полностью избавиться от клиента Oracle, как было на в программах под Delphi с компонентом ODAC for NET...
но сами программы и само программирование под Nemerle оказалось в 2 раза проще... могу вас уверить...
Хотя на первую переделку я и потратил на 75% больше времени, чем на проект в Delphi (связанную больше со переделкой себя под новый синтаксис), однако другие 4 удались в три раза быстрее чем если бы я даже писал их в Delphi с его GUI (благо в в нем мало что изменилось — самые больше изменения были в бизнес логике)...
Жду не дождусь какого-никакого plugin_а для MS VC 2005 для Nemerle, хоть от создателей, хоть от других заинтересованных лиц... Самому создавать его нет времени... к сожалею, но, думаю, было бы очень интересно
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Vermicious Knid, Вы писали:
VD>И не нужно забывать, что Нэмерл впитал в себя все антиграбельные технологии C#. А так же умудрился избавиться от некоторых грабель C#. Так финалайзер в Нэмерле, слава богу, объявляется как простой виртуальный метод без вызова потомков и синтаксиса дестркутора С++. Так что никого не смутит, то что он допускает вызов виртуальных метдов и глупые вопросы больше не будут звучать.
VD>Так же устранена проблема с неоднозачностью if-ов. Но она не очень то и мешала.
по мне так
Unless,
When,
и отдельный If {} Else...
Выглядять приятнее для понимая и глаза чем то чтое сть в других языках...
Хотя нет elseif...
Так он и не нужен в сязи с Matching...
Здравствуйте, srggal, Вы писали:
S>ГМ, я чего-то не понимаю, Вроде не так давно был целый флейм о вреде макросов в С++ и Ваша позиция была стойкой — макросы это зло. С чего бы это такие перемены ?
S>Чем эти макросы лучше друних, которые на С++?
Ох уж эти уроды придумывающие термины и использующие их не по назначению.
Макросы Немерла неимеют никакого отношения к макросам С++. Просто термин используется один.
Макросы немерла работают на синтактичко-семантическом уровне. Этот уровень даже выше чем уровень шаблонов в С++.
Макросы Немерла работают с AST причем могут орбащаться к системе проверки типов языка, а макросы С++ (точнее С) работаеют на уровне тесковых подстановок. Они ничего не знают о самой программе и способны внести такие изменения в текст програмы, что потом даже с поллитрой не поймешь в чем дело.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Но такие люди умеют отбросить свои предрассутки и оценить прогрессивное новое. Или ты все о тех кто вообще ничему новому не доверяет?
