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

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

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

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

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

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

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

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

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

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


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

последнюю главу.

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

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

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

Ещё раз: во view-слое тоже бывают ошибки, с соответствующим процентом банальных опечаток. Вместо того, чтобы дать компилятору возможность ловить их автоматически, ты предлагаешь городить вручную юнит-тесты, суммарного кода в которых для мало-мальски сложных интерактивных страниц будут как минимум не меньше, чем в самой странице, тупо потому что нужно покрыть все базовые варианты поведения этой страницы. И использоваться при этом монстров типа celestia, которые ни простоты, ни скорости работы тестов не добавят. И поддерживать это потом всё в актуальном состоянии, что опять же, в случае celestia, гораздо сложнее, чем в "обычных" тестах, т.к. на клиенте можно проверять только косвенные признаки правильно отработавшего серверного кода: типа "а вот есть ли у нас элемент с таким-то id, содержащим такой-то текст?". А если кто-нибудь в ресурсном файле исправил грамматическую ошибку в тексте, или прикрутил локализацию, то все тесты дружно полетят. В отличие от компилятора. Я на скале view-слой не тестирую вообще: логическим ошибкам в нём просто неоткуда взяться, он простой как пять копеек, а опечатки и согласования типов ловит компилятор.

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

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

U>Т.е. своей головы у тебя нет и сам ты предложить решение не можешь? Поэтому в этом случае ты ждал десять лет, пока МС решит проблему?

На основе чего вы сделали такой вывод?

P.S. Если честно, всегда тупо писал .ToArray. Склеивание строк никогда не было узким местом в моих приложениях.

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

U>>Это в каком шарпе появилось?
A>4й фреймворк.

Т.е. до появления 4-го фрамеворка ты использовал стандартный string.Join?

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

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

A>Ну, не работать могут конкретные реализации. Если Visual Assist как-то переваривает Си++, то уж Питон-то точно можно переварить.
Вот тут ты не прав.
С++ не смотря на всю свою ужасность статически типизированный.
Так что там есть что переваривать.
А в питоне переваривать нечего.
Информации в исходниках просто физически нет.

A>Меня вообще конкретные реализации мало волнуют, я просто хочу сказать что язык без IDE рассматривать не стоит. С#, если писать в Блокноте, то ещё говно, наверное.
Покажи работающую, которая хотя бы в 10 строках не путается.
Нет таких. Ибо проблемы теоритические и "реализациями" не решаются.
А вот для немерле решарпер при наличии ресурсов сделать можно.
Компилятор второго немереле вообще изначально проектируется не только как компилятор но и как фундамент для ИДЕ.

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

U>Т.е. до появления 4-го фрамеворка ты использовал стандартный string.Join?

Честно говоря, я его использую так редко, что мне сложно ответить на твой вопрос.

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

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

В самом деле? Пример дашь? А я в ответку решение на скале без проблем.

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

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

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

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

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

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

+1

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

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

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

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

FR>Тебе не нужно, это уже практически аксиома
Что значит мне не нужно?
Оно вообще не нужно.
Ибо никто не может сказать зачем.

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

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

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

L>P.S. Если честно, всегда тупо писал .ToArray. Склеивание строк никогда не было узким местом в моих приложениях.

Т.е. до шарпа 3.5 ты пользовался стандартным string.Join, каждый раз руками преобразуя коллекцию исходных типов в коллекцию строк. И у тебя не возникало мыслей, что код этого преобразования является мусорным, соответственно ты не задумывался о том, что в первом шарпе можно было самому написать решение, которое сделало бы это ненужным в простых случаях, а во втором шарпе — для всех случаях?

И сколько языков нужно изучить, чтобы это понять?

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

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

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

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


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

последнюю главу.

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

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

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

D>Ещё раз: во view-слое тоже бывают ошибки, с соответствующим процентом банальных опечаток. Вместо того, чтобы дать компилятору возможность ловить их автоматически, ты предлагаешь городить вручную юнит-тесты, суммарного кода в которых для мало-мальски сложных интерактивных страниц будут как минимум не меньше, чем в самой странице, тупо потому что нужно покрыть все базовые варианты поведения этой страницы. И использоваться при этом монстров типа celestia, которые ни простоты, ни скорости работы тестов не добавят. И поддерживать это потом всё в актуальном состоянии, что опять же, в случае celestia, гораздо сложнее, чем в "обычных" тестах, т.к. на клиенте можно проверять только косвенные признаки правильно отработавшего серверного кода: типа "а вот есть ли у нас элемент с таким-то id, содержащим такой-то текст?". А если кто-нибудь в ресурсном файле исправил грамматическую ошибку в тексте, или прикрутил локализацию, то все тесты дружно полетят. В отличие от компилятора. Я на скале view-слой не тестирую вообще: логическим ошибкам в нём просто неоткуда взяться, он простой как пять копеек, а опечатки и согласования типов ловит компилятор.

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

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

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

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

Применяется к каждому item'у, т.е. он должен называться itemFormat.

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

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

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

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

D>В самом деле? Пример дашь? А я в ответку решение на скале без проблем.

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

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

D>Разница в том, что в твоём случае, чтобы это сделала машина, надо либо писать юнит-тесты, либо кликать до нужного места в программе. Так что у тебя машина это делает не сама, а с твоей активной помощью.

Нет был разговор про PyPi там все тоже делает полностью автоматически компилятор и анализатор.

D>Мы бы и рады послушать. Какие-нибудь новые для разнообразия, вдруг они окажутся убедительнее нынешних. Но проблема в том, что их нет.

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

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

L>>к чему относится format?
U>Применяется к каждому item'у, т.е. он должен называться itemFormat.

Есть перегрузка IEnumerable<T> там для каждого элемента вызывается ToString(). Да, только в 4м фреймворке.

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

NB>ты ведь понимаешь, что никто в нормальном здравии так писать не будет.
Почему?
В C# пишут.
В хаскеле пишут.
Почему на С++ не будут?

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

FR>Чуть выше показали на шаблонах C++.
Показывать на С++ и говорить что статика говно это демагогия.
Ибо С++ сам по себе гора страшных костылей.

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

L>>P.S. Если честно, всегда тупо писал .ToArray. Склеивание строк никогда не было узким местом в моих приложениях.

U>Т.е. до шарпа 3.5 ты пользовался стандартным string.Join, каждый раз руками преобразуя коллекцию исходных типов в коллекцию строк.

Думай дальше.

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

Да, можно. Что ты хотел этим продемонстрировать?

U>И сколько языков нужно изучить, чтобы это понять?

Очевидно, нисколько. О чем ты вообще?

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

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

Выше пример с шаблонами C++

FR>>Тебе не нужно, это уже практически аксиома
WH>Что значит мне не нужно?
WH>Оно вообще не нужно.
WH>Ибо никто не может сказать зачем.

Нет критерий нужности доказывает только практика, по нему очень даже нужно.

FR>>Оно поможет тем что нужно меньше правок.
WH>Это ложь.

Нет.

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

Практика.

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

NB>>ты ведь понимаешь, что никто в нормальном здравии так писать не будет.
WH>Почему?
WH>В C# пишут.
WH>В хаскеле пишут.
WH>Почему на С++ не будут?

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