Мои пять козявок на тему Почему у Nemerle нет будущего - Компьютерные священные войны

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

E>+-
E>Есть final.
E>Если несколько методов с разными сигнатурами виртуальные, то кто гарантирует что мы из-за ошибки в названии метода или списке параметров не поставили override у совсем другого метода?

final — это совсем из другой оперы. Это запрет на переопределение. Аналог в C#/Nemerle — sealed.

Помешать ошибке в описанных мной случаях это не может.

VD>>5. Присвоение вместо сравнения. Как и в С++ эти грабли присуствуют в Ява.

E>?
E>Не понял.

Что там понимать:

while (variable = 1)
    ...

вместо

while (variable == 1)
    ...

и приплызд. Хотя конечно это могли быть проблемы компилятора который у меня тогда был.

E>Никто не подскажет программисту убрать однажды написанный ignore.

Я вообще не понял, что ты пытался сказать. Зачем что-то убирать? Или ты явно выражашь намерение проигнорировать результат, или ты используешь результат. В обратном случае получаешь сообщение компилятора. Таким образом ты физически не можешь проигнорировать значение функции по невнимательности.

Ошибка — эта очень частая.

E>А как же наличие спецификаций исключений в Java? Аналог в Nemerle есть?

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

DG>Думаю к тому, что Немерле не Лисп

И для этого нужно писать статью?

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

L>Здравствуйте, Dr.Gigabit, Вы писали:

DG>>Думаю к тому, что Немерле не Лисп

L>И для этого нужно писать статью?

макросы это лисп, лисп это сложно, немерле это макросы, немерле это сложно. Улавливаете мысль?
Так вот статься думаю(я не автор,к сожалению) для того, что бы показать что немерле это вовсе не сложно

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

DG>макросы это лисп, лисп это сложно, немерле это макросы, немерле это сложно. Улавливаете мысль?

Это называется аналогия

DG>Так вот статья думаю (я не автор,к сожалению) для того, что бы показать что немерле это вовсе не сложно

Не-е-е, в топку, это не доказательство. Вот если бы кто-то сказал — "у нас было 100 программистов на С#. Из них 17 перешли на Nemerle и стали более продуктивны, 5 перешли и так же продуктивны, 29 перешли и менее продуктивны, а 49 вообще не смогли освоить язык", то это было бы уже кое-что. А то собралисть тут умнейшие люди и обсуждают какой Nemerle простой

Для кого-то из присутствующих может быть, но вообще...

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

L>Это вопрос терминологии. Для меня дополнение — это частный случай изменения синтаксиса, а макрос — это зачастую изменение синтаксиса.

Ага. Но по собственному желанию. Это не воля свыше.

VD>>И нам с тобой как потебителям останется выбрать нужны нам его поделки или нет.

L>Зачастую это не так. Это верно только для новых проектов. Для других проектов (а их большинство), возможностей выбора зачастую просто нет. Зато есть унаследованный код. И не факт, что твое представление об уродливости синтаксиса будет совпадать с представлениями тех программистов, которые писали код до тебя.

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

Так что макросы тут не пирчем. Разницы между бардачным проектированием классов/функций и бардачным проектирвоанием макросов — нет.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Скажи, ты читал эту статью? Крыша плавилась?

L>Какое отношение эта статья имеет к лиспу?

А какое отношение имеет Лисп к этой теме (к Немерле)? Ты ведь не маргнул глазом — провел аналогию с Лиспом и сделал на ее базе далеко идущие выводы. Меж тем аналогия не верна.

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

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

Вся сила Немерле в том, что позволяет писать используя его почти на C#-е. Это очень похоже на ситуацию с С++ в начале его развития, когда люди писали на С++ как на С и постепенно обучались новым возможностям (ООП, а потом и шаблонам).

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

L>И для этого нужно писать статью?

Как видишь. Иначе и это было бы еще одним поводом для домыслов

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

DG>макросы это лисп, лисп это сложно, немерле это макросы, немерле это сложно. Улавливаете мысль?

Я бы сказал, не улавливаете, а вспоминате свой ход мыслей .

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

DG>>макросы это лисп, лисп это сложно, немерле это макросы, немерле это сложно. Улавливаете мысль?

A>Это называется аналогия

Это называется логическая ошибка. Коию ты и еще немало народа делают.

Лисп сложно потому что Лисп это сложно (причем это утверждение верно не для всех).
Макроы сложно создавать потому что для этого нужно подняться на одну ступень абстракции (измерение) выше.
Использовать же макросы сложно только если это плохо написанный или неотлаженный макрос. Тут они ничем не отличаются от библиотечной фунции. Например, использовать функцию с названием Open которая форматирует диск — сложно. И ничго в мире это не изменит. А использовать макрос while который реализует понятную идеому цикла с условием — просто даже не смотря, на то что многие могут не понять как реализован данный макрос:
Небольшой отчет о сделанной работе

...для макроса "while" (сначала приводится код использующий макрос)

(а это уже подсказка) первый варинт нужен чтобы было понятно что ображуем "тело" передавющееся макросу.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>>Это называется аналогия

VD>Это называется логическая ошибка. Коию ты и еще немало народа делают.

Не, ну я же не сказал, что это правильная аналогия

VD>Макроы сложно создавать потому что для этого нужно подняться на одну ступень абстракции (измерение) выше.

+1

VD>Использовать же макросы сложно только если это плохо написанный или неотлаженный макрос. Тут они ничем не отличаются от библиотечной фунции. Например, использовать функцию с названием Open которая форматирует диск — сложно. И ничго в мире это не изменит. А использовать макрос while который реализует понятную идеому цикла с условием — просто даже не смотря, на то что многие могут не понять как реализован данный макрос:

+1

Теперь вопрос — чтобы использовать Nemerle (потому что в шарпе я макросов не заметил) обезьянкам переучиваться надо? И если надо, то оно того стоит всегда-всегда?

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

VD>Так что макросы тут не пирчем. Разницы между бардачным проектированием классов/функций и бардачным проектирвоанием макросов — нет.

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

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

L>>Какое отношение эта статья имеет к лиспу?

VD>А какое отношение имеет Лисп к этой теме (к Немерле)? Ты ведь не маргнул глазом — провел аналогию с Лиспом и сделал на ее базе далеко идущие выводы. Меж тем аналогия не верна.

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

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

L>Таки есть. Макросы — гораздо более мощный инструмент, и с помощью него ты не только ногу себе отстрелишь, но и пол-туловища снесешь к е**ням.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Теперь вопрос — чтобы использовать Nemerle (потому что в шарпе я макросов не заметил) обезьянкам переучиваться надо? И если надо, то оно того стоит всегда-всегда?

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

Хотя программирование обезьянками по-моему глупость. Можно конечно иметь ряд неквалифицированных кадров чтобы поручать им неквалифицированную, но объемную работу. Но при наличии макросов очень многие из задач будет выгоднее решить генерацией кода. Как минимум будет исключен человеческий фактор и разползание ошибок по проекту.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

ОК. Тогда объясни что ты вообще хотел сказать.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

L>>Таки есть. Макросы — гораздо более мощный инструмент, и с помощью него ты не только ногу себе отстрелишь, но и пол-туловища снесешь к е**ням.

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

Не хочется спорить. У тебя на этой ниве (споры) опыта будет на порядки поболее чем у меня. Время нас рассудит. Посмотрим что будет годика через 3. Ставлю на то, что большого распространиения Nemerle за этот период не получит.

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

L>Не хочется спорить. У тебя на этой ниве (споры) опыта будет на порядки поболее чем у меня. Время нас рассудит. Посмотрим что будет годика через 3.

+1

L> Ставлю на то, что большого распространиения Nemerle за этот период не получит.

Ставить, класть и даже забивать не буду. Но что-то мне подсказывает, что сдедующий движок этого сайта будет на Nemerle.

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

По крайней мере хотелось бы так думать.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>>А что есть? Насколько помню, в Java операции приведения не возвращают null в случае неудачи.

VD>Возможно я путаю. С явой много лет дел не имел. В C# такие грабли есть. Так как Немерле не прямой наследник Явы, то могли бы и эти грабли тоже подцепить, но не переняли. Именно потому, что заботились о безопасности языка.

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

Поверить во что? В то, что операция приведения типа в Java не возвращает null?
Или в то, что Nemerle безопаснее Java?
Мне кажется, что это именно тебе нужно лучше узнать другие языки.

VD>>>2. Нет старой сишной проблемы возникающей в switch если забыть закрыть case break-ом. В C# такой проблемы тоже нет, но там это достигается обязательностью break в конце case.

E>>Понятно.

VD>Что понятно?

Понятно, что ты считаешь, что эта фича в Nemerle делает язык более безопасным, чем Java.

VD>Да, уж. Я лучше пожеву. Хотя я в общем-то не о себе. Тут и без меня людей хватает. Вон IT, например, и другие. Так же стоит поглядеть на голосование по поводу Немерле. Там четко было видно, что большинство из топ-а РСДН-а оценивает его как минимум как перспективный язык определяющих будующее ЯП.

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

Но вопрос в другом: "Будут ли язык Nemerle широко востребован индустрией?". И важен этот вопрос по одной простой причине -- выявление рисков по вкладыванию средств и времени в Nemerle для того, чтобы сделать Nemerle основным языком разработки.

E>>Ты выдумал за меня какую-то теорию и пытаешься заставить меня ее доказывать. Увольте, сударь.

VD>ОК, буду считать эту фразу заменой "беру свои слова про ученых обратно".

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

E>>Модула, Эйфель, Оберон, Пролог и Ада не только нравится, но и используется кучей программистов-практиков.

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

Уж во всяком случае гораздо больше, чем Nemerle. В особенности что касается языка Ада.

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

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

. Так что предлагаю не развивать эту тему.

Нет, я хочу сказать, что условия разработки OpenSource и Freeware для собственного удовольствия сильно отличаются от разработки софта под заказ или на деньги инвестора/кредита, а именно:
* в OpenSource у тебя нет жестких сроков;
* в OpenSource у тебя нет проблемы подбора персонала. Ты начинаешь в одиночку или в небольшом круге единомышленников, по ходу дела к тебе присоединяются энтузиасты желающие что-нибудь изучать и делать. Поэтому даже начинающий программист без большого опыта в программировании или платформе, но со светлой головой, могут оказывать очень серьезную помощь в проекте;
* в OpenSource ты можешь себе позволить выпускать alpha- и beta- версии продуктов без опасения потерять пользователей, очень надолго откладывать выпуск release-версии.

Не так уж сложно заметить, что когда нет увлеченной одной идеей (интересом к одному языку) команды, когда есть жесткие сроки и требуется обеспечить высокое качество сразу, то подход к выбору технологии и персонала меняется. Так вот Eiffel, Oberon и Ada используются (прочти внимательно, используются) в коммерческих проектах.

E>> Тем не менее, популярными они не стали. При том, что так же являются хорошими языками, с кучей достоинств.

VD>Они у тебя стали резко хорошими исключительно на время пока ты пыташся тут доказать свои домыслы. Реально не составит труда понять,ч то Аду с Модулой ты вообще в глаза не видел, а Оберон с Прологом на этом сайте у Губанова и во время обученя в институте. Так же не составит труда найти твои споры с тем же Губановым.

Ну найди. И заодно обоснуй свои утверждения о моем незнании Ады и Модулы.
А что касается Eiffel, то это язык, изучая который задаешься одним простым вопросом -- нафига были придуманы Java и C#, если был Eiffel? Очень стройный и приятный язык, безнадежно загубленный маркетингом.

VD>Я уже давно сказал, что время само расставит все на свои места. А подобным гаданиям грошь цена. Лично я вижу приемщества языка и желаю языку лучшей судьбы, но говорить что-то с уверенностью о его будущем не буду. Ибо глупо это. Количество факторов так велико, что даже гадание на подбрасвывании монетки и то будет более точно. К тому же все каждую минуту может измениться. Вдруг завтра появится Мерле или B++ и расклад сил изменится? В общем, пустое это.

Выделенное является ключевым моментом в твоих высказываниях. Ты очень быстро соскочил с одной иглы на C#, затем так же быстро на Nemerle, затем так же быстро на новый B++ (может потому, что тебе не нужно заниматься сопровождением предыдущих проектов?). А вот тем, что начнет вкладывать деньги в разработку на Nemerle сделать это просто так не получится.

Так что ты можешь продолжать считать, что я не вижу достоинств в Nemerle, но дело в другом. Хотелось бы увидеть, насколько безопасно закладываться на Nemerle в долгосрочной перспективе. И здесь, представь себе, есть подозрения, что достоинства Nemerle, которые ты с сотоварищи здесь рекламируете, будут со временем становится недостатками. По той простой причине, что требуют для своего успешного применения высокой квалификации. Может быть поэтому интерес к Nemerle проявляют люди и Top-а RSDN-а (им ведь по барабану, какой язык осваивать и на чем писать). Так что я думаю, у Nemerle есть хорошие шансы стать мощным и сложным инструментом (что-то вроде C++), для небольших высококвалифицированных команд.

А опровергнуть это мнение можно только фактами. Которые пока можно найти только в исходниках компилятора Nemerle. Вообще интересный критерий -- пример использования языка искать в компиляторе языка.

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

VD>final — это совсем из другой оперы. Это запрет на переопределение. Аналог в C#/Nemerle — sealed.

VD>Помешать ошибке в описанных мной случаях это не может.

Однако не понятно, как такие ошибки влияют на безопасность?

VD>>>5. Присвоение вместо сравнения. Как и в С++ эти грабли присуствуют в Ява.

E>>?
E>>Не понял.

VD>Что там понимать:
VD>

VD>while (variable = 1)
VD>    ...
VD>

VD>вместо
VD>

VD>while (variable == 1)
VD>    ...
VD>

VD>и приплызд. Хотя конечно это могли быть проблемы компилятора который у меня тогда был.

Очень вероятно:

class Test {
    public void test_assigment_in_condition() {
        int var = 0;
        if( var = 1 )
            System.out.println( "failure (var = 1)!" );
    }
}

результат:

Test.java:4: incompatible types
found   : int
required: boolean
                if( var = 1 )
                        ^
1 error

Так что мимо кассы. Подобная проблема будет существовать только, если var имеет тип boolean.

E>>Никто не подскажет программисту убрать однажды написанный ignore.

VD>Я вообще не понял, что ты пытался сказать. Зачем что-то убирать? Или ты явно выражашь намерение проигнорировать результат, или ты используешь результат. В обратном случае получаешь сообщение компилятора. Таким образом ты физически не можешь проигнорировать значение функции по невнимательности.

Я хочу сказать, что во многих случаях придется писать ignore. Например, когда объект возвращает ссылку на самого себя для того, чтобы можно было выстраивать цепочку действий. Вот аналоги из C++:

std::cout << "total time: " << (start - finish) << " msec" << std::endl;

Md5_Hash hash;
hash.put( "Message: " ).put( message_id ).put( ", content length: " ).put( content_length );

Программист вынужден будет в этих случаях писать ignore. Геморрой на ровном месте.

VD>Ошибка — эта очень частая.

May be. Тем не менее к безопасности это вряд ли имеет отношение. Катострофических последствий это не вызовет, поскольку это логическая ошибка программиста. С таким же успехом программист может поставить ignore там, где ему нужно было сохранить значение. Запись:

ignore( str1.Replace( "some", "other" ) );

остается синтаксически валидной, но вот смысла в ней совершенно нет.

E>>А как же наличие спецификаций исключений в Java? Аналог в Nemerle есть?

VD>Это к граблям не приводит.

Да уж. Потерянные исключения -- это не грабли.

Итого получается: реально исправленные проблемы с ==/equals, гипотетическое преимущество в switch/case и такое же гипотетическое преимущество (ли?) по поводу возвращаемого значения. И минус спецификация исключений. Не густо для языка, появившегося на 10 лет позже Java.

	От:	Dr.Gigabit
	Дата:	13.08.06 19:56
	Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	13.08.06 21:01
Оценка:

	От:	Lloyd
	Дата:	13.08.06 21:19
	Оценка:

	От:	Dr.Gigabit
	Дата:	13.08.06 21:28
	Оценка:	1 (1) +1

От:	adontz	http://adontz.wordpress.com/
Дата:	13.08.06 21:36
Оценка:	+1

От:	eao197	http://eao197.blogspot.com
Дата:	14.08.06 05:17
Оценка:	-1