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

A>>В шаблонах Си++ структурная типизация. То есть, если говорить проще, факт использования типа влияет на процесс его рефакторинга.
D>А можешь примерчик нарисовать для иллюстрации? А то я не въехал.
В С++ типы динамически типизированы.
Вот у нас есть template<class T>. И это все что у нас есть. Про тип T мы ничего не знаем пока его нам не дадут и мы не начнем компилировать данный шаблон с данным типом.
И нет никакой возможности задать какие у типа должны быть методы.
Какие вложенные типы итп.

Порутчикам: Про хаки, которыми можно что-то вытащить, мне рассказывать не надо (я сам про них кому угодно могу рассказать). Ибо они начинают работать, когда нам уже тип подсунули.

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

FR>>Юнит тесты в динамике да необходимы, но не тонны, их размер будет вполне сопоставим с размером оных для статики.

D>Гыгы, нуну. -1.

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

FR>>Тесты в этом вполне рулят.

D>Пишите, Шура, пишите, они золотые.

Жаль, мне ты казался более вменяемым

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

WH>Порутчикам: Про хаки, которыми можно что-то вытащить, мне рассказывать не надо (я сам про них кому угодно могу рассказать). Ибо они начинают работать, когда нам уже тип подсунули.

Жаль что эти редиски из комитета концепты зарубили

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

WH>>Тесты гонять?
FR>Да.
WH>>А где гарантия, что покрытие 100%?
FR>100% гарантии теперь даже в банках не дают.

Демагогия detected. Система типов именно что даёт математически доказанные гарантии.

FR>В данном случае да статика(вернее ее подмножество) рулит.

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

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

U>Вот более удачный пример. В шарпе есть такая функция string.Join, которая благодаря гениальным программистам из МС принимает только массив строк и ничего другого. В результате при использовании этой функции типичным является такой код:

U>

U>List<string> itemsAsString = new List<string>();
U>foreach (int item in items)
U>  itemsAsString.Add(item.ToString());
U>return string.Join(", ", itemsAsString.ToArray());
U>

U>Объясни сколько языков нужно знать для того, чтобы понять, что весь код относящийся к созданию промежуточного массива строк является мусорным?

Достаточно знать, что в 4.0 это исправили.

U>Также объясни сколько языков нужно знать для того, чтобы понять, что даже в C# 1.0 можно было написать функцию: string MyJoin(string separator, string format, IEnumerable items), которая позволила бы избавиться от мусорного кода, хотя бы в простых (но очень распространенных) случаях?

к чему относится format?

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

L>Корректный ответ на этот вопрос можно дать только зная язык.
L>Далее — см. парадокс Блаба.

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

Тем более что налицо следующее наблюдение: значительный прирост производительности программиста дает не столько язык, сколько наличие хороших библиотек и инструментария вокруг него. Джава или дотнет тому пример. Имеем тупые, как пробка, языки (по крайней мере C# в прошлых версиях), но мильон библиотек под все случаи жизни + одна из самых неплохих на сегодня IDE в сумме делают из тупейшего языка просто чудеса в плане производительности программиста. И даже миллионы индусов стали кому-то полезны. Значит, дело не столько только в языке, сколько в инфраструктуре: помимо среды и библиотек это доступный хороший справочный материал, форумы, книги, мильон примеров по интернету на все случаи жизни и т.д. Все это создает уверенность, что взяв этот язык вдруг не упрешься по ходу разработки в нечто, значительно прибавляющее трудоемкости и геммороя.

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

WH>>Порутчикам: Про хаки, которыми можно что-то вытащить, мне рассказывать не надо (я сам про них кому угодно могу рассказать). Ибо они начинают работать, когда нам уже тип подсунули.

FR>Жаль что эти редиски из комитета концепты зарубили

жаль то оно конечно жаль, но обсуждаемую проблему концепты бы не решили.

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

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

FR>Плюс абстрактная интерпретация которая позволяет нам смотреть только на нужные для данного действия аспекты и отбрасывая несущественные.
И нахрена козе баян если нормальные языки и так все проверяют?

WH>>Отсюда вывод: Код по факту статически типизирован. Но компилятору об этом почему-то ничего не говорят.
FR>Нет в целом код может быть не типизирован статически.
Мне ни кто, ни разу не привел пример когда динамическая типизация нужны.
Ближе всех был мыщъх с очень узкой задачей декодирования жабоскрипта. Для этого он использовал интерпритатор жабоскрипта чтобы скрипт сам себя декодировал.
Остальные не показали ничего. Ни разу.

FR>утиную типизацию вместо интерфейсов
И как оно мне поможет найти места, где код править надо?

FR>В данном случае да статика(вернее ее подмножество) рулит.
Она всегда рулит.

FR>Все таки 1001 раз это все уже уныло.
Аргументов как не было так и нет.

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

FR>>>Юнит тесты в динамике да необходимы, но не тонны, их размер будет вполне сопоставим с размером оных для статики.

D>>Гыгы, нуну. -1.

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

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

FR>>>Тесты в этом вполне рулят.
D>>Пишите, Шура, пишите, они золотые.
FR>Жаль, мне ты казался более вменяемым

Ну, сорри, что разочаровал. Я не спец по языкам и компиляторам, но зато я практик, гы, в отличие от этих "теоретиков" Влада и WolfHound-а.

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

NB>жаль то оно конечно жаль, но обсуждаемую проблему концепты бы не решили.
Именно они и должны были ее решить. Хотябы частично.
Ибо они по факту классы типов (привет хаскелю) для типов.

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

A>>Какие рефакторинги поддерживает интеграция Немерле?
WH>Переименование.

Я вот думал, что VS поддерживает переименование в C#. А потом поставил ReSharper и узнал о преименовании много нового . Хотя я согласен, что переименвоание наиболее часто используемый вид рефакторинга, списочек всё же скудноват. Автоматизация рефакторинга ценится не частотой использования, а сэкономленным временем.

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

NB>>жаль то оно конечно жаль, но обсуждаемую проблему концепты бы не решили.
WH>Именно они и должны были ее решить. Хотябы частично.
WH>Ибо они по факту классы типов (привет хаскелю) для типов.

Ну вот такой код:

template< typename Iterator > 
void foo ( Iterator it ) { it->bar(); }

потом я решаю, что bar плохое название, и переименовываю на baz. как концепты помогут мне найти все места, где используется старое наименование?

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

D>Демагогия detected. Система типов именно что даёт математически доказанные гарантии.

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

Автор(ы):
Дж. Митчелл


Если Вы хотите написать или уже пишете свой язык программирования №1 в мире, то стоит заботать данную книгу. Книга большая, очень много математики, читается тяжело,
но создание языка программирования №1 — требует жертв. Книга представляет собой теоретическое введение в лямбда-исчисление (основу современных языков программирования).
Материал книги использовался при проведении 3-х семестровых курсов в Стэнфорде. Изучение книги позволяет при создании своего языка встать "на плечи гигантов" и переиспользовать опыт по выделению базовых абстракций из которых строятся языки программирования.

последнюю главу.
Для императивных языков без вывода типов никаких математических теорий просто нет.

FR>>В данном случае да статика(вернее ее подмножество) рулит.

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

Зачем менюшки, юнит тесты выполняются одним нажатием на клавишу, и вообще с ними удобно работать http://pydev.blogspot.com/2010/12/improved-unittest-support-in-pydev.html приложение запускается не чаще чем в статике.

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

A>Я вот думал, что VS поддерживает переименование в C#. А потом поставил ReSharper и узнал о преименовании много нового .
И что ты такого нового узнал?
Просто я решарпер уже давно не видел, ибо на C# давно не пишу.

A>Хотя я согласен, что переименвоание наиболее часто используемый вид рефакторинга, списочек всё же скудноват. Автоматизация рефакторинга ценится не частотой использования, а сэкономленным временем.
Но работает.
А в ИДЕ для динамически типизированных языков не работает.
А количество неработающих фич никого не интересует.

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

A>>В шаблонах Си++ структурная типизация. То есть, если говорить проще, факт использования типа влияет на процесс его рефакторинга.
D>А можешь примерчик нарисовать для иллюстрации? А то я не въехал.

template <class T>
class MyTemplate
{
public:
    void Method(T t)
    {
        t.Invoke();
    }
};

class MyTest
{
public:
    Invoke();
}

class MyTest2
{
public:
    Invoke();
}

При переименовании MyTest.Invoke() надо так же переименовать вызов T.Invoke() в MyTemplate<T>.Method(T), если шаблон MyTemplate инстанциировался классом MyTest. Так же надо найти и переименовать методы Invoke в других классах, которыми инстанциируется MyTemplate (например MyTest2). Добавь сюда правила перегрузки функций: const, &, koenig lookup.

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

FR>>Жаль что эти редиски из комитета концепты зарубили

NB>жаль то оно конечно жаль, но обсуждаемую проблему концепты бы не решили.

Полностью нет, но очень приличную часть да.

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

NB>потом я решаю, что bar плохое название, и переименовываю на baz. как концепты помогут мне найти все места, где используется старое наименование?
Я С++ давно не интересовался, так что не помню точно, что там предлагалось.
Поэтому напишу, как это могло бы быть:

contract FooBar
{
    void bar();
}

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

template<class Iterator, class Value> 
where Iterator : iterator<Value>
where Value : FooBar
void foo ( Iterator it ) { it->bar(); }

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

A>>Я вот думал, что VS поддерживает переименование в C#. А потом поставил ReSharper и узнал о преименовании много нового .
WH>И что ты такого нового узнал?
WH>Просто я решарпер уже давно не видел, ибо на C# давно не пишу.

Решарпер переименовывает тип в комментариях, регионах, свойства одноимённые с типом, поля и переменные. В общем это не просто корректная замена имени типа. Например вот это

class Test
{
    private MyOldType _myOldType;

    public MyOldType MyOldType
    {
        get { return _myOldType; }
    }
}

студия преобразует к виду

class Test
{
    private MyNewType _myOldType;

    public MyNewType MyOldType
    {
        get { return _myOldType; }
    }
}

что не очень здорово.

A>>Хотя я согласен, что переименвоание наиболее часто используемый вид рефакторинга, списочек всё же скудноват. Автоматизация рефакторинга ценится не частотой использования, а сэкономленным временем.
WH>Но работает.
WH>А в ИДЕ для динамически типизированных языков не работает.
WH>А количество неработающих фич никого не интересует.

Ну, не работать могут конкретные реализации. Если Visual Assist как-то переваривает Си++, то уж Питон-то точно можно переварить. Меня вообще конкретные реализации мало волнуют, я просто хочу сказать что язык без IDE рассматривать не стоит. С#, если писать в Блокноте, то ещё говно, наверное.

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

VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.

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

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

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

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

WH>А что в статически типизированных языках обобщенный код уже отменили?
WH>Не знал.

Так с анализом обобщенного когда и в статике проблематично.

FR>>Плюс абстрактная интерпретация которая позволяет нам смотреть только на нужные для данного действия аспекты и отбрасывая несущественные.
WH>И нахрена козе баян если нормальные языки и так все проверяют?

А какая разница если это делает машина?

WH>>>Отсюда вывод: Код по факту статически типизирован. Но компилятору об этом почему-то ничего не говорят.
FR>>Нет в целом код может быть не типизирован статически.
WH>Мне ни кто, ни разу не привел пример когда динамическая типизация нужны.
WH>Ближе всех был мыщъх с очень узкой задачей декодирования жабоскрипта. Для этого он использовал интерпритатор жабоскрипта чтобы скрипт сам себя декодировал.
WH>Остальные не показали ничего. Ни разу.

Тебе не нужно, это уже практически аксиома

FR>>утиную типизацию вместо интерфейсов
WH>И как оно мне поможет найти места, где код править надо?

Оно поможет тем что нужно меньше правок.

FR>>В данном случае да статика(вернее ее подмножество) рулит.
WH>Она всегда рулит.

FR>>Все таки 1001 раз это все уже уныло.
WH>Аргументов как не было так и нет.

Угу, кто не хочет слушать не услышит.