Ответ на »сообщение 2707« (AVC)
___________________________

Священную войну (holy war или джихад) ведут функциональщики.

Ну вот, сначала объявили в терроризме, а потом:

Никто так и не смог откровенно ответить Руслану на вопрос, является ли ФП серебряной пулей.

ещё и в безумии... :о(

Серебрянной пули нет!

Эти слова Брукса мы тут повторяли неоднократно (в тех или иных формах)... Почему вы их не заметили? :о(

Ответ на »сообщение 2697« (Geniepro)
___________________________

Ответ на »сообщение 2686« (Илья Ермаков)
___________________________
Состояние модулей в ИЯ может изменяться заранее неизвестным образом. Это может как угодно изменять поведение этих модулей - функции, вычисляемые процедурами в этих модулях. Сейчас один результат, через полчаса при тех же входных данных - другой, завтра - третий... Какой-то генератор случайных чисел получается... :о)

Если процедура имеет смысл мат. функции, преобразующей входные данные - то она и будет написана только от входных данных...
Если процедура возвращает некоторую характеристику текущего состояния модуля - то естетсвенно, ее значение зависит от состояния этого модуля. Это тоже чистая функция, но функция состояния модуля. Рассматривайте ее как индикатор некоторого параметра в состоянии модуля ("давление пара" али "обороты коленвала" :-) ).
И в том, и в другом случае работает правило: если процедура написана как функция, с возвращаемым значением, то она не должна иметь побочных эффектов... Увы, в Обероне компилятор это не контролирует, можете, если хотите, "взять на карандаш" этот реальный "пробел". Но в той же Аде такой контроль есть - процедура-функция не может иметь побочный эффект, иначе - по шее от компилятора...

Ответ на »сообщение 2700« (panda)
___________________________

>>>Да хоть в 110. Ее все равно быстрее открыть, чем делать File - Open.

А я было поверил Вашей фразе из »сообщение 2668« ;)

>>>Возможно, Вы полагаете, что в обероновских средах нет такой возможности?
Разве я такое говорил? ;)

Ответ на »сообщение 2696« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2695« (Илья Ермаков)
___________________________

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

Вообще-то всё не так просто. В Хаскелле до чёртиков разных способов создания новых типов...
Вот пример, который мне сейчас в голову пришёл:

module ModA (
            Kilometers,
            Color,
            Distance (Distance)
) where

type Color  = Int

data Kilometers = Int
instance Num  Kilometers where
instance Show Kilometers where
instance Eq  Kilometers where

newtype Distance = Distance Int
instance Num  Distance where
instance Show Distance where
instance Eq  Distance where

module ModB (
            Kilograms,
            Density,
            Time (Time)
) where

type Density = Int

data Kilograms = Int
instance Num  Kilograms where
instance Show Kilograms where
instance Eq  Kilograms where

newtype Time = Time Int
instance Num  Time where
instance Show Time where
instance Eq  Time where 

module Main where

import ModA
import ModB

type Velocity = Float

main = do print (red - high)  -- Допустимое смешивание типов
          print (km  + kg  )  -- Ошибка: несовместимые типы
          print (sec * len )  -- Ошибка: несовместимые типы
          print (red - kg  )  -- Ошибка: несовместимые типы
          print (red - sec )  -- Ошибка: несовместимые типы
          print (km  - len )  -- Ошибка: несовместимые типы
          print (speed / kg)  -- Ошибка: несовместимые типы

speed = 100.0 :: Velocity

red  =  5 :: Color
high = 50 :: Density

km  = 10 :: Kilometers
kg  = 20 :: Kilograms

sec  = Time 5
len  = Distance 2       

type создаёт фактически синонимы для имеющихся типов, а не новые типы...
Так что есть способы типизации по имени (data, newtype), а есть - по содержимому (type)...

Никого не убеждая, описываю ситуацию.

Работаю в проекте которому чуть меньше 10 лет. Средства разработки VC - С/С++.
Количество разработчиков несколько десятков + такой же отдел тестеров. Всего может и за сотню перевалит. Разбросаны по нескольким странам.

Количество c/cpp/h файлов порядка 4500. Всего сорцы занимают 45MB. Т.е средний файл имеет размер 10К или поделив на 20 получаем 500 строчек на файл.

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

Отлавливать баги, исправлять, изменять, улучшать в таком коде - это просто наказание. Все действительно начинается с тыканья по функциям и переменным где они определены, инициализируются и как используются. Часы, дни и даже недели в Debug'ере... Code-review, Static Analisis, UnitTesting, Purify и т.д.

"Шпаклюешь" в одном месте прорывает в другом. Жёсткий timing по времени. Release должен выйти вовремя. Проект очень успешный - хорошо продаётся.

Все простые программисты имеют высшее образование и опыт 4-8 и более лет на С/С++ и других погремушках. Все плюются, всех тошнит, все ругают С/С++ (например за проблемы с include'ами).

Но самое интересное, что когда пытаешься объяснить, что это проблема в самом языке программирования и никакие Purify, StaticAnalysis, IDE не могут решить и исключить проблемы в самом языке программирования, далеко не все понимают! Хотят иметь свободу и не иметь проблем! "Плохой дизайн, безрукий коллега, недостаточный Unitest" и т.д. но не средство разработки!

Начав изучение программирования на Modula-2 ещё в школе, я был просто в восторге от её продуманности, простоте и возможностях. Мне не с чем было сравнивать. Я не был знаком ни с Pascal ни с C/C++. Просто программировал на Modula-2. Мне казался он идеальным.

Но со временем, меня начали раздражать не однозначности и с диапазонами и с перечислениями и даже не квалифицированный импорт. Да откровенную глупость написать - не напишешь. Modula-2 достаточно строг, но как всегда - человеческий фактор с которым компилятор сделать ничего не может, кроме как... запретить вообще.

Так что для меня не стало разочарованием отсутствие в Oberon этих и многих других "понтов". Возможно я не понимаю всех причин побудивших Вирта и его команду по убирать "лишнее", но если я в течении 3-5 лет программирования в школе и в универе на Modula-2 почувствовал "дискомфорт" в некоторых фичах, то совершенно логично Вирт, потративший только на ветку Pascal -> Modula -> Oberon - лет 30 и вообще на программирование и разработку компиляторов и всяких там систем - лет 60, наверняка многие вещи прочувствовал гораздо лучше меня и наверное лучше большинства присутствующих на этом форуме (без обид). Я уж не говорю про горе программистов на C++/Java с опытом 7 лет+.

Не забудем и про всякие премии, которые наверное не просто так даются.

Суть не в том, что бы закрыв глаза верить всему, что говорит господин Вирт, а проявить уважение и постараться понять причины. Кажется Вирт и ФЯ занимался - что то не пошло - значит были причины. Какие? Нужно разбираться, а не кричать: "он дурак!".

P.S. Когда пришлось познакомится в разное время с Pascal (для олимпиад), C/C++ (в университете) и Delphi (был один проект) - просто тошнило. От С++ и сейчас тошнит, даже после 6 лет использования в университете и на работе, т.е. дело явно не в не знании его возможностей, а в чем то другом.

P.P.S. Да кстати, в С++ нет поддержки длинных чисел, но благодаря operator overloading, можно получить такой же изящный код как и на ФЯ. Ну так что "кто на новенького"?

Ответ на »сообщение 2702« (panda)
___________________________

Я 9 лет разрабатывал на Delphi и никогда не возникало потребности использовать map/reduce/lambda. Но попробовав их на Python и возвращаясь в Delphi мне есть с чем сравнивать. Начнем holy war за ФП?

Священную войну (holy war или джихад) ведут функциональщики.
Оберонщики не оспаривают, что у ФП есть свои плюсы, и что это направление перспективно.
Вопрос ставится о границах применимости этого подхода.
Почему-то этот, IMHO, естественный для любого грамотного человека вопрос вызывает у функциональщиков бурю возмущения.
Ка-а-ак?! У ФП могут быть какие-то границы?! Даешь ФП без границ!!
Такое восприятие и лежит в основе разнообразных holy wars.
Никто так и не смог откровенно ответить Руслану на вопрос, является ли ФП серебряной пулей. Это говорит о многом.

Не буду спорить - в плане прихода "масс программистов" Оберон не сильно "безопаснее".
Однако это вопросы уже другого разреза. От орд дилетантов и невежд не спасет никакой язык.
Это проблемы образования и подготовки кадров...
В общем, все это палки о двух концах.

Ответ на »сообщение 2701« (Илья Ермаков)
___________________________
Не спорю, что дурной пример, навернули ребята не относящегося к делу... 
Не только дурной пример, но и говорящий пример.
Уже который по счету пример, показывающий что оберон совершенно спокойно позволяет писать точно также как писали до него на других языках. Все те же "удобства" для желающих развалиться на диване.
А ведь еще раз повторяю - это не лохи (пока). Пока в обероне тусуются в подавляющем большинстве грамотные программисты. И то зачастую сиюминутное удобство написания берет вверх над грамотной архитектурой, декомпозицией задачи на меньшие и независимые подзадачи.
Что же произойдет если "открыть шлюзы" и пустить к вам армию программистов гораздо более слабого уровня ?
Вы говорили о том что мол оберон их переучит. Не вижу.
Чтобы переучить нужно ставить палки в колеса, делать привычный метод работы либо неудобным (лисп), либо невозможным (хаскель).
Оберон не делает ни того ни другого.
Ему по существу нечего предложить в плане повышения качества кода и надежности программ в неконтролируемой среде (массы программистов)

И вообще, уважаемые хозяева ветки сказали, что эта тема им не интересна, давайте завершимся - при своих мнениях :-)

Ответ на »сообщение 2700« (panda)
___________________________

Ответ на »сообщение 2678« (Илья Ермаков)
___________________________

Знаете, реализация интересующей функциональности может быть рассредоточена по десятку-другому модулей, откуда ее надо аккуратно "отсечь" и перенести... Вот вам и "найти реализацию по щелчку мышки"... :-)
Да хоть в 110. Ее все равно быстрее открыть, чем делать File - Open.
Надоело спорить не по делу... Каким образом явная квалификация мешает открывать по щелчку мыши? Она всего лишь избавляет от необходимости щелкать для того, чтобы видеть, что откуда. В разработке системных или инфраструктурных частей ПО, особенно компонентного, очень важно видеть, куда и когда идет граф управления... В ФП графа управления нет, там позывов к использованию явной квалификации меньше... А в Дельфе - просто банальная лень написать лишнее слово (кстати, если очень хочется, можно научить среду саму дописывать полный префикс) и "дремучесть", уж извините...