Ответ на »сообщение 4354« (Stargazer)
___________________________
>>> По-вашему получается, что существуют такие задачи и такие сущности, которые на 3GL принципиально невыразимы?
Нет, дело в том, что всё, что можно заставить работать на компьютерах, можно написать не то, что на ASM, но в машинных кодах. Но управление памятью, например, в данном случае остается на вашей совести… любые ошибки и центральный процессор ни чем Вам не поможет… В тоже время в Оберон или в dot-NET берут эти вещи под свой контроль и гарантируют, что ничего ни куда не утечет…
Да, без проблем, на 3GL языках Вы можете написать распределенную систему в виде множества exe-шников, крутящихся на многих компьютеров, но семантика взаимодействия храниться в Вашей голове, и нет такого выполняющего устройства, которое бы брало на себя управление и гарантировало стабильность этой системы, и правильность взаимодействия частей в рамках этой системы.

Ответ на »сообщение 4352« (Стэн)
___________________________

Главное, не начинать делить языки – на языки программирования, и языки конструирования систем, так как, как уже было выяснено, даже самая небольшая программа – система.

С этим высказыванием трудно согласиться. И вот почему. Язык ориентирован в две стороны -- в сторону человека и в сторону машины (компилятора, другого языка, операционной прослойки и т.п.). Рассмотрим ту сторону, которая ориентирована на человека. Не слишком ли мы много (с подачи американцев) уделяем внимания компьютерам. Знаете, у Дейкстры по этому поводу была очень хорошая фраза: "Вычислительная наука имеет не большее отношение к компьютерам, чем астрономия -- к телескопам". Именно "вычислительная наука" (computing science), а не "компьютерная наука" (computer science) -- плод американского взгляда на программирование.

Как только речь идет о разделении труда, о вычленении ролей (компетенций) участников проекта, автоматически требуется для каждой такой профессии свой набор методов, инструментов, свой уровень абстракции, свой понятийный аппарат.

Упоощенное деление:
1. Аналитик (постановщик задачи)
2. Архитектор (главный архитектор проекта -- ГАП, chief software architect)
3. Инженер (главный инженер проекта -- ГИП, chief software engineer)
4. Проектировщик
5. Начальник участка (прораб, он же team leader)
6. Монтажник, электрик, отделочник (программисты)
7. Руководитель службы технического контроля (и сама служба, quality assurance)
8. Эксплуатанционщики

Пока мы кроме п.6 ничего не затрагивали. Для индивидуального производства это обычно и не надо, поскольку программист -- и швец, и жнец, и на дуде игрец. Но лишь для индивидуального: пошивочное ателье, мастерская художника, народный промысел...

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

А что касается того, что все сведется к одному процессу в рамках конкретной ОС, так, например, нетрудно показать, что для программирования достаточно всего-то обычной спички -- они выкладываются друг к другу (головкой вверх -- "1", головка вниз -- "0") -- и готов (любой) алгоритм.

Ответ на »сообщение 4353« (Стэн)
___________________________


...
Вот она – задача системы! И dot-NET, стоящий на наших клиентских компьютерах, ничем не поможет, так как он ничего не знает о конфигурациях каналов связи, да и не должен знать. Это другой уровень, другие языки и другие системы.

По-вашему получается, что существуют такие задачи и такие сущности, которые на 3GL принципиально невыразимы?

Ответ на »сообщение 4318« (Антон Григорьев)
___________________________

Ответ на »сообщение 4315« (Стэн)
___________________________

Так причем здесь модули и способ их импорта? И вообще, причем здесь Оберон? Подставляйте вместо Оберона любой другой язык, на котором можно написать программу для компьютера, и по этой схеме его тоже можно опускать ниже плинтуса...

Это не совсем верное утверждение. Есть языки, в которые на уровне либо самого языка, либо СТАНДРТНЫХ библиотек встроены средства создания распределённых приложений. Java, например, или C#. Конечно, от зоопарка операционных систем это в полной мере не спасает, но если везде установлена подходящая среда исполнения, всё же можно говорить о том, что одни языки подходят для создания таких систем лучше, чем другие.
Антон, в свете сказанного мной до этого, выскажу следующее предположение. Да, действительно, для некоторого вида систем такие языки могут подходить лучше, чем другие, но принципиально это не спасает, и большие системы строить не помогает.
Рассмотрим пример:
Вы начальник какой-то вирусной лаборатории и у вас произошел инцидент с экспериментальным и очень опасным вирусом. Много народу заразилось и очень скоро погибнет, если быстро не сконструировать антивирус. Вы не знаете, как это сделать и связываетесь со мной, так как я очень крутой вирусолог и знаю все обо всем ;)  Но есть одна проблема – я живу уединенно далеко в горах, и единственная связь со мной – И-нет через спутник. И у меня и у Вас имеются приложения, которые обеспечивают видеоконференцию в реальном времени, написанные на C# + dot-NET. Ну и что? Самое узкое место – это канал связи. У нас экстренная ситуация и крайне желательно переконфигурировать спутники и роутеры так, чтобы на время обеспечить нашему трафику максимальный приоритет, потому что от этого зависят жизни многих людей.
Вот она – задача системы! И dot-NET, стоящий на наших клиентских компьютерах, ничем не поможет, так как он ничего не знает о конфигурациях каналов связи, да и не должен знать. Это другой уровень, другие языки и другие системы.

Ответ на »сообщение 4345« (Сергей Перовский)
___________________________
>>> И я склонен принять его сторону: какой модуль должен реализовывать тот или иной интерфейс в конкретной системе, должно описываться в языке конструирования системы, а не в языке программирования.
Вы уж извините, я повторюсь. (»сообщение 4315«) О какой системе сейчас речь? Запуская Оберон-программу, да и любую другую, в Windows – мы получаем систему из одного приложения, что-то типа Excel. Это конечно система, но явно не того типа, о котором тут говорил ASU. И можно очень долго рассуждать о том, надо ли изобретать какой-либо язык для описания взаимодействия модулей или нет – это ничего принципиально не даст. Любое взаимодействие с удаленным сервером – и приехали. Весь протокол этого взаимодействия придется реализовывать руками в отдельно взятом модуле, и среда выполнения локального приложения ничем не поможет потому, что сервер не обязан быть написан на Обероне или dot-NET.

Однако все не так плохо! Главное, не начинать делить языки – на языки программирования, и языки конструирования систем, так как, как уже было выяснено, даже самая небольшая программа – система.
Начиная с ассемблеров и далее, так называемые языки программирования, были предназначены только для одного – написания управляющих программ для аппаратных процессоров. Потом появились виртуальные машины SmallTalk, Java, .NET и т.д., но всё осталось по-старому – выполняющее устройство и программа. Даже язык SQL, считающийся декларативным, и который многие любят противопоставлять таким «императивным» языкам как C++ и Pascal на самом деле ничем не отличается от них – на SQL мы тоже пишем управляющую программу, только исполняющее устройство имеет другую конструкцию, что и обуславливает столь сильные различия в языках.

Доказательство декларативности Pascal: На Pascal мы не описываем, как центральный процессор должен выполнять вычисления, т.е. когда и на какие линии должен подаваться тот или иной уровень напряжения, следовательно, Pascal – декларативный язык ;)

И переходя к построению больших систем, но не систем вообще, а распределенных  программно-аппаратных систем, мы можем посмотреть на эту задачу также: исполняющее устройство и язык. Только в данном случае понятие исполняющего устройства трансформируется в среду, распределенную между многими компьютерами, где каждый из них является командным блоком, также как блоки в процессоре.
И язык в данном случае – это такой же язык, как и языки 3GL, но, так как исполняющее устройство другое, он будет обладать иным синтаксисом и семантикой. И ни какое это не другое средство… все то же самое, просто это другой уровень.
И это совсем не должен быть скриптовый динамический язык. Он вполне может быть компилируемым со статической проверкой типов и т.д., просто типы и форматы выходных файлов будут отличаться от того, что мы видим в Pascal и C++.

PS: С созданием нового языка – 3GL никуда не денуться. Как драйверы писались на C или ASM, так и будут писаться, только эти языки останутся в той нише, для которой они предназначены, а не будут использоваться для всего подряд.

Ответ на »сообщение 4348« (Руслан Богатырев)
___________________________

Добавлю. Все это прозрачным образом отображается на конечные автоматы и сети Петри. С возможностями соответствующего анализа (задача достижимости состояний) на формальном уровне.

Думал, что очевидно, но все же добавлю. Такой КА (СП) подменяется на лету элементарно. Т.е. ничего не надо перекомпилировать и пересобирать, чтобы получить разную схему обработки исключений (в зависимости от условий эксплуатации системы). КА (СП) -- это картридж данных (вынул, вставил). А диспетчер, которому передает управление ран-тайм при возникновении исключений, оперирует именно этим картриджем.

Ответ на »сообщение 4349« (Сергей Перовский)
___________________________

С ходу не найду, слишком много наворотили :) Поищу.
Он говорил о том, что для конструирования нужны другие средства, а не 3GL.  А в языке программирования средств межмодульного взаимодействия быть не должно. Так что притензии к языку были, но именно с позиций ДРУГОГО СРЕДСТВА(слово язык действительно, видимо, не употреблялось).

Убежден, что не найдете. Можете даже не тратить понапрасну время.

Принципиальные моменты следующие:
1. Идея кластеров как внешнего языка мной была изложена за несколько дней до появления здесь ASU (до инициирования им дискуссии). И я это ему явно указал с точной ссылкой в ходе дискуссии.
2. Ни о каком языке конструирования он не говорил (а язык -- это принципиально).
3. Он предъявлял претензии сначала к квалифицирующему импорту Оберона, а потом уже просто к импорту (даже интерфейсов). Никаких проблем в этом плане нет. Проблемы абсолютно надуманы. И языку кластеров механизм импорта языка Оберон только помогает, поскольку в противном случае (в подходе ASU) импорт становится теневым и выносится на уровень операционный без регламентации (я уже приводил различия между языком и средой -- первый фиксирован, вторая -- с каждой версией принимает все новые более размытые очертания).

Ответ на »сообщение 4347« (Руслан Богатырев)
___________________________
>>>в подтверждение того, что ASU говорил о языке конструирования и не предъявлял претензии к языку программирования -- ссылку в студию!
С ходу не найду, слишком много наворотили :) Поищу.
Он говорил о том, что для конструирования нужны другие средства, а не 3GL.  А в языке программирования средств межмодульного взаимодействия быть не должно. Так что притензии к языку были, но именно с позиций ДРУГОГО СРЕДСТВА(слово язык действительно, видимо, не употреблялось).

Ответ на »сообщение 4344« (Руслан Богатырев)
___________________________

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

Добавлю. Все это прозрачным образом отображается на конечные автоматы и сети Петри. С возможностями соответствующего анализа (задача достижимости состояний) на формальном уровне.

Ответ на »сообщение 4345« (Сергей Перовский)
___________________________

И я склонен принять его сторону: какой модуль должен реализовывать тот или иной интерфейс в конкретной системе, должно описываться в языке конструирования системы, а не в языке программирования.

Извините за требование конкретики, но в подтверждение того, что ASU говорил о языке конструирования и не предъявлял претензии к языку программирования -- ссылку в студию!