Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Сергей Прохоренко

Страницы: [1] 2
1
Да сама по себе точка с запятой - не грязь, но вот если можно ставить, а можно нет, то уже как бы и грязь..
Надо кому-то что-то объяснять - а почему в текущем коллективе или проекте или где ещё принято не ставить (или ставить).
Вместо того, чтобы иметь "вмороженный" в компилятор единственный вариант.
А Вам и Вашим сотрудникам это реально мешает в работе на КП/ББ?

И, кстати, почему так и не распространился какой-то единый coding style guide для оберонов? Каждый пишет как попало...

Ну, кое-какие указания по стилю имеются в документе Oberon for LPC2000 Microcontrollers, в разделе 10 Programming Conventions and Guidelines. Потом, есть ещё "бьютифаеры", которые автоматически задают стиль.

2
Нет, у Богатырева была другая, весьма сомнительная идея - иметь несколько "ортогональных" языков, хотя практика доказала необходимость мультипарадигменных языков. Поищите еще на "Королевстве Дельфи", там, где про создание операционной системы РОСА.

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

3
Общий раздел / Re:Идеальный ЯП
« : Март 11, 2011, 05:52:24 pm »
Вообще мне представляется, что например присваивание ... должно быть таким:
a ← bТехническая возможность сейчас для этого есть.

А мне представляется иначе: https://sites.google.com/site/purebuilder/#TOC-24

4
Гхм. ООП в true oberon'e - с нефиговым таким недостатком. По степени возможных граблей может поспорить с жабаскриптом :) Да, и оно точно так же "не работает" с идеей pure функций.

Во всех нынешних языках ООП страдает какими-нибудь пороками. Не хватает фундаментальности в анализе ООП, а поэтому реализация оказывается такой уродливой. Надо думать, что делать.

5
А зачем там вообще какие-то переменные?
Затем, что hello world что-то таки печатает куда-то, сам этот процесс таки изменяет состояние чего-то, вот это самое что-то это и есть глобальная переменная.

Вот буквально сегодня смотрел исходники функции printf для микроконтроллера который у нас используется -- там без глобальной переменной не обошлось. Причем по фиксированному адресу. :-)

Но мы же говорим о новом языке высокого уровня, а не о том, во что он транслируется. Да в ассемблере есть и глобальные переменные, и goto, и побочные эффекты на каждом шагу. И я отношусь к этому совершенно спокойно, потому что транслятор, как правило, не допускает ошибок, в отличие от программиста.

6
Что подразумеваем под глобальными переменными?

Переменная, объявленная снаружи процедуры/функции, и доступная как снаружи, так и внутри нее. См. Википедию.

Собственно хотелось бы увидеть, как без глобальных переменных получится, ну, скажем написать Hello World.

А зачем там вообще какие-то переменные?

7
А чем сущность "классического" ООП отличается от Обероновых - в моем представлении это набор концепций, а в вашем?

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

Классический ООП основан на классах и интерфейсах, содержащих методы (ну и поля). Наиболее яркие примеры: Дельфи, Си++, Ява. Обероновский ООП (кроме Оберона-2 и КП) - на процедурных типах, при том, что процедуры не привязаны к структурным типам данных (записям, объектам, классам, интерфейсам и т.п.). Обероновский ООП имеет не только достоинства, но и недостатки. Но имеет смысл подумать об устранении недостатков, а не о заимствовании классического ООП.

8
И потом - полный запрет.... для некоторых задач они естественны... А что естественно то не безобразно, как известно

Насколько понимаю, речь идет о глобальных переменных.

Думаю, что в программировании вообще нет ничего естественного. А естественность глобальных переменных и подавно - полная ерунда. В программировании всё искусственное. Когда разработчики недостаточно искусны, появляются такие примитивные и убогие вещи, как глобальные переменные, мудреные правила видимости и прочий винигрет... совершенно безобразный! Глобальные переменные - это отображение хаоса модели задачи в хаос программного кода.

9
Под классическим ООП подразумевается то, что в КП и Обероне-2?

Да. Скопировано из мейнстрима.

10
Мне кажется, что поставленная задача тут чрезмерно усложнена расширительным толкованием понятия "Побочный эффект". Если сузить толкование до обычного, то получение функций и процедур без побочных эффектов станет вполне посильной задачей. Можно будет обойтись (за редкими исключениями) без функций и процедур с побочными эффектами. Правда, для этого потребуются серьезные решения по языку, как это предложено в PureBuilder:
  • полный запрет глобальных и статических переменных,
  • модификация механизма исключений в функциональном стиле,
  • отказ от классического ООП в пользу ООП, реализованного в Обероне и в Обероне-07.

11
Общий раздел / Re:Оберон в образовании.
« : Февраль 26, 2011, 02:24:34 pm »
По-поводу Fortran. Там есть функции (FUNCTION) и подпрограммы (SUBROUTINE). Общий термин - процедура (PROCEDURE). Дык вот, таки функции имеют возвращаемое значение, процедуры - нет. 

Любую процедуру (как функцию, так и подпрограмму) можно объявить PURE. Контроль на отсутствие побочных эффектов. Принято объявлять чистыми функции, а подпрограммы использовать для изменения состояния (императивный язык всё-таки).

При такой дисциплине наличие ключевого слова CALL в тексте программы крайне полезно. Позволяет однозначно идентифицировать место, где могут лежать грабельки.

Вот так. Но это, конечно, не вся история.

Чистые функции необходимы, например, для использования во всяких там FORALL и DO CONCURENT. Есть ещё концепция поэлементной функции (ELEMENTAL). Это функция, которая определяется для обычного скалярного аргумента, но может быть применена для массива таких аргументов любой размерности. Такие функции читсые по-умолчанию. То есть ELEMENTAL подразумевает PURE. Хотя в новом стандарте можно заиметь и ELEMENTAL IMPURE функцию. Ещё все стандартные функции чистые.

А с параметрами там тоже интересно. Указывается т.н. намерение (INTENT). Оно может быть IN, OUT и INOUT...

Не язык а мечта! Буду изучать FORTRAN.  :D

12
Общий раздел / Re:Оберон в образовании.
« : Февраль 25, 2011, 09:02:43 pm »
1. С какого это бодуна мы хотим, чтобы не было побочных эффектов? Побочный эффект - нормальный инструмент в программировании.

Ну да, используешь какую-нибудь функцию в выражении, а она зараза втихаря нужный файл закрывает или еще что-нибудь в этом роде творит. Вполне себе нормально! Если есть возможность такие вещи поставить под контроль, то почему нет? Хотим без страховки бегать по перилам, чтобы круче выглядеть в глазах окружающих?

Для контроля как раз полезны синтаксические отличия функций от процедур (call, return, out-параметры). А Вирт отказался от слова function, мне кажется, из чисто маркетинговых соображений - чтобы еще уменьшить количество ключевых слов и козырять этим. Наглядность кода при этом снизилась.

Я понимаю, что тем, кто съел собаку на C/C++, теперь море по колено, и они такими мелочами, как наглядность, не заморачиваются. Оберон уже на три порядка нагляднее C/C++, чего же, дескать, еще желать? Но у людей, не прошедших эти медные трубы, требования к наглядности (и надежности!) более высокие.

13
Общий раздел / Re:Оберон в образовании.
« : Февраль 25, 2011, 06:25:07 pm »
Тогда лучше использовать дрвний термин "подпрограмма". Применение этого термина никак не требует разделения на процедуры и функции. Хотя даже в фортране (видимо, из чисто практических соображений) были и subroutine и function.

Если мы хотим, чтобы не было побочных эффектов, то для функции это сделать проще - можно потребовать, чтобы не было OUT-параметров. В процедуре OUT-параметры будут обязательно, иначе значения никак не вернуть. Синтаксис у функций и процедур разный, употребление тоже. Нет смысла экономить на ключевом слове в ущерб наглядности.

14
Соответственно 5 - нет необходимости в механизме исключений.

Вы теперь против механизма исключений, даже такого сильно ограниченного функциональным стилем и "скрещенного" с кодами ошибки, как в PureBuilder?

Возникает несколько вопросов:
1) Что взамен - для действительно аварийных ситуаций, делающих бессмысленным возвращаемое значение функции?
2) Что изменить в языке, чтобы код обработки ошибок в рантайме был отделен в программе от нормального штатного кода?
3) Как же тогда учить студентов осторожному применению механизма исключений в "промышленных" языках?

15
Я думаю, что нужно предоставить программисту удобную возможность проинициализировать переменную при объявлении и напомнить ему, если это не сделано. Но принуждать к инициализации не нужно. Иначе в рантайме уже не удастся сгенерировать и обработать исключение, когда действительно осмысленная инициализация не прошла. Программа будет утверждать, что "всё хорошо, прекрасная маркиза", хотя на самом деле это не так.

Страницы: [1] 2