Как вы считаете, из за каких свойств языка разработчику приятно на нём писать. Что даёт fun? Процитирую кусок из этой статьи:

> The other big reason we looked at Scala was that, although we’ve run into problems with Ruby, we like the flexibility of the language. We like that it’s such a full featured language, that it’s fun to code in. It’s the same reason so many Java people end up writing Ruby after they leave some big enterprise company. They want to have fun day to day. We didn’t want to leave that behind and go to a language with a very dry, businesslike community, like C++, for example. We know that people write super high performance code in C++, and engineers like Steve and Robey have had experience with that. But we wanted to be using a language that we’re really passionate about, and it seemed worth taking a gamble on Scala.

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

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

vsb>Как вы считаете, из за каких свойств языка разработчику приятно на нём писать. Что даёт fun?

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

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

Ytz>fun дает не сам язык, а результат. Когда надо долго писать, чтобы что-то получить — фана мало, когда результат видно сразу — фана много. Поэтому важно сразу получить что-то работающее и уже потом постепенно добавлять функционал.
Я не соглашусь с таким высказыванием, т.к. для меня фанство языка выражается очень просто : Если язык позволяет мне писать программы наиболее близкие к описанию логики предметной области — это фанство, в противном случае — отстой. Результатом фанского языка являются краткие, четкие и очевидные последовательности предложений языка. Если для выражения мысли мне надо написать кучу кода, в которых исходную мысль не увидеть даже с микроскопом — такой язык в топку. Поэтому Java и C# — ни разу не фанские, Scala — так себе, ей нужен в виде костылика Clojure, Nemerle (в основном с метапрограммированием и построением собственных DSL) — мой выбор фанского языка на сегодняшний день
При этом, если для реализации задачи нужно писать много, то я буду писать много и фанства у меня от этого не убавится. Декомпозиция задачи с выбором языка вроде не связаны, а возможность быстрой реализации прототипа опять на Nemerle есть.

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

HT>Я не соглашусь с таким высказыванием, т.к. для меня фанство языка выражается очень просто : Если язык позволяет мне писать программы наиболее близкие к описанию логики предметной области — это фанство, в противном случае — отстой. Результатом фанского языка являются краткие, четкие и очевидные последовательности предложений языка. Если для выражения мысли мне надо написать кучу кода, в которых исходную мысль не увидеть даже с микроскопом — такой язык в топку.

Может вы просто не умеете их готовить? Я не про кучу кода, а про видимость основной мысли (что в общем то ортогонально).

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

vsb>Как вы считаете, из за каких свойств языка разработчику приятно на нём писать. Что даёт fun?

Соглашусь с Ytz по поводу быстрого результата, потому языки без REPL так себе.
Второй fun'овый параметр (по сути почти прямо влияющий на первый) — если компилируется — работает, соот-но нужна сильная типизация.

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

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

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

так же радует, когда пишешь мало рутинного кода
в той же Java или C приходится писать много рутинного кода.
в C# поменьше, особенно в последних
js сильно расстраивает после C#-linq

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

DG>поддерживаю — радует когда можно быстро получить результат.

DG>так же радует, когда пишешь мало рутинного кода
DG>в той же Java или C приходится писать много рутинного кода.
DG>в C# поменьше, особенно в последних
DG>js сильно расстраивает после C#-linq

а linq.js?

К>а linq.js?

спасибо, как workaround пойдет.

но глобально расстраивает, что нет extension-ов (обязательно нужны обертки, чтобы как последовательность методов писать)
и что нет краткого синтаксиса для лямбд

К>а linq.js?

DG> и что нет краткого синтаксиса для лямбд

но я смотрю они пошли дальше, и заюзали трюк, когда код в виде строки передается, и сделали свой язычок для лямбд
вот этим js и расстраивает, что приходится использовать всякие нехорошие трюки чтобы писать удобно

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

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

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

Тогда, чем прямее язык позволяет выражать то, что ты “думаешь”, тем приятнее писать. И чем больше надо писать вспомогательного кода, тем язык неприятнее.

Например когда надо перебрать элементы массива, foreach прямее выражает мысль, чем for (int i = 0; i < N; ++i).

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

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

К>а linq.js?
Лучше на мой взгляд jsinq — он не пытается притянуть C#/.net в js, оставаясь при этом в практически том же, а то и большем функционале.

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

vsb>Как вы считаете, из за каких свойств языка разработчику приятно на нём писать. Что даёт fun?
...

Фан дает прикладная область , а ковыряние в языке ради языка это несколько незрело , что ли. И быстро надоест.

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

vsb>Как вы считаете, из за каких свойств языка разработчику приятно на нём писать. Что даёт fun?

Простота.

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

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

vsb>>Как вы считаете, из за каких свойств языка разработчику приятно на нём писать. Что даёт fun?

O>Простота.

В каком смысле? Для меня вот дает шанс наоборот сложность — сложность решаемых задач.

On 04/29/2011 11:46 AM, vsb wrote:

> Как вы считаете, из за каких свойств языка разработчику приятно на нём писать.
> Что даёт fun? Процитирую кусок из этой статьи

Высокоинтеллектуальный, функциональный (во всех смыслах) язык и -- чтобы много
скобочек.

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

vsb>>>Как вы считаете, из за каких свойств языка разработчику приятно на нём писать. Что даёт fun?
O>>Простота.

H>В каком смысле? Для меня вот дает шанс наоборот сложность — сложность решаемых задач.

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

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

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

По моему скромному мнению.

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

Ytz>fun дает не сам язык, а результат. Когда надо долго писать, чтобы что-то получить — фана мало, когда результат видно сразу — фана много. Поэтому важно сразу получить что-то работающее и уже потом постепенно добавлять функционал.

Ага. И именно по этому в мире есть куча на первый взгляд интересных вещей которые оказываются ни на что ни годны при тщательном рассмотрении. Фофаны (4fun-ы) обычно доводят дело до состояния когда ясно что оно может удастся и за тем бросают.

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

ЗЫ

Простите за скептицизм.

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

Кё>Кобольщик, взяв современный С++, будет наверное безмерно счастлив,

Не факт. Может оказаться, что он просто не поймет новых концепций (парадокс Блаба никто не отменял).

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

Вот именно! Важно понимание и принятие концепций. Без этого "пробовать" можно хоть до посинения.

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

M>Фан дает прикладная область , а ковыряние в языке ради языка это несколько незрело , что ли. И быстро надоест.

Если у человека прикладной областью являются языки, то почему бы ему не получать удовольствие от "ковыряния в языках"?

Здравствуйте, 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>Ценность любого высказывания нулевая, если оно до тебя не доходит.

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

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

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

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

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

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

VE>Т.е. практически любая полезная деятельность выливается в повышение сложности решения.

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

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

VE>Разумеется.

Рад, что мы пришли к единому мнению.

VE>Только где грань между написанием инструмента и собственно решением?

Эта грань тонка и эфемерна. Более того только с опытом можно научиться ее четко улавливать.
Возможно что тут нужны научные исследования.

VE>Любой вспомогательный класс по сути есть улучшение инструмента.

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

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

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

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

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

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

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

VD>Да.
VD>Только вот у библиотек есть ограничения. У фрэймворков тоже, но в них подразумевается что можно выходить за рамки одного инструмента (языка, например) и это дает простор для маневра. Но создавать фреймворки в традиционной манере очень сложно. То что для макросного подхода является задачей средней сложности, то для фреймворкного может оказаться неподемной задачей.

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

VE>>Только где грань между написанием инструмента и собственно решением?

VD>Эта грань тонка и эфемерна. Более того только с опытом можно научиться ее четко улавливать.

Вот именно поэтому исходная фраза бесполезна, так как она оперирует понятиями сложность решения и сложность инструмента, грань между которыми (решением и инструментом) тонка и эфемерна.

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

Я это и не оспаривал.

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

N>Это не плоскогубцы и молоточки — это готовая рабочая среда, реализованная в виде качественных библиотек. В таком окружении могут комфортно работать даже непрограммисты (математики, физики).

Вообще-то и то и другое — это инструменты. Библиотечки, язычки, среды разработки — это как раз и есть плоскогубцы и молоточки программистов.

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

Ты можешь провести чёткую грань между разработчиками библиотек и их пользователями?

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

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

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

Вот и я о том же. Жаль только, что до многих такая простая мысль не доходит, приходится объяснять.

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

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

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

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

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

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

BASIC?

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

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

J>BASIC?

РАПИРА

Проц Старт()
    Вывод 'Здравствуй, мир!'
Кон Проц

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

N>>Ты и Влад, как мне кажется, путаете разработчиков библиотек и их пользователей. Разработчиков мало, им нужен мощный язык. Пользователей большинство — им надо решать проблемы предметной области, то есть нужны конкретные (и удобные!) библиотеки.
WH>Загони Nemerle.Peg в библиотеку...

Опять 25...
Ты реально сравнивал на нейтиве разницу, скажем, в работе табличных лексеров и кодогенеренных на switch/case? Там единицы процентов разница или ее нет вообще. При том, что первый вариант вполне себе библиотечный. По замерам, эффективность символьного буффера больше сказывается на производительности, чем техника исполнения парсера. Если заюзать unsafe под дотнетом (покатит для устанавливаемых локально библиотек и для click-once), то можно нивелировать тормоза выборки из дотнетных массивов. Потому как символьные буфера на дотнетных массивах (или не приведи господи на IEnumerable<char>) губят быстродействие парсера сразу в полтора-два раза. А без буферов никак, многогигабайтные лог-файлы в строку не загонишь.

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

IT>Вообще-то и то и другое — это инструменты. Библиотечки, язычки, среды разработки — это как раз и есть плоскогубцы и молоточки программистов.

Мне эта аналогия ни о чём не говорит. Разве что употребление слова молоточки с уменьшительно-ласкательным суффиксом выдаёт некоторое пренебрежительное отношение к ним.

N>>Ты и Влад, как мне кажется, путаете разработчиков библиотек и их пользователей. Разработчиков мало, им нужен мощный язык. Пользователей большинство — им надо решать проблемы предметной области, то есть нужны конкретные (и удобные!) библиотеки.
IT>Ты можешь провести чёткую грань между разработчиками библиотек и их пользователями?

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

Мне кажется, что ты хочешь донести до меня мысль о необходимости разработки языка (или даже компилятора?) под каждую задачу?

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

IT>Вот и я о том же. Жаль только, что до многих такая простая мысль не доходит, приходится объяснять.

Это-то ладно, некоторые вообще сию мысль гениальной считают. Вот где беда.

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

Ой и не говори!

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

IT>>Вообще-то и то и другое — это инструменты. Библиотечки, язычки, среды разработки — это как раз и есть плоскогубцы и молоточки программистов.
N>Мне эта аналогия ни о чём не говорит. Разве что употребление слова молоточки с уменьшительно-ласкательным суффиксом выдаёт некоторое пренебрежительное отношение к ним.

Попробуй реагировать не только на уменьшительно-ласкательные суффиксы, но, например, на слова вроде 'инструменты'.

IT>>Ты можешь провести чёткую грань между разработчиками библиотек и их пользователями?

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

Как раз вот такое разделение на 'самых грамотных' и остальных и приводит чаще всего к созданию редкостных уродцев. Но это тема другого разговора.

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

N>Мне кажется, что ты хочешь донести до меня мысль о необходимости разработки языка (или даже компилятора?) под каждую задачу?

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

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

IT>>Вот и я о том же. Жаль только, что до многих такая простая мысль не доходит, приходится объяснять.
VE>Это-то ладно, некоторые вообще сию мысль гениальной считают. Вот где беда.

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

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

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

VE>Алсо, опыт с курицами показывает, что они охотнее клюют кнопку, выдающее одно зерно за каждое нажатие, нежели кнопку, которая выдает 10 зёрен, но после 5 нажатий. Т.е. время до получения положительного подкрепления критично.

Тупые курицы считать не умеют. Поставьте туда дельфинов, и пусть они в кнопки клюют

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

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

Нет, конечно.


IT>Я хочу донести мысль, что под каждую задачу нужно выбирать наиболее подходящий инструмент.

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

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

Я не согласен и привожу примеры из сложной области — математики. Решение — Матлаб. Мощные языки не дают практически никакого выигрыша на таких задач, они ничего не могут поделать со сложностью предметной области. Математика тут идеальный пример: многие её уравнения и теоремы выглядят просто и компактно, но очень сложны для понимания.
Все метаязыки позволяют бороться лишь с громоздкостью представления задачи, решают по сути рутинные задачи и только.

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

Приятно писать на языке который ты сам и разработал.