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

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

I>>Ну вообще говоря язык проектируется под определенный набор фич, а точнее под определенные задачи

K>И вас, конечно, не затруднит перечислить эти определенные задачи, которые требуют возможности передавать функцию "вниз", но не требуют передавать "вверх"?

Обработка данных.

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

Стек был изобретен задолго до алгола.

>И функции, которые можно передавать только "вниз" — один из результатов такого выжимания. Они такие не потому, что нужны именно такие, а потому, что другие их создатели себе позволить не могли.

Это неважно.

K>Это смешно, потому, что критерий смешной и обобщение бесполезно. Нет никакого применения для обобщения замыканий и не замыканий введением "пустого контекста". Ну, кроме как насмешить собеседника в форумном диспуте.

Это уменьшает количество понятий.

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

I>Мейнстрим это задачи, а не ЯП.

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

I>ЯП это уже следствие.

ЯП из задачи никак не следует.

I>Так ты определись, можно ли модели предсказывать или нет

По адекватной модели — можно конечно.

I>Не важно для чего делали. Важно для чего он пригоден. Иногда это одно и то же, иногда — нет.

Т.е. создатели языка не в состоянии определить его "пригодность" к чему-то на этапе дизайна? Ну это и не возражение вовсе. Если бы существовала реальная, а не воображаемая связь между свойствами языка и классом задач, для решение которых нужны как раз такие свойства — можно было бы "вычислять" язык из задачи или наоборот, "вычислять" задачу, для которой язык подходит лучше всего по свойствам данного языка. Это сделао бы вашу теорию проверяемой. Но это все фантастика, а значит связь эта — ничем не подтвержденные измышления.

K>>Подавляющее большинство языков не заточены под какую-то нишу.
I>Это заблуждение. Проверяется очень легко — берешь одну и ту же задачу и пишешь на самых разных ЯП.

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

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

А вот это уж точно фантастика. В реальном мире обычно наоборот: код либо компактный и понятный, но тормозной — либо уродливый и многословный, но быстрый, либо и уродливый и тормозной. До красивого и быстрого кода индустрии еще далеко.

I>Выбор языка вообще говоря определяется задачами, а не состоянием рынка труда. НАпример несмотря на то, что подавляющее большинство умеет JS + С# или Java или С++, есть целая куча вакансий по другим языкам.

А теперь перенесите C и PHP (ну, может питон еще) из второй кучи в первую и вторую кучу будет видно разве только в микроскоп.

I>Правильно, я и говорю — язык это следствие. А главное это задачи.

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

K>>4) Не смотря на все это, иногда таки можно выбрать кактус, который колется поменьше — это инициирует лавинообразный переход на новое семейство языков, как только мы можем себе это позволить, но не раньше.
I>Это непроверяемо и нефальсифицируемо, так шта...

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

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

K>>И вас, конечно, не затруднит перечислить эти определенные задачи, которые требуют возможности передавать функцию "вниз", но не требуют передавать "вверх"?
I>Обработка данных.

Что за обработка данных? Или это опять "обобщенная задача" которая в себя вообще все включает?
Почему обработка данных требует передачу функций "вниз"? Почему не требует передачу "вверх"?

I>Стек был изобретен задолго до алгола.

Да неужели?

>>И функции, которые можно передавать только "вниз" — один из результатов такого выжимания. Они такие не потому, что нужны именно такие, а потому, что другие их создатели себе позволить не могли.
I>Это неважно.

Если это не важно — что вообще важно? Я показываю на реальных примерах причины, по которым языки становятся такими, какими становятся.

I>Это уменьшает количество понятий.

Зачем? Какая от этого польза?

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

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

I>>Мейнстрим это задачи, а не ЯП.

K>Не согласен. Задачи у мейнстрима как раз меняются, а характерные свойства инструментария и культуры производства остаются.

I>>ЯП это уже следствие.
K>ЯП из задачи никак не следует.

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

I>>Так ты определись, можно ли модели предсказывать или нет
K>По адекватной модели — можно конечно.

Значит ООП дает адекватную модель

I>>Не важно для чего делали. Важно для чего он пригоден. Иногда это одно и то же, иногда — нет.

K>Т.е. создатели языка не в состоянии определить его "пригодность" к чему-то на этапе дизайна?

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

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

Она уже давно есть, здесь не надо ничего придумывать.

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

Конечно. Проверяем на SQL. В своих задачах он рвёт в хлам любые языки. Попробуй использовать его для обработки данных, рендеринга, вычислений, UI ... SQL cдох вместе с твоей теорией.

Берём Хаскель и делаем всякие вычисления — хаскель крут. грузим XML, пишем вебсайт со всеми потрохами, мобильное, серверное с богатым UI — хаскель сдох вместе с твоей теорией.

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

K>А вот это уж точно фантастика. В реальном мире обычно наоборот: код либо компактный и понятный, но тормозной — либо уродливый и многословный, но быстрый, либо и уродливый и тормозной. До красивого и быстрого кода индустрии еще далеко.

Красивый код это твой термин и ты сам его притянул. Для запросов к базе пока трудно найти замену SQL — здесь все компактно, понятно и быстро — порвать SQL по перформансу крайне сложно.
Низкоуровневые операции — на С++ это просто и компактно да еще и быстро. Порвать С++ здесь вряд ли получится.


I>>Выбор языка вообще говоря определяется задачами, а не состоянием рынка труда. НАпример несмотря на то, что подавляющее большинство умеет JS + С# или Java или С++, есть целая куча вакансий по другим языкам.

K>А теперь перенесите C и PHP (ну, может питон еще) из второй кучи в первую и вторую кучу будет видно разве только в микроскоп.

А еще лучше всю вторую кучку перекинуть в первую,это даст неоспоримое доказательство твоей теории.

I>>Правильно, я и говорю — язык это следствие. А главное это задачи.

K>Если бы это было так, то существовал настоящий "зоопарк" сильно различающихся языков, каждый из которых живет в одной нише.

Этот зоопарк уже давно существует

K>>>4) Не смотря на все это, иногда таки можно выбрать кактус, который колется поменьше — это инициирует лавинообразный переход на новое семейство языков, как только мы можем себе это позволить, но не раньше.
I>>Это непроверяемо и нефальсифицируемо, так шта...

K>Ну почему? Эта теория дает вполне проверяемые предсказания. Например, ФЯ, когда (и если) получат технически приемлимые реализации и инфраструктуру будут доминировать в большинстве областей вне зависимости от задачи, а на сохранившихся ООЯ будут эмулировать ФП, точно так же как ООЯ вытеснили СЯ, а на оставшихся эмулируют ООП сейчас.

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

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

Почему то эта кадровая инерция не мешала появлению шейдеров с возникновением видеокарт, не мешала появлению SQL c возникновением реляционных БД, не мешала распространению js+css с распростренением браузеров

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

I>Она уже давно есть, здесь не надо ничего придумывать.

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

I>Проверяем на SQL.

SQL я упомянул как один из немногих исключений. Это ДСЛ. Вы же говорили о "специализации" языков общего назначения.

I>Берём Хаскель и делаем всякие вычисления — хаскель крут.

Вычисления? Вы шутите?

I>грузим XML, пишем вебсайт со всеми потрохами, мобильное, серверное с богатым UI

А это, опять таки упомянутое, сравнение набора библиотек.

I>Низкоуровневые операции — на С++ это просто

Как бы не так. С чем сравнивали?

I>и компактно

Да уж, конечно. С чем сравнивали?

I>да еще и быстро. Порвать С++ здесь вряд ли получится.

Правильно. Есть быстрая реализация. Других подходящих реализаций нет, так что сравнивали C++ с C++-ом. Естественно он победил!
А как ваша теория объясняет то, что не то что на C++, а вовсе на C пишут не только "низкоуровневый" софт.

I>А еще лучше всю вторую кучку перекинуть в первую,это даст неоспоримое доказательство твоей теории.

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

K>>Если бы это было так, то существовал настоящий "зоопарк" сильно различающихся языков, каждый из которых живет в одной нише.
I>Этот зоопарк уже давно существует

Вы, как будто с другой планеты пишете. У нас, на Земле, одно время почти все задачи на C решали, потом почти все те же самые — на C++.

I>Вообще говоря у них уже есть эти самые приемлемые реализации и инфраструктура, кроме некоторых лабораторных языков вроде хаскеля.

Какие еще ФЯ, кроме "некоторых лабораторных"?

I>Почему то эта кадровая инерция не мешала появлению шейдеров с возникновением видеокарт, не мешала появлению SQL c возникновением реляционных БД, не мешала распространению js+css с распростренением браузеров

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

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

K>>>И вас, конечно, не затруднит перечислить эти определенные задачи, которые требуют возможности передавать функцию "вниз", но не требуют передавать "вверх"?
I>>Обработка данных.

K>Что за обработка данных? Или это опять "обобщенная задача" которая в себя вообще все включает?

сбор, ввод, хранение, накопление, поиск, контроль, передача, представление.

K>Почему обработка данных требует передачу функций "вниз"? Почему не требует передачу "вверх"?

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

I>>Стек был изобретен задолго до алгола.

K>Да неужели?

В Алголе стек всего лишь получил специальную поддержку в процессоре:

Algol 60 would have been impossible to adequately process in a reasonable way without the concept of
stacks. Though we had stacks before, only in Algol 60 did stacks come to take a central place in the
design of processors.

K>Если это не важно — что вообще важно? Я показываю на реальных примерах причины, по которым языки становятся такими, какими становятся.

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

I>>Это уменьшает количество понятий.

K>Зачем? Какая от этого польза?

Бритва Оккама утратила актуальность ? Не знал

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

I>>Она уже давно есть, здесь не надо ничего придумывать.

K>Если есть — предъявляйте упомянутый способ ""вычислять" язык из задачи или наоборот, "вычислять" задачу, для которой язык подходит лучше всего по свойствам данного языка."

I>>Проверяем на SQL.

K>SQL я упомянул как один из немногих исключений. Это ДСЛ. Вы же говорили о "специализации" языков общего назначения.

I>>Берём Хаскель и делаем всякие вычисления — хаскель крут.

K>Вычисления? Вы шутите?

Вычисления и прочие алгоритмические задачи.

I>>грузим XML, пишем вебсайт со всеми потрохами, мобильное, серверное с богатым UI

K>А это, опять таки упомянутое, сравнение набора библиотек.

Напиши на чистом хаскеле самый быстрый парсер XML и посмотри на результат.

I>>Низкоуровневые операции — на С++ это просто

K>Как бы не так. С чем сравнивали?

С самыми разными языками, на которых мне доводилось работать. Можешь меня опровергнуть — покажи хорошую массовую ОС писаную не на С/C++, достаточно одного примера.

I>>и компактно

K>Да уж, конечно. С чем сравнивали?

см выше.

I>>да еще и быстро. Порвать С++ здесь вряд ли получится.

K>Правильно. Есть быстрая реализация. Других подходящих реализаций нет, так что сравнивали C++ с C++-ом. Естественно он победил!

Не правильно. См выше.

K>А как ваша теория объясняет то, что не то что на C++, а вовсе на C пишут не только "низкоуровневый" софт.

Очень просто, С это всегда С++, С++ не всегда С.

I>>А еще лучше всю вторую кучку перекинуть в первую,это даст неоспоримое доказательство твоей теории.

K>Попробуйте сначала найти ее без микроскопа, а потом можно решить — перекидывать или нет.

I>>Этот зоопарк уже давно существует

K>Вы, как будто с другой планеты пишете. У нас, на Земле, одно время почти все задачи на C решали, потом почти все те же самые — на C++.

Если точнее, то такого никогда не было.

I>>Вообще говоря у них уже есть эти самые приемлемые реализации и инфраструктура, кроме некоторых лабораторных языков вроде хаскеля.

K>Какие еще ФЯ, кроме "некоторых лабораторных"?

Erlang, Ocaml

I>>Почему то эта кадровая инерция не мешала появлению шейдеров с возникновением видеокарт, не мешала появлению SQL c возникновением реляционных БД, не мешала распространению js+css с распростренением браузеров

K>Потому, что это DSL, которые специализированы по определению. Вы же утверждали, что языки общего назначения выбирают по задаче.

Конечно. Напиши драйвер на хаскеле, питоне, руби... Можешь даже на дельфи попробовать — реализуемо, но в своем уме никто этим не занимается.

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

...
I>>>То есть вложеные процедуры есть замыкания.

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

I>Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

Язык (Object Pascal,Delphi) — вообще запрещает передавать вложеные процедуры куда бы то ни было

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

I>>Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

W>Язык (Object Pascal,Delphi) — вообще запрещает передавать вложеные процедуры куда бы то ни было

Почти. Вниз все работает:

program test;
uses crt;
type
  MegaProc = procedure(s:string);

  procedure Main;


    procedure Suxx(p:Pointer);
              var proc:MegaProc;
    begin
     proc := MegaProc(p);

     proc('hello world');
    end;

    procedure Print(s:string);far;
    begin
     WriteLn(s);
    end;


  begin


    Suxx(@Print); {вызываем вложеную и передем как параметр вложуную}
  end;

  begin
  Main;
end.

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

G>Кстати, есть хороший пример, как люди крупно облажались с ООП подходом "моделируя реальность".
G>WinForms — каждый раз при изменении размера визуального компонента каскадно вызываются множественные перерасчеты. Конечно до модели взаомодействия молекул в луже там далеко, но немного похоже. Модель крайне неэффективная и работает очень медленно. Ага, и им пришлось еще модельку ломать, что бы хоть как-то криво заработало, но результат-то все-равно печальный.
Да, для меня это пример грустного юмора.
Когда начинается поиск примеров задач, для которых ООП позволяет в полный рост "моделировать реальный мир", то как раз оконный UI выходит на первый план. Всё здорово — окна-объекты обмениваются сообщениями; идентичность и инкапсуляция в полный рост. Всё как Кей сказал.

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

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

L>перевернуло мое представление о создании программ. У него описано, что истоки нужно искать в реальном мире, составляя так называемые use-case'ы. Реальные случаи использования системы.
L>А из них выделять существительные (классы) и глаголы (методы). Это само собой не все ООП, но суть такова.
Надо почитать. Пока что звучит страшно: очередная попытка пропихивания мисконцепций авторитетом.

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

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

Это тоже нормально реализуется в ООП

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

I>Это тоже нормально реализуется в ООП
Но не в таком ООП, которое приходит в голову наивному проектировщику. Обработка WM_PAINT тысячами WindowProc — это худший способ добиться результата.

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

I>>Это тоже нормально реализуется в ООП
S>Но не в таком ООП, которое приходит в голову наивному проектировщику. Обработка WM_PAINT тысячами WindowProc — это худший способ добиться результата.

Проектирование глобального рендерера это задача мягко говоря не простая. В WPF микрософт отказались той моджели что WinForms и во многих сценариях перформанс стал ещё хуже.

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

K>>Почему обработка данных требует передачу функций "вниз"? Почему не требует передачу "вверх"?
I>Потому что в большинстве этих задач ресурсы и вычисления нужно описывать и контролировать явно.

Ну, допустим, нужно. Почему требуется передача функций "вниз"? Почему не требуется "вверх"?

I>В Алголе стек всего лишь получил специальную поддержку в процессоре:

Так в Алголе или в процессоре? Да, аппаратная поддержка стека появилась после Алгола. Вы это хотели сказать? Ну и понятно почему. Это первый язык для которого она бы пригодилась.
Не понятно о каком "всего лишь" можно говорить, стек — это главная алголовская инновация, определившая облик основных языков на полвека вперед. До этого либо память распределялась статически и не было никаких рекурсий (Фортран) — либо все было в куче (Лисп).

I>Потому что ты не рассматриваешь причины, по которым ЯП вообще появились и почему они востребованы до сих пор.

Ну разумеется я рассматриваю эти причины.

I>То есть у тебя ЯП сами по себе, в вакууме, да еще с неотъемлимым свойством "популярность" которое меняеся само по себе.

Сами по себе они у вас. У меня они как раз рассматриваются без отрыва от реальности. ЯП нужны для написания библиотек. Это их единственная "специализация". Одни лучше для этого подходят — другие хуже. Почему хуже? Потому что на определенном этапе не было технической возможности сделать лучше. Есть тенденция переходить на языки, которые подходят для этого лучше, после того, как эти улучшения можно себе позволить. С поправкой на кадровую и инфраструктурную "инерции". Ответ на появление новых задач — это появление новых библиотек (и ДСЛ-ей, которые, если встроены — вообще мало чем от библиотек отличаются). Языки общего назначения в ответ на появление нового класса задач не появляются.

K>>Зачем? Какая от этого польза?
I>Бритва Оккама утратила актуальность ?

Разумеется не утратила. Поэтому я и спрашиваю: зачем? какая от этого польза? В ответ на введение бессмысленного объединения замыкания-и-не-замыкания-все-вместе со всякими "пустыми контекстами".

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

I>>>Берём Хаскель и делаем всякие вычисления — хаскель крут.
K>>Вычисления? Вы шутите?
I>Вычисления и прочие алгоритмические задачи.

Вы всерьез считаете, что хаскель в нынешнем состоянии "крут для вычислений"? А что вы подразумеваете под "неалгоритмическими" задачами? И почему хаскель, по-вашему, не крут для них?

I>Напиши на чистом хаскеле самый быстрый парсер XML и посмотри на результат.

Результат будет не хуже чем в среднем по компилируемым языкам, не считая небольшого числа языков в имплементации которых были вложены основные усилия вроде C++. Скорость в данном случае — в первую очередь вопрос имплементации (некоторые языковые фичи вроде динамики ограничивают скорость принциписально).
И, собственно про скорость (в числе прочего) я и говорю "(не)можем себе позволить".

I>С самыми разными языками, на которых мне доводилось работать. Можешь меня опровергнуть — покажи хорошую массовую ОС писаную не на С/C++, достаточно одного примера.

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

I>>>и компактно
I>см выше.

Что это за язык такой, на котором код менее компактный, чем на C++? Брейнфак? Лисп? C? Java? Вот, пожалуй и все — на остальных будет компактнее.

K>>Правильно. Есть быстрая реализация. Других подходящих реализаций нет, так что сравнивали C++ с C++-ом. Естественно он победил!
I>Не правильно. См выше.

Да все правильно. Выше и сравнивается C++ с самим собой.

K>>А как ваша теория объясняет то, что не то что на C++, а вовсе на C пишут не только "низкоуровневый" софт.
I>Очень просто, С это всегда С++, С++ не всегда С.
Во-первых, С — это не всегда С++, ну да ладо. Вопрос то не в этом. Вопрос в том, что если ниша C++ — низкоуровневый код, то как объяснить то, что на нем пишут не только операционные системы (BeOS), но и, например, почтовые клиенты (Thunderbird), поисковые движки (Google), компиляторы (clang), софт для марсохода? В ответ на какой вызов "появился" C++? Когда возникла задача "написание операционнх систем"? "Написание почтовых клиентов"? "Написание поисковых движков"? "Написание компиляторов"? "Программирование марсоходов"? Ведь по вашей теории все это просто не может быть написано на одном языке — иначе языки общего назначения действительно языки общего назначения, как утверждаю я, а не "нишевые", как утверждаете вы. Или вы очередным "вводом пустого контекста" сейчас объясните, что все эти ниши — на самом деле одна ниша?
Как ваша теория объясняет, например, написание интернет-магазина Гремом на лиспе, а потом его переписывание на C++?

В рамках моей теории это все естественно. На C++ переходят, когда (считают что) могут себе это позволить. К примеру, разработчики gcc могут позволить с 14-го числа этого месяца. А когда могут себе позволить что-то более продвинутое — начнут использовать это что-то. Если же "продвинутое" позволить себе уже нельзя — откатываются вниз.

K>>Вы, как будто с другой планеты пишете. У нас, на Земле, одно время почти все задачи на C решали, потом почти все те же самые — на C++.
I>Если точнее, то такого никогда не было.

На планете Земля вполне было. Не существует на нашей планете такой ниши, где бы C не отметился.

K>>Какие еще ФЯ, кроме "некоторых лабораторных"?
I>Erlang, Ocaml

Во-первых, я говорил про ФЯ, а не гибриды. Во-вторых, Окамл — еще "лабораторнее" (в плохом смысле этого слова) Хаскеля. Было, конечно, время, когда Окамл был вообще единственной хоть сколько нибудь пригодной для использования реализацией (недо)ФЯ, но эти времена миновали. В-третих, Эрланг — это как раз один из немногих реально существующих представителей выдуманного вами мира непонятных языков которые то ли общего назначения — то ли ДСЛ, по крайней мере 1% задач он решает лучше, чем 99% языков, а для оставшихся 99% вообще не пригоден.

I>Конечно. Напиши драйвер на хаскеле, питоне, руби... Можешь даже на дельфи попробовать — реализуемо, но в своем уме никто этим не занимается.

Все тот же случай "не можем себе позволить" и соревнующийся сам с собой C.

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

I>>Потому что ты не рассматриваешь причины, по которым ЯП вообще появились и почему они востребованы до сих пор.
K>Ну разумеется я рассматриваю эти причины.

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


Тут снова надо определиться. Не можешь или счиашешь, что ЯП имеет смысл в отрыве от задач — просто не пиши ничего.



K>>>Почему обработка данных требует передачу функций "вниз"? Почему не требует передачу "вверх"?
I>>Потому что в большинстве этих задач ресурсы и вычисления нужно описывать и контролировать явно.
K>Ну, допустим, нужно. Почему требуется передача функций "вниз"? Почему не требуется "вверх"?

Для явного контроля нужно всегда четко знать, что именно ты вызываешь, какие при этом используются ресурсы, какие побочные эффекты и явно указываешь когда что должно освобождаться. Передача функий вверх очевидно ухудшает этот расклад, тк контекст будет хрен знает где. Передача функции вниз ничего не ухудшает — всегда виден локальный контекст.
Простой пример — замыкания в C#. В большинстве случаев, где нужен ручной контроль ресурсов нужно быть в курсе, что именно захватывается, когда освободися и освободится ли вообще. Проявляется это так — одна простая строчка а в памяти висит граф объектов в полтора гигабайта весом и занимает всё АП процесса.
Отсюда понятно, что задачи реалтайма, особенно жосткого, решать очень и очень тяжело, т.к. нужно бороться с основными свойствами замыканий. Многие задачи обработки данных тоже просто так не получится выполнять, замыкания придется обкладывать костылями или отказаться от них вообще.

I>>В Алголе стек всего лишь получил специальную поддержку в процессоре:

K>Так в Алголе или в процессоре? Да, аппаратная поддержка стека появилась после Алгола. Вы это хотели сказать? Ну и понятно почему. Это первый язык для которого она бы пригодилась.
K>Не понятно о каком "всего лишь" можно говорить, стек — это главная алголовская инновация, определившая облик основных языков на полвека вперед. До этого либо память распределялась статически и не было никаких рекурсий (Фортран) — либо все было в куче (Лисп).

Я привел цитату, читай внимательно. Если ты не веришь разработчику алгола, то о чем можно спорить ? Внятно сказано — стек был и до алгола, с алголом он получил поддержку в процессоре. Всё.

I>>То есть у тебя ЯП сами по себе, в вакууме, да еще с неотъемлимым свойством "популярность" которое меняеся само по себе.

K>Сами по себе они у вас. У меня они как раз рассматриваются без отрыва от реальности.

Странно, но про задачи только я пишу, а ты в принципе отказываешь рассматривать то, благодаря чему ЯП актуальны.

>ЯП нужны для написания библиотек. Это их единственная "специализация". Одни лучше для этого подходят — другие хуже. Почему хуже? Потому что на определенном этапе не было технической возможности сделать лучше. Есть тенденция переходить на языки, которые подходят для этого лучше, после того, как эти улучшения можно себе позволить. С поправкой на кадровую и инфраструктурную "инерции". Ответ на появление новых задач — это появление новых библиотек (и ДСЛ-ей, которые, если встроены — вообще мало чем от библиотек отличаются). Языки общего назначения в ответ на появление нового класса задач не появляются.

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

K>>>Зачем? Какая от этого польза?
I>>Бритва Оккама утратила актуальность ?

K>Разумеется не утратила. Поэтому я и спрашиваю: зачем? какая от этого польза? В ответ на введение бессмысленного объединения замыкания-и-не-замыкания-все-вместе со всякими "пустыми контекстами".

Просто потому что бритва оккама еще не утратила актуальность. У меня никаких новых понятий не вводится. У меня есть замыкания и контекст, всё. У тебя есть вложеные функций, замыкания и тот же самый контекст.
Пустой контекст это просто конкретный случай а не новое понятие. Точно так же можно сказать пустой клас, пустая функция, пустая лямбда и тд и тд.

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

K>Все тот же случай "не можем себе позволить" и соревнующийся сам с собой C.

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

Полагаю, ты сделал для себя выбор — повторять мантру или нет.






K>Вы всерьез считаете, что хаскель в нынешнем состоянии "крут для вычислений"? А что вы подразумеваете под "неалгоритмическими" задачами? И почему хаскель, по-вашему, не крут для них?

Конечно. Позволяет вводить высокоуровневые оптимизации и здесь предела практически нет, в отличие от задач обработки данных. "неалгоритмические задачи" — в моем сообщении такого термина нет.

I>>Напиши на чистом хаскеле самый быстрый парсер XML и посмотри на результат.

K>Результат будет не хуже чем в среднем по компилируемым языкам, не считая небольшого числа языков в имплементации которых были вложены основные усилия вроде C++.

"В среднем" это неинтересно. Те же C# и Java порвут хаскель просто в хлам. Отсюда ясно, что C# и Джава более пригодны для этих задач, нежели хаскель.

I>>С самыми разными языками, на которых мне доводилось работать. Можешь меня опровергнуть — покажи хорошую массовую ОС писаную не на С/C++, достаточно одного примера.

K>Ну, для написания ОС нельзя (с незначительными в контексте дискуссии оговорками) ничего себе позволить кроме C++ и C. Значит и сравнивать можно только С++ с C. Т.е. пример это вырожденный — если бы были ОС с равной функциональностью на разных языках — можно было бы сравнивать код и определить какой язык лучше подходит. Но в условиях, когда выбор языка себе прозволить нельзя — и сравнивать нечего.

Когда речь про ОС, ты почему то понимаешь пригодность языка для определенных задач. А как чуть что другое — так все языки резко одинаковы.

Давай не ОС, а обработку изображений, звука, видео, текст ? Что, и здесь плохо, опять С++ мешает ? Ну ладно, берем гигантски пакеты вроде Офиса. Тут вроде бы ничего не мешает. Как ты будешь описывать АПИ взаимодействия компонентов на хаскеле ? Наверное тебе нравится такой вариант "плагины для ХаскельОфис можно писать только на хаскеле"

I>>>>и компактно
I>>см выше.

K>Что это за язык такой, на котором код менее компактный, чем на C++? Брейнфак? Лисп? C? Java? Вот, пожалуй и все — на остальных будет компактнее.

Я уже говорил, берешь задачу и требования — функциональные, нефункциональные. Реализуешь, меряешь. Реализовал, результат удовлетворяет — язык пригоден. Не реализовал — не пригоден. Реализовал, результат неудовлетворяет — язык не пригоден.

K>>>Правильно. Есть быстрая реализация. Других подходящих реализаций нет, так что сравнивали C++ с C++-ом. Естественно он победил!
I>>Не правильно. См выше.

K>Да все правильно. Выше и сравнивается C++ с самим собой.

См выше, про мантру.

K>>>А как ваша теория объясняет то, что не то что на C++, а вовсе на C пишут не только "низкоуровневый" софт.
I>>Очень просто, С это всегда С++, С++ не всегда С.
K>Во-первых, С — это не всегда С++, ну да ладо. Вопрос то не в этом. Вопрос в том, что если ниша C++ — низкоуровневый код, то как объяснить то, что на нем пишут не только операционные системы (BeOS), но и, например, почтовые клиенты (Thunderbird), поисковые движки (Google), компиляторы (clang), софт для марсохода?

Пока пишут, и доля С++ в этих областях сокращается. Софт для марсохода это обработка данных + управление железом — в чистом виде именно то подо что заточен С++.

> В ответ на какой вызов "появился" C++? Когда возникла задача "написание операционнх систем"? "Написание почтовых клиентов"? "Написание поисковых движков"? "Написание компиляторов"? "Программирование марсоходов"? Ведь по вашей теории все это просто не может быть написано на одном языке — иначе языки общего назначения действительно языки общего назначения, как утверждаю я, а не "нишевые", как утверждаете вы. Или вы очередным "вводом пустого контекста" сейчас объясните, что все эти ниши — на самом деле одна ниша?

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

K>Как ваша теория объясняет, например, написание интернет-магазина Гремом на лиспе, а потом его переписывание на C++?

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

K>В рамках моей теории это все естественно. На C++ переходят, когда (считают что) могут себе это позволить. К примеру, разработчики gcc могут позволить с 14-го числа этого месяца. А когда могут себе позволить что-то более продвинутое — начнут использовать это что-то. Если же "продвинутое" позволить себе уже нельзя — откатываются вниз.

"могут позволить" это практически "теория всего".

K>>>Вы, как будто с другой планеты пишете. У нас, на Земле, одно время почти все задачи на C решали, потом почти все те же самые — на C++.
I>>Если точнее, то такого никогда не было.

K>На планете Земля вполне было. Не существует на нашей планете такой ниши, где бы C не отметился.

То есть, даже единичное использование означает что "задачи решали на С" ? Я ж говорю — "теория всего"

K>Во-первых, я говорил про ФЯ, а не гибриды.

Тут можно и заканчивать, ибо нет ни одного языка не-гибрида, разве что xml какой или машинный код

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

I>Надо определиться имеют ли смысл ЯП в отрыве от задач.

Никакой инструмент не имеет смысла в отрыве от задач. Проблема в том, что вы не понимаете для каких задач существуют обсуждаемые инструменты. Языки общего назначения — это инструменты для разработки инструментов: библиотек, ДСЛ, других языков общего назначения. Это и есть задача. Поэтому все языки в одной "нише" и конкурируют друг с другом. Никто не изобретает языки, например, для разработки компиляторов, но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.
Выбор языка происходит не под задачу, а так:
1) Отсекаем все языки, для которых вы не найдете программистов.
2) Отсекаем все языки, для которых нет устраивающих вас реализаций.
3) отсекаем все языки, не имеющие набора библиотек, которые нужны для решения ваших задач.
Вот теперь мы переходим к сравнению языков:
4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
Чем продвинутее язык, тем сложнее его реализовать и тем позднее появится практически пригодная имплементация. У каждого нового языка первоначально нет библиотек. Почему же происходит смена? Продвинутый язык лучше подходит для написания библиотек и потому рано или поздно догоняет и перегоняет.

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

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

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

Можно не бороться со свойствами замыканий, а бороться с замыканиями. Про лямбда-лифтинг слышали? Вот только это требует качественной и более затратной при разработке реализации, а не наивной, в которой все замыкания в куче.

I>Внятно сказано — стек был и до алгола

Где?

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

"Легко" — это зависит от хаскелла как языка. "Эффективно" — это зависит от качества его реализации, которой еще далего до нужного уровня. Т.е. мы останавливаемся на пункте 2, до сравнения языков еще далеко.

I>Просто потому что бритва оккама еще не утратила актуальность. У меня никаких новых понятий не вводится. У меня есть замыкания и контекст, всё. У тебя есть вложеные функций, замыкания и тот же самый контекст.

Разделение на замыкание и static chain вполне имеет смысл. Это вы сами обосновали выше, сравнивая их. Это необходимые сущности, их введение обосновано.

I>Пустой контекст это просто конкретный случай а не новое понятие.

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

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

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

Объяснил уже три раза — последний раз здесь

Автор: Klapaucius
Дата: 24.08.12

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

K>>Вы всерьез считаете, что хаскель в нынешнем состоянии "крут для вычислений"? А что вы подразумеваете под "неалгоритмическими" задачами? И почему хаскель, по-вашему, не крут для них?
I>Конечно. Позволяет вводить высокоуровневые оптимизации

Это все существует в зачаточной форме. Потенциал есть, работы ведутся, но до устройчивых результатов еще далеко.

I>в отличие от задач обработки данных

Не понятно, в чем отличие.

K>>Результат будет не хуже чем в среднем по компилируемым языкам, не считая небольшого числа языков в имплементации которых были вложены основные усилия вроде C++.
I>"В среднем" это неинтересно. Те же C# и Java порвут хаскель просто в хлам.

Насчет "в хлам" — это сомнительно, но думаю, что C# на CLR порвет, а C# на Mono — наоборот, глотнет пыли на обочине. Идея ясна? Разумеется, HotSpot и CLR входят в число десятка имплементаций, в которые труда вложено больше, чем во все остальные вместе взятые.

I>Когда речь про ОС, ты почему то понимаешь пригодность языка для определенных задач. А как чуть что другое — так все языки резко одинаковы.

Пригодность реализации. До сравнения языков дело вообще не доходит.

K>>Вопрос то не в этом. Вопрос в том, что если ниша C++ — низкоуровневый код, то как объяснить то, что на нем пишут не только операционные системы (BeOS), но и, например, почтовые клиенты (Thunderbird), поисковые движки (Google), компиляторы (clang), софт для марсохода?
I>Пока пишут, и доля С++ в этих областях сокращается.

Как же так? Ведь в вашей теории:
1) Один язык не может занимать несколько областей. Одна область — один идеально подходящий для нее язык.
2) Доля в области не может сократится. Язык — это ответ на появление новой области и пока существует область ее будет занимать один и тот же язык.
Вы эти следствия своей теории понимаете? В реальности их наблюдаете?

I>Софт для марсохода это обработка данных + управление железом — в чистом виде именно то подо что заточен С++.

Я знал! Я знал!

Или вы очередным "вводом пустого контекста" сейчас объясните, что все эти ниши — на самом деле одна ниша?

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

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

I>Чисто экономические причины. Думаю вместо лиспа мог бы быть какой угодно язык, в т.ч. С++. Яха купил фактически пользовательскую базу, то есть бизнес, а сам язык никого не интересует, абы работало.

Если бы язык не интересовал — все бы оставили как есть. Но ведь переписали — потому, что язык интересовал. Только Грема один, а Яху — другой.

I>То есть, даже единичное использование означает что "задачи решали на С" ?

Куда больше, чем просто единичное. Куда деваться-то если "других языков у меня для вас нет"? Единичное использование для практически всех ниш — такое почти для каждого языка можно найти.

K>>Во-первых, я говорил про ФЯ, а не гибриды.
I>Тут можно и заканчивать, ибо нет ни одного языка не-гибрида

Ладно, под "гибридом" я имею в виду то, что обычно тут имеют в виду — императивный язык с несколькими функциональными финтифлюшками. Когда я говорил ФЯ в этой ветке я подразумевал полноценную поддержку ФП.