Здравствуйте, 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, Вы писали:

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