R3>Может хватит писать новые программы и языки, а сделать нормальный командный интерфейс из которого автоматически родится язык?
теория на это отвечает — что не родится (в том смысле, что в вопросе подразумевается, что родится сам собой должен какой-то один самый правильный язык, а что-то однозначно правильное рождается только если критерии заложену в саму проблему и не меняются по ходу).
язык (и соответственно критерии хорошести языка) определяются "сложностью" решаемых задач, а не видом api исполнителя.
api-исполнителя, например, система команд процессора x86 зафиксирована дцать лет назад, но языки под это развиваются до сих пор.
api-исполнителя, *nix-ос, тоже зафиксировано дцать лет назад, но языки на базе этого api развиваются до сих пор
реляционные движки зафиксированы дцать лет назад, но языки развиваются до сих пор
и т.д.
зы
если брать тот же пример с гугл-поиском, то будет следующая ситуация:
если нужно просто выполнить множество запросов — то это простой командный язык (аля bat-файлы + sql)
если следующие запросы зависят от предыдущих, то уже потребуется процедурный язык (переменные, условия, циклы, процедуры и т.д.)
если следующие запросы зависят настолько сложным образом, что для получения ответа необходимо строить полноценные модели, то потребуется ооп-шный язык (или навороченный фя-шный аналог)
и т.д.
т.е. сложность языка зависит от сложности проблематики решаемой проблемы.
Здравствуйте, Real 3L0, Вы писали:
R3>Описывать далее определения "телевизор" и "железная коробка" не имеет смысла, ибо большинство людей их поймёт однозначно.
Не "большинство", а целевая аудитория: данные тексты пишутся в предположении что читающий их уже владеет некоторыми "определениями". При этом вполне себе могут быть и ссылки на источники этих "определений по-умолчанию", если таковые определения довольно специфичны для темы или же неоднозначно трактуются в теме — например, разными авторами.
0>> Программирование, в первую очередь, и есть разрешение этой неполноты и неоднозначности. R3>В программировании же эта проблема не решена, а её никогда не было, потому что начиная с самого-самого первого бита, все объекты жёстко типизированы/определены.
Поэтому лично я его и люблю больше всего! Компьютер всегда делает то, что ты ему сказал, а не то, что ты хотел чтобы он сделал или он подумал что ты хотел сделать именно это и именно таким образом.
Здравствуйте, The Lex, Вы писали:
TL>Не "большинство", а целевая аудитория: данные тексты пишутся в предположении что читающий их уже владеет некоторыми "определениями". При этом вполне себе могут быть и ссылки на источники этих "определений по-умолчанию", если таковые определения довольно специфичны для темы или же неоднозначно трактуются в теме — например, разными авторами.
Вообще-то, ни про какие "данные тексты" я не говорил. А тексты пишутся для разных людей.
TL> Поэтому лично я его и люблю больше всего! Компьютер всегда делает то, что ты ему сказал, а не то, что ты хотел чтобы он сделал или он подумал что ты хотел сделать именно это и именно таким образом.
К счастью, не все любят "каждый день считать одни и те жи биты". Пользователи более требовательный народ, поэтому они уже иногда получают, что компьютер им делает то, что они хотели бы что бы он делал. Программисты же как сидели в каменоломнях, так и сидят.
DG>>какое кол-во абстракций может удержать в голове человек?
U>Весьма ограниченное.
текущие исследования это не подтверждают.
у человека маленькая оперативная память, но высокие способности по усвоению абстракций.
DG>>сколько абстракций на текущий момент поддерживают main-stream языки "нативно": например, Java/C#?
U>C# поддерживает небольшое количество абстракций, поэтому его могут освоить многие, хотя далеко не все. У C++ абстракций больше и они сложнее, поэтому его хорошо освоить могут очень немногие.
какие абстракции поддерживает C++, но не поддерживает C#?
навскидку помню только:
1. макросы,
2. шаблоны,
3. возможность размещения структуры данных в произвольном участке памяти,
4. возможность вставки ассемблерного кода (напрямую и через intrinsic-и)
у C#/.net-а в плюсе:
1)промежуточный код
2)reflection
3)gc
4)строгая типизация на этапе рантайма
5)проверка валидности обращений к памяти (ссылок — косвенно за счет gc и индексов масивов)
6)авто boxing/unboxing
7)lambda
8)вывод типов переменных
9)генерация кода на лету
10)dynamic
11)yield-ы
12)полноценные бинарные модули
весь смысл в том, что чем больше абстракций "нативно" поддерживает ЯП (но, конечно, не в виде винегрета, как, например, PL/I)
тем меньше об этом приходится думать разработчику.
например, сейчас приходится думать про то, что числа бывают — float, double, int, byte, biginteger, decimal, singed/unsigned и т.д.
и это лишь следствие того, что ЯП нативно не поддерживает понятие числа.
если бы поддерживал, то было бы одно понятие number, которое все эти навороты прозрачно поддерживало бы.
вот ты часто думаешь про gc в .net-е? или про boxing/unboxing? или про промежуточный код?
или про то, что благодаря несколько внедренным абстракциям нет проблемы с проездами по памяти?
U>Примерно такому же количеству как в школе. Разница лишь в том, что большинство школьных абстракций становится не нужными и больше не загромождает память, а их место занимает институтские абстракции, обычно несколько более сложные. При этом институтский курс могут хорошо усвоить еще меньшее количество людей, чем школьный. Т.е. с увеличением количества и сложности абстракций процент людей способных ими оперировать очень быстро падает.
какой процент людей в России способен освоить высшее образование?
и ничего что лет 200 назад бытовало мнение, что читать/писать и считать и говорить на иностранных языках способны лишь избранные? а сейчас это умеет каждый. с тех пор люди поменялись?
чем твое мнение отличается от данного мнения?
DG>>числа, пожалуйста, хотя бы порядки.
U>Для этого надо определиться, что мы понимаем под абстракцией и до какого уровня абстракции детализируем.
один из вариантов подсчета — сколько слов(понятий) столько и абстракций.
средний человек оперирует 15-30 тыс. различных слов(понятий)
а в текущих яп — максимум 100 слов(понятий) нативных наберется.
разница на два порядка.
вообще правильно абстракции делить по уровням(понятиям) — навскидку:
понятие — абстракция 0-го порядка,
аксиоматическое понятие — абстракция 1-го порядка,
модель — абстракция 2-го порядка,
теория — абстракция 3-го порядка.
текущие ЯП способны полноценно оперировать лишь на уровне 0-го порядка. при этом имея очень ограниченный встроенный набор абстракций 1-го и 2-го порядка.
R3>... это опять получается программа. Т.е. программа над программами. R3>Может хватит писать новые программы и языки, а сделать нормальный командный интерфейс из которого автоматически родится язык?
кстати, например, заявление от одного человека другому человека — это программа или нет?
слишком сложная семантика для одной команды.
одна команда — это обычно одно предложение.
а заявление строится из 3 частей:
1) описание(модель) ситуации,
2) набор логических выводов из ситуации
3) набор инструкций что необходимо сделать
Здравствуйте, DarkGray, Вы писали:
R3>>Думаю, в абсолютном большинстве — это команда. DG>слишком сложная семантика для одной команды. DG>одна команда — это обычно одно предложение. DG>а заявление строится из 3 частей: DG>1) описание(модель) ситуации, DG>2) набор логических выводов из ситуации DG>3) набор инструкций что необходимо сделать
Ааа, ты имел в виду заявление, как документ. Я думал про словесное/устное заявление.
Но даже в случае заявления-документа, пункты 1 и 2 не являются ключевыми (я бы даже сказал, не являются существенными), ибо в любом случае получатель заявления будет принимать решение не только и не сколько из-за информации в этих пунктах.
R3>Но даже в случае заявления-документа, пункты 1 и 2 не являются ключевыми (я бы даже сказал, не являются существенными), ибо в любом случае получатель заявления будет принимать решение не только и не сколько из-за информации в этих пунктах.
это будет плохое заявление, т.к. без п.1 и п.2 будет непонятна позиция заявителя.
Здравствуйте, DarkGray, Вы писали:
R3>>Но даже в случае заявления-документа, пункты 1 и 2 не являются ключевыми (я бы даже сказал, не являются существенными), ибо в любом случае получатель заявления будет принимать решение не только и не сколько из-за информации в этих пунктах. DG>это будет плохое заявление, т.к. без п.1 и п.2 будет непонятна позиция заявителя.
Здравствуйте, DarkGray, Вы писали:
DG>текущие исследования это не подтверждают. DG>у человека маленькая оперативная память, но высокие способности по усвоению абстракций.
Если бы человек мог бы удерживать в голове очень большое количество абстракций, то специализации труда бы не требовалось. Однако это совершенно не так.
DG>весь смысл в том, что чем больше абстракций "нативно" поддерживает ЯП (но, конечно, не в виде винегрета, как, например, PL/I) DG>тем меньше об этом приходится думать разработчику.
Во-первых, абстракции бывают хорошие и плохие. Первые имеют внутреннюю логику и не содержат избыточных деталей, вторые — наоборот. При равной сложности хорошими абстракциями оперировать проще, чем плохими.
Во-вторых, абстракции бывают сложными и простыми. Например, модель управления памятью в С++ это сложная абстракция, модель управления в С# это простая абстракция. Естественно простыми абстракциями оперировать проще, чем сложными. Однако далеко не все явления можно описать простыми абстракциями, кроме того описание сложного явления простой абстракцией как правило приводит к снижению гибкости. Например, автоматическое управление памятью хорошо легло на десктопы, т.к. на десктопных задачах ручное управление памятью требуется крайне редко, но использовать автоматическое управление памятью на АРМ-процессорах вряд ли получится, т.к. там ручное управление памятью критически необходимо.
DG>какие абстракции поддерживает C++, но не поддерживает C#?
Модель памяти в плюсах это сложная абстракция, шаблоны и макросы это очень сложные абстракции. В шарпе ничего подобного нет, там практически все абстракции являются простыми. Именно поэтому шарп в освоении намного проще плюсов.
Если бы возможности людей по усвоению абстракций были бы безграничны, то люди всегда выбирали бы более мощные инструменты, даже ценой увеличения их сложности, однако в действительно люди стремятся выбирать максимально простой инструмент, если он позволяет решать основную массу задач.
DG>какой процент людей в России способен освоить высшее образование?
Процентов десять. Если повысить качество образования, за счет использования только хороших абстракций, то этот процент можно несколько повысить. Но сейчас в образовании и в науке мы наблюдаем обратный процесс, абстракции становятся все более плохими.
DG>и ничего что лет 200 назад бытовало мнение, что читать/писать и считать и говорить на иностранных языках способны лишь избранные? а сейчас это умеет каждый. с тех пор люди поменялись?
Я не вижу ничего сверхестественного в высшем образовании, т.е. я не считаю, что человек с современным высшим образованием владеет абстракциями принципиально лучше крестьянина 18 века.
получатель хотел сделать что-то "хорошее" для заявителя по результатам заявления, или нет? или до заявителя ему вообще как до лампочки?
зы
есть простое правила:
1. чем высокоуровневее исполнитель, тем больше необходимо предоставлять информации "зачем и почему это делается", и меньше "как"
2. чем низкоуровневее исполнитель, тем больше необходимо предоставлять информации "как это делается", и меньше "зачем".
модель памяти реализованная в C#/.net на порядок, если не на два сложнее, чем в C++.
ты смешиваешь два нюанса:
1. сколько абстракций необходимо знать и держать в голове для того, чтобы пользоваться языком
2. сколько абстракций реализовано в языке "нативно".
и что есть закономерность, чем выше первое, тем ниже второе и обратно.
в C#/.net-е абстракций реализовано больше, но удерживать в голове абстракций нужно меньше.
и соответственно я говорю о том, что высокоуровневым языком проще пользоваться, потому что реализованных в нем абстракций больше и меньше абстракций необходимо держать в голове.
Здравствуйте, DarkGray, Вы писали:
U>>Модель памяти в плюсах это сложная абстракция DG>модель памяти реализованная в C#/.net на порядок, если не на два сложнее, чем в C++.
С точки зрения пользователя (программиста в данном контексте) модель памяти в C++ намного сложнее модели памяти в C#. И за счет своей сложности плюсовая модель памяти намного гибче.
DG>и соответственно я говорю о том, что высокоуровневым языком проще пользоваться, потому что реализованных в нем абстракций больше и меньше абстракций необходимо держать в голове.
Высокоуровневым языком проще пользоваться только до тех пор, пока мы решаем только типовые задачи. Как только по условию задачи нам нужно сделать нечто более хитрое, выясняется что то, что на низкоуровневом языке делается за пять копеек на высокоуровневом либо не делается вообще, либо требует постоянных танцев с бубном. Те же ОРМ тому наглядный пример.
U>Высокоуровневым языком проще пользоваться только до тех пор, пока мы решаем только типовые задачи. Как только по условию задачи нам нужно сделать нечто более хитрое, выясняется что то, что на низкоуровневом языке делается за пять копеек на высокоуровневом либо не делается вообще, либо требует постоянных танцев с бубном. Те же ОРМ тому наглядный пример.
вот только orm не является высокоуровневой абстракцией.
orm — это плохая реализация объектно-ориентированной абстракции поверх реляционной абстракции.
Здравствуйте, DarkGray, Вы писали:
DG>получатель хотел сделать что-то "хорошее" для заявителя по результатам заявления, или нет? или до заявителя ему вообще как до лампочки?
Я не совсем понимаю, что мы обсуждаем: передачу информации или чувства?
Если первое, то достаточно только команды, всё остальное делает получатель команды: анализирует заявление и даёт добро или запрещает выполнение команды.
Если второе, то это получается ...
DG>1. чем высокоуровневее исполнитель, тем больше необходимо предоставлять информации "зачем и почему это делается", и меньше "как" DG>2. чем низкоуровневее исполнитель, тем больше необходимо предоставлять информации "как это делается", и меньше "зачем".
I.
... заявлением ты пытаешся обработать ситуацию с чувствами исполнителя, которые к цели заявления не имеют никакого отношения. Более того:
1. исполнитель должен знать "зачем и почему это делается", иначе мы указываем на его некомпетентность;
2. исполнитель должен знать "как это делается", иначе мы указываем на его некомпетентность.
II.
... что мы расписываем своё виденье "зачем, почему, как", что может расходиться с виденьем исполнителя. И в результате мы получим отказ. Но это не значит, что мы были не правы — мы могли ошибиться в своём виденьи. Ошиблись — переписываем программу-заявление заново и повторяем процесс.
Хотя изначально было бы проще послать только команду и пусть уже исполнитель уточняет детали "зачем", "почему" или "как".
III.
Конечно, предыдущие два пункта в реальном (современном, российском) мире работают плохо (не везде). Но я не собираюсь жить по этим правилам при общении с компьютером: уж он то должен уметь определить — давать добро моему заявлению или нет.
R3>Я не совсем понимаю, что мы обсуждаем: передачу информации или чувства?
правильную передачу информацию.
проблема в том, что высокоуровневый исполнитель очень гибкий, и он может выполнить задачу миллионом способов.
и чтобы высокоуровневому исполнителю правильно выбрать необходимый способ ему требуются ответы на вопрос "зачем и почему"
> 1. исполнитель должен знать "зачем и почему это делается", иначе мы указываем на его некомпетентность;
если ты приходишь допустим в ателье, и говоришь "сшейте мне костюм", то исполнитель, по-умолчанию, не знает — зачем тебе костюм, и почему ты решил его сшить.
может у тебя свадьба, может похороны, может ты собираешься на важные переговоры, может у тебя предыдущий повседневный костюм сдох.
если ты говоришь гуглу — найди мне Москву.
то гугл не знает зачем и почему ты это ищешь?
R3>Хотя изначально было бы проще послать только команду и пусть уже исполнитель уточняет детали "зачем", "почему" или "как".
медленная работы системы (заказчик — исполнитель), из-за большого кол-ва запросов туда-сюда
Здравствуйте, DarkGray, Вы писали:
R3>>Я не совсем понимаю, что мы обсуждаем: передачу информации или чувства? DG>правильную передачу информацию. DG>проблема в том, что высокоуровневый исполнитель очень гибкий, и он может выполнить задачу миллионом способов. DG>и чтобы высокоуровневому исполнителю правильно выбрать необходимый способ ему требуются ответы на вопрос "зачем и почему"
Все ответы на эти вопросы он может и должен получить сам. (*) Компьютер ему может помочь найти ответы на эти вопросы или, как минимум, подсказать.
Почему до сих пор этого не сделано — я не знаю.
Ты, кстати, сам об этом не задумывался — почему?
>> 1. исполнитель должен знать "зачем и почему это делается", иначе мы указываем на его некомпетентность; DG>если ты приходишь допустим в ателье, и говоришь "сшейте мне костюм", то исполнитель, по-умолчанию, не знает — зачем тебе костюм, и почему ты решил его сшить. DG>может у тебя свадьба, может похороны, может ты собираешься на важные переговоры, может у тебя предыдущий повседневный костюм сдох.
"Свадьба" — это зачем. "Свадебный костюм" — это цель. Достаточно указать цель. "Свадебный костюм" — это более точная цель, чем "костюм". Но из "свадьба" никак не следует, что мне нужен именно "свадебный костюм". Доказано на собственном опыте. Т.е. надо уточнять цель, а не зачем и почему.
Сначала написал другой текст (ниже), но потом понял, что он ни о чём, но удалять было жалко.
+1. Я просто обожаю этот тест, придуманный, кажется MS, для тестирования претендентов на работу, и как сами работодатели не правильно его исталковывают.
Вам дают карандаш, чистый лист бумаги и говорят "Я хочу дом. Вы проектировщик. Я прошу Вас нарисовать мне дом" (как-то так)
Правильное действие по версии работодателя: претендент должен начать подробно распрашивать о том, какой дом он должен нарисовать.
Если бы такой претендент устраивался ко мне в контору и начал всё распрашивать, то я бы погнал его взашей, как бессмысленного, ибо (внимание! или, как говорят в интернетах, "внезапно!") если я знаю ответы на все вопросы, то зачем я пришёл просить нарисовать мне дом?
Вопросы, конечно, должны быть, но только самого верхнего уровня: "какого типа дом?", "какой планировки: студия или какие там ещё есть?", но не "какого цвета обои?"
Причём самый неправильный ответ по версии работодателя — претендент ничего не спрашивая начинает рисовать дом — я считаю гораздо лучше, чем спрашивание каких-то вопросов. (Правда, это лучше только в том случае, если претендент понимает, что он рисует всего лишь один вариант из всех вариантов. )
Так же и в случае с костюмом: меня должны спросить только тип костюма. Ну, я могу ещё высказать некоторые пожелания, если я разбираюсь в костюмах.
DG>если ты говоришь гуглу — найди мне Москву. DG>то гугл не знает зачем и почему ты это ищешь?
Но когда я ищу "ресторан", то именно гугл заботится о том, чтобы предложить мне ближайшие ко мне рестораны.
R3>>Хотя изначально было бы проще послать только команду и пусть уже исполнитель уточняет детали "зачем", "почему" или "как". DG>медленная работы системы (заказчик — исполнитель), из-за большого кол-ва запросов туда-сюда
R3>Все ответы на эти вопросы он может и должен получить сам. (*) Компьютер ему может помочь найти ответы на эти вопросы или, как минимум, подсказать.
и мы возращаемся к тому, что ты рассказываешь про интерактивный сценарий.
а во многих ситуациях, в том числе, и когда пишется заявление — нужен пакетный режим (когда из самого текста запроса однозначно с первого раза должно быть понятно, что именно хочется)
R3> "Свадьба" — это зачем. "Свадебный костюм" — это цель. Достаточно указать цель. "Свадебный костюм" — это более точная цель, чем "костюм". Но из "свадьба" никак не следует, что мне нужен именно "свадебный костюм".
цель — это и есть ответ на вопрос "зачем".
и в данном случае — цепочка целей (если мы берем классических вариант): быть на уровне в качестве жениха на свадьбе -> костюм для жениха -> черный парадный костюм
ответ на вопрос "почему" расскрывает инфу, почему именно такая цепочка редукции целей была выбрана — это важно:
1) потому часто когда неспециалист ставит задачу специалисту, очень часто происходит неправильная редукция цели (неправильная формулировка).
2) формируется набор критериев на основе которых заказчик оценивает результат решения
исходя из п.1.:
фиксирование в запросе дополнительной информации помогает с большей вероятностью выявить и устранить ошибки в тракте:
заказчик подумал -> сформулировал -> сказал -> дошло до исполнителя -> исполнитель воспринял -> переложил на свою модель(язык) -> осмыслил
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Mna, Вы писали:
Mna>>Не совсем на этот вопрос будет мой ответ, но решил поделиться своим видением программирования будущего, Mna>>до которого кое-кто может и не доживет, а кое-где возможно программируют и сейчас (будущее распределено неравномерно)
FR>Это прошлое, 80 — 90 коды,
аргумент не принимается.
АЭС — тоже прошлое, 1950-ые годы, но пока что они самое современное что есть в энергетике.
и про маргинальные 1%ые ветряки лучше не упоминать.
что-то не может быть плохим если это прошлое.
> экспертные системы, базы знаний,
да, на новом витке, правильным образом:
> ИИ,
нет > пролог,
нет нет > машины пятого поколения.
трижды нет, и вообще не в кассу. это был не научный подход.
Правильным образом: без ИИ, и без претензий на ИИ, но с базой знаний, без пролога. но с улучшенной логикой, небинарной,
и без маркетинговых заблуждений, по крайней мере для вижнари, а не для тех кому ( миллионам леммингов-кодеров) кому это
навязывается — для них пожалуй маркетинг — самое то, схавают вчистую.
торможение НТР, в компьютерной сфере тоже же происходит. не спроста же все так грустно довольно долго? и самолеты точно
такие же как пару поколений назад, и после расщепляющих АЭС ничего нового нет. это разве может быть случайным?
Поэтому лично я его и люблю больше всего! Компьютер всегда делает то, что ты ему сказал, а не то, что ты хотел чтобы он сделал или он подумал что ты хотел сделать именно это и именно таким образом. 
А тексты пишутся для разных людей.
Т.е. надо уточнять цель, а не зачем и почему. 
