В Немерле не нравится низкая и сложно предсказуемая производительность. В С++ не нравится многословность. К счастью, они отлично совмещаются через C++/CLI.
Ce n'est que pour vous dire ce que je vous dis.
Re[22]: C#: const для переменных, pattern-matching, ...
Здравствуйте, Lloyd, Вы писали:
L>>>Главное в это верить. WH>>В отличие от тебя я это знаю.
L>И часто-часто повторять. И ни в коем случае не сомневаться.
Ты часто раздражаешь меня своей манерой алогичного мышления.
Вот в этой теме тебе много много раз приводили железные аргументы, но повторяешь одну и ту же глупость без малейшего сомнения.
Будь конструктивнее. Опиши гипотетический случай пугающий твою ранимую дущу, а мы тебе расскажем где ты ошибаешься и т.п. Ну, или признаем твою правоту, если ты действительно прав.
WH>>А у тебя только вера в какие-то страшные бедствия, которые никто из практиков не видел.
L>Практиков, говоришь? Я с год назад спрашивал про практику использования, кроме самого компилятора никто особо серьезного примера использования привести не смог. За год что-то изменилось или это и есть ваша "практика"?
Случаев использования полно. Но ты от вопроса то не уходит. А то у тебя и так логиках хромает как у блондинки. Сосредоточься на одной проблеме. Так будет проще не ошибиться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Недостатки в компиляторе и языке:
1. Низкая скорость компиляции и как следствие периодическое подторможивание при комплите в IDE.
2. Сложность разработки не тривиальных макросов (требующих наличии информации о типах).
3. Недостаточная для некоторых задач расширяемость синтаксиса.
4. Компилятор основан на System.Reflection.Emit, что приводит к привязке исполняемых модулей к текущим версиям фрэймворка (FW). По сути из-за этого поддерживаются только FW 2-4 и Моно. Такие ответвления как КомпактFW и Сервилат не поддерживаются. Планируется перевод на CCI, что должно снять эту проблему.
Недостатки в IDE:
1. Макросы уровня выражения под управлением IDE ведут себя не так же как при компиляции. Неумелый макро-писатель может создать макрос неустойчиво работающий в IDE, но работающий в компиляторе. Виной сему императивный подход в работе с деревом типов.
2. Малый набор рефакторингов, точнее наличие всего двух их видов. Не помешали бы многие фичи РеШарпера. Особенно выделение метода (а еще лучше перевод локальной функции в метод), выделение интерфейса и т.п.
Надеюсь, что все эти недостатки будут устранены в Nemerle 2.0. Ну, а некоторые и раньше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: C#: const для переменных, pattern-matching, ...
Здравствуйте, VladD2, Вы писали:
L>>>>Главное в это верить. WH>>>В отличие от тебя я это знаю.
L>>И часто-часто повторять. И ни в коем случае не сомневаться.
VD>Ты часто раздражаешь меня своей манерой алогичного мышления.
А ты не раздражайся. Если ты видишь в чем-то нелогичность, это вполне может оказаться потому, что ты не видишь логики.
VD>Вот в этой теме тебе много много раз приводили железные аргументы, но повторяешь одну и ту же глупость без малейшего сомнения.
Да ведь не было ни оного аргумента, были пассы руками и уверения, что все оч. хорошо. На железные доводы не тянет как-то.
VD>Будь конструктивнее. Опиши гипотетический случай пугающий твою ранимую дущу, а мы тебе расскажем где ты ошибаешься и т.п. Ну, или признаем твою правоту, если ты действительно прав.
Я привел пример с выбором между var и явной декларацией типа. Оппонент предпочел сделать вид, что он не понял, в чем суть претензии. Уж не знаю, почему так получилось — то ли не дочитал до конца и бросился отвечать, то ли ответа не было и решил придраться к формальностям.
Дабы не искать, отквочу:
Даже такой простой выбор, как выбор между var и явной типизацией — весьма неоднозначен и приводит к долгим, продолжительным и безсмысленным спорам, не утихающим и до сих пор. Эти споры имеют место быть даже не смотря на то, что (я уверен) проектировшики языка сидели и целенаправленно рассматривали все плюсы и минусы этого решения.
Если теперь взять рядового программиста, которому которому платят денежку не за то, что он пишет расширения компилятора, а за решения бизнес-задач, то встает вопрос,
а хватит ли ему времени, компетенции и желания на то, чтобы рассмотреть все возможные последствия изменения синтаксиса языка?
По-моему, ответ на этот вопрос очевиден.
Хотя я уже знаю ответ. Вы просто опять съедете на то, что нет такой проблемы.
Собственно, как было с ненужностью "отладки" макросов, когда ты на публике с пеной у рта уверял, что средств получения кода, сгенерированного макросом нет за ненадобностью, а в личной переписке, надев маску "ты кого угодно достанешь", признал, что средства-таки есть.
WH>>>А у тебя только вера в какие-то страшные бедствия, которые никто из практиков не видел.
L>>Практиков, говоришь? Я с год назад спрашивал про практику использования, кроме самого компилятора никто особо серьезного примера использования привести не смог. За год что-то изменилось или это и есть ваша "практика"?
VD>Случаев использования полно.
Опять как и год назад сошлешься на компилятор?
VD>Но ты от вопроса то не уходит.
А это и не уход от вопроса. Собеседник в качестве аргумента сослался на практику, вот пусть и уточнит, что за практику он имеет в виду.
VD>А то у тебя и так логиках хромает как у блондинки. Сосредоточься на одной проблеме. Так будет проще не ошибиться.
Ты как всегда очень конструктивен. Фразы "алогичность мышления", "повторяешь глупость", "ранимая душа", "логиках хромает как у блондинки" очень настраивают на конструктивный разговор.
Здравствуйте, Lloyd, Вы писали:
Q>>Всё равно math-like синтаксис «where» в Хаскель мне нравится больше, чем дурацкое разнесение объявления и определения переменной по разным углам. В нём иерархическая структура выражения чётче просматривается.
L>да я не против. вопрос лишь в том, как это ляжет на императивные блоки кода.
В языках ML семейства (которые вполне и императивные) нормально ложится.
Здравствуйте, VladD2, Вы писали:
VD>О, как? А можно с этого места по подробнее? Чем эта предсказуемость отличается скажем от C#?
.NET вообще плохая платформа для вычислений, но в Немерле производительность сильно зависит ещё и от того, инлайнятся ли функции, оптимизируется ли хвостовая рекурсия, во что разворачивается использование туплов, и какой код генерируется макросами (особенно foreach). Чисто личный опыт.
Здравствуйте, dimgel, Вы писали:
D>2. Не люблю, когда злоупотребляют аннотациями: они хуже проверяются типизатором. В жаве почти все фреймворки работают на аннотациях. Это вот отчаянное желание превратить всё на свете в POJO с аннотациями бесит. Взять тот же Spring MVC. Я хз чем плохо запихать обработчик каждого URL в отдельный класс-функтор (Page.service: Request -> Response), а свойства обработчика сделать дополнительными свойствами / виртуальными методами этого класса. (Не, правда, если кто пробовал и знает, чем плохо, очень прошу поделиться.) Нет, мы разрешим использовать POJO, обращать любой метод в обработчик запроса путём навешивания на него тонны аннотаций — на сам метод и на каждый параметр. Итого: типизация пролетает, как фанера над парижем; нетривиальную валидацию параметров, как и нетривиальную обработку ошибок, хрен прикрутишь; отладить эту AOP-хрень практически невозможно; IDE никаких подсказок не возможностям не даёт (базового класса нет, виртуальные методы подсмотреть негде, а аннотации я хз какие в каком случае применимы), приходится долго читать доки на каждую мелочь. Аналогичные претензии к Tapestry, а вот Wicket рулит.
А покажи неривиальную валидаци, не вписывающуюся в JSR-303?
A>А еще: A>0) нельзя использовать русские буквы в именах переменных и функций
Можно любые, вот цитата из стандарта (старого):
identifier:
nondigit
identifier nondigit
identifier digit
nondigit: one of
universal-character-name
_ a b c d e f g h i j k l m
n o p q r s t u v w x y z
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
hex-quad:
hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit
universal-character-name:
\u hex-quad
\U hex-quad hex-quad
так что все вопросы к конкретному редактору — по старому стандарту он обязан просто превращать юникодные символы в \uXXXX в момент сохранения файла на диск (и обратно при загрузке).
Кстати, если вызов компилятора завернуть в элементарный скрипт, который любые уникодные символы будет превращать в universal-character-name и потом звать компилятор — вообще никаких усилий от редактора не потребуется.
В новом стандарте еще проще:
identifier-nondigit:
nondigit
universal-character-name
other implementation-defined characters
но universal-character-name никуда не делся, так что скрипт будет работать и с кодом, соответствующим новому стандарту.
A>1) нельзя сделать operator[](int index1, int index2)
это да, арность, приоритеты и прочая менять нельзя. Это, кстати, дает стабильность синтаксиса, в отличие от языков, в которых это можно. Потому что сейчас a[1,2] эквивалентно a[2], потому что оператор запятая. И это не зависит от типа а. А если разрешить такое, как у тебя, то в зависимости от типа а может быть как оператор запятая + вызов унарной версии, так и вызов бинарной версии.
A>2) и вообще переопределенных операторов как-то мало
В сымсле — мало? 46 операторов (все, кроме четырёх ". .* :: ?:") — это мало? Или ты к тому, что нельзя новых наопределять? Так это палка о двух концах, так как, определяя новый оператор, его нужно каким-то образом включить в систему существующих операторов в смысле приоритета и ассоциативности — немаленькая нагрузка на компилятор, не говоря уже о возникающих неоднозначностях: a**b — это новый оператор ** или a*(*b), как сейчас? Но лучше, конечно, 5 звёздочек
A>3) нельзя return x,y ;
return boost::make_tuple(x,y);
A>4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )"
можно в C++0x (VC и GCC уже поддерживают)
A>5) нельзя поймать исключение SegFault и продолжить работу
оно за пределами языка, так что надо пользоваться внеязыковыми средствами, доступными в библиотеках.
A>6) В STL нет контейнера "граф"
А так же Map/Reduce, youtube video search, переводчика с японского на корейский и еще миллиона структур и алгоритмов. Библиотеки на что? Boost.Graph, например.
Здравствуйте, okman, Вы писали:
O>Отсутствие двоичного стандарта.
Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам
O>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь.
Ну вот была MFC "на всю жизнь" — и как?
O>Отсутствие единого глобального соглашения о скобках, отступах и именах.
Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?
O>Наплодили меташаблоны с концептами, списками типов и кортежами, вместо того, чтобы вызвать O>add_ref, поставить блокировку и вернуть shared_ptr.
не понял, какая связь?
O>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64.
Вообще-то возможность заточки под платформу — это фича языка
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, okman, Вы писали:
O>>Отсутствие двоичного стандарта. J>Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам
O>>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь. J>Ну вот была MFC "на всю жизнь" — и как?
O>>Отсутствие единого глобального соглашения о скобках, отступах и именах. J>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, VladD2, Вы писали:
VD>>О, как? А можно с этого места по подробнее? Чем эта предсказуемость отличается скажем от C#?
DR>.NET вообще плохая платформа для вычислений, но в Немерле производительность сильно зависит ещё и от того, инлайнятся ли функции, оптимизируется ли хвостовая рекурсия, во что разворачивается использование туплов, и какой код генерируется макросами (особенно foreach). Чисто личный опыт.
а на N хвостовая рекурсия может не разворачиваться в цикл???
Здравствуйте, jazzer.
Вы как-то очень уж серъезно решили "не обойти стороной" мое сообщение.
В любом языке, как и в человеке, можно найти кучу недостатков, и при этом спокойно с ним жить.
O>>Отсутствие двоичного стандарта. J>Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам
А мне бы хватило стандарта для одной определенной платформы (Windows) — схема расширения имен,
объектные файлы, передача объектов/исключений между модулями и тому подобное.
Чтобы можно было гарантировать совместимость интерфейсов C++ между теми же dll, собранными
разными компиляторами. Может быть, в таких громадинах как COM тогда и не было бы необходимости.
O>>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь. J>Ну вот была MFC "на всю жизнь" — и как?
Вот и я о том же — MFC даже не является частью языка, подобно STL.
А если сесть и перечислить все либы, с которыми приходилось работать, получится весьма немалый список.
Причем каждая из них реализует какую-то особую концепцию, каждую нужно понять и осилить, хотя бы
на уровне прототипов. Куда эта дорога ведет ? Почему в новом стандарте нет либы для работы с XML,
ведь он используется повсеместно ?
O>>Отсутствие единого глобального соглашения о скобках, отступах и именах. J>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?
Ну да, это как-то маниакально.
Но почему-то в том же .NET принято именовать сущности более-менее единообразно (видел в нескольких
проектах), а в коде на C++ постоянно приходится видеть нечто в таком стиле:
O>>Наплодили меташаблоны с концептами, списками типов и кортежами, вместо того, чтобы вызвать O>>add_ref, поставить блокировку и вернуть shared_ptr. J>не понял, какая связь?
Я к тому, что некоторые существующие концепции программирования в C++ эволюционировали в нечто
настолько сложное и запредельное для понимания обычными людьми, что сильно потеряли, на мой взгляд,
в практическом отношении. Особенно в коллективной разработке, когда квалификация программистов
может значительно отличаться. Мне нравится, когда шаблоны используются как в STL или бустовских
смартпоинтерах, или как обертки для COM-интерфейсов в ATL, но когда из них делают что-то,
понятное лишь гуру метапрограммирования — это перебор.
O>>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64. J>Вообще-то возможность заточки под платформу — это фича языка
Если заточек становится слишком много, значит язык не справляется со своей задачей.
Здравствуйте, Ziaw, Вы писали:
F>>и выглядит оно вполне логично.. Z> можно посмотреть на эту логику?
ну если сложные типы передаются по ссылке и сигнатура метода создаётся лишь однажды при объявлении/импорте, то логично, что список создаётся на момент объявления функции и живёт там продолжительное время..
Здравствуйте, Курилка, Вы писали:
O>>>Отсутствие единого глобального соглашения о скобках, отступах и именах. J>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться? К>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.
для плюсов тоже есть различные соглашения, но все забивают..
и для жавы забивают, и на пеп8 кладут бывает.. особенно брутальны бывают споры при переносе кода на несколько строк..
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Курилка, Вы писали:
O>>>>Отсутствие единого глобального соглашения о скобках, отступах и именах. J>>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться? К>>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.
F>для плюсов тоже есть различные соглашения, но все забивают..
Различные != рекомендуемые F>и для жавы забивают, и на пеп8 кладут бывает.. особенно брутальны бывают споры при переносе кода на несколько строк..
Ну на любом языке можно писать ужасный код, и что?
Вопрос-то в первую очередь организационный, а в случае жабы/питона есть чуть большая вероятность решения этого вопроса ну и чуть меньше визуального мусора при работе с чужим кодом (типа приведённого okman рядом).
Здравствуйте, Jack128, Вы писали:
J>а на N хвостовая рекурсия может не разворачиваться в цикл???
Насколько я знаю, хвостовая рекурсия разворачивается всегда. Для меня проблема только в том, что отсутствие хвостовой рекурсии не всегда очевидно. О нём узнаёшь из профайлера или при падении со StackOverflowException.
можно посмотреть на эту логику?
