Oberon space
General Category => Общий раздел => Тема начата: DIzer от Март 18, 2011, 07:49:41 am
-
Господа, а может создать многоуровневый ЯП - каждый новый уровень будет обратно совместим с предыдущим. Такое разделение можно выбрать из многих принципов (например , как попытались сделать это создатели GPCP). Я предлагаю для начала рассмотреть 2 уровневую схему.
1. Максимально простой и высокоуровневый (без низкоуровневых артефактов исполнителя) для обучения алгоритмизации и высокоуровневого программирования (большинство повседневных задач).
2. Приближенный к "реалиям" жизни то есть к модели исполнителя, особенностям железа...(системное программирование, биндинги к сторонним библиотекам)
Разграничение между ними - модули (т.е например если он начинается с module - это первый уровень , с MODULE- второй)
Первому уровню должно быть понятна большая часть того что экспортирует второй, второй должен ПОЛНОСТЬЮ понимать что сделано (и КАК) на первом...
-
Что-то подобное когда-то предлагал Р.Богатырёв, да так вроде и заглохло...
-
Что-то подобное когда-то предлагал Р.Богатырёв, да так вроде и заглохло...
Можно ссылку или направление поиска? (интересно насколько он проработал идею)...
-
rbogatyrev.livejournal.com (http://rbogatyrev.livejournal.com)
-
Что-то подобное когда-то предлагал Р.Богатырёв, да так вроде и заглохло...
Можно ссылку или направление поиска? (интересно насколько он проработал идею)...
В основном вот:
http://rbogatyrev.livejournal.com/2007/07/17/
http://rbogatyrev.livejournal.com/2007/08/24/
Вообще эти обсуждения велись на форуме Oberoncore и вроде как были перенесены в архив.
-
Нет, у Богатырева была другая, весьма сомнительная идея - иметь несколько "ортогональных" языков, хотя практика доказала необходимость мультипарадигменных языков. Поищите еще на "Королевстве Дельфи", там, где про создание операционной системы РОСА.
А многоуровневый язык - идея очевидная и даже частично реализованная (например, модуль SYSTEM в Блэкбоксе), но явно недооцененная. Для ее реализации необходимо иметь среду разработки (IDE), которая бы сопротивлялась неуместному использованию низкоуровневых средств. То есть, одним только языком тут не обойтись.
-
То же самое делается в Haskell'e на уровне системы типов языка :-)
IDE для этого не нужна.
-
Спасибо (всем за ссылки), но Богатырев насколько я понял (поправьте) вел речь в первую очередь о ОС в которую ПОЛНОСТЬЮ ортогонально (то есть независимо) интегрируется (а также единовременно поддерживются) несколько языков. Я предлагаю другое...
-
А многоуровневый язык - идея очевидная и даже частично реализованная (например, модуль SYSTEM в Блэкбоксе), но явно недооцененная.
Кто же спорит, весь смысл в идеалогии на которой строится это построения (модели) ...
-
Идея хорошая, и довольно популярная, но тут вся суть в деталях. Без деталей сложно что-то обсуждать.
-
То же самое делается в Haskell'e на уровне системы типов языка :-)
IDE для этого не нужна.
ЧТО строится в Хаскеле, с КАКОЙ ЦЕЛЬЮ, КАКИМИ средствами, для КОГО, и наконец , ДЛЯ ЧЕГО ИДЕ не нужна?
-
Идея хорошая, и довольно популярная, но тут вся суть в деталях. Без деталей сложно что-то обсуждать.
Вот я и предлагаю что бы определиться с деталя для начала ответить на вопросы ДЛЯ ЧЕГО, ДЛЯ КОГО. (детали прояснятся в обсуждении...)
-
1. Максимально простой и высокоуровневый (без низкоуровневых артефактов исполнителя) для обучения алгоритмизации и высокоуровневого программирования (большинство повседневных задач).
Так таки вот, что значит таки высокоуровневый, без артефактов исполнителя? Вообще без артефактов исполнителя не бывает в принципе, обычно чтобы избавиться от артефактов исполнителя реального вводят исполнителя виртуального, и завязываются уже на его артефакты.
Кроме того, замена реального исполнителя на виртуальный не делает язык высокоуровневым.
-
Так таки вот, что значит таки высокоуровневый, без артефактов исполнителя? Вообще без артефактов исполнителя не бывает в принципе, обычно чтобы избавиться от артефактов исполнителя реального вводят исполнителя виртуального, и завязываются уже на его артефакты.
Кроме того, замена реального исполнителя на виртуальный не делает язык высокоуровневым.
Чтобы глубоко не ударяться в философию
1. Есть понятия абстрагирования и идеализации, позволяющие приближенно рассматривать окружающий наш мир с помощью некоторого числа понятий, концепций, правил, законов...
2. Этот набор понятий... в контексте некоторой задачи можно рассматривать как некоторую систему описывающую данную задачу...
3. Есть понятие алгоритма -как метода решения задач, с определенными свойствами (конечность, детерменированность, массовость)
4. Будем считать что большинство систем встречающихся на практике достаточно описывается с помощью небольшого числа понятий информатики (в контексте задачи - императивная модель со строгой типизацией) (переменная, тип данных, данные, оператор присваивания, цикл, ветвление).
5. Изходя из п.4. Алгоритм можно выразить через понятия информатики.
6. Есть понятие ЯП , как промежуточного звена между человеком и исполнителем. (модель человека и исполнителя надо уточнять)
7. Есть понятие программы(мм), как оторбражения алгоритма, сформированного в терминах п.4 на ЯП п.6
Это основные понятия с которыми приходится иметь дело при решении большинства задач...
артефакты вылазят в п.5... основная проблема заключается в том, что они гадят во все пункты выше....
-
Спасибо (всем за ссылки), но Богатырев насколько я понял (поправьте) вел речь в первую очередь о ОС в которую ПОЛНОСТЬЮ ортогонально (то есть независимо) интегрируется (а также единовременно поддерживются) несколько языков. Я предлагаю другое...
Он предлагал разработать семейство дополняющих языков -- от самого низоуровневого до языка интеграции систем, написанных на языках более низкого уровня.
Вы предложили два уровня языков, а Богатырёв то ли три, то ли четыре, уже точно не помню...
-
ЧТО строится в Хаскеле, с КАКОЙ ЦЕЛЬЮ, КАКИМИ средствами, для КОГО, и наконец , ДЛЯ ЧЕГО ИДЕ не нужна?
... необходимо иметь среду разработки (IDE), которая бы сопротивлялась неуместному использованию низкоуровневых средств. То есть, одним только языком тут не обойтись.
То же самое делается в Haskell'e на уровне системы типов языка :-)
IDE для этого не нужна.
-
Спасибо (всем за ссылки), но Богатырев насколько я понял (поправьте) вел речь в первую очередь о ОС в которую ПОЛНОСТЬЮ ортогонально (то есть независимо) интегрируется (а также единовременно поддерживются) несколько языков. Я предлагаю другое...
Он предлагал разработать семейство дополняющих языков -- от самого низоуровневого до языка интеграции систем, написанных на языках более низкого уровня.
Вы предложили два уровня языков, а Богатырёв то ли три, то ли четыре, уже точно не помню...
Тогда в каком смысле им используется понятие "ортогональности", но ладно... я предлагаю идти не "снизу" а с противополжного направления (один фиг - системные языки есть , как и системы (ОС), и они развиваются и будут испльзоваться хотим мы этого или нет).
-
ЧТО строится в Хаскеле, с КАКОЙ ЦЕЛЬЮ, КАКИМИ средствами, для КОГО, и наконец , ДЛЯ ЧЕГО ИДЕ не нужна?
... необходимо иметь среду разработки (IDE), которая бы сопротивлялась неуместному использованию низкоуровневых средств. То есть, одним только языком тут не обойтись.
То же самое делается в Haskell'e на уровне системы типов языка :-)
IDE для этого не нужна.
Это я так понимаю Ваш вариант ответа ;) ? - поражает своей бессмысленностью и отрывом от контекста обсуждения... :-*
-
....
Это основные понятия с которыми приходится иметь дело при решении большинства задач...
артефакты вылазят в п.5... основная проблема заключается в том, что они гадят во все пункты выше....
Поправочка в п.6 конечно...
-
Это я так понимаю Ваш вариант ответа ;) ? - поражает своей бессмысленностью и отрывом от контекста обсуждения... :-*
Меня в свою очередь поражает Ваше (не)понимание простых казалось бы вещей, обсуждающихся здесь.
Или Вы просто троллингом занимаетесь от безделья?
-
Ой, народ, давайте тут лучше не будем личности обсуждать? Если уж на то пошло, то лучше уж заняться тонким троллингом друг друга :-) А еще лучше по возможности обсудить тему :-)
-
Это я так понимаю Ваш вариант ответа ;) ? - поражает своей бессмысленностью и отрывом от контекста обсуждения... :-*
Вапще мне непонятно, что там Вам непонятно.
Это же уже тут обсуждалось, и довольно подробно -- все низкоуровневые средства вроде ввода/вывода, изменяемых переменных, процессов, в Хаскелле завёрнуты в монаду IO, которая является типом данных языка Хаскелл, и, соответственно, их (этих низкоуровневых средств) использование контроллируется системой типов Хаскелла.
Реализованно это на уровне языка программирования без использования каких-то дополнительных средств типа IDE. Значит, в принципе для контроля использования низкоуровневых средств можно обойтись без IDE.
Что тут может быть непонятно? В чём здесь бессмысленность и отрыв от контекста?
Если тема, поднятая Сергеем Прохоренко, была оторвана от контекста обсуждения этого топика, то претензии к нему.
-
Похожее направление мысли поднял сегодня Дмитрий Дагаев своей статьёй:
http://forum.oberoncore.ru/viewtopic.php?f=62&t=3337
-
Похожее направление мысли поднял сегодня Дмитрий Дагаев своей статьёй:
http://forum.oberoncore.ru/viewtopic.php?f=62&t=3337
Вроде нет
1. Иде мы здесь не обсуждаем.
2. В качестве парного языка он предлагает тикл.
Да и общий концепт у него офтопный, затрудняюсь даже сказать что можно почерпнуть из его статьи в контексте этой темы...
-
Проблемы языка и среды плотно связаны. Перетекают друг в друга. Разумеется, математикам это претит - как это формализм можно завязывать на какую-то бренную машину/среду :)
Вопросы подняты у Дагаева как раз самые острые и насущные - как нормально обеспечить пространство для работы с информацией для людей. Очень реальная постановка из жизни.
А просто "надо язык верхнего уровня"... Это потребность "щось робитi". :)
-
Проблемы языка и среды плотно связаны. Перетекают друг в друга. Разумеется, математикам это претит - как это формализм можно завязывать на какую-то бренную машину/среду :)
Вопросы подняты у Дагаева как раз самые острые и насущные - как нормально обеспечить пространство для работы с информацией для людей. Очень реальная постановка из жизни.
А просто "надо язык верхнего уровня"... Это потребность "щось робитi". :)
Да РОБИТ - но подход его ИМХО представляется поверхностным...
-
Похожее направление мысли поднял сегодня Дмитрий Дагаев своей статьёй:
http://forum.oberoncore.ru/viewtopic.php?f=62&t=3337
Это немного не то направление что тут пытаются обсуждать, но и оно мне интересно. Особенно в свете tk (не tcl).
-
Похожее направление мысли поднял сегодня Дмитрий Дагаев своей статьёй:
http://forum.oberoncore.ru/viewtopic.php?f=62&t=3337
Это немного не то направление что тут пытаются обсуждать, но и оно мне интересно. Особенно в свете tk (не tcl).
Так сделайте новую ветку..
-
Возвращаясь к нашим баранам:
3. Есть понятие алгоритма -как метода решения задач, с определенными свойствами (конечность, детерменированность, массовость)
4. Будем считать что большинство систем встречающихся на практике достаточно описывается с помощью небольшого числа понятий информатики (в контексте задачи - императивная модель со строгой типизацией) (переменная, тип данных, данные, оператор присваивания, цикл, ветвление).
5. Изходя из п.4. Алгоритм можно выразить через понятия информатики.
Так таки вот: если не ошибаюсь, понятие алгоритма и его свойства вытекает из теории вычислимости, а теория вычислимости непосредственно связана и определана была через машину Тьюринга самим Тьюрингом. А машина тьюринга это и есть императивная модель.
Посему все эти три пункта на самом деле один пункт.
-
6. Есть понятие ЯП , как промежуточного звена между человеком и исполнителем. (модель человека и исполнителя надо уточнять)
Тут не очень понятно, ну вот возьмем скажем алгорифмы Маркова (они мне близки и понятны более чем скажем Тьюринга машина), там вполне конкретный исполнитель, логика его работы, описывается в тех же терминах, что и программа писаная для него, если программа писана, значит был язык на котором она написана. Так вот, язык тут не разлучен с исполнителем. Внимание вопрос -- где тут промежуточное звено? По моему, тут человек напрямую взаимодействует с исполнителем на его языке.
Я к тому, что в твоих пунктах явно чего-то не хватает.
Возьмем пачку ЯП. Возьмем некую задачу, ну, скажем, задачу поиска подстроки в строке. Внезапно окажется, что на некоторых языках эту задачу решить проще. а на некоторых сложнее. Почему? Потому, что каждый язык, кроме того самого синтаксиса который все видят, на который все ведутся, но который второстепенен, у каждого языка есть своя семантика, которая, вообще говоря, является тем самым виртуальным исполнителем языком которого и является данный ЯП. Исполнитель оперирует некими понятиями, если эти понятия близки решаемой задаче, то задача на данном ЯП решается просто, если же нет, то задача решается сложнее (но все равно решается).
Возвращаясь к поиску подстроки в строке -- на языке алгорифмов Маркова, эта задача решается очень и очень просто. В пару-тройку строчек (каждач строчка символов в 3-5), на языке машины Тьюринга эта задача решается уже сложно.
Это были просто ЯП. Теперь про языки высокого уровня. Языки высокого уровня позволяют построить набор абстракций удобных для решения задачи, позволяют это сделать вне зависимости от того, какая модель исполнителя нативна (эмм.. какой тип исполнителя родной) для данного ЯП. То есть даже если под капотом у нас машина Тьюринга, то ЯВУ все равно позволить построить над ним модель исполнителя алгорифмов Маркова и уже в этих терминах решить задачу. Чем язык уровнем выше, тем он проще и точнее позволяет построить модель нужного исполнителя и языка его, тем меньше (в данной задаче) из под Маркова будет выглядывать Тьюринг. В идеале, Тьюринга не будет видно вообще. И так для каждой задачи.
-
Возвращаясь к нашим баранам:
3. Есть понятие алгоритма -как метода решения задач, с определенными свойствами (конечность, детерменированность, массовость)
4. Будем считать что большинство систем встречающихся на практике достаточно описывается с помощью небольшого числа понятий информатики (в контексте задачи - императивная модель со строгой типизацией) (переменная, тип данных, данные, оператор присваивания, цикл, ветвление).
5. Изходя из п.4. Алгоритм можно выразить через понятия информатики.
Так таки вот: если не ошибаюсь, понятие алгоритма и его свойства вытекает из теории вычислимости, а теория вычислимости непосредственно связана и определана была через машину Тьюринга самим Тьюрингом. А машина тьюринга это и есть императивная модель.
Посему все эти три пункта на самом деле один пункт.
1. Нет- я имею ввиду гораздо более общее определение - человеческое которое наиболее часто используется на практике (в котором исполнитель не фигурирует в явном виде) - пример - нахождение кореней квадратного уравнения.
2. Нет-это всего лишь одно из возможных описаний (алгорифмы Маркова и машина Проста вполне могут быть использованы для этого) - но речь идет о том что оперировать нужно понятиями максимально приближенными к задачи... а не терминами (языком) исполнителя - кстати хороший пример - попробуйте описать систему описывающую скажем решения уровнения теплопроводности для достаточно широкого круга задач на машине Тюринга...
3. Нет -это всего лишь исполнитель работающий в рамках императивной концепции...
-
Тут не очень понятно, ну вот возьмем скажем алгорифмы Маркова (они мне близки и понятны более чем скажем Тьюринга машина), там вполне конкретный исполнитель, логика его работы, описывается в тех же терминах, что и программа писаная для него, если программа писана, значит был язык на котором она написана. Так вот, язык тут не разлучен с исполнителем. Внимание вопрос -- где тут промежуточное звено? По моему, тут человек напрямую взаимодействует с исполнителем на его языке.
Когда вы пишете программу для машин Маркова , Тьюринга...- вы пишете ее (непосредственно) в командах исполнителя, точно также вы можете программировать в командах процессора интела (бинарный код). Но это не ЯП. Здесь ЧЕЛОВЕК является НЕПОСРЕДСТВЕННО промежуточным звеном - он ОТОБРАЖАЕТ алгоритм решения задачи на систему комант исполнителя.
Но как вы понимаете для серьезных задач это не выход ;)
Я к тому, что в твоих пунктах явно чего-то не хватает.
Эти пункты я привел просто как базис от которого можно отталкиваться (для того чтобы консолидировать цели в обсуждении).
Возьмем пачку ЯП. Возьмем некую задачу, ну, скажем, задачу поиска подстроки в строке. Внезапно окажется, что на некоторых языках эту задачу решить проще. а на некоторых сложнее. Почему? Потому, что каждый язык, кроме того самого синтаксиса который все видят, на который все ведутся, но который второстепенен, у каждого языка есть своя семантика, которая, вообще говоря, является тем самым виртуальным исполнителем языком которого и является данный ЯП. Исполнитель оперирует некими понятиями, если эти понятия близки решаемой задаче, то задача на данном ЯП решается просто, если же нет, то задача решается сложнее (но все равно решается).
Возвращаясь к поиску подстроки в строке -- на языке алгорифмов Маркова, эта задача решается очень и очень просто. В пару-тройку строчек (каждач строчка символов в 3-5), на языке машины Тьюринга эта задача решается уже сложно.
Не понял что из этого - действительно система команд исполнителя Маркова родственна приведенным вами задачам обработки последовательности символов?
Это были просто ЯП. Теперь про языки высокого уровня. Языки высокого уровня позволяют построить набор абстракций удобных для решения задачи, позволяют это сделать вне зависимости от того, какая модель исполнителя нативна (эмм.. какой тип исполнителя родной) для данного ЯП. То есть даже если под капотом у нас машина Тьюринга, то ЯВУ все равно позволить построить над ним модель исполнителя алгорифмов Маркова и уже в этих терминах решить задачу. Чем язык уровнем выше, тем он проще и точнее позволяет построить модель нужного исполнителя и языка его, тем меньше (в данной задаче) из под Маркова будет выглядывать Тьюринг. В идеале, Тьюринга не будет видно вообще. И так для каждой задачи.
В терминах того что я предложил - это формулируется так, ЯВУ позволяет отображение алгоритма п.5 (в терминах п.4) на программу в терминах ЯП - с относительно небольшими искажениями, минимизирует влияние исполнителя на алгоритм - и вот тут еще тонкие моменты - УЧИТЫВАЕТ ВЛИЯНИЕ ЧЕЛОВЕЧЕСКОГО ФАКТОРА (посредством некоторой модели), так же он может содержать некоторые добавления которые упрощают описание на нем систем определенного вида (специализированность - нап. ЭРЛАНГ, ФОРТ)...
-
Не понял что из этого - действительно система команд исполнителя Маркова родственна приведенным вами задачам обработки последовательности символов?
Да. Там решать данную задачу наиболее удобно.