Re[3]: Python
От: Temoto  
Дата: 25.04.11 20:15
Оценка: +1
T>>Нет статической проверки типов. Да и типов по большому счёту нет. Один object с наклейками для проверок в рантайме.

A>это фича.


Это нерелевантно. Вопрос был "что не нравится", а не "назовите всё кроме фич". Но даже если потролить, мы, наверное, по-разному понимаем фичи.

Полиморфизм, замыкания, ФВП, юникодные строки, list comprehension — это фичи. Они позволяют делать то, что иначе было бы в разной степени некрасивым "многабукф".

Отсутствие типов и статической их проверки позволяет делать то же самое, что "обычные" полиморфизм, вывод типов, кодогенерация или шаблоны плюс разной степени трудноуловимые баги и существенно затрудняют оптимизации. Я не могу назвать это фичей. Это отсутствие фичи и свиду симпатичный (любое говно можно преподнести как конфету) костыль взамен. Для прототипов — самое то! Для боевого кода хочется побольше уверенности и поменьше накладных расходов. Видимо, поэтому существенная масса разрабов колются, плакают но продолжают жрать С++.
Re[4]: Python
От: Abyx Россия  
Дата: 25.04.11 21:12
Оценка: +1
Здравствуйте, Temoto, Вы писали:

... (много букф)

это называется "динамическая типизация" и это фича.
то что вы хотите от языка с динамической типизацией чтоб он был как язык со статической типизацией — означает что вы выбрали не тот язык, и не понимаете почему он так спроектирован.
In Zen We Trust
Re[2]: PHP
От: Философ Ад http://vk.com/id10256428
Дата: 25.04.11 23:32
Оценка:
Здравствуйте, dimgel, Вы писали:

Мыши кололись и плакали, но продолжали жрать кактус
Всё сказанное выше — личное мнение, если не указано обратное.
Re[7]: C# NotNullable типов
От: vdimas Россия  
Дата: 26.04.11 01:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

U>>Мы про систему типов шарпа или про проектирование языка с нуля?

WH>Один хрен там магия жуткая понадобится.
WH>Причем на ровном месте. Просто по тому что тебе так захотелось.

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

Поэтому, проверка контракта NotNull вполне решаема на зависимых типах без всяких монад Maybe, просто лишь объявление такого типа и использование его во всех вычислениях.
Re[9]: C++, неявное преобразование signed <-> unsigned
От: igna Россия  
Дата: 26.04.11 04:52
Оценка:
Здравствуйте, Abyx, Вы писали:

A>очевидно надо сделать класс noncopyable или самому реализовать оператор присваивания


Тогда вместо ошибки компиляции с точным указанием строки получим менее внятную ошибку компоновки:

class X {
    int const i_;
public:
    X(int i) : i_ (i) {}

    void f(X const& x)
    {
        *this = x;
    }
private:
    X& operator=(X const&);
};


И главное, я все же не понимаю, от каких таких багов предупреждение C4512 призвано уберечь.
Re[9]: C++, неявное преобразование signed <-> unsigned
От: igna Россия  
Дата: 26.04.11 04:59
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Там ж написано: не могу сгенерить operator=


Это же не баг. Ты из контекста не выпадай: здесь
Автор: Слава
Дата: 23.04.11
Re[28]: C#: const для переменных, pattern-matching, ...
От: Ziaw Россия  
Дата: 26.04.11 05:14
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Да я и не оспариваю это, конечно выбор и ответственность лежит исключительно на "конкретной группе людей". Так и есть.

L>Я ставлю под сомнние то, что человек, не занимающейся проектированием языков, в состоянии адекватно внести изменения в синтаксис существующего языка. Под "адекватностью" я тут имею в виду что внесенное изменение не будет "конфликтовать" с другими концепциями языка и не будет с течением времени выглядеть как нелогичная нелепица. Основанием для этих сомнений служит а) личный опыт написания (и развития) программ, генерирующих код, и б) многочисленные неадекватности и нелогичности, найденые тем же nikov-ом в шарпе и многими другими — в C++.

L>>>Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?


При всем этом на процесс разработки эти неоднозначности практически не влияют. Вероятность на них наткнуться мала, а немного подравить код, чтобы ее устранить настолько легко, что проблема выеденного яйца не стоит.

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


L>"Бредовая мантра о вреде макросов" существует только в твоей голове. Я уже уточнил, что именно я имел в виду, когда писал, что метапрограммирование — не нужно. Да, я изначально выбрал неудачную формулировку, признаю свою ошибку.


Есть руби, в котором метапрограммирование это неотъемлемая часть. Практически каждый серьезный широкоиспользуемый плагин для RoR широко использует кодогенерацию (зачастую текстовую) и свой edsl.

Практически все плагины которые не придумали (придумали плохой) edsl или не справились с кодогенерацией просто непопулярны. Для рельс практически нет платных плагинов, их разрабатывает community. Никакой катастрофы не произошло, популярность у языка и фреймворка прекрасные.

К сожалению, рубийный подход прямо не работает. Не все, что так легко делается в руби легко сделать в nemerle (обратное тоже верно).
Re[4]: C++ операция запятая
От: jazzer Россия Skype: enerjazzer
Дата: 26.04.11 05:32
Оценка:
Здравствуйте, 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 );

Очень смешно. Грамматику почитай, что ли.
  postfix-expression [ expression ]
  postfix-expression ( expression-list opt )

expression-list:
  assignment-expression
  expression-list , assignment-expression // разделитель аргументов

expression:
  assignment-expression
  expression , assignment-expression // оператор запятая


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-пальцевой слепой печати — заходи, а иначе — не надо, плиз, сходи в КСВ лучше.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[2]: C++ невозможно отличить создание временнoгo обьекта о
От: anglichanin  
Дата: 26.04.11 05:46
Оценка: -2
Здравствуйте, Слава, Вы писали:
С>C++ невозможно отличить создание временнoгo обьекта от вызова функции:

С>int a = foo(B(x)); — что здесь B(x) ?


Не стоит приводить примеры из студенческих лабораторных. Любой инструмент можно испортить культурой его использования.
Re[29]: C#: const для переменных, pattern-matching, ...
От: Lloyd Россия  
Дата: 26.04.11 05:55
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Есть руби, в котором метапрограммирование это неотъемлемая часть. Практически каждый серьезный широкоиспользуемый плагин для RoR широко использует кодогенерацию (зачастую текстовую) и свой edsl.


Z>Практически все плагины которые не придумали (придумали плохой) edsl или не справились с кодогенерацией просто непопулярны. Для рельс практически нет платных плагинов, их разрабатывает community. Никакой катастрофы не произошло, популярность у языка и фреймворка прекрасные.


Z>К сожалению, рубийный подход прямо не работает. Не все, что так легко делается в руби легко сделать в nemerle (обратное тоже верно).


Ну, может быть я действительно чрезчур критично отношусь к опасности этого подхода.
Re[3]: Студенческие лабораторные
От: Qbit86 Кипр
Дата: 26.04.11 05:55
Оценка:
Здравствуйте, anglichanin, Вы писали:

С>>C++ невозможно отличить создание временнoгo обьекта от вызова функции:

С>>int a = foo(B(x)); — что здесь B(x) ?

A>Не стоит приводить примеры из студенческих лабораторных. Любой инструмент можно испортить культурой его использования.


При чём тут студенческие лабораторные? Даже в стандартной библиотеке можно найти подобные примеры, типа back_inserter/back_insert_iterator.
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: C++
От: FR  
Дата: 26.04.11 06:08
Оценка:
Здравствуйте, CreatorCray, Вы писали:


CC>Дык для Windows есть считай стандартизированый ABI — MSVC.


Хотелось, бы но именно бинарного даже в пределах MSVC для C++ нету.
Re[5]: C++
От: FR  
Дата: 26.04.11 06:17
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>А чего именно ты этим хочешь добиться?

CC>Чтоб вызов foo<0.5>() обламывался при компиляции?

D не обламывается http://www.digitalmars.com/d/2.0/templates-revisited.html

import std.stdio;

template factorial(double n) if (n > 1.0)
{
  const factorial = n * factorial!(n-1);
}

template factorial(double n) if (n <= 1.0)
{
  const factorial = 1.0;
}


void main()
{
  writeln(factorial!(4));
}


Конечно при этом надо учитывать особенности плавающих чисел.
Re: ActionScript 3.0
От: maxkar  
Дата: 26.04.11 20:18
Оценка:
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
От: Слава Израиль  
Дата: 26.04.11 20:51
Оценка:
Здравствуйте, 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
Спасибо за внимание
Re[5]: C++
От: GarryIV  
Дата: 26.04.11 23:03
Оценка:
Здравствуйте, jazzer, Вы писали:

O>>>>Отсутствие единого глобального соглашения о скобках, отступах и именах.

J>>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?

К>>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.


J>Я тебе и на Си с десяток таких насобираю.

В том то и дело, что с десяток. А вот для Java это единственные Code Conventions.

J>Это часть языка? Нет.

J>Код, не соответствующий этим соглашениям в "других песочницах", отвергается компиляторами? Нет.

А это не важно, я не помню видел ли я Java код написанный как-то по другому.
WBR, Igor Evgrafov
Re[6]: C++
От: jazzer Россия Skype: enerjazzer
Дата: 27.04.11 00:16
Оценка:
Здравствуйте, FR, Вы писали:

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


CC>>А чего именно ты этим хочешь добиться?

CC>>Чтоб вызов foo<0.5>() обламывался при компиляции?
FR>Конечно при этом надо учитывать особенности плавающих чисел.
Вот из-за этих особенностей в С++ этого и нет — признали слишком опасным
Тут в рантайме у людей через одного проблемы с плавающей точкой, какой уж там компайл-тайм.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: C++, неявное преобразование signed <-> unsigned
От: igna Россия  
Дата: 27.04.11 05:43
Оценка:
Здравствуйте, Слава, Вы писали:

С>struct aa
С>{
С>    int* b;
С>    aa(int a)
С>    {
С>        b = new int(a);
С>    }
С>    ~aa()
С>    {
С>        delete b;
С>        b = 0;
С>    }
С>};


Этого достаточно, смотри:

int main() 
{
    aa x(5);
    aa y(x); //утечка памяти. И даже компилятор не предупреждает...
}


Мой класс тут ни при чем, баг в твоем.

PS. Возвращаемое значение функции main — int, а не void.
Re: Java
От: Miroff Россия  
Дата: 27.04.11 05:53
Оценка:
Здравствуйте, Философ, Вы писали:

0. Сверхнизкая скорость развития.
1. Примитивные типы, которые не наследуются от Object. Из за того что оптимизации по памяти вынесены на уровень типов получается геморрой.
2. Отсутствие перегрузки операторов. Ведет к появлению монстров типа BigInteger.
3. Отсутствие явного синтаксиса для immutable типов.
4. Недоделанные генерики которые прикрутили с учетом обратной совместимости.
5. Отсутствие короткого синтаксиса для замыканий. Фактически не дает пользоваться функциональщиной.
Re[7]: C++
От: FR  
Дата: 27.04.11 08:54
Оценка:
Здравствуйте, jazzer, Вы писали:

FR>>Конечно при этом надо учитывать особенности плавающих чисел.

J>Вот из-за этих особенностей в С++ этого и нет — признали слишком опасным

Не вижу опасностей больших чем те уже есть.

J>Тут в рантайме у людей через одного проблемы с плавающей точкой, какой уж там компайл-тайм.


В компайл-тайм как раз проще будет, ошибка сразу проявится.

И если уж поддерживаешь Compile Time Function Execution (CTFE) (C++0x constexpr)
то и поддержка плавающих чисел и строк в параметрах шаблонов логична.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.