Здравствуйте, sereginseregin, Вы писали: S>ИМХО S>Введение понятия "Язык программирования" исторически ошибочная ветвь развития. Введена она пионерами ИТ в надежде, что однажды компьютеры будут разговаривать с ними как люди. S>Не могу пока доказать (пока сам не проверю на практике), но мне кажется, что: S>1. Все наши беды из-за врожденных иллюзий, связанных с компьютеризацией S>2. Компьютер — это лишь устройство по переработке больших потоков данных, которой нужны не алгоритмы, а структуры+формулы (Возможно т.н. Функциональные ЯП идут в правильном направлении) S>3. Чтобы избавиться от иллюзий, необходимо переосмысление идеологий несколькими поколениями
Ок, а что должно заполнять ту нишу, которую сейчас ошибочно заполняют "языки программирования"?
Что должно быть вместо них?
Здравствуйте, DarkGray, Вы писали:
DG>бред, даже люди не смогли обойтись без исскуственных ЯП для разговора между собой (мат. язык, хим. язык, язык доказательств и т.д.)
Спорить по понятиям можно бесконечно...
По существу вопроса: "Есть ли предел высокоуровневости языка?" — для IT области, думаю, данный вопрос в будущем станет неактуальным.
Здравствуйте, 0x7be, Вы писали:
0>Ок, а что должно заполнять ту нишу, которую сейчас ошибочно заполняют "языки программирования"? 0>Что должно быть вместо них?
Не знаю...
Я вижу отсутствие системы между Кодом программ на различных Языках программирования и Описанием прикладных задач, которые эти программы решают.
Никто пока не предложил ясный алгоритм перехода от проектирования системы к ее кодированию. Даже в книжках по UML пишут про некий творческий подход при переходе между моделью и кодом программы.
В математике, физике и тд. такого нет. Математическая формула однозначно описывает явление, никаких примерно или творческих подходов.
Развитие всякого рода уровней ЯП проблему не решает.
Следовательно, нужно отвлечься от данного понятия вернутся к началу, как это все зарождалось. А зарождались ЯП с команд, с помощью которых человек мечтал управлять компьютером, как искусственным интеллектом...
Здравствуйте, sereginseregin, Вы писали:
S>Я вижу отсутствие системы между Кодом программ на различных Языках программирования и Описанием прикладных задач, которые эти программы решают. S>Никто пока не предложил ясный алгоритм перехода от проектирования системы к ее кодированию. Даже в книжках по UML пишут про некий творческий подход при переходе между моделью и кодом программы.
Это называется "семантический разрыв (semantic gap)" и о нем уже много копий было сломано. Если вкратце, то есть фундаментальная проблема перевода решения, изложенного на ЕЯ в потребляемый машиной вид. он связан с тем, что описание на ЕЯ никогда не бывает полным и однозначным. Программирование, в первую очередь, и есть разрешение этой неполноты и неоднозначности. Методов сделать это автоматически пока нет и единственный инструмент, который умеет это делать — это творческий ум человека. Именно из-за этого провалились идеи о том, что язык программирования, который будет выглядеть как английский язык, станет вдруг подвластен бухгалтерам.
S>В математике, физике и тд. такого нет. Математическая формула однозначно описывает явление, никаких примерно или творческих подходов.
Аналогия неверна. Правильная аналогия такая: есть описание явления на ЕЯ, а его надо описать на языке формул.
Это тоже пока делается только при помощи человека.
S>Развитие всякого рода уровней ЯП проблему не решает.
Проблему семантического разрыва решит только ИИ.
S>Следовательно, нужно отвлечься от данного понятия вернутся к началу, как это все зарождалось. А зарождались ЯП с команд, с помощью которых человек мечтал управлять компьютером, как искусственным интеллектом...
Зарождались ЯП с двух направлений — от машинных кодов (Фортран) и от математики (Лисп).
Здравствуйте, DarkGray, Вы писали:
DG>имхо, высокоуровневость бесконечна — т.к. можно вводить всё более и более сложные абстракции.
Высокоуровневость ограничена, т.к. абстракции решают любые проблемы кроме проблемы увеличения количества абстракции. Соответственно язык со множеством сложных абстракций не взлетит, разработчик просто не сможет удержать все эти абстракции в голове.
S>В математике, физике и тд. такого нет. Математическая формула однозначно описывает явление, никаких примерно или творческих подходов.
правда лишь наполовину.
чем сложнее система, тем менее она четкая.
математика работает с простыми системами — у них все однозначно.
физика особенно сложная: СТО, квантовая, космо и т.д. — работает со сложными системами, и у них там все очень неоднозначно.
химия, биология, социология и т.д. — работают с еще более сложными системами, и оперируют еще более нечеткими понятиями
программирование — это подвид информатики, которая подвид научной методологии и научной философии.
этот раздел науки изучает — мышление, формирование, хранение и преобразование знаний и т.д.
и эти науки оперируют тоже очень сложными понятиями, и изучаемые элементы их тоже менее четкие
связь между, например, научной методологией и программированием я показывал — и там, и там очень остро стоит проблема правильной фиксации понятий(терминов) (в программировании ее часто рассматривают более узко — как фиксации типов данных)
основная задача программирования, как и науки вообще, это построить модель решаемой задачи/проблемы.
и в этом программирование тесно переплетается с научной философией — которая рассматривает на фундаментальном уровне, как правильно строятся модели(теории) изучаемой области.
S>Развитие всякого рода уровней ЯП проблему не решает. S>Следовательно, нужно отвлечься от данного понятия вернутся к началу, как это все зарождалось. А зарождались ЯП с команд, с помощью которых человек мечтал управлять компьютером, как искусственным интеллектом...
на данный момент, я плохо понимаю как ты собрался решать вопрос сложной коммуникации между человеком и компьютером без языка?
на уровне команд — можно разговаривать только со служебной собакой: фас, ату, сидеть и т.д.
как только задача становиться чуть сложнее, нужен полноценный язык для коммуникации.
U>Высокоуровневость ограничена, т.к. абстракции решают любые проблемы кроме проблемы увеличения количества абстракции. Соответственно язык со множеством сложных абстракций не взлетит, разработчик просто не сможет удержать все эти абстракции в голове.
какое кол-во абстракций может удержать в голове человек?
сколько абстракций на текущий момент поддерживают main-stream языки "нативно": например, Java/C#?
какому кол-ву абстракций обучают в школе?
какому кол-ву абстракций обучают в институте?
Здравствуйте, 0x7be, Вы писали:
0>Это называется "семантический разрыв (semantic gap)" и о нем уже много копий было сломано. Если вкратце, то есть фундаментальная проблема перевода решения, изложенного на ЕЯ в потребляемый машиной вид. он связан с тем, что описание на ЕЯ никогда не бывает полным и однозначным.
Бывает. Именно для этого в документах пишутся всякие "Определения"/"Обозначения". Они как раз и предназначены для того, чтобы дальнейшее описание в документе трактовалось однозначно.
Проблема только в уровне детализации этих "определений": автор документа описывает объекты только до того уровня, после которого (как он думает) остальные определения читатель поймёт однозначно.
Например:
"Компьютер — это монитор и системный блок"
"Монитор — это телевизор"
"Системный блок — это железная коробка"
Описывать далее определения "телевизор" и "железная коробка" не имеет смысла, ибо большинство людей их поймёт однозначно.
0> Программирование, в первую очередь, и есть разрешение этой неполноты и неоднозначности.
В программировании же эта проблема не решена, а её никогда не было, потому что начиная с самого-самого первого бита, все объекты жёстко типизированы/определены.
0>Проблему семантического разрыва решит только ИИ.
Ещё не ясно, что будет, если вбить в "базу" все определения и предложить пользователю оперировать этими определениями. Так что возможно никакого ИИ и не понадобится.
Здравствуйте, DarkGray, Вы писали:
DG>на данный момент, я плохо понимаю как ты собрался решать вопрос сложной коммуникации между человеком и компьютером без языка? DG>на уровне команд — можно разговаривать только со служебной собакой: фас, ату, сидеть и т.д. DG>как только задача становиться чуть сложнее, нужен полноценный язык для коммуникации.
Компьютер в текущей его реализации был и есть всего лишь машина. Чтобы мы сейчас не программировали — это будет всего лишь эмуляция человека. Это как многозадачность: мы видим параллельное выполнение приложений, но в процессоре (в старых моделях) они всё равно выполняются последовательно.
Далее: интерфейс взаимодействия с машиной — через команды. О каких коммуникациях идёт речь?
R3>Компьютер в текущей его реализации был и есть всего лишь машина. Чтобы мы сейчас не программировали — это будет всего лишь эмуляция человека. Это как многозадачность: мы видим параллельное выполнение приложений, но в процессоре (в старых моделях) они всё равно выполняются последовательно.
если что-то — выглядит как кошка, мяукает как кошка, и ходит как кошка — то это кошка.
какая разница компьютер — действительно думает, или лишь хорошо прикидывается?
какая разница гугл сам ищет, или его этому научили — общаться-то(коммуницировать) с гуглом-то все равно надо, чтобы ему объяснить, что именно ты хочешь найти.
R3>Далее: интерфейс взаимодействия с машиной — через команды. О каких коммуникациях идёт речь?
вот есть гугл-поиск — это машина, но с ней приходится коммуницироваться.
пока общение чисто интерактивное простого набора команд достаточно, т.к. если гугл что-то не так понял, то легко можно дать новую команду, поменять старую.
если же нужно что-то большее, например:
не хочется много времени тратить на итерации, а хочется сразу сказать, что именно и как хочется найти,
или хочется использовать гугл как часть большей системы
и т.д.
то от простого набора команд — приходится переходить к какому-то описанию что именно надо сделать (а это уже и есть полноценный язык)
Здравствуйте, DarkGray, Вы писали:
U>>Высокоуровневость ограничена, т.к. абстракции решают любые проблемы кроме проблемы увеличения количества абстракции. Соответственно язык со множеством сложных абстракций не взлетит, разработчик просто не сможет удержать все эти абстракции в голове.
DG>какое кол-во абстракций может удержать в голове человек?
Весьма ограниченное.
DG>сколько абстракций на текущий момент поддерживают main-stream языки "нативно": например, Java/C#?
C# поддерживает небольшое количество абстракций, поэтому его могут освоить многие, хотя далеко не все. У C++ абстракций больше и они сложнее, поэтому его хорошо освоить могут очень немногие.
DG>какому кол-ву абстракций обучают в школе?
Не слишком большому, но при этом выпускников, которые хорошо владели бы абстрациями всех преподаваемых предметов единицы. Т.е. даже все абстракции, которые преподают в школе, в голову подавляющего большинства людей не помещаются.
DG>какому кол-ву абстракций обучают в институте?
Примерно такому же количеству как в школе. Разница лишь в том, что большинство школьных абстракций становится не нужными и больше не загромождает память, а их место занимает институтские абстракции, обычно несколько более сложные. При этом институтский курс могут хорошо усвоить еще меньшее количество людей, чем школьный. Т.е. с увеличением количества и сложности абстракций процент людей способных ими оперировать очень быстро падает.
DG>числа, пожалуйста, хотя бы порядки.
Для этого надо определиться, что мы понимаем под абстракцией и до какого уровня абстракции детализируем.
Здравствуйте, Real 3L0, Вы писали:
R3>Бывает. ... R3>Проблема только в уровне детализации этих "определений": автор документа описывает объекты только до того уровня, после которого (как он думает) остальные определения читатель поймёт однозначно.
Первое и второе предложения противоречат друг другу.
Документы на ЕЯ бывают более и менее формализованы, но до такой степени программ они почти никогда не формализуются.
Не не смотря на то, что это в принципе возможно, для такой формализации все равно надо быть программистом!
0>> Программирование, в первую очередь, и есть разрешение этой неполноты и неоднозначности. R3>В программировании же эта проблема не решена, а её никогда не было, потому что начиная с самого-самого первого бита, все объекты жёстко типизированы/определены.
А я и не говорю, что проблема "в программировании". Проблема в том, что при переходе от неформального описания к формальному необходимо делать то, что пока умеют только специально обученные люди.
R3>Ещё не ясно, что будет, если вбить в "базу" все определения и предложить пользователю оперировать этими определениями. Так что возможно никакого ИИ и не понадобится.
И что ты вобьешь, например, под названием "системный блок"?
или можно сформулировать так:
api + набор команд — это интерактивный режим.
минусы: если необходимо выполнить подряд много команд, то высокий оверхед из-за латентности коммуникации (при чем здесь есть теоретический предел в виде скорости света. если сервер гугла располагается на другой конце планеты, то от десятков мс никуда не денешься).
для решения предыдущей проблемы переходят к пакетному режиму:
когда последовательность команд оформляют в пакет.
R3> R3>Компьютер в текущей его реализации был и есть всего лишь машина. Чтобы мы сейчас не программировали — это будет всего лишь эмуляция человека. Это как многозадачность: мы видим параллельное выполнение приложений, но в процессоре (в старых моделях) они всё равно выполняются последовательно. R3>Далее: интерфейс взаимодействия с машиной — через команды. О каких коммуникациях идёт речь?
+2 (пишу в последний пост, предыдущая ветка, считаю, аналогична по направлению спора)
Я больше не верю в ИИ, ну разве что вначале появится какой-то Искусственный интеллект, а затем только Язык коммуникации с ним
Отрекитесь от навязанного вам писателями-фантастами Компьютера-разумного. Может быть в будущем мы сможем создать Искусственный разум, но для это современные микросхемы пока не подходят, что-то недостает конструктивно. Пока компьютеры — это машины с ОГРАНИЧЕННЫМ числом команд.
Все современные решения ИИ — это эмуляция, иллюзия разума...
Здравствуйте, DarkGray, Вы писали:
DG>какая разница компьютер — действительно думает, или лишь хорошо прикидывается?
Разница в том, что ...
DG>то от простого набора команд — приходится переходить к какому-то описанию что именно надо сделать (а это уже и есть полноценный язык)
... это опять получается программа. Т.е. программа над программами.
Может хватит писать новые программы и языки, а сделать нормальный командный интерфейс из которого автоматически родится язык?
Здравствуйте, 0x7be, Вы писали:
R3>>Проблема только в уровне детализации этих "определений": автор документа описывает объекты только до того уровня, после которого (как он думает) остальные определения читатель поймёт однозначно. 0>Первое и второе предложения противоречат друг другу. 0>Документы на ЕЯ бывают более и менее формализованы, но до такой степени программ они почти никогда не формализуются.
А почему ты сравниваешь документы (для человека) и программу (для компьютера)?
0>Не не смотря на то, что это в принципе возможно, для такой формализации все равно надо быть программистом!
Документ (для человека) без проблем одинаково понимается разными людьми.
0>А я и не говорю, что проблема "в программировании". Проблема в том, что при переходе от неформального описания к формальному необходимо делать то, что пока умеют только специально обученные люди.
+1. А я говорю, что в рамках "документов (для человека)" — ЕЯ может быть полон и однозначен.
R3>>Ещё не ясно, что будет, если вбить в "базу" все определения и предложить пользователю оперировать этими определениями. Так что возможно никакого ИИ и не понадобится. 0>И что ты вобьешь, например, под названием "системный блок"?
Не знаю, надо спросить у тех, кто занимается наполнением таких баз.
Здравствуйте, Real 3L0, Вы писали:
R3>Может хватит писать новые программы и языки, а сделать нормальный командный интерфейс из которого автоматически родится язык?
Язык и команды должны быть естественными (сохранить данные, изменить, рассчитать по формуле и т.д.)
Просто пытаясь сделать компьютер разумнее, ассемблер (набор машинных команд) превращается в руках программиста в неуправляемого монстра, которого маркетологи восхваляют как новое приближение к интеллекту. Отсюда, например, масса детских болезней в Объектно-ориентированных языках программирования.
Читал-читал и решил свои 5 копеей вставить.
Разговор явно смещается от вопроса: какими свойствами должен обладать язык следующий в уровне абстрактных иерархий, к вопросу — какими должны быть синтаксис и грамматика такого языка. Думаю что парадигма ООП достаточно гибка, чтобы программист на основе собственных классов создал любой синтаксис какой нам захочется. При этом базовыми будут конструкции
типа object.method(...). Повышение абстракции тут в возможности использования понятий из проблемной области.
Но существующая парадигма (ООП) уже предоставляет нам эту возможность, так что говорить об этом как о языке более абстрактном, чем язык с поддержкой ООП не приходиться. Вернее, это не правильно.
Давайте согласимся, что не в синтаксисе и грамматике будет сделан следующий рывок в абстрагировании процесса программирования. ООП появилось из концепции абстрактных типов данных. Тут явно нужна новая концепция. Пролог, функциональное программировани,
экспертные системы и т.п. существуют не один десяток лет и что-то не видно, что они создают серъезную конкуренцию для ООП или ООД (о-о-декомпозиции). Это просто иструменты заточеные под решение задачь своего класса (имхо). Во всяком случае нельзы сказать что выше (абстрактнее) — ФП или ООП.
Хочу сказать вот что, в ЕЯ существует много приемов, которые в принципе нельзя использовать в математике. Например, в математикеможно либо доказать, либо постулировать свойства объекта Х. А в ЕЯ можно взять другой объект Y с совершенно другими свойствами и
использовать его везде где использовали или хотели использовать Х. Потом, формализм в математике и программировании — это очень разные вещи и цели его применения диаметрально противоположные. Не стоит забывать, что строгость и формализм есть не более чем очень осторожное употребление ЕЯ, а не наоборот , как хотелось бы думать многим математикам (что ЕЯ есть упрощение математических построений).
По поводу ЕЯ могу сказать только, что он бесконечно сложнее любых математических моделей. Все грамматические правила, что тут упоминались, не являются формальными в строгом смысле слова, потому применимость аппарата фомальных логик вообще и специальных
грамматик в частности под вопросом. Ну нет на сегодня математической модели ЕЯ — с этим нужно считаться.
Плохо что мы не можем измерить, насколько близко мы подобрались к понятиям из ЕЯ. Считаю, что дело не только в неоднозначности и ассоциативности. Малейшие изменения в контексте могут повлечь за собой существенные изменения смысла понятий ЕЯ.
Т.е. понятия ЕЯ не просто содержат несколько смыслов, а намного сложнее — контекст управляет какой смысл допустим, а какой нет для понятий ЕЯ в каждом конкретном случае. Т.е. если встречается три раза понятие из ЕЯ, то у кажого из них есть свой диапазон неоднозначности и своя собственная сеть ассциативности. Потому переход от конкретного к абстрактному (обобщению свойств всех упоминаний некоторого понятия ЕЯ в одном абстрактном
понятии более высокого уровня) просто не сработает.
Но уточнять эту зависимость можно до посинения, все равно что-то упустим. Потому мне кажется, что процесс приближения понятий ЕЯ из некоторой проблемной области может продолжаться до бесконечности. Потому я не совсем уверен, что повышение абстрактности связано с привлечением ЕЯ.
У меня есть несколько мыслей, но не буду утомлять форумчан доморощенными идеями. Могу лишь сформулировать несколько интересных следствий.
1) Главным заблуждением программистов есть предрассудок, что программист мыслит в терминах объектов. Это не правда. Вспомним, что любое применение паттерна проектирования заметно усложняет и ограничивает последующие применение других паттернов проектирования. Так прямо и пишут в книжках по ООД. Объекты и все с ними связанное есть результат мышления, но ни в коем случае не его часть или главная особенность.
Абстрагирование — это гораздо более замысловытый процесс, чем позволяет нам судить ООП. Мысленно мы можем сколько угодно рассматривать систему с различных точек зрения, но ООД позволяет использовать только единственный способ декомпозиции, единственную иерархию классов, единственный вариант деления на абстрактные уровни. Гради Буч (если не вру) по этому поводу сказал, разрабатывать программу с поддержкой несколькими независимыми иерархиями классов — это все равно что попросить архитектора построить дом сразу на двух фундаментах одновременно, вещь сложная и вряд ли получиться. Потому любой прогаммист прежде чем испольовать некоторый объект должен серьезно подумать, а может другой объект выбранный другим образом тут будет уместнее? Ни один язык программирования
не поддерживает подобной возможности — множественные декомпозиции задачи на части. Ясно почему, правила перехода от одной декомпозиции к другой многократно
превосходят сложность самой программы.
В книге "Умные указатели" есть частный вариант решения, когда используются грани кристалла, т.е. любое обращение к любому объекту должно происходить через
промежуточный и объект-интерфейс (паттерн фасад вроде бы). Тогда мы можем не только не знать реализацию объекта, но и его интерфейс. Автор утверждает, что
накладные расходы компенсируются возможностью не только заменить реализацию, но и заменить и интерфейс объекта в любое время (даже во время работы программы).
Правда для смены абстрактных уровней и иерархии наследования объектов надо прдумывать дополнительные приемы, но идея ясна.
2) Предрассудок второй: Инкапсуляция защищает реализацию от изменений. Придумана математически образованными программистами, которые не проводят различий между формализмом в математике и программировании. Независимость изменений в реализации объекта от реализации других частей программы очень полезна по разным причинам. Например, можно разбить задачу на независимые части.
Все "доказательства" не являются объективными, поскольку Не рассматриваются случаи, когда интерфейс объекта должен измениться, когда применяется другая декомпозиция на оюъекты, в результате наша реализация будет распределена по нескольким объектам. Потому, для того чтобы действительно программист мог независимо менять реализацию одного объекта, этот объект должен быть специальным образом выбран, а при выборе должно быть учтено какие изменения должны происходить. Это, кстати, еще один фактор почему так трудно разделить задачу на части.
Звучит все немного надумано, но зато элементарно проверяется. Для любой программы берутся несколько изменений, если возможно провести границы так, чтобы "зоны действия изменений" не пересакались, то тогда действительно можно изолировать части программы одна от другой. На практике уже при 3-4 изменениях обязательно возникнут непредвиденные "наложения". При этом очередность изменений имеет значения, изменение порядка меняет "зоны влияния" отдельных преобразований. Потому для измерения данного эффекта нужно брать все ерестановки очередности порядка преобразований.
Потому правильнее говорить, инкапсуляция иногда помогает независимо изменять реализацию незаметно для всей остальной программы, при условии что объект и его интерфейс были выбраны правильно и продуманно. Выводы — любая декомпозиция упрощая некоторые преобразования и изменения одновременно затрудняет выполнение других преобразований и изменений в программе. Причем преимуществ всегда в разы меньше чем недостатков. В теории программирования проблема носит название "проблемы трассировки требований к проекту".
Здравствуйте, Real 3L0, Вы писали:
R3>А почему ты сравниваешь документы (для человека) и программу (для компьютера)?
Я их не сравниваю. Я говорю о том, что происходит в процессе перевода решения задачи из неформального описания в исполнимую компьютером программу.
Ранее sereginseregin указал на наличие семантического разрыва, а я объяснял его суть.
0>>Не не смотря на то, что это в принципе возможно, для такой формализации все равно надо быть программистом! R3> Документ (для человека) без проблем одинаково понимается разными людьми.
Вот не скажи. Сколько уже наблюдал ситуаций, когда разные люди по-разному понимают один и тот же текст. Бывает, сядешь с человеком, опишешь систему, согласуешь все, а потом оказывается, что он видел своим внутренним взором совсем не то, что ты.
R3>+1. А я говорю, что в рамках "документов (для человека)" — ЕЯ может быть полон и однозначен.
Он может быть полон и однозначен в строгом смысле, но тогда он будет записан на формальном языке.
Он может быть полон и однозначен в какой-то степени. То есть человек из твоего же отдела его поймет правильно, а сотрудник партнерской компании — нет.
Здравствуйте, 0x7be, Вы писали:
R3>>А почему ты сравниваешь документы (для человека) и программу (для компьютера)? 0>Я их не сравниваю. Я говорю о том, что происходит в процессе перевода решения задачи из неформального описания в исполнимую компьютером программу. 0>Ранее sereginseregin указал на наличие семантического разрыва, а я объяснял его суть.
Ок.
0>Вот не скажи. Сколько уже наблюдал ситуаций, когда разные люди по-разному понимают один и тот же текст. Бывает, сядешь с человеком, опишешь систему, согласуешь все, а потом оказывается, что он видел своим внутренним взором совсем не то, что ты.
Так может проблема в тексте или человеке, а не в ЕЯ? "Разбор полётов" делали?
R3>>+1. А я говорю, что в рамках "документов (для человека)" — ЕЯ может быть полон и однозначен. 0>Он может быть полон и однозначен в строгом смысле, но тогда он будет записан на формальном языке. 0>Он может быть полон и однозначен в какой-то степени. То есть человек из твоего же отдела его поймет правильно, а сотрудник партнерской компании — нет.
Так что возможно никакого ИИ и не понадобится.
