T>>Нет статической проверки типов. Да и типов по большому счёту нет. Один object с наклейками для проверок в рантайме.
A>это фича.
Это нерелевантно. Вопрос был "что не нравится", а не "назовите всё кроме фич". Но даже если потролить, мы, наверное, по-разному понимаем фичи.
Полиморфизм, замыкания, ФВП, юникодные строки, list comprehension — это фичи. Они позволяют делать то, что иначе было бы в разной степени некрасивым "многабукф".
Отсутствие типов и статической их проверки позволяет делать то же самое, что "обычные" полиморфизм, вывод типов, кодогенерация или шаблоны плюс разной степени трудноуловимые баги и существенно затрудняют оптимизации. Я не могу назвать это фичей. Это отсутствие фичи и свиду симпатичный (любое говно можно преподнести как конфету) костыль взамен. Для прототипов — самое то! Для боевого кода хочется побольше уверенности и поменьше накладных расходов. Видимо, поэтому существенная масса разрабов колются, плакают но продолжают жрать С++.
это называется "динамическая типизация" и это фича.
то что вы хотите от языка с динамической типизацией чтоб он был как язык со статической типизацией — означает что вы выбрали не тот язык, и не понимаете почему он так спроектирован.
Здравствуйте, WolfHound, Вы писали:
U>>Мы про систему типов шарпа или про проектирование языка с нуля? WH>Один хрен там магия жуткая понадобится. WH>Причем на ровном месте. Просто по тому что тебе так захотелось.
Вот это тот самый пример (сорри что встрял), который отличает использование зависимых типов в agda2 и в твоем предложенном варианте динамического приведения значения обычного типа к зависимому. Тут не просто система типов, а как бы суперкомпиляция. Но это реализовано в языках с зависимыми типами и это работает. В приведенном отрывке ниже участка проверки на if код имеет некие гарантии, и эти гарантии учитываются при выводе типов.
Поэтому, проверка контракта NotNull вполне решаема на зависимых типах без всяких монад Maybe, просто лишь объявление такого типа и использование его во всех вычислениях.
Re[9]: C++, неявное преобразование signed <-> unsigned
Здравствуйте, Lloyd, Вы писали:
L>Да я и не оспариваю это, конечно выбор и ответственность лежит исключительно на "конкретной группе людей". Так и есть. L>Я ставлю под сомнние то, что человек, не занимающейся проектированием языков, в состоянии адекватно внести изменения в синтаксис существующего языка. Под "адекватностью" я тут имею в виду что внесенное изменение не будет "конфликтовать" с другими концепциями языка и не будет с течением времени выглядеть как нелогичная нелепица. Основанием для этих сомнений служит а) личный опыт написания (и развития) программ, генерирующих код, и б) многочисленные неадекватности и нелогичности, найденые тем же nikov-ом в шарпе и многими другими — в C++.
L>>>Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?
При всем этом на процесс разработки эти неоднозначности практически не влияют. Вероятность на них наткнуться мала, а немного подравить код, чтобы ее устранить настолько легко, что проблема выеденного яйца не стоит.
VD>>В общем, в очередной раз жалею бессмысленно потраченное время. В прочем, возможно, что хоть не ты так может кто-то другой попытается понять вполне простые и очевидные доводы и не будет повторять за тобой бредову мантру о вреде макросов.
L>"Бредовая мантра о вреде макросов" существует только в твоей голове. Я уже уточнил, что именно я имел в виду, когда писал, что метапрограммирование — не нужно. Да, я изначально выбрал неудачную формулировку, признаю свою ошибку.
Есть руби, в котором метапрограммирование это неотъемлемая часть. Практически каждый серьезный широкоиспользуемый плагин для RoR широко использует кодогенерацию (зачастую текстовую) и свой edsl.
Практически все плагины которые не придумали (придумали плохой) edsl или не справились с кодогенерацией просто непопулярны. Для рельс практически нет платных плагинов, их разрабатывает community. Никакой катастрофы не произошло, популярность у языка и фреймворка прекрасные.
К сожалению, рубийный подход прямо не работает. Не все, что так легко делается в руби легко сделать в nemerle (обратное тоже верно).
Здравствуйте, alpha21264, Вы писали:
J>>так что все вопросы к конкретному редактору — по старому стандарту он обязан просто превращать юникодные символы в \uXXXX в момент сохранения файла на диск (и обратно при загрузке). J>>Кстати, если вызов компилятора завернуть в элементарный скрипт, который любые уникодные символы будет превращать в universal-character-name и потом звать компилятор — вообще никаких усилий от редактора не потребуется.
A>С ужасом представил, как это будет выглядеть при отладке.
ой, да. Дебагер — наше все ну да дебагер тоже можно заточить это преобразование делать, пр крайней мере gdb7 и дальше — там можно на Питоне фильтрацию написать. Если уж так позарез нужны русские идентификаторы.
A>Нельзя так пугать. Лучше бы ты транслит посоветовал. A>Или английский учить, как тут многие "выучившие" советуют.
Ессно, английский. Русский (и в виде транслита тоже) выглядит крайне неуклюже из-за того, что в русском языке есть склонения, спряжения, и род.
Сравни "I.love(Olga);" и "Я.любить(Ольга);"
J>>В новом стандарте еще проще: J>>
J>> other implementation-defined characters
J>>
A>Ну вот выйдет новый стандарт, напишут компилятор, потом подтянутся остальные тулзы. Может быть ближе к пенсии и получится.
Студия уже позволяет, вроде.
A>Вы что-же батенька, хотите все функции с двумя аргументами запретить? Там же тоже в середине есть запятая. A>Например strcmp( s1,s2 );
A>Ну вот простейшая же вещь. Строки можно сравнить и по длинне и по алфавиту. A>И то и другое — оператор "больше". Как предлагаете выйти из ситуации?
Флудим?
A>>>3) нельзя return x,y ; J>>
J>>return boost::make_tuple(x,y);
J>>
A>Ты бы мне еще посоветовал структуру завести. Или вернуть через выходные параметры.
Будешь продолжать бессмысленный флуд — посоветую. A>Ты не видишь, насколько эта запись длиннее необходимой?
Насколько?
A>>>4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )" J>>можно в C++0x (VC и GCC уже поддерживают)
A>Это как бы несколько другой язык.
С чего бы вдруг другой? Причем компиляторы _уже_ поддерживают. Тебе шашечки или ехать? Или просто пофлудить охота, видимо.
A>>>5) нельзя поймать исключение SegFault и продолжить работу J>>оно за пределами языка, так что надо пользоваться внеязыковыми средствами, доступными в библиотеках.
A>Ну а почему оно "за пределами языка"? Должно быть "в пределах". (топаю ножкой)
A>>>6) В STL нет контейнера "граф" J>>А так же Map/Reduce, youtube video search, переводчика с японского на корейский и еще миллиона структур и алгоритмов. Библиотеки на что? Boost.Graph, например.
A>Да как тебе сказать... STL это УЖЕ библиотека.
Я на этот бред не буду отвечать, хорошо? В общем-то, и на предыдущий не надо было.
Будет желание серьезно что-то обсудить, а не просто позубоскалить и поупражняться в 10-пальцевой слепой печати — заходи, а иначе — не надо, плиз, сходи в КСВ лучше.
Здравствуйте, Ziaw, Вы писали:
Z>Есть руби, в котором метапрограммирование это неотъемлемая часть. Практически каждый серьезный широкоиспользуемый плагин для RoR широко использует кодогенерацию (зачастую текстовую) и свой edsl.
Z>Практически все плагины которые не придумали (придумали плохой) edsl или не справились с кодогенерацией просто непопулярны. Для рельс практически нет платных плагинов, их разрабатывает community. Никакой катастрофы не произошло, популярность у языка и фреймворка прекрасные.
Z>К сожалению, рубийный подход прямо не работает. Не все, что так легко делается в руби легко сделать в nemerle (обратное тоже верно).
Ну, может быть я действительно чрезчур критично отношусь к опасности этого подхода.
Здравствуйте, anglichanin, Вы писали:
С>>C++ невозможно отличить создание временнoгo обьекта от вызова функции: С>>int a = foo(B(x)); — что здесь B(x) ?
A>Не стоит приводить примеры из студенческих лабораторных. Любой инструмент можно испортить культурой его использования.
При чём тут студенческие лабораторные? Даже в стандартной библиотеке можно найти подобные примеры, типа back_inserter/back_insert_iterator.
1. Невозможность отвязать instance method от этого instance. Т.е. если я могу писать someInstance.someMethod(arg1, ..., argn), то я хочу иметь возможность писать и SomeClass.someMethod(someInstance, arg1, ..., argn). Это чтобы в Array.map и т.п. передавать отвязанные функции.
2. Слабая динамика у конструкторов. Я не могу вызывать конструктор с заранее неизвестным числом аргументов. Для функции написать someFunc.apply(null, args) можно, а вот создать экземпляр var cls : Class = ..., new cls(args) где args — массив аргументов конструктора — нельзя. Приходится писать методы с фиксированным числом аргументов. Такие конструкторы парсеры внешних данных позволили бы сократить. Ну и в конфиг внешний уже далеко не все можно положить.
3. Номинативная типизация интерфейсов. Хочу структурную. И сахар для создания новых интерфейсов на базе существующих с переопределением и добавлением полей. Основное применение этой штуки — подписка и отписка от глобальной модели данных в локальных модулях. Внутри модуля подписка/отписка происходит с оберткой, после завершения работы модуля отписка происходит в одном месте. Это позволяет не особо задумываться о lifetime management внутри модуля.
Re[8]: C++, неявное преобразование signed <-> unsigned
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Слава, Вы писали:
С>>Это не ерунда, а трудно вылавливаемые баги в будующем. У нас по умолчанию W4 и работаем без варнингов.
I>Какой здесь может быть баг?:
I>
I>class X {
I> int const i_;
I>public:
I> X(int i) : i_ (i) {}
I>}; // warning C4512: 'X' : assignment operator could not be generated
I>
Модифицируем пример. Можно?
struct aa
{
int* b;
aa(int a)
{
b = new int(a);
}
~aa()
{
delete b;
b = 0;
}
};
class X {
aa const i_;
public:
X(int i) : i_ (i) {}
};
void main()
{
X x(5);
X y(x); //утечка памяти. А компилятор предупреждал....int a =0;
}
значит нельзя в copy constructor вызывать operator= - компилятор же сказал - не могу сгенерировать. Такой обьект должен быть non cpoyble
Здравствуйте, jazzer, Вы писали:
O>>>>Отсутствие единого глобального соглашения о скобках, отступах и именах. J>>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?
К>>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.
J>Я тебе и на Си с десяток таких насобираю.
В том то и дело, что с десяток. А вот для Java это единственные Code Conventions.
J>Это часть языка? Нет. J>Код, не соответствующий этим соглашениям в "других песочницах", отвергается компиляторами? Нет.
А это не важно, я не помню видел ли я Java код написанный как-то по другому.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, CreatorCray, Вы писали:
CC>>А чего именно ты этим хочешь добиться? CC>>Чтоб вызов foo<0.5>() обламывался при компиляции? FR>Конечно при этом надо учитывать особенности плавающих чисел.
Вот из-за этих особенностей в С++ этого и нет — признали слишком опасным
Тут в рантайме у людей через одного проблемы с плавающей точкой, какой уж там компайл-тайм.
0. Сверхнизкая скорость развития.
1. Примитивные типы, которые не наследуются от Object. Из за того что оптимизации по памяти вынесены на уровень типов получается геморрой.
2. Отсутствие перегрузки операторов. Ведет к появлению монстров типа BigInteger.
3. Отсутствие явного синтаксиса для immutable типов.
4. Недоделанные генерики которые прикрутили с учетом обратной совместимости.
5. Отсутствие короткого синтаксиса для замыканий. Фактически не дает пользоваться функциональщиной.
Здравствуйте, jazzer, Вы писали:
FR>>Конечно при этом надо учитывать особенности плавающих чисел. J>Вот из-за этих особенностей в С++ этого и нет — признали слишком опасным
Не вижу опасностей больших чем те уже есть.
J>Тут в рантайме у людей через одного проблемы с плавающей точкой, какой уж там компайл-тайм.
В компайл-тайм как раз проще будет, ошибка сразу проявится.