Автор Тема: Оберон в образовании.  (Прочитано 103299 раз)

Валерий Лаптев

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #135 : Февраль 25, 2011, 06:41:20 pm »
Если мы хотим, чтобы не было побочных эффектов, то для функции это сделать проще - можно потребовать, чтобы не было OUT-параметров. В процедуре OUT-параметры будут обязательно, иначе значения никак не вернуть. Синтаксис у функций и процедур разный, употребление тоже. Нет смысла экономить на ключевом слове в ущерб наглядности.
1. С какого это бодуна мы хотим, чтобы не было побочных эффектов? Побочный эффект - нормальный инструмент в программировании.
2. Это только для начинающих и при обучении полезно иметь совсем разные обозначения для почти одинаковых сущностей. А чем больше пишешь, тем хочется короче... :) То есть одно слово procedure в КП для обоих видов подпрограмм - как раз из этой оперы... 

DIzer

  • Гость
Re:Оберон в образовании.
« Ответ #136 : Февраль 25, 2011, 06:45:50 pm »
Если мы хотим, чтобы не было побочных эффектов, то для функции это сделать проще - можно потребовать, чтобы не было OUT-параметров. В процедуре OUT-параметры будут обязательно, иначе значения никак не вернуть. Синтаксис у функций и процедур разный, употребление тоже. Нет смысла экономить на ключевом слове в ущерб наглядности.
1. С какого это бодуна мы хотим, чтобы не было побочных эффектов? Побочный эффект - нормальный инструмент в программировании.
2. Это только для начинающих и при обучении полезно иметь совсем разные обозначения для почти одинаковых сущностей. А чем больше пишешь, тем хочется короче... :) То есть одно слово procedure в КП для обоих видов подпрограмм - как раз из этой оперы...  

Браво, а если вспомнить что они НЕИЗБЕЖНЫ (в больших системах) :D .... то вышеприведенное обсуждение.... как минимум забавно (для меня)
« Последнее редактирование: Февраль 25, 2011, 06:48:21 pm от DIzer »

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #137 : Февраль 25, 2011, 06:52:23 pm »
Только вот побочные эффекты должны быть строго контролируемы.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Оберон в образовании.
« Ответ #138 : Февраль 25, 2011, 06:57:00 pm »
Только вот побочные эффекты должны быть строго контролируемы.
Не... меня смешат попытки решить эту проблему комбинаторным способом, уж лучше гадая на кофейной гуще = хотя второе не так весело!

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #139 : Февраль 25, 2011, 07:05:17 pm »
Только вот побочные эффекты должны быть строго контролируемы.
Не... меня смешат попытки решить эту проблему комбинаторным способом, уж лучше гадая на кофейной гуще = хотя второе не так весело!

А есть иные предложения? ;-)

Кстати, да, я могу переформулировать своё то предложение о борьбе с ВНЕЗАПНЫМИ побочными эффектами. В отдельной теме. В принципе, там ничего абсолютно нет революционного. Чистая эволюция. Просто мы все будем делать явно вот и всё :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #140 : Февраль 25, 2011, 07:46:55 pm »
Тогда лучше использовать дрвний термин "подпрограмма". Применение этого термина никак не требует разделения на процедуры и функции. Хотя даже в фортране (видимо, из чисто практических соображений) были и subroutine и function.

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

Вот я в упор не понимаю - какое у них разное употребление :) Сегодня функция... пардон, процедура ничего не возвращает (рисует фигуры, как кто-то приводил пример), завтра - она уже возвращает количество отрисованных фигур. И что, теперь она - функция и должна по-другому употребляться и восприниматься?

Валерий Лаптев

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #141 : Февраль 25, 2011, 08:04:15 pm »
Вызов функции, возвращающей значение определенного типа, может быть операндом выражения соответствующего типа. Вызов процедуры - нет. В фортране и PL-1 вызовы отличались даже синтаксически. Вызов процедуры - это отдельный оператор CALL.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #142 : Февраль 25, 2011, 08:16:10 pm »
Вызов функции, возвращающей значение определенного типа, может быть операндом выражения соответствующего типа. Вызов процедуры - нет.

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

Сергей Прохоренко

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

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

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

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #144 : Февраль 25, 2011, 09:15:41 pm »
Я понимаю, что тем, кто съел собаку на C/C++, теперь море по колено, и они такими мелочами, как наглядность, не заморачиваются. Оберон уже на три порядка нагляднее C/C++, чего же, дескать, еще желать? Но у людей, не прошедших эти медные трубы, требования к наглядности (и надежности!) более высокие.
Вот не надо тут смешивать таки.
С++-программисты очень любят наглядность и очень любят страховаться от выстрелов в ногу (чтобы компилятор проверял максимум всего). Посмотрите на тот же буст например. Максимально строгая типизация и т.д. и т.п. И таки С++ во многих аспектах получается сделать наглядней чем Оберон.

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

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #145 : Февраль 25, 2011, 09:25:48 pm »
1. С какого это бодуна мы хотим, чтобы не было побочных эффектов? Побочный эффект - нормальный инструмент в программировании.

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

Дык. Желание понятно. Метод решения - нет. Ну допустим вы запретите обращаться к "внешним" сущностям из "функций". От "закрытия файла" это не спасет. Всегда можно спустить в качестве аргумента ну очень абстрактный интерфейс, вызов метода которого закроет файл. Никакого контроля. Ограничить аргументы простыми неуказательными типами? Тогда толку от таких "функций" будет ничтожно мало.

Цитата: Сергей Прохоренко
Я понимаю, что тем, кто съел собаку на C/C++, теперь море по колено, и они такими мелочами, как наглядность, не заморачиваются.

Не надо обвинять плюсистов в настолько страшных грехах :) Они все люди и наглядность кода им тоже важна. И именно поэтому я считаю, что оберон еще пилить и пилить ;)

Цитата: Сергей Прохоренко
Оберон уже на три порядка нагляднее C/C++, чего же, дескать, еще желать?

Давайте не будем в этом топике ;) Ограничимся функциями и процедурами (хотя это тоже уже неоригинальный топик).

Цитата: Сергей Прохоренко
Но у людей, не прошедших эти медные трубы, требования к наглядности (и надежности!) более высокие.

Описываемую проблему ("неожиданное закрытие файла") я, будучи на С++, решаю такими самоограничениями:
1. Минимум глобальных переменных. Это значит, что функция не может закрыть файл, если только к ней через аргумент не пришло что-то, что можно использовать для закрытия файла.
2. По возможности аргументы делаются const. Это уменьшает вероятность того, что функция сделает что-то деструктивное даже используя такие аргументы.

Да, мне хотелось бы больше контроля. Поэтому я пытаюсь понять чем же мне может помочь разделение на процедуры и функции. Но пока я не вижу никакой реальной помощи, кроме чисто умозрительного "функция не будет закрывать файл, потому что она функция, а не процедура".
« Последнее редактирование: Февраль 25, 2011, 09:27:47 pm от vlad »

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #146 : Февраль 25, 2011, 09:31:52 pm »
vlad, а оцени ка моё предложение по контролю http://oberon.talk4fun.net/index.php?topic=6.msg260#msg260
Ну и далее по тексту.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #147 : Февраль 25, 2011, 09:42:51 pm »
vlad, а оцени ка моё предложение по контролю http://oberon.talk4fun.net/index.php?topic=6.msg260#msg260
Ну и далее по тексту.

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #148 : Февраль 25, 2011, 09:45:25 pm »
А чем плох тотальный конст? (опять же, можно сделать тотальный конст, но указать исключения из тотальности для данного конкретного случая. хотя... и исключения не нужны -- достаточно дать отдельными параметрами не константными ссылками на те места структуры, которые можно таки менять).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Оберон в образовании.
« Ответ #149 : Февраль 25, 2011, 09:46:59 pm »
Посмотрите на тот же буст например.

Не надо смотреть на буст, если вы не программируете на C++ :) Лучше спросить у тех, кто его использует, какие проблемы он помогает решать.

P.S. И уж тем более не надо смотреть его исходники ;)