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

D>>Что-то мне подсказывает, что ты неправ, потому что как при выводе типов, так и при проверки их согласованности используются формальные алгоритмы с известными свойствами. Но это пусть лучше "теоретики" ответят.

FR>Если не знаешь, то про демагогию лучше промолчать.

Влад описывал алгоритм вывода типов совсем недавно, через итеративное решение неполной системы, и это отдельный этап. Проверка согласованности типов выполняется в любом случае. Компилятор скалы после вывода типов проверят сначала корректность программы в системе типов скалы, а потом отдельно — в системе типов жавы, т.к. компиляция идёт под JVM. Про математические гарантии системы типов я взял фразу у Мартина Одерски, автора скалы. (Я понимаю, что для тебя он тоже ламер, демагог и теоретик, ну извините, чем богаты. Ты сам наверное куда больше языков разработал, чем Одерски и Влад с WolfHound-ом вместе взятые.)

FR>В веб я ни в зуб ногой так что ничего ни могу сказать. В desktop все удобно и просто.

В desktop, чтобы тестировать user interaction, ты должен делать эмуляцию действий пользователя. "Кликнуть по такому-то контролу, затем ввести что-то в такое-то поле, затем проверить что в такой-то области появился такой-то текст". Проще, но не сильно.

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

FR>Чуть выше показали на шаблонах C++.

Чуть выше ответили так же, что в шаблонах используется динамическая типизация. Generics в скале таких проблем не имеют, там можно указывать вариантность и lower/upper bounds, контроль 100%-ный и внутри generic-методов, и при вызове.

FR>Бессмысленно проверено 1001 раз.

Именно.

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

V>Значимость парадокса Блабла ИМХО преувеличена. Этот парадокс скорее применим к студенту 1-го курса, пока он прошел только тройку императивных языков по программе, и ему еще не прочитали другие языки и парадигмы. Потому как после 2-3-го курса профильного обучения с его Лиспами, Прологами, ИИ, базами знаний и курсовыми по разработке "запчастей" компиляторов, остальное выглядит как "где-то я ЭТО уже видел".
Это не правда.
Вон посмотри на Дворкина с Лаптевым. Они блин профессоры!
Но один застрял в С++ другой в обероне.
И ничего за их приделами не видят.

V>Тем более что налицо следующее наблюдение: значительный прирост производительности программиста дает не столько язык, сколько наличие хороших библиотек и инструментария вокруг него.
Вот только ты сильно преуменьшаешь значимость языка.
Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.

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

FR>>Чуть выше показали на шаблонах C++.
D>Чуть выше ответили так же, что в шаблонах используется динамическая типизация.

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

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

WH>>Ну так где аргументы то?
WH>>Есть только один: Меньше кода.
WH>>Но это по сравнению с жабой меньше. А по сравнению с немерле экономии почти нет.
WH>>А какие еще? Ну, хоть один.

FR>Практика.

Это демагогия, а не аргументы. Практика у всех своя. Практика дельфистов говорит, что дельфи — самый лучший из языков. Практика PHP-ников с восемью классами среднего образования говорит, что на PHP можно написать всё что угодно. Аргументы-то где?

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

U>>И сколько языков нужно изучить, чтобы это понять?
L>Очевидно, нисколько. О чем ты вообще?

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

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

NB>весь интерфейс используемый в функции переписывают?
NB>этож застрелиться можно.
NB>я думал это си — многословный язык, ан нет.
Ты о чем?
Это будет прописано один раз.

contract FooBar
{
    void bar();
}

Это вообще часть стандартной библиотеки.

template<class Value>
contract iterator
{
    Value* operator->();
}

Остается это

template<class Iterator, class Value> 
where Iterator : iterator<Value>
where Value : FooBar

Но тут ни куда не деться.

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

WH>Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.

Если сущностей в коде в десять раз меньше, а не буковок.

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

WH>>Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.
U>Если сущностей в коде в десять раз меньше, а не буковок.

Кстати если сущностей столькоже, а кода очень мало получается наоборот. Кто поймёт собственный Regexp написанный месяц назад?

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

A>Структурная, а не динамическая. Это разыне вещи. Там типизация статическая (ты не можешь добавить метод классу в рантайме, шаблон не будет использовать метод из наследника) и структурная.
Для тебя, похоже, новость, что типы имеют свои типы.
И типы типов в С++ описать нельзя.
Как следствие вычисление типов динамически типизированное.

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

FR>>Если не знаешь, то про демагогию лучше промолчать.

D>Влад описывал алгоритм вывода типов совсем недавно, через итеративное решение неполной системы, и это отдельный этап. Проверка согласованности типов выполняется в любом случае. Компилятор скалы после вывода типов проверят сначала корректность программы в системе типов скалы, а потом отдельно — в системе типов жавы, т.к. компиляция идёт под JVM. Про математические гарантии системы типов я взял фразу у Мартина Одерски, автора скалы. (Я понимаю, что для тебя он тоже ламер, демагог и теоретик, ну извините, чем богаты. Ты сам наверное куда больше языков разработал, чем Одерски и Влад с WolfHound-ом вместе взятые.)

Нет, а вот твой тупой переход на личности мне очень не нравится, хотелось бы чтобы модераторы придерживались такого же мнения.
Ладно бы еще тонко тролил
Ну и если про авторитеты, в математике я буду доверять больше Дж. Митчелу а не Мартиу Одерски, при всем моем к нему уважении.

FR>>В веб я ни в зуб ногой так что ничего ни могу сказать. В desktop все удобно и просто.

D>В desktop, чтобы тестировать user interaction, ты должен делать эмуляцию действий пользователя. "Кликнуть по такому-то контролу, затем ввести что-то в такое-то поле, затем проверить что в такой-то области появился такой-то текст". Проще, но не сильно.

Зависит от приложения.

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

WH>>Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.

U>Если сущностей в коде в десять раз меньше, а не буковок.

ИМХО эти вещи до некотороый степени взаимосвязаны. Там где я в ФП могу написать `val strings = ints.map(_.toStrings)`, на императивном языке я буду вынужден корёжиться с циклом (сорри, вы тут неподалёку что-то похожее в тему обсуждали, но мне в вашу тему вчитываться лениво). И сущностей меньше, и букв.

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

A>>Структурная, а не динамическая. Это разыне вещи. Там типизация статическая (ты не можешь добавить метод классу в рантайме, шаблон не будет использовать метод из наследника) и структурная.
WH>Для тебя, похоже, новость, что типы имеют свои типы.

Тебе есть что сказать по существу? Я где-то не прав?

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

NB>>весь интерфейс используемый в функции переписывают?
NB>>этож застрелиться можно.
NB>>я думал это си — многословный язык, ан нет.
WH>Ты о чем?
WH>Это будет прописано один раз.
WH>

WH>contract FooBar
WH>{
WH>    void bar();
WH>}
WH>

именно об этом. если в функции еще используется bar1 и bar2 то их тоже придется описать (опять же здесь или в отдельном контракте?)
если в отдельном контракте то опять их все перечислять в функции.
если в этом, то в другой функции придется создавать свой контракт.
засорять пространство имен.

этого никто не будет делать.

WH>Это вообще часть стандартной библиотеки.
WH>

WH>template<class Value>
WH>contract iterator
WH>{
WH>    Value* operator->();
WH>}
WH>

с этим не спорю.

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

WH>>Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.
U>Если сущностей в коде в десять раз меньше, а не буковок.
Ессно я не имею в виду шифрование исходников сжатием имен в однобуквенную хрень.
И если код написан нормально и он в 10 раз меньше то вывод о том что из него убрали, напрашивается сам собой.

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

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

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

FR>Ну и если про авторитеты, в математике я буду доверять больше Дж. Митчелу а не Мартиу Одерски, при всем моем к нему уважении.

Ну а я буду больше доверять Одерски, чем тебе. И прежде всего — своему опыту использования языков. Ок?

D>>В desktop, чтобы тестировать user interaction, ты должен делать эмуляцию действий пользователя. "Кликнуть по такому-то контролу, затем ввести что-то в такое-то поле, затем проверить что в такой-то области появился такой-то текст". Проще, но не сильно.

FR>Зависит от приложения.

Во, прогресс, уже "зависит от", без оголтелого отрицания самой возможности существования ситуаций, когда тесты себе дороже.

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

FR>>Практика.

D>Это демагогия, а не аргументы. Практика у всех своя. Практика дельфистов говорит, что дельфи — самый лучший из языков. Практика PHP-ников с восемью классами среднего образования говорит, что на PHP можно написать всё что угодно. Аргументы-то где?

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

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

NB>именно об этом. если в функции еще используется bar1 и bar2 то их тоже придется описать (опять же здесь или в отдельном контракте?)
NB>если в отдельном контракте то опять их все перечислять в функции.
NB>если в этом, то в другой функции придется создавать свой контракт.
NB>засорять пространство имен.
Если говорить не об абстрактных bar, baz итп то выяснится что у нас есть вполне определенный контракт, которому должны соответствовать объекты, попадающие в библиотеку.
Практика языков, где по-другому не сделать говорит, что это никого не напрягает и занимает намного меньше места, чем ты себе напридумывал.

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

A>Тебе есть что сказать по существу? Я где-то не прав?
Так я вроде по существу и сказал.
Что не ясно?

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

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

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

Прикольно я тоже общаюсь с фанатиком.
Теоретизм наших уважаемых модераторов в динамике это не переход на личности а факт.