Ответ на »сообщение 2245« (Сергей Губанов)
___________________________
Да у Вас просто возникла ассоциация: "состояние" --> "дискретность".
Нет. Это не я писал про "состояния, выраженные в значениях набора переменных". И про переходы из состояния в состояние (желаемые, нужные наборы занчений множества переменных)... То, что это прямо отобразилось на дискреты - ну шо ж - метод в данном случае подошёл...

В то же время физический термин "состояние", вообще говоря, не имеет отношения к дискретности.
Полностью солидарен!

Не всё в Мире дискретно, но состояния имеет (непрерывные спектры).
Ну вот опять! То, что вы в данном случае определяете как "состояние" - просто абстракция, заменяющая недостаток знания по конкретным процессам, происходящим внутри некоторой системы, производящей именно такой набор и конфигурацию "пиков" на спектре...

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

Ответ на »сообщение 2211« (info21)
___________________________
Ответ на »сообщение 2192« (Владимир Лось)
___________________________
Любопытный case, надо сказать, для психоаналитика.
В своё время - ужЕ. Перед поступлением в фымышугу. Рекомендация для приёма от классного воспитателя и психоаналитика: "неординарность мышления"... :о) Так шо вы припоздали... Впрочем, - как всегда.
Только при чем тут Оберон...
68

Ответ на »сообщение 2262« (Снегурочка)
___________________________

Проблема "подобия" достаточно известная (generic programming).

Кстати, некоторые вещи "подобия" заложены в классическом Обероне: объекты одного и того же класса "клепаются" под общую заготовку, но потом могут функционально "доопределяться", иметь разное поведение (конкретные объекты одного и того же класса) - поля записи, из которой строится класс, могут быть процедурного типа и после инициации объекта перекоммутироваться на лету простым присваиванием "ссылки" на процедуру. В общем случае штука опасная, но если очень нужно и осторожно, может дать хороший generic-эффект.

Ответ на »сообщение 2260« (Сергей Перовский)
___________________________
у меня знакомый отладивается путем repl в winhugs

а можно еще логи и юнит-тесты задействовать.

Ответ на »сообщение 2250« (Alexey Veselovsky)
___________________________

Тем не менее, у Оберона таки есть проблемы. Иногда (причем это самое иногда - довольно часто случается), возникает необходимость написать множество однотипных классов(и/или модулей) (например, как в моем случае - это коллекция технологических GUI-элементов).

Проблема "подобия" достаточно известная (generic programming). В Обероне экземпляр модуля с конкретным именем может быть только один. Нет типов модулей. Это очень хорошо для тех случаев, когда без подобия можно обойтись (нет ненужных наворотов). Но в проекте может наступить момент, когда такая потребность вдруг неожиданно появляется. Это (подобие) желательно продумать еще на этапе отработки проектных решений.

Соответствующие эксперименты (generic modules) в свое время велись еще с расширениями языка Modula-2 и потом вошли в ISO-стандарт Modula-2 и в язык Modula-3. Вирт к этому относился сдержанно-скептически, как и к exception handling.

Ответ на »сообщение 2260« (Сергей Перовский)
___________________________
Мы ставим HALT после присваиваний и культурненько разглядываем дамп...

Вот еще одна провокация на две стороны :)
Демонстративно написано на Паскале :P

Function MyFunc(A,B,C:integer):integer;
begin
//Апофеоз функционального подхода.
  result:=F1(F2(A,A),F3(A,B),F4(B,C));
end;
Но работает неправильно.
F1,F2,F3,F4- функции сторонних разработчиков, может быть и доступные в исходниках, но достаточно сложные.

Чтобы понять, где ошибка переписываю так:
Function MyFunc(A,B,C:integer):integer;
var K1,K2,K3,K4:integer;
begin
//Назад в пещеры!
  K4:=F4(B,C);
  K3:=F3(A,B);
  K2:=F2(A,A);
  K1:=F1(K2,K3,K4);
  result:=K1;
end;
Затем прохожу это дело (Оберонщики, внимание!) пошаговым отладчиком.

А как поступаете вы?

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

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

Из своего скромного опыта работы с Прологом могу сказать, что способ мышления там отличается от "привычного": надо считать на несколько ходов вперед, прокручивая в голове, как будет вестись логический вывод. При этом активное использование cut (отсечения вариантов) очень напоминает goto-программирование. Для императивных вещей "тактика" проще и требует меньших мыслительных затрат. При этом "стратегии" сильно разнятся. Я бы сказала, что там в большей степени идет поиск и формулировка правил-гипотез, а в императивном и ООП частенько сразу шашки наголо и давай рубать.

Но человек так устроен, что почти ко всему адаптируется. Как шахматисты уровня выше мастера многие вещи просто не считают, а "чувствуют" (на подсознательном уровне; отсекая, где надо детально считать, а где и так видно), так и в случае с Прологом (предполагаю, что это справедливо и по отношению к Haskell, Erlang и т.п.) - с годами и опытом приходит "интуиция". Но даже мастером спорта по шахматам за один год стать трудновато. 3-5 лет надо попахать.

Ответ на »сообщение 2255« (Снегурочка)
___________________________

Уроки Erlang.

А вот какие выводы сделал Бьерн Декер (2000) из опыта создания EriPascal и Erlang, а также о роли и месте ФП:
A most remarkable observation is that while hardware developments go ahead at great speed (noteMoore’s law) basic programming still remains at about the same level
of technology as 30 years ago. Tremendous efforts are made on various methodolgies
and the visions in industry seem to be in the direction of “software factories” where the work can be reduced to mere “coding”.

Today when large numbers of people are available with university degrees in Computer Science there should be a greater emphasis on better technologies. Functional programming has been around just as long and difficult problems such as hot code loading and distributed programming can only reasonably be handled through better technology such as Erlang provides.

Was it worth the effort? Did the Erlang development produce the desired technical result and did it serve the needs for product development? The answer must be “yes”
on both accounts. Erlang has also shown that:
* Functional programming can be used for very large applications involving large project teams.
* Functional programming can be used for industrial real time embedded applications.
* Functional programming gives significant commercial advantages in raising design productivity and enabling rapid developments through prototypes and successive increments.
<...>
Erlang provides many examples of the difficulty of technology introduction, notably:
* Erlang and functional programming in general both enable and require a new way of working with much more interactivity. The top-down waterfall methodologies were designed to handle conventional programming languages. Technology and methodology both have to be changed.
* Marketing a new programming language and a new way of working requires a huge effort and investment. Twice Erlang Systems has tried marketing Erlang with limited resources and with meager results. Sun has probably spent a fortune on Java but that has paid back in the form of increased demand for computer equipment. Ericsson is a telecommunications company and selling Erlang would not sell more switches.
* Open source combined with a good support organisation provided the real breakthrough.

Еще одно вполне очевидное его замечание относительно ФП: It might well be that it is difficult to introduce functional programming into an old and established company culture. This, on the other hand, leaves the field wide open for exploitation by new companies free from tradition.

Вот интересно что (касательно ФЯ и ЛП)
http://www.progz.ru/forum/index.php?s=96b1dd25f538ec13c2b6b2420b8e97d2&showforum=10
это форум по Прологу (в конце концов что ФЯ, что ЛЯ можно рассматривать в контексте сложности абстракции и матподготовки как примерно одно и тоже  ). Если поанализировать его хоть немного, то видно с каким скрипом решаются даже "простые" задачи студентами. Я потому то и взял в кавычки слово "простые", что при внешней простоте (часто таки в одну две три строчки) работает далеко не так очевидно все.
Также нисколько не сомневаюсь, что есть люди мастерски этим владеющие например модератор этого форума Винитарх. Но вот беда - Винитархов немного! В том то и дело, что рассуждения многих форумча как-то игнорируют различие между "есть такой мужик голова" и "среднестатистический разработчик" (набежит две сотни...). Я не питаю иллюзии, что человек работающий в одиночесвте ка-то хорошо уяснит себе проблемы разработки в коллективе, но все же призываю таких одиночек при расуждении понимать эту разницу.