Здравствуйте, Аноним, Вы писали:

I>>Очень интересно, особенно с учетом того, что "паттерны" есть даже в естественном языке.

А>Ха, отличный пример — естественный язык! Естественные языки гораздо хуже, избыточнее и непоследовательнее, чем самые плохие из формальных искусственных языков.

Шо, в самом деле ?

Смотри: "рейз на флопе" — сразу ясно, что к чему. Куда ты собираешься бежать от таких паттернов ?

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

А>>Ха, отличный пример — естественный язык! Естественные языки гораздо хуже, избыточнее и непоследовательнее, чем самые плохие из формальных искусственных языков.

I>Шо, в самом деле ?
I>Смотри: "рейз на флопе" — сразу ясно, что к чему. Куда ты собираешься бежать от таких паттернов ?

Нечего возразить? Предлагаю революционную идею: признать, что оппонент прав. Надо бы учиться уже культурно дискутировать в XXI веке.

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

EP>>2. C++11 должен быть и выше и правее C++98 — быстрый код стало легче писать.
AK>Он и так выше. А почему он должен быть правее-то?
AK>С++11 позволяет выжать из железа тоже самое, что и С++98

Язык C позволяет выжать из железа тоже самое, но это потребовало бы целое болото кода. По факту же на C в основном используют runtime полиморфизм, там где в C++ легко обходятся статикой.
На Java/C# тоже можно писать очень быстрый код — для этого нужно отказаться практически от всего, и использовать один большой массив байт как кучу и стэк, всё вручную.

AK>, просто облегчает процесс написания кода.

Это "облегчает" дорогого стоит. Именно из-за отсутствия "облегчает" многие языки являются тормозными.

C++11 (а тем более C++14) как раз сильно облегчает написание быстрого кода:
1. auto/decltype — раньше вывод типов был доступен только при вызове шаблонов функций, а сейчас везде. Раньше нужно было либо использовать type-erasure (что дорого в runtime), либо добавлять дополнительные вызовы (что неудобно).
2. Лямбды — если раньше boost::bind на member function был распространён, то сейчас его заменяют лямбды — что более производительно.
3. rvalue references — есть возможность просто скомпилировать старый код новым компилятором получить и ускорение.
4. Появился perfect forwarding, который раньше использовался редко через эмуляцию. Это позволяет легко писать штуки типа vector::emplace_back

EP>>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код.
AK>Вы пробовали? У вас получалось легко писать код на JavaScript?

Пробовал. Часто использую Python, иногда JavaScript — и там и там вижу преимущества динамики.

AK>Я про практическую часть спрашивал. У меня JS-код шёл с большим скрипом. Забытая скобочка или, хуже того, опечатка в имени элемента — проявлялись лишь после запуска приложения. А мне нужно было писать часть, которая делает снимки фото-камерой и заливает результат на сервер. Отлаживать приходилось в эмуляторе — "сохранить, скомпилить, перезапустить, ввести все параметры.." И только после этого увидеть в консоли сообщение, что оно не нашло такого элемента.

Unit test'ы и покрытие для динамики более критичны чем для статики.

Здравствуйте, Аноним, Вы писали:

EP>>На C#/Java обобщённый код особо не получается

Автор: Evgeny.Panasyuk
Дата: 04.11.13

. На C++ с этим всё нормально, но приходится то тут, то там подсказывать компилятору (auto, decltype, template, etc).
А>Чтобы проверить корректность типизации, нужно ввести ограничения, а, точнее, объяснить компилятору свои намерения формально, чтобы он и мог выполнить проверки. Ничего удивительного, что не получается написать нонсенс вроде "обобщенная функция с непонятно какой сигнатурой".

На C++ я спокойно могу написать функцию которая получает на вход функциональный объект, произвольный набор аргументов, применяет аргументы к функциональному объекту и возвращает результат, <b>со всеми статическими проверками</b>:

#include <iostream>

template<typename F, typename ...Args>
auto apply(F f, Args... args)
{
    return f(args...);
}

double foo(int x, double y)
{
    return x + y;
}

int main()
{
    std::cout << apply(foo, 1, 0.1);
}

Тоже самое возможно и в динамике, только менее многословно (сравни apply):

def apply(f, *args):
    return f(*args)

def foo(x, y):
    return x + y

print apply(foo, 1, 0.1)

EP>>На языках с динамической типизацией этот обобщённый код получается легко и непринуждённо, но приносятся в жертву compile-time проверки.
А>Здесь, собственно, нет никакого противопоставления: указываешь типы — получаешь проверки, не указываешь — не получаешь.

В примере выше на C++ типы не указанны, при этом все проверки происходят compile-time
Да и вообще, в большинстве кода явные типы не обязательны — и это отнюдь не означает потерю статических проверок.

А>Я предпочитаю проверки,

Я думаю все предпочитают compile-time проверки.

А>ибо код, который просто написан, и для которого нет никакого обоснования корректности — бесполезен, а именно с этим и возникают проблемы.

Хм, обоснования корректности? Ты можешь хотя бы обосновать что произвольный код на Тьюринг-полном языке со статическими проверками останавливается?

А>После статически типизированного языка программировать на динамическим как-то неуютно из-за невозможно проверить даже базовую корректность без запуска.

Я пишу и на C++, с огромным количеством статических проверок, и на динамических языках.
Везде просто нужен свой подход.

А>Код не только пишется, но еще и читается, меняется, исполняется и отлаживается.
А>Да и вообще, программа с тотальным отсутствием типов и читается-то хуже, потому что программисту, читающему код, нужно тоже выводить типы, чтобы понять, что код делает.
А>Например, что делает данная фукнция:
А>

А>function concatenate(a, b);
А>

А>А если так:
А>

А>Matrix3x3 concatenate(Matrix3x3 a, Matrix3x3 b);
А>

А>Я не знаю, каким изощренным и неземным мышлением надо обладать, чтобы сказать, что с кодом в стиле первого фрагмента работать проще?

Если у тебя concatenate работает с одним единственным типом — то лучше со вторым.
Если же это намного более мощная обобщённая функция, которая работает с разными типами, не прибитыми наследованием к конкретному интерфейсу, то второй вариант никак не получится.
Лучше всего его описать на концепциях C++:

template<SemiGroupElement T>
T concatenate(T a, T b);

А пока нет концепций, используем первый вариант:

template<typename SemiGroupElement>
SemiGroupElement concatenate(SemiGroupElement a, SemiGroupElement b);

А>Ну и про обобщенный код: что, кто-то хочет сказать, что раз функция в первом фрагменте такая вся из себя обобщенная, не должна ли она тогда конкатенировать все подряд: и строки, и матрицы, и списки, и массивы, и звуковые файлы, и еще черт знает что? Слабо написать такую обобщенную функцию?

Не слабо, вот конкретный пример:

template <class T, class Integer, class MonoidOperation>
T power(T x, Integer n, MonoidOperation op);

Это функция возводит x в заданную целую степень n, причём делает это достаточно оптимальным способом.
Ах да, и работает она и с целыми, и с матрицами, и со строками, и списками, и звуковыми файлами.

EP>>Собственно код на языках со статической типизацией с каждым годом становится похож на код языков с динамической типизацией (например полиморфные лямбды в C++14, или те же лямбды в C# — удобно ведь). Но динамические языки — это то что доступно здесь и сейчас.
А>Просто некорректное сравнение. Статическая типизация все равно остается статической, так что динамические языки — это не то, "что доступно здесь и сейчас", а скорее "не хотите ли вы из кареты пересесть в телегу".

Чем же оно некорректное?
Вот Python'ская лябмда:

foo(lambda x: bar(x, 1))

Вот C#:

foo(x => bar(x, 1));

C++:

foo([](auto x){ return bar(x, 1); });

Вопрос — какой тип у параметра лямбды?

А>Для тебя это привлекательно звучит по какой-то причине, для других — не уверен, например, для меня — не особо.

Да мне если честно параллельно кому это привлекательно, а кому нет.
Но факт остаётся фактом — обобщённый код на языках со статической типизацией сильно похож (отсутствием конкретных типов) на код в динамических языках.

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

VD>>Жабаскрип без ЖЦ обходится. Но это ему не шибко помогает.

A>А как же тогда в JavaScript менеджится память?

На подсчете ссылок, вестимо. До недавнего времени многие реализации так были сделаны.

Я это к тому говорил, что Жабахрип он тормозом родился, тормозом и помрет. Наличие или отсутствие ЖЦ на это не сильно влияет. Главные источники тормозов в нем — это динамическая типизация и динамическая природа хранения информации. Это ограничивает оптимизации примитивными вычислениями.

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

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

DM>Давно проверял?
DM>Эта проблема была очень давно, и мне казалось, ее уже давно исправили.

Вообще не проверял. Слышал год назад от тех кто плотно использует Скалу. Уверен, что ничего не изменится пока они for на макросах не перепишут. Но они вроде как пока только в тестовом режиме идут. Или я отстал от жизни?

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

VD>>Жабаскрип без ЖЦ обходится.

DM>Это где такой?

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

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

I>И давно ?

С самого своего существования, если конечно, не считать подсчет ссылок видом ЖЦ.

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

EP>На C#/Java обобщённый код особо не получается

Автор: Evgeny.Panasyuk
Дата: 04.11.13

.

Там речь о небольшой недоработке языка. В Nemerle с этим проблем нет.

Что до обобщенного кода, то это палка о двух концах. Простота написания обобщенного кода в динамических языках это как плюс, так и минус, так как любой код получается обобщенным, что требует больше контроля со стороны разработчиков. В итоге из-за этого разработка больших сильно связанных проектов почти невозможны на динамических языках. Сайты живут за счет слабой связанности (каждая страница как отдельное приложение контачащее с другими через интерфейс).

EP>На C++ с этим всё нормально, но приходится то тут, то там подсказывать компилятору (auto, decltype, template, etc).

На С++ как раз все совсем не нормально. У него присутствуют некоторые плохие черты динамики — типы не всегда проверяются в момент их описания. Шаблоны проверяются только при раскрытии. А это усложняет диагностику ошибок, ухудшает интеллисенс (усложняет его реализацию) и создает прочие проблемы.

EP>Собственно код на языках со статической типизацией с каждым годом становится похож на код языков с динамической типизацией (например полиморфные лямбды в C++14, или те же лямбды в C# — удобно ведь). Но динамические языки — это то что доступно здесь и сейчас.

Лябды не имеют отношения к стаике или динамике. Как и полиморфизм. К динамике имеет отношение исключительно динамическая интерпретация типа "объектов". Весь полиморфизм в динамических языках на ней основан. Но как я уже сказа выше, это палка о двух конца. И мне ее второй конец не нравится сильно больше чем первый.

VD>>Я предпочитают статические проверки типов и качественный интеллисес.

EP>Я думаю все предпочитают статические проверки.

Нет. Я видел не мало людей которые думают иначе. Иначе не было бы столько поклонников Руби, Питона, ПХП, Лиспа.

В динамике намного проще использовать метапрограммирование, например. Хорошее МП в статических языках пока что есть только Немерле. И то там есть что дорабатывать.

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

VD>>Это ты расскажи тем кто Хорм в Гуле пилит. Они в итоге замаялись с тормозным и глючным посчетом ссылок и запилили ЖЦ для плюсов. Убогий конечно, но для их задач все равно лучше чем то что можно сделать в плюсах без него.

EP>А есть ссылка?

здесь

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

I>Похоже этот ЖЦ настолько убог, что нет никакой возможности даже проверить его работоспособности, ибо DOM ведёт себя так, как будто этот ЖЦ сделан целиком и полностью на счетчиках ссылок.

Его просто еще нет в релизном Хроме. Но обещают в скором времени это исправить.

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

VD>>Жабаскрип без ЖЦ обходится.

AVK>Оно и видно:
AVK>https://developers.google.com/v8/design#garb_coll
AVK>http://blogs.msdn.com/b/ericlippert/archive/2003/09/17/53038.aspx

Это последние версии. А на протяжении 10 лет он жил на подсчете ссылок и не чавкал.

Короче, его тормоза далеко не в ЖЦ кроются. Там база гнилая.

Здравствуйте, Евгений Акиньшин, Вы писали:

I>>Вообще эта хрень пролазит уже в мобайл, не сильно в курсе какие успехи.

ЕА>Ничего не понял — чем бы помешал единый способ работы с потоками везде, включая браузер и какая поддержка им нужна?

Тебя не смущает, что браузер пока что, в общем виде, не поддерживает файловые операции в хтмл-страницах ? Сами по себе стримы это всего лишь одна из многих вычислительных моделей, которая в браузерных приложениях очень слабо задействована.

Идея простая — в приложение идёт только то, что реально используется. Незачем создавать аналог флеша или сильверлайта но на джаваскрипте.

I>>следующем стандарте. INotifyPropertyChanged при желании реализуется очень просто — где надо, берёшь и файришь эвент

ЕА>Ну так я о том же: каждый у кого возникает желание, придумывает свой, ни с чем не совместимый евент\листенер и потом сиди пиши переходники между ними.

Это больше домыслы. В основном эвенты и листенеры хорошо совместимы.

I>>А зачем они нужны ?

ЕА>Деньги считать

И указателей и всякого другого мусора тоже нет.

I>>>>Динамика дает возможности, которых в C# нет и никогда не будет

ЕА>>>Например?

I>>метапрограммирование в рантайме. На этом сделана целая куча либ.

ЕА>Ну так в си-шарпе это тоже частенько используется — начиная от компиляции лямбд и кончая полноценной кодогенерацией с запуском компилятора. Понятно, что в динамике это будет удобнее делать, но "нет и никогда не будет" это перебор.

Покажи как на C# пропатчить Console.Write

Здравствуйте, Аноним, Вы писали:

А>>>Ха, отличный пример — естественный язык! Естественные языки гораздо хуже, избыточнее и непоследовательнее, чем самые плохие из формальных искусственных языков.

I>>Шо, в самом деле ?
I>>Смотри: "рейз на флопе" — сразу ясно, что к чему. Куда ты собираешься бежать от таких паттернов ?

А>Нечего возразить? Предлагаю революционную идею: признать, что оппонент прав. Надо бы учиться уже культурно дискутировать в XXI веке.

Я привел пример паттерна. Покажи каким языком ты собираешься его искоренить.

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

EP>>На C#/Java обобщённый код особо не получается

Автор: Evgeny.Panasyuk
Дата: 04.11.13

.
VD>Там речь о небольшой недоработке языка. В Nemerle с этим проблем нет.

На C#/Java получится ли сделать нечто похожее на apply:

template<typename F, typename ...Args>
auto apply(F f, Args... args)
{
    return f(args...);
}

без сильного ухода в динамику?
А во многих динамических языках это доступно уже десятки лет.

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

Согласен — это недостаток.

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

А вот это неясно откуда следует.

EP>>На C++ с этим всё нормально, но приходится то тут, то там подсказывать компилятору (auto, decltype, template, etc).
VD>На С++ как раз все совсем не нормально.

Это контр-пример того, что отсутствие явного указания типов обязательно ведёт к ошибкам в runtime.

VD>У него присутствуют некоторые плохие черты динамики — типы не всегда проверяются в момент их описания. Шаблоны проверяются только при раскрытии. А это усложняет диагностику ошибок, ухудшает интеллисенс (усложняет его реализацию) и создает прочие проблемы.

Это действительно создаёт проблемы, которые требуют внимания — например, тестирования на архитипах.

EP>>Собственно код на языках со статической типизацией с каждым годом становится похож на код языков с динамической типизацией (например полиморфные лямбды в C++14, или те же лямбды в C# — удобно ведь). Но динамические языки — это то что доступно здесь и сейчас.
VD>Лябды не имеют отношения к стаике или динамике. Как и полиморфизм. К динамике имеет отношение исключительно динамическая интерпретация типа "объектов". Весь полиморфизм в динамических языках на ней основан.

Ты про содержание, а я же говорю про форму (то с чем работает программист):

foo([](auto x){ return bar(x, 1); });

foo(lambda x: bar(x, 1))

Разве не видно что статика по форме, становится похожа на динамику? Конкретные типы указываются всё реже и реже.

VD>>>Я предпочитают статические проверки типов и качественный интеллисес.
EP>>Я думаю все предпочитают статические проверки.
VD>Нет. Я видел не мало людей которые думают иначе. Иначе не было бы столько поклонников Руби, Питона, ПХП, Лиспа.

А из-за чего они думают иначе?
Они действительно против статической проверки (и принципиально не гоняют свой код по статическим анализаторам типа pylint)?
Или же они просто за те возможности которые дают динамические языки здесь и сейчас?
Это разные вещи.

VD>В динамике намного проще использовать метапрограммирование, например. Хорошее МП в статических языках пока что есть только Немерле. И то там есть что дорабатывать.

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

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

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

I>>И давно ?

VD>С самого своего существования, если конечно, не считать подсчет ссылок видом ЖЦ.

У тебя сведения из середины 90х

http://lmgtfy.com/?q=javascript+garbage+collection

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

VD>Это последние версии.

Последние? Ты по ссылкам то сходи — статья про JScript от 2003 года. Да и V8 релизнули в 2008 году.


VD>Короче, его тормоза далеко не в ЖЦ кроются. Там база гнилая.

Ну, Даффи довольно много спорных утверждений там сделал. Бог с ним, с тормозами, тем более что он таки там самый тормозной на графике, но вот как у него safety оказалась выше и шарпа и джавы — вот это куда интереснее. И ответа на этот вопрос в его статье нет.

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

I>Покажи как на C# пропатчить Console.Write

А зачем?

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

I>Пример

I>

I>var f = (int x) => x * 2;
I>

I>

И что этот пример должен показать?

I>Вот есть у тебя метод
I>

I>void Write(string data) {}
I>

I>Покажи код на CodeDom, который пропатчит метод нужного экземпляр или класс и будет дополнительно файрить эвент.

http://msdn.microsoft.com/en-us/library/hh549175.aspx

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

EP>Язык C позволяет выжать из железа тоже самое, но это потребовало бы целое болото кода.

На графике это вертикальная ось, а не горизонтальная