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

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

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

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

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

L>Понятий "хорошо" и "плохо", имхо, не существует. Зато есть "лучше" и "хуже", для употребления которых уже и нужно зныние иных языков.

И что эта игра словами изменила? Если думать не в терминах языка, а в терминах решаемой задачи, то становится видно можно ли найденное решение записать лучшим образом по сравнению с записью в используемом языке. Знать другие языки для этого не требуется. Вот если видишь, что решение можно было записать лучше, но язык не позволил, тогда да возникает вопрос, а существуют ли языки, в которых нужная тебе запись доступна. И вот только для ответа на этот вопрос требуется знание других языков.

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

L>>Понятий "хорошо" и "плохо", имхо, не существует. Зато есть "лучше" и "хуже", для употребления которых уже и нужно зныние иных языков.

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

Есть у тебя список, надо вернут все элементы, удовлетворяюшие условию.
Если ты не знаком с функциональными фичами шарпа, то у тебя родится тчо-то вроде

var result = new List();
foreach (var x in coll)
  if (test(x))
    result.Add(x);

Как, думая в терминах решаемой задачи, прийти к более простому варианту

var result = new List(coll.Where(test));

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

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

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

L>Есть у тебя список, надо вернут все элементы, удовлетворяюшие условию.
L>Если ты не знаком с функциональными фичами шарпа, то у тебя родится тчо-то вроде

L>

L>var result = new List();
L>foreach (var x in coll)
L>  if (test(x))
L>    result.Add(x);

L>

L>Как, думая в терминах решаемой задачи, прийти к более простому варианту
L>

L>var result = new List(coll.Where(test));
L>

L>

В том-то и смысл, что самому такой вариант выдумывать не надо. Надо лишь посмотреть, что может предоставить язык для оперирования со списками. Для этого есть литература и туториалы по языку, примеры кода в сети.
Ещё пример: достаточно бегло посмотреть на Матлаб, чтобы понять как он удобен для решения многих математических задач по сравнению с любыми универсальными языками высокого уровня. Но люди, занимающие символьными вычислениями в Maple, посмотрев на Матлаб вряд ли поменяют язык. И для этого совсем не надо ничего серьёзно изучать.

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

WH>Неверная логика.
WH>Если человек не знает о возможностях то он о них и думать не будет.

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

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

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

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

Отсутствие смысла в изучении языка ради изучения языка.

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

N>Чтобы узнать о возможностях, не обязательно изучать язык. Достаточно посмотреть, как на нём решаются типичные задачи твоей предметной области.
Плохой способ.
Ибо ты узнаешь не столько о языке сколько, о тараканах тех, кто писал конкретный проект.
А учитывая, что на любом языке можно писать как на фортране...

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

L>Есть у тебя список, надо вернут все элементы, удовлетворяюшие условию.
L>Если ты не знаком с функциональными фичами шарпа, то у тебя родится тчо-то вроде

L>

L>var result = new List();
L>foreach (var x in coll)
L>  if (test(x))
L>    result.Add(x);

L>

L>Как, думая в терминах решаемой задачи, прийти к более простому варианту
L>

L>var result = new List(coll.Where(test));
L>

L>

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

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

A>2) Байндинг между bool и Visibility выполняется только с написание своего класса-конвертора. Я его написал, он не заработал, так и не понял почему.
Оффтоп, но всё же. Есть готовый конвертер: BooleanToVisibilityConverter

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

U>Плохой пример. Для меня первый вариант проще, чем второй. В простых случаях (таких как приведенный) это не заметно, но очень хорошо видно в случаях сложных.
Чем первый вариант проще?

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

N>>Чтобы узнать о возможностях, не обязательно изучать язык. Достаточно посмотреть, как на нём решаются типичные задачи твоей предметной области.
WH>Плохой способ.
WH>Ибо ты узнаешь не столько о языке сколько, о тараканах тех, кто писал конкретный проект.
WH>А учитывая, что на любом языке можно писать как на фортране...

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

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

FR>Очень большей частью как раз не аргументированные и Влад и WolfHound чистые теоретики и не имеют мало мальского опыта писания на этих языках.

Вот тут мне не надо ляля. Я читаю флеймы достаточно подробно. Не все и не всегда, но тем не менее. С аргументацией у немерлистов всё гораздо лучше, чем у их оппонентов, чьи аргументы сводятся к "не читал но осуждаю", ноль конструктива. Да ты хоть эту ветку перечитай. Половина спорщиков даже примерно не представляет, что такое макросы в N.

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

J>Здравствуйте, ajukraine, Вы писали:
J>Если не секрет, зачем было писать на английском и с ошибками?

С русским еще хуже

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

D>Вот тут мне не надо ляля. Я читаю флеймы достаточно подробно. Не все и не всегда, но тем не менее. С аргументацией у немерлистов всё гораздо лучше, чем у их оппонентов, чьи аргументы сводятся к "не читал но осуждаю", ноль конструктива. Да ты хоть эту ветку перечитай. Половина спорщиков даже примерно не представляет, что такое макросы в N.

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

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

D>>Вот тут мне не надо ляля. Я читаю флеймы достаточно подробно. Не все и не всегда, но тем не менее. С аргументацией у немерлистов всё гораздо лучше, чем у их оппонентов, чьи аргументы сводятся к "не читал но осуждаю", ноль конструктива. Да ты хоть эту ветку перечитай. Половина спорщиков даже примерно не представляет, что такое макросы в N.

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

Как тебе уже ответил WolfHound, в твоих ответах отсутствуют конкретные возражения по конкретным претензиям к динамике. Чистое бла-бла-бла. Сам я не знаю питона, но я знаю PHP и скалу, и я вполне могу экстраполировать свой опыт со слабо-динамически-типизированным языком на сильно-, тем более, что это будет по сути не экстра- а интерполяция (там с другого конца скала подпирает). То есть, я знаю достаточно, чтобы квалифицированно оценивать аргументы обоих сторон. Ты — сторона спора. Я — посторонний наблюдатель. "В споре рождается истина" — это, конечно, полная брехня, но одно исключение я таки-обнаружил: в позиции постороннего наблюдателя картина максимально полная, учитывающая аргументы всех сторон. Это касается не только статики-динамики, но и rich-anemic, к примеру, и всех остальных срачей. Ну а ты, если тебе так охота защищать динамику, — так защищай её, продумывай ответы на аргументы твоих оппонентов. Наезды на их квалификацию — это не аргументы, а переход на личности. Доказывающий кстати, что твоя квалификация ниже, раз тебя не хватает на аргументы должного уровня.

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

N>Разумеется, что надо выбирать примеры кода от создателей языка, авторов книг по нему или распространённых и известных продуктов на нём.
И ничего не поменялось.
Скажем код адептов тяжёлых ОРМ и легких ОРМ будет противоречить друг другу чуть менее чем во всем.
И все действо будет происходить на одном и том же языке.

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


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

D>Как тебе уже ответил WolfHound, в твоих ответах отсутствуют конкретные возражения по конкретным претензиям к динамике. Чистое бла-бла-бла.

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

D>Сам я не знаю питона, но я знаю PHP и скалу, и я вполне могу экстраполировать свой опыт со слабо-динамически-типизированным языком на сильно-, тем более, что это будет по сути не экстра- а интерполяция (там с другого конца скала подпирает).

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

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

Я тоже, так как пишу еще и на одном из самых сильно типизированных языков — OCaml.

D>Ты — сторона спора.

Я уже практически нет, так иногда огрызаюсь.

D>Я — посторонний наблюдатель. "В споре рождается истина" — это, конечно, полная брехня, но одно исключение я таки-обнаружил: в позиции постороннего наблюдателя картина максимально полная, учитывающая аргументы всех сторон. Это касается не только статики-динамики, но и rich-anemic, к примеру, и всех остальных срачей. Ну а ты, если тебе так охота защищать динамику, — так защищай её, продумывай ответы на аргументы твоих оппонентов. Наезды на их квалификацию — это не аргументы, а переход на личности.

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

D>Доказывающий кстати, что твоя квалификация ниже, раз тебя не хватает на аргументы должного уровня.

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

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

_>Отсутствие смысла в изучении языка ради изучения языка.

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

Ну и есть языки, не зависящие от "главного" языка, на котором пишется проект.
Например, bash/grep/cut/whatever для командной строки и стартовых скриптов (PowerShell на винде?) и perl для работы с логами. Без знания перла (причем в объеме четвертого перла, т.е. без классов и т.п.) работать с логами — мучение, я вижу это на примере своих коллег, перла не знающих — то, что я делаю минут за 5-10 на перле, они могут делать по полдня на питоне, экселе, SQLite и прочих не приспособленных для этого девайсах. Причем это не преувеличение, это реальные цифры.

You will always get what you always got
  If you always do  what you always did

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

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

Является ли сильная типизация по сравнению со слабой преимуществом при автоматическом рефакторинге, если оба языка динамически типизированные? Я склонен считать, что нет, т.к. ошибка типов в любом случае вылетит в рантайме, IDE никакой помощи тут не предоставит. Если так, то это ключевая претензия, и она ни на йоту не гипертрофированная: её значение переоценить невозможно. Как по мне, невозможность быстро и надёжно (без необходимости писать тонну юнит тестов) рефакторить код — это приговор языку. На любом хоть сколько-нибудь крупном проекте рефакторинг будет выливаться в такой геморрой, что проще повеситься. "Отвинтили пупок — отвалилась задница." Всё остальное я перетерплю, но когда рефакторинг кода похож на хождение по минному полю, когда на каждый чих типа переименования метода приходится вручную шерстить весь проект глобальным поиском, потом смотреть, что из найденного относится к нашему классу, а что не относится (а в отсутствие информации о типах приходится анализировать логику, иногда глубоко), а потом молиться, чтобы где-нибудь не упала завязанная на рефлексии динамика, конструирующая имя вызываемого метода так, что он не нашёлся поиском... это ад, в общем. Огромное количество временных затрат на ровном месте. Вот реальная проблема. А что в рантайме я не смогу присвоить числовой переменной строку — мне глубоко пофиг, я уже привык assert-ами по коду разбрасываться, они неплохо компенсируют слабую типизацию.