R3>Кажется, с наличием интелисенса в шарпе хорошим тоном стало давать длинные осмысленные имена.
это учет особенности исполнителя.
т.к. программа должна выполняться(пониматься) не только машиной, но и разработчиком(человеком), то приходится учитывать особенности человека, как исполнителя.
у человека — аналоговая память и аналоговый ввод-вывод, аналог в отличие от цифры — очень сильно подвержен искажениям из-за шума.
поэтому человек вынужден использовать, и привык использовать — длинные идентификаторы.
у человека очень плохая механическая память, но в тоже время очень развит навык обобщения(и аналогий) — поэтому человеку удобнее переиспользовать идентификаторы для похожих ситуаций.
также на это накладываются культурные особенности: длина массовых английских индификаторов — 3-4 символа, длина русских — 7-8 символов.
соответственно, при подсчете длины программы стоит такие нюансы учитывать, и нормализовывать подсчет длины программы.
один из вариантов нормализации, когда неизменяемые идентификаторы(части идентификаторов) считаются, как один символ.
например, get, set, print, write, user, item и т.д. — это символы, и идентификатор — getUserItem — состоит из трех символов.
"a также" — keyword, подчеркивающий окончание перечисления и некое противопоставление Константина Петру и Ивану
DS>6) Минус два минус минус три
это неестественная фраза для ЕЯ, и есть транслитерация с математического языка.
с точки зрения ЕЯ получается:
минус<глагол> два<название, существительное> минус<глагол> минус<прилагательное> три<название, существительное>
и более естественной фразой будет:
вычесть два вычесть отрицательное три (но вот "отрицательное три" уже режет ухо, т.к. в ЕЯ в основном используются только натуральные числа, и небольшое кол-во рациональных чисел(дробей))
зы
также это можно рассматривать как перечисление существительных, тогда формально по правилам ЕЯ их стоит разделять запятыми (но в угоду мат.языку где такого нет, в ЕЯ тоже запятых не ставят)
DS>Вы скажите, если надоест, а то, может, еще что-нибудь в голову придет.
пиши еще, пока интересно — ты не повторяешься, мозги поразминать полезно.
DS>>1) Смеркалось.
R3>объект "местоположение" == "Город N", характеристика-объекта: "время" == "20:00" (или во сколько там это происходит? )
это ты уже во смысл лезешь.
Смеркалось — происходила смена "светлоты" на тьму.
примечание: обычно применяется для обозначения природной смены светлого времени суток на темное время суток.
Вы писали:
DS>>5) Петр, Иван, а также Константин DG>это названия в роли существительных DG>"a также" — keyword, подчеркивающий окончание перечисления и некое противопоставление Константина Петру и Ивану
Я вот всё это описываю проще:
есть класс "Человек" =>
есть объекты: "Петр", "Иван", "Константин"
DS>>6) Минус два минус минус три
DG>это неестественная фраза для ЕЯ, и есть транслитерация с математического языка.
+1. В ЕЯ говорят "[от] минус 2 отнять (вычесть) минус 3"
Я это записал бы как:
есть класс "Число", у которого есть действие "вычитание" =>
"-2" "вычитание" "-3"
DG>также это можно рассматривать как перечисление существительных, тогда формально по правилам ЕЯ их стоит разделять запятыми (но в угоду мат.языку где такого нет, в ЕЯ тоже запятых не ставят)
это способ вытаскивание смысла из фразы без додумывания информации, которой во фразе не было.
R3>Я вот всё это описываю проще: R3>есть класс "Человек" => R3>есть объекты: "Петр", "Иван", "Константин"
так можно упрощать, но стоит понимать, что произошло додумывание.
во фразе не упоминалось, что речь шла про людей.
DG>>также это можно рассматривать как перечисление существительных, тогда формально по правилам ЕЯ их стоит разделять запятыми (но в угоду мат.языку где такого нет, в ЕЯ тоже запятых не ставят)
R3>Как это не ставят?
будут ставить только если есть явное подчеркивание, что идет речь о перечислении символов: "диктую: минус, 2, минус, минус, 3"
во фразе: "1 получится если вычислить выражение: минус 2 минус минус 3", запятых не будет, но хотя намек на перечисление есть.
Здравствуйте, FR, Вы писали: FR>А почему ты думаешь что естественный язык должен быть выше уровнем чем языки программирования.
Что мы сейчас делаем на ЯП? По сути — описываем способы решения для возникающих задач (переводим постановку в алгоритм). А какой предельный способ решения? Задача => (выкидываем промежуточное звено в виде программирования) => Решение. Команда, указание, вопрос, как, наверное, самые краткие способы постановки задач в идеальном случае: "Найди оптимальные доказательства для Millennium Prize Problems" — и всё. TSD/PSD/etc они в сумме, обычно, длиннее или короче исходников "на компиляцию" по ним написанных? И что, обычно, выходит более высокоуровневым в контексте краткости описания задачи — *SD на ЕЯ или код на каком-нибудь "Incredible Koq++ with ERC and AI aka IKEA 1.0" ?
Здравствуйте, DarkGray, Вы писали:
R3>>откуда ты взял этот способ "перевода"? DG>это способ вытаскивание смысла из фразы без додумывания информации, которой во фразе не было.
Понял. Да.
Просто я уже мыслю в рамках своей разработки, а у меня сначала идут определения классов, поэтому объект — это всегда определённая сущность.
W>А какой предельный способ решения? Задача => (выкидываем промежуточное звено в виде программирования) => Решение. Команда, указание, вопрос, как, наверное, самые краткие способы постановки задач в идеальном случае:
как минимум еще должно быть:
описание постановки задачи в виде модель задачи,
а также описание результа — как мы поймем что это тот результат который мы хотели? (критерии, способ измерения и т.д.)
и под это тоже должны быть языки, свои абстракции и т.д.
это кстати подводит к вопросу, а какой идеальный способ постановки задачи одним человеком другому человеку?
частично ответ есть в менеджменте (в науке об управлении)
Здравствуйте, DarkGray, Вы писали:
DG>это кстати подводит к вопросу, а какой идеальный способ постановки задачи одним человеком другому человеку? DG>частично ответ есть в менеджменте (в науке об управлении)
Здравствуйте, Cris, Вы писали:
C>самый высокоуровневый язык будет ... это будет наш язык, я точней наши мысли, мы только подумали а компилятор уже наши мысли в машинный код скомпилировал
А ты никогда не сталкивался с тем, когда два человека, читая один и тот же текст, понимают его по разному? Такой язык неизбежно очень сильно увеличит долю тестирования.
Здравствуйте, Wolverrum, Вы писали:
FR>>А почему ты думаешь что естественный язык должен быть выше уровнем чем языки программирования.
W>Что мы сейчас делаем на ЯП? По сути — описываем способы решения для возникающих задач (переводим постановку в алгоритм). А какой предельный способ решения? Задача => (выкидываем промежуточное звено в виде программирования) => Решение. Команда, указание, вопрос, как, наверное, самые краткие способы постановки задач в идеальном случае: "Найди оптимальные доказательства для Millennium Prize Problems" — и всё. TSD/PSD/etc они в сумме, обычно, длиннее или короче исходников "на компиляцию" по ним написанных? И что, обычно, выходит более высокоуровневым в контексте краткости описания задачи — *SD на ЕЯ или код на каком-нибудь "Incredible Koq++ with ERC and AI aka IKEA 1.0" ?
Существующее программно аппаратное обеспечение не умеет и еще долго (если не всегда) не будет уметь решать так декларативно описанные задачи.
И боюсь если даже и научится, то наиболее удобным и эффективным способом общения с таким решателем будет не ЕЯ а некий сугубо формальный и малоестественный суперпролог.
1. между заказчиком и исполнителем должно быть установлено единое видение (единый язык коммуникации, единый словарь термины, единые модели мира и т.д.)
2. заказчик должен передать всю информацию, которая у него есть, но нет у исполнителя (в рамках предыдущего разговора, если у компьютера нет знания об окружающем мире, то мы всю эту информации должны ему передать)
3. заказчик должен ответить на вопросы "как он поймет, что результат это тот, который он хотел? как он собирается оценивать качество(оптимальность) решения?". ответы формализовать и передать исполнителю.
при обычной ситуации: когда заказчик специалист в одной теме, а исполнитель в другой — то ответственность за вышеуказанные пункты делится между ними следующим образом:
заказчик отвечает за пункт 3, а также за формирование общего видения и передачи инфы, которая необходима для п.3
исполнитель отвечает за п.1 и п.2, он должен вытянуть необходимую инфу из п.2, и формировать п.1
идеальный интерфейс взаимодействия с компьютером примерно так и должен выглядеть (в итерационном виде, конечно)
Здравствуйте, 0x7be, Вы писали:
0>Коллеги! 0>Как вы думаете — есть ли некий теоретический предел повышения уровня языка, при условии, что он остается языком общего назначения, то есть в него не вводятся модели, специфичные для предметных областей? Что бы сузить поле для обсуждения вопросами производительности я сейчас хочу пренебречь. Речь идет только о выразительных возможностях языка.
Сам вопрос субъективный в части "что считать специфичным", это больше отражает стиль мышления того или иного челвоека. Для кого-то linq это непонятно для чегу нужная ерунда, а для другого язык программирования, который не предоставлят данных средств, будет считаться ущербным. Для кого-то матрицы это математическая специфика, а для кого-то нет.
Любую абстракцию можно рассматривать как некоторую библиотеку + соответствующий синтаксический сахар. А дальше вечная дилемма между теми, кто считает, что "запас карман не тяготит", и теми, кто думает, что "лишний член жопе непонятка". Новая абстракция усложняет язык, требует больше времени на его изучение, ну и может нести некоторые бенефиты. Размер бенефика, как я уже говорил, субъективен.
Здравствуйте, DarkGray, Вы писали:
DG>идеальный интерфейс взаимодействия с компьютером примерно так и должен выглядеть (в итерационном виде, конечно)
Согласен, но не уверен, что итерационность — это хорошо: пока пользователь будет "перебрасываться" фразами с копьютером, он может забыть начало разговора.
Здравствуйте, 0x7be, Вы писали:
0>Коллеги! 0>Как вы думаете — есть ли некий теоретический предел повышения уровня языка, при условии, что он остается языком общего назначения, то есть в него не вводятся модели, специфичные для предметных областей? Что бы сузить поле для обсуждения вопросами производительности я сейчас хочу пренебречь. Речь идет только о выразительных возможностях языка.
Не совсем на этот вопрос будет мой ответ, но решил поделиться своим видением программирования будущего,
до которого кое-кто может и не доживет, а кое-где возможно программируют и сейчас (будущее распределено неравномерно)
Для начала резюме, нужные цитаты из темы, чтоб были в одном месте:
Re[3]: Хотелось бы просто привести пример
От: Wolverrum
FR>А почему ты думаешь что естественный язык должен быть выше уровнем чем языки программирования.
Что мы сейчас делаем на ЯП? По сути — описываем способы решения для возникающих задач (переводим
постановку в алгоритм).
А какой предельный способ решения?
Задача => (выкидываем промежуточное звено в виде программирования) => Решение.
Команда, указание, вопрос, как, наверное, самые краткие способы постановки задач в идеальном случае:
"Найди оптимальные доказательства для Millennium Prize Problems" — и всё.
TSD/PSD/etc они в сумме, обычно, длиннее или короче исходников "на компиляцию" по ним написанных?
И что, обычно, выходит более высокоуровневым в контексте краткости описания задачи —
*SD на ЕЯ или код на каком-нибудь "Koq++ + ERC + AI" ?
***
От: DarkGray
W> А какой предельный способ решения?
это кстати подводит к вопросу, а какой идеальный способ постановки задачи одним человеком другому человеку?
частично ответ есть в менеджменте (в науке об управлении)
***
От: DarkGray
R3>А можно детальней?
1. между заказчиком и исполнителем должно быть установлено единое видение (единый язык коммуникации,
единый словарь термины, единые модели мира и т.д.)
2. заказчик должен передать всю информацию, которая у него есть, но нет у исполнителя (в рамках
предыдущего разговора, если у компьютера нет знания об окружающем мире, то мы всю эту информации
должны ему передать)
3. заказчик должен ответить на вопросы "как он поймет, что результат это тот, который он хотел?
как он собирается оценивать качество(оптимальность) решения?".
ответы формализовать и передать исполнителю.
при обычной ситуации: когда заказчик специалист в одной теме, а исполнитель в другой — то
ответственность за вышеуказанные пункты делится между ними следующим образом:
заказчик отвечает за пункт 3, а также за формирование общего видения и передачи инфы, которая
необходима для п.3
исполнитель отвечает за п.1 и п.2, он должен вытянуть необходимую инфу из п.2, и формировать п.1
идеальный интерфейс взаимодействия с компьютером примерно так и должен выглядеть (в итерационном
виде, конечно)
***
теперь мое представление (5 копеек):
Инженерный взгляд
1. не язык программирования а среда, вытягивающаяя знания из эксперта.
Потом может из извлеченных знаний — сгенерировать программу на нужном языке.
2. интерактивные этапы: извлечение инфо о
2.1 язык, предметная область, модели
2.2 конкретизация подобласти
...
2.n уточненная задача которую нужно решить.
на этапе 2.n все необходимое знание по постановке задачи извлечено.
3. Для итерационного извлечения инфо на этапах 2.i используется формализованное подможество ЕЯ.
4. Эвристики по решению задачи
Имеется постановка задачи. теперь необходимы эвристики по извлечению знаний по решению задачи
4.1 интерактивное извлечение знаний по решению задачи
...
4.n эвристики извлечены
5. библиотеки:
5.1 библиотека алгоритмов, уже решенных задач — то есть уже построенные алгоритмы
5.2 библиотека эвристик — уже извлеченные эвристики
6. Метод решения
применить алгоритмы, если есть готовые, иначе
построить алгоритмы, используя эвристики построения алгоритмов, потом применить алгоритм,
если есть такие эвристики, иначе
извлечь такие эвристики, по п.4
промежуточные алгоритмы заносить в библиотеку п.5
**
Ручное вмешательство человека требуется:
подготовка эвристик для библиотеки, в п.5.2
подготовка "низкоуровневых"(=на обычных ЯП) алгоритмов в п.5.1
вся отладка
интерактивность в предоставлении экспертных знаний
Кстати, ответ на вопрос будет текст п.1. Но это конечно не ЯП общего назначения, а среда. С другой стороны модель предметной области хоть в среде и описана, но в язык среды не встроена сама по себе.
Сейчас много работают над формализацией, категоризацией знаний, и оформлением онтологической модели знания.
Здравствуйте, Mna, Вы писали:
Mna>Не совсем на этот вопрос будет мой ответ, но решил поделиться своим видением программирования будущего, Mna>до которого кое-кто может и не доживет, а кое-где возможно программируют и сейчас (будущее распределено неравномерно)
Это прошлое, 80 — 90 коды, экспертные системы, базы знаний, ИИ, пролог, машины пятого поколения.
Здравствуйте, 0x7be, Вы писали:
0>Коллеги! 0>Как вы думаете — есть ли некий теоретический предел повышения уровня языка
При всем прочитанном выше...
ИМХО
Введение понятия "Язык программирования" исторически ошибочная ветвь развития. Введена она пионерами ИТ в надежде, что однажды компьютеры будут разговаривать с ними как люди.
Не могу пока доказать (пока сам не проверю на практике), но мне кажется, что:
1. Все наши беды из-за врожденных иллюзий, связанных с компьютеризацией
2. Компьютер — это лишь устройство по переработке больших потоков данных, которой нужны не алгоритмы, а структуры+формулы (Возможно т.н. Функциональные ЯП идут в правильном направлении)
3. Чтобы избавиться от иллюзий, необходимо переосмысление идеологий несколькими поколениями
Уровень ЯП — это бесполезное понятие, используемое маркетологами...
S>Уровень ЯП — это бесполезное понятие, используемое маркетологами...
бред, даже люди не смогли обойтись без исскуственных ЯП для разговора между собой (мат. язык, хим. язык, язык доказательств и т.д.)
язык нужен для фиксации, обмена, перепроверке, комбинирования(и разделении) информации.
если брать пример mna про среду, то результатом работы среды все-равно будут знания выраженные на каком-то языке.
знания, которые лежат в бд, решают лишь задачу хранения информации, но задачи обмена информацией (и более сложные задачи которые на этом построены) — не решаются, из-за отсутствия удобного и стандартизованного представления для вывода и ввода информации.
FR>Это прошлое, 80 — 90 коды, экспертные системы, базы знаний, ИИ, пролог, машины пятого поколения.
в 80-х это было модно, так же как сейчас модно делать соц. сети.
ряд успехов был достигнут, но из-за малого научного фундамента, и низкой производительности компьютеров — серьезного продвижения не получилось.
развитие малыми темпами в этом направлении идет, но пока без революционных прорывов.
зы
экспертные системы, базы знаний, ии(системы выводов) и т.д. и сейчас строятся.
например, встраивание вывода типов в c# — это же тоже маленький кусочек слабого ИИ.
)
