Здравствуйте, Lloyd, Вы писали:
L>Есть у тебя список, надо вернут все элементы, удовлетворяюшие условию. L>Если ты не знаком с функциональными фичами шарпа, то у тебя родится тчо-то вроде
Вот более удачный пример. В шарпе есть такая функция string.Join, которая благодаря гениальным программистам из МС принимает только массив строк и ничего другого. В результате при использовании этой функции типичным является такой код:
List<string> itemsAsString = new List<string>();
foreach (int item in items)
itemsAsString.Add(item.ToString());
return string.Join(", ", itemsAsString.ToArray());
Объясни сколько языков нужно знать для того, чтобы понять, что весь код относящийся к созданию промежуточного массива строк является мусорным?
Также объясни сколько языков нужно знать для того, чтобы понять, что даже в C# 1.0 можно было написать функцию: string MyJoin(string separator, string format, IEnumerable items), которая позволила бы избавиться от мусорного кода, хотя бы в простых (но очень распространенных) случаях?
Re[13]: Что вас останавливает от изучения нового языка?
Здравствуйте, dimgel, Вы писали:
D>Является ли сильная типизация по сравнению со слабой преимуществом при автоматическом рефакторинге, если оба языка динамически типизированные? Я склонен считать, что нет, т.к. ошибка типов в любом случае вылетит в рантайме, IDE никакой помощи тут не предоставит. Если так, то это ключевая претензия, и она ни на йоту не гипертрофированная: её значение переоценить невозможно. Как по мне, невозможность быстро и надёжно (без необходимости писать тонну юнит тестов) рефакторить код — это приговор языку. На любом хоть сколько-нибудь крупном проекте рефакторинг будет выливаться в такой геморрой, что проще повеситься. "Отвинтили пупок — отвалилась задница." Всё остальное я перетерплю, но когда рефакторинг кода похож на хождение по минному полю, когда на каждый чих типа переименования метода приходится вручную шерстить весь проект глобальным поиском, потом смотреть, что из найденного относится к нашему классу, а что не относится (а в отсутствие информации о типах приходится анализировать логику, иногда глубоко), а потом молиться, чтобы где-нибудь не упала завязанная на рефлексии динамика, конструирующая имя вызываемого метода так, что он не нашёлся поиском... это ад, в общем. Огромное количество временных затрат на ровном месте. Вот реальная проблема. А что в рантайме я не смогу присвоить числовой переменной строку — мне глубоко пофиг, я уже привык assert-ами по коду разбрасываться, они неплохо компенсируют слабую типизацию.
Рефакторинг это поведение IDE, а не свойство языка. Си++ типизирован и кому это помогло?
Здравствуйте, Undying, Вы писали:
U>Также объясни сколько языков нужно знать для того, чтобы понять, что даже в C# 1.0 можно было написать функцию: string MyJoin(string separator, string format, IEnumerable items), которая позволила бы избавиться от мусорного кода, хотя бы в простых (но очень распространенных) случаях?
[Serializable, ComVisible(true)]
public sealed class String : IComparable, ICloneable, IConvertible, IComparable<string>, IEnumerable<char>, IEnumerable, IEquatable<string>
{
...
public static string Join(string separator, IEnumerable<string> values);
...
}
Здравствуйте, adontz, Вы писали:
D>>Является ли сильная типизация по сравнению со слабой преимуществом при автоматическом рефакторинге, если оба языка динамически типизированные? Я склонен считать, что нет, т.к. ошибка типов в любом случае вылетит в рантайме, IDE никакой помощи тут не предоставит.
A>Рефакторинг это поведение IDE, а не свойство языка. Си++ типизирован и кому это помогло?
1. Ты не ответил на вопрос в начале моего поста.
2. При отсутствии информации о типах, IDE неспособна надёжно выполнить автоматический рефакторинг (кроме локальных, например, переименование приватного члена класса или внутренней переменной метода). И никак не помогает при ручном рефакторинге. Про C++ это не ко мне, я его не помню. Но на скале я могу расхерачить API классов просто вдребезги, не беспокоясь о том, что потом где-нибудь забуду поменять использующий их код. Компилятор не даст забыть. И на C++, по идее, тоже не должен дать забыть, если typecast-ами не увлекаться — я просто не уверен, что нынче на нём вообще можно писать без кастов. На PHP приходится работать чётко по Фаулеру — крошечными шагами, тратя массу времени на проверку корректности каждого шага. И думаю, что на сильнотипизированных динамических языках ситуация не лучше.
Re[9]: Что вас останавливает от изучения нового языка?
Здравствуйте, MxMsk, Вы писали:
U>>Плохой пример. Для меня первый вариант проще, чем второй. В простых случаях (таких как приведенный) это не заметно, но очень хорошо видно в случаях сложных. MM>Чем первый вариант проще?
Насчет проще на таком простом примере видно не будет. Но в этом случае код примерно одинаков по сложности, т.к. содержит равное количество сущностей. В обоих вариантах есть и пробег по коллекции, и условие, и обработка условия. Разница лишь в лаконичности, т.к. во втором случае пробег по коллекции спрятан внутрь функции.
Здравствуйте, adontz, Вы писали:
U>>Также объясни сколько языков нужно знать для того, чтобы понять, что даже в C# 1.0 можно было написать функцию: string MyJoin(string separator, string format, IEnumerable items), которая позволила бы избавиться от мусорного кода, хотя бы в простых (но очень распространенных) случаях? A>
A> public static string Join(string separator, IEnumerable<string> values);
A>
Это в каком шарпе появилось? Очевидно, что не в 1.0 и вроде даже не в 2.0.
Re[10]: Что вас останавливает от изучения нового языка?
Здравствуйте, dimgel, Вы писали:
D>1. Ты не ответил на вопрос в начале моего поста.
Является ли типизация преимуществом при рефаткоринге? Нет. Даже статически типизированный язык может быть трудным для рефакторина.
D>2. При отсутствии информации о типах, IDE неспособна надёжно выполнить автоматический рефакторинг (кроме локальных, например, переименование приватного члена класса или внутренней переменной метода). И никак не помогает при ручном рефакторинге. Про C++ это не ко мне, я его не помню. Но на скале я могу расхерачить API классов просто вдребезги, не беспокоясь о том, что потом где-нибудь забуду поменять использующий их код. Компилятор не даст забыть. И на C++, по идее, тоже не должен дать забыть, если typecast-ами не увлекаться — я просто не уверен, что нынче на нём вообще можно писать без кастов. На PHP приходится работать чётко по Фаулеру — крошечными шагами, тратя массу времени на проверку корректности каждого шага. И думаю, что на сильнотипизированных динамических языках ситуация не лучше.
В шаблонах Си++ структурная типизация. То есть, если говорить проще, факт использования типа влияет на процесс его рефакторинга.
Здравствуйте, dimgel, Вы писали:
FR>>Я PHP и JavaScript практически не знаю, но судя по тем же флеймам они гораздо более подвержены ошибкам чем питон и руби ввиду очень слабой типизации.
D>Является ли сильная типизация по сравнению со слабой преимуществом при автоматическом рефакторинге, если оба языка динамически типизированные?
В теории и частично и на практике(PyPy) да является, для сильно типизированного динамического языка подмножество кода приводимого к статическому будет намного большим. Например тот-же PyPy транслирует код в статически типизированный RPython для которого все плюшки статически
сильно типизированных языков доступны.
D>Я склонен считать, что нет, т.к. ошибка типов в любом случае вылетит в рантайме, IDE никакой помощи тут не предоставит.
Статический анализ кода для динамики тоже существует и используется в таких вещах как pylint pychecker rope
Плюс довольно большое число ошибок ловится в такой фазе как загрузка модуля, да это рантайм, но он не требует полного исполнения кода, также как и
такие вещи как абстрактная интерпретация работающая на грани динамики и статики.
Конечно пока до уровня хорошей сильной статики это все не дотягивает, но движение есть.
D>Если так, то это ключевая претензия, и она ни на йоту не гипертрофированная: её значение переоценить невозможно. Как по мне, невозможность быстро и надёжно (без необходимости писать тонну юнит тестов) рефакторить код — это приговор языку.
Я так не считаю, как и множество других программистов.
Юнит тесты в динамике да необходимы, но не тонны, их размер будет вполне сопоставим с размером оных для статики.
D>На любом хоть сколько-нибудь крупном проекте рефакторинг будет выливаться в такой геморрой, что проще повеситься. "Отвинтили пупок — отвалилась задница." Всё остальное я перетерплю, но когда рефакторинг кода похож на хождение по минному полю, когда на каждый чих типа переименования метода приходится вручную шерстить весь проект глобальным поиском, потом смотреть, что из найденного относится к нашему классу, а что не относится (а в отсутствие информации о типах приходится анализировать логику, иногда глубоко), а потом молиться, чтобы где-нибудь не упала завязанная на рефлексии динамика, конструирующая имя вызываемого метода так, что он не нашёлся поиском... это ад, в общем. Огромное количество временных затрат на ровном месте. Вот реальная проблема. А что в рантайме я не смогу присвоить числовой переменной строку — мне глубоко пофиг, я уже привык assert-ами по коду разбрасываться, они неплохо компенсируют слабую типизацию.
Тесты в этом вполне рулят.
Re[14]: Что вас останавливает от изучения нового языка?
Здравствуйте, FR, Вы писали:
FR>Угу IDE'шки для питона сейчас уже вменяемее чем для C++.
Нашёл с чем сравнивать.
Ты хотя бы с интеграций немерле сравни.
Смех же на палочке. Питон намного старше. Имеет на порядки больше ресурсов, а все ИДЕ, в том числе коммерческие говно на фоне интеграции немерла.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Что вас останавливает от изучения нового языка?
Здравствуйте, WolfHound, Вы писали:
FR>>Угу IDE'шки для питона сейчас уже вменяемее чем для C++. WH>Нашёл с чем сравнивать. WH>Ты хотя бы с интеграций немерле сравни. WH>Смех же на палочке. Питон намного старше. Имеет на порядки больше ресурсов, а все ИДЕ, в том числе коммерческие говно на фоне интеграции немерла.
Какие рефакторинги поддерживает интеграция Немерле?
Здравствуйте, FR, Вы писали:
FR>В теории и частично и на практике(PyPy) да является, для сильно типизированного динамического языка подмножество кода приводимого к статическому будет намного большим. Например тот-же PyPy транслирует код в статически типизированный RPython для которого все плюшки статически FR>сильно типизированных языков доступны.
Но это возможно только для де-факто статически типизированных кусков кода.
Отсюда вывод: Код по факту статически типизирован. Но компилятору об этом почему-то ничего не говорят.
Следствие: Раз код и так статически типизирован то нахрена нам вообще динамическая типизация?
FR>Я так не считаю, как и множество других программистов. FR>Юнит тесты в динамике да необходимы, но не тонны, их размер будет вполне сопоставим с размером оных для статики.
Ты почитай, что тебе говорят.
Как, например я код рефакторю: Правлю интерфейсы, и компилятор мне все места, где код поправить нужно находит.
Что мне может предложить питон?
Тесты гонять?
А где гарантия, что покрытие 100%?
А если оно и 100% то где гарантия что на вход все типы подаются?
А в случае со статикой мне забыть ни о чем не дадут.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Что вас останавливает от изучения нового языка?
Здравствуйте, adontz, Вы писали:
A>Какие рефакторинги поддерживает интеграция Немерле?
Переименование.
А какие рефакторинги поддерживают ИДЕ питона?
Переименование там не работает! Все что они осилили это глобальная замена всех одноименных методов.
С автодополнением и навигацией та же байда.
И это фундаментальные проблемы, которые не лечатся теоритически.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Что вас останавливает от изучения нового языка?
Здравствуйте, adontz, Вы писали:
A>В шаблонах Си++ структурная типизация. То есть, если говорить проще, факт использования типа влияет на процесс его рефакторинга.
А можешь примерчик нарисовать для иллюстрации? А то я не въехал.
Re[8]: Что вас останавливает от изучения нового языка?
Здравствуйте, Nuzhny, Вы писали:
N>В том-то и смысл, что самому такой вариант выдумывать не надо. Надо лишь посмотреть, что может предоставить язык для оперирования со списками. Для этого есть литература и туториалы по языку, примеры кода в сети.
Посыл оппонента был в том, что и этого не надо, достаточно думать "в терминах решаемой задачи". Собственно, на это я и возражал.
Re: Что вас останавливает от изучения нового языка?
Здравствуйте, VladD2, Вы писали:
VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
Меня особо ничего не останавливает.
Раньше писал на ассемблере для восьмиразрядных компьютеров, этот опыт позже перенес на Windows.
Потом понадобилось работать с COM — стал изучать C и C++. В результате понравилось, возвращаться не захотел.
Несколько раз приходилось плотно "общаться" с другими языками — C#, Javascript, некоторые скриптовые
диалекты для узкоспецифических областей. Тоже никаких особых проблем не наблюдалось, просто брал и делал.
Думаю, любой современный язык можно освоить в достаточной степени за два или три года.
В смысле, до такой степени, когда он становится основным. Ничего тут страшного-ужасного нету.
Если придется по каким-то причинам оставить С++ и перейти на управляемые языки, спокойно
перенесу это явление и там тоже найду себе работу по вкусу.
VD>Для затравки дам некоторые возможные ответы: VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
Есть такой момент.
Меня, например, жутко бесит необходимость в паскалевских диалектах писать что-то вроде "a:=n",
а не просто "a=n". Но это так, мелочь. На ассемблере тоже нету фигурных скобок, а ведь привык же.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
Да, интересный пункт.
Но ведь если нет ООП, значит есть что-то другое, гораздо более сильное. Так ведь ?
Какая-то новая парадигма... Интересно было бы, по крайней мере.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...". VD>...
Если человек пишет системный софт вроде драйверов, систем мониторинга и контроля доступа, то он
сильно ограничен в выборе средств. Скажем так — язык определяется предметной областью, к которой
человек расположен, а вовсе не личными предпочтениями.
VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?
Такое, наверное, может возникнуть тогда, когда язык изучался просто с целью расширения кругозора.
Как меч в ножнах — наточен до звона в лезвии, а резануть нечего (или некого).
Re[14]: Что вас останавливает от изучения нового языка?
Здравствуйте, Undying, Вы писали:
U>Плохой пример. Для меня первый вариант проще, чем второй. В простых случаях (таких как приведенный) это не заметно, но очень хорошо видно в случаях сложных.
Как раз в простом случае-то преимуществ и не видно. Вот когда будет под десяток этих where и когда будут они присоединяться/отсоединяться в зависимости от тех изи иных условий, вот тогда-то и будет хороший пример.
Re[15]: Что вас останавливает от изучения нового языка?
WH>Но это возможно только для де-факто статически типизированных кусков кода.
Не совсем, скорее для кода который приводится к конечному числу статически типизированных вариантов.
Плюс абстрактная интерпретация которая позволяет нам смотреть только на нужные для данного действия аспекты
и отбрасывая несущественные.
WH>Отсюда вывод: Код по факту статически типизирован. Но компилятору об этом почему-то ничего не говорят.
Нет в целом код может быть не типизирован статически.
WH>Следствие: Раз код и так статически типизирован то нахрена нам вообще динамическая типизация?
Вам не нужно, мы это уже давно выяснили
FR>>Я так не считаю, как и множество других программистов. FR>>Юнит тесты в динамике да необходимы, но не тонны, их размер будет вполне сопоставим с размером оных для статики. WH>Ты почитай, что тебе говорят. WH>Как, например я код рефакторю: Правлю интерфейсы, и компилятор мне все места, где код поправить нужно находит. WH>Что мне может предложить питон?
утиную типизацию вместо интерфейсов
WH>Тесты гонять?
Да.
WH>А где гарантия, что покрытие 100%? WH>А если оно и 100% то где гарантия что на вход все типы подаются?
100% гарантии теперь даже в банках не дают.
WH>А в случае со статикой мне забыть ни о чем не дадут.
В данном случае да статика(вернее ее подмножество) рулит.
