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

O>В том смысле, что основные конструкции языка должны быть предельно простыми, даже
O>на уровне примитивизма. Это дает разработчику небывалую гибкость в выборе средств для
O>решения его задач, а еще позволяет самовыражаться.

"Сложность решения не может превышать более чем на порядок сложность инструмента" (c) IT.

Не уверен, в том что IT точно угадал с размером зависимости, но что зависимость точно есть в этом я уверен.

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

vsb>И, в общем то, я с этим согласен. На Scala писать интересно. На Java писать скучно. И это напрямую влияет на производительность, на "вхождение в поток", что, в конечном счёте, выливается в производительность программиста и его лояльность.

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

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

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

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

O>>В том смысле, что основные конструкции языка должны быть предельно простыми, даже
O>>на уровне примитивизма. Это дает разработчику небывалую гибкость в выборе средств для
O>>решения его задач, а еще позволяет самовыражаться.

VD>"Сложность решения не может превышать более чем на порядок сложность инструмента" (c) IT.

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

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

VD>>"Сложность решения не может превышать более чем на порядок сложность инструмента" (c) IT.

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

Согласен. практически на любом языке можно написать отличную библиотеку для конкретной предметной области. И использование связки маломощный язык + отличная библиотека будет сверхудобным.

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

O>В том смысле, что основные конструкции языка должны быть предельно простыми, даже
O>на уровне примитивизма. Это дает разработчику небывалую гибкость в выборе средств для
O>решения его задач, а еще позволяет самовыражаться.

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

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

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

Здравствуйте, Кодёнок, Вы писали:

Кё>То есть, фан зависит не только от языка, но и от содержимого головы программиста. Кобольщик, взяв современный С++, будет наверное безмерно счастлив, но человек, который “попробовал на вкус” лямбды не будет по-настоящему доволен ни одним языком, в котором их нет.

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

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

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

Это неверное заявление. Причем сразу в двух точек зрения.

1. Так как могут быть готовые более мощные инструменты (например, тот же Nemerle vs. C#).
2. Так как объем и сложность задачи могут значительно превышать затраты на разработку инструмента, особенно когда разработка ведется не с нуля, а и с использованием готовых средств (с применением библиотек, макросов, продуктов вроде MPS и т.п.)

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

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

O>>В том смысле, что основные конструкции языка должны быть предельно простыми, даже
O>>на уровне примитивизма. Это дает разработчику небывалую гибкость в выборе средств для
O>>решения его задач, а еще позволяет самовыражаться.

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

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

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

Это и есть простота. В моем понимании, подчеркиваю.
Когда суть языка сводится к оперированию простейшими конструкциями, все основные сложности
смещаются в область архитектуры. При таком раскладе почти не остается возможности угодить в
какую-то тонкую синтаксическую западню, не увидеть чего-то, существующего неявно или
погрязнуть в коде, перенасыщенном модными техническими приемами.
При этом существуют, разумеется, проблемы совсем другого рода, но одним дано их решать, другим — нет.

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

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

VD>Это неверное заявление. Причем сразу в двух точек зрения.

VD>1. Так как могут быть готовые более мощные инструменты (например, тот же Nemerle vs. C#).

Чушь какая-то.
Как влияет наличие нового инструмента на _возможность_ решения на старом?

VD>2. Так как объем и сложность задачи могут значительно превышать затраты на разработку инструмента, особенно когда разработка ведется не с нуля, а и с использованием готовых средств (с применением библиотек, макросов, продуктов вроде MPS и т.п.)

И какое это отношение имеет к _возможной_ сложности решения?

Сложность решения не может превышать более чем на порядок сложность инструмента

Где тут речь о каких-то других инструментах и затратах в принципе?

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

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

VD>>1. Так как могут быть готовые более мощные инструменты (например, тот же Nemerle vs. C#).

VE>Чушь какая-то.
VE>Как влияет наличие нового инструмента на _возможность_ решения на старом?

Про старый ты сам домыслил. Вот у тебя чушь и получилась.

VD>>2. Так как объем и сложность задачи могут значительно превышать затраты на разработку инструмента, особенно когда разработка ведется не с нуля, а и с использованием готовых средств (с применением библиотек, макросов, продуктов вроде MPS и т.п.)

VE>И какое это отношение имеет к _возможной_ сложности решения?

Прямое. Для решения задачи может потребоваться создание нового инструмента просто потому что без этого она не решается.

VE>

Сложность решения не может превышать более чем на порядок сложность инструмента

VE>Где тут речь о каких-то других инструментах и затратах в принципе?

Тут речь о том, что не все инструменты подходят для решения всех задач. Для решения некоторых требуется создавать новые инструменты (или переходить на них, если они есть).

VE>Если перефразировать хотя бы так: сложность решения увеличивается с увеличением сложности инструмента при прочих равных (времени разработки, к примеру), то это хотя бы скажет о том, что более сложный инструмент приоритетнее.

А не надо ошибочно перефразировать. Вообще не надо перефразировать. Мысль ведь и так очевидна.
Ну, а при использовании более сложного инструмента (по делу, конечно) решение как раз упрощается.

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

O>Это и есть простота. В моем понимании, подчеркиваю.
O>Когда суть языка сводится к оперированию простейшими конструкциями, все основные сложности
O>смещаются в область архитектуры. При таком раскладе почти не остается возможности угодить в
O>какую-то тонкую синтаксическую западню, не увидеть чего-то, существующего неявно или
O>погрязнуть в коде, перенасыщенном модными техническими приемами.
O>При этом существуют, разумеется, проблемы совсем другого рода, но одним дано их решать, другим — нет.

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

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

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

Так я и говорю — одним дано управляться с этим, а другим нет.

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

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

O>Так я и говорю — одним дано управляться с этим, а другим нет.

На некоторых объемах не дано никому.

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

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

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

O>>Так я и говорю — одним дано управляться с этим, а другим нет.

VD>На некоторых объемах не дано никому.

От языка не зависит.

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

VD>>"Сложность решения не может превышать более чем на порядок сложность инструмента" (c) IT.

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

А где здесь противоречие? Это как раз только подтверждает гениальность мысли, кстати, не моей.

VE>Так что ценность сего высказывания нулевая.

Ценность любого высказывания нулевая, если оно до тебя не доходит.

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

N>Согласен. практически на любом языке можно написать отличную библиотеку для конкретной предметной области. И использование связки маломощный язык + отличная библиотека будет сверхудобным.

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

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

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

вот-вот. библиотеки — это инструмент первого уровня, они позволяют сгруппировать код, который и так можно написать на этом языке. макросы — второй уровень, они позволяют добавить syntax sugar. а третий уровень — это семантика самого языка. если например в хаскеле все значения ленивы и потоко-безопасны, то добавить это в немерле можно только полностью переписав все библиотеки

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

N>>Согласен. практически на любом языке можно написать отличную библиотеку для конкретной предметной области. И использование связки маломощный язык + отличная библиотека будет сверхудобным.

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

Ох уж мне эти аналогии.
1. На С++ можно написать обалденную матричную библиотеку, перегрузив необходимые операторы и использовав слайсы. И решать соответствующие задачи практически на естественном язык математики.
2. На довольно убогом языке Матлаба можно реализовывать сложные математические модели практически в несколько строк. Только за счёт огромного количества библиотек — Toolbox'ов.

Это не плоскогубцы и молоточки — это готовая рабочая среда, реализованная в виде качественных библиотек. В таком окружении могут комфортно работать даже непрограммисты (математики, физики).
Ты и Влад, как мне кажется, путаете разработчиков библиотек и их пользователей. Разработчиков мало, им нужен мощный язык. Пользователей большинство — им надо решать проблемы предметной области, то есть нужны конкретные (и удобные!) библиотеки.

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

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

VD>>>1. Так как могут быть готовые более мощные инструменты (например, тот же Nemerle vs. C#).

VE>>Чушь какая-то.
VE>>Как влияет наличие нового инструмента на _возможность_ решения на старом?

VD>Про старый ты сам домыслил. Вот у тебя чушь и получилась.

Минуточку:

Сложность решения не может превышать более чем на порядок сложность инструмента

Так как могут быть готовые более мощные инструменты (например, тот же Nemerle vs. C#).

Тут речь об одном и том же инструменте или сравниваются два?

VE>>И какое это отношение имеет к _возможной_ сложности решения?

VD>Прямое. Для решения задачи может потребоваться создание нового инструмента просто потому что без этого она не решается.

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

VD>Тут речь о том, что не все инструменты подходят для решения всех задач. Для решения некоторых требуется создавать новые инструменты (или переходить на них, если они есть).

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

VD>Ну, а при использовании более сложного инструмента (по делу, конечно) решение как раз упрощается.

Но на более простом инструменте решение при этом не усложняется, и уж тем более не становится невозможным.

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

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

VD>>>"Сложность решения не может превышать более чем на порядок сложность инструмента" (c) IT.

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

IT>А где здесь противоречие? Это как раз только подтверждает гениальность мысли, кстати, не моей.

Нет противоречия. Просто в итоге получается, что все решения ограничены сверху (что, кстати, не факт, что верно), причем для всех инструментов одинаково (так как все инструменты выразимы в терминах других). Разница лишь во времени реализации решения. Очень полезная мысль.

VE>>Так что ценность сего высказывания нулевая.

IT>Ценность любого высказывания нулевая, если оно до тебя не доходит.

Однако обратное неверно. Если ценность нулевая, далеко не факт, что оно не дошло.
Впрочем, в аргументах логику давно принято задвигать подальше.