На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Ivan
Всего в теме 4531 сообщение
Ссылки по теме "Оберон" и "Компонентный паскаль"
Отслеживать это обсуждение 
- Free Pascal, Oberon, BlackBox
- Разработка препроцессора gpre для delphi\freepascal.
- Component Pascal и среда разработки BlackBox
- FreePascal: реальная альтернатива или OpenSource — блажь?
| № 1681 08-10-2004 13:17 |   |
Ответ на »сообщение 1679« (Сергей Губанов)
___________________________
как правильно перевести на русский язык слово pattern. в переводе книги Мартина Фаулера "Архитектура корпоративных программных приложений" используют словосочетание "типовое решение".
А почему просто "образец" не подходит?
| № 1680 08-10-2004 13:14 | |
| № 1679 08-10-2004 11:50 | |
Кстати, тут как-то обсуждалось как правильно перевести на русский язык слово pattern. Так вот, в переводе книги Мартина Фаулера "Архитектура корпоративных программных приложений" переводчики используют словосочетание "типовое решение".
| № 1678 08-10-2004 10:19 | |
| № 1677 07-10-2004 11:18 | |
| № 1676 04-10-2004 17:56 | |
Ответ на »сообщение 1675« ()
___________________________
То есть, запись а ля:
SYSTEM.MOVE(srcPtr, dstPtr, byteCount);
будет просто ошибкой (SYSTEM.MOVE требует целые на месте адресов мест источника и назначения), а запись:
SYSTEM.MOVE(SYSTEM.ADR(srcPtr), SYSTEM.ADR(dstPtr), byteCount);
возьмет в качестве аргументов адреса самих переменных указателей... что черевато минимум трапом по голове... :о) Хотя, вам может повести, если byteCount <= 4, но єто немного не то, что мі озидали... :о)))
| № 1675 04-10-2004 17:50 | |
Совет
Между прочим (по причине применения СМ в АО), заметьте, что, если имеем:
VAR p: POINTER TO ARRAY OF x;
То таки уже имейте себе в виду, что:
SYSTEM.VAL(LONGINT, p) # SYSTEM.ADR(p[0])
и, если вы в С писали:
memcpy(dst_ptr, src_ptr, bytes_count);
то в АО мы пишем:
IMPORT S := SYSTEM;
...
S.MOVE(S.ADR(dstPtr^), S.ADR(srcPtr^), bytesCount);
или
S.MOVE(S.ADR(dstPtr[0]), S.ADR(srcPtr[0]), bytesCount);
Как по мне, так предпочтительней второй вариант записи...
С уважением
| № 1674 29-09-2004 09:59 | |
Ответ на »сообщение 1673« (Max Belugin)
Степанов
The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
Но ведь, очевидно, что он имеет ввиду "программирование в малом", в то время как интерфейсы используются для "программирования на больших масштабах". Компоненты взаимодействуют друг с другом по определенным интерфейсам, а все интересные алгоритмы упрятаны внутри компонентов. Это две разных вселенных. Им нечего делить друг с другом.
| № 1673 28-09-2004 19:05 | |
Ответ на »сообщение 1672« ()
___________________________
Степанов со товарищи - все в сторону чисто объектов капают
http://www.stlport.org/resources/StepanovUSA.html
--------------------------------------------------
Question:
I think STL and Generic Programming mark a definite departure from the common C++ programming style, which I find is almost completely derived from SmallTalk. Do you agree?
Answer:
Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper's Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
| № 1672 28-09-2004 17:56 | |
Ответ на »сообщение 1671« (Сергей Губанов)
___________________________
Кстати, ваши мысли "перекликаются" со словами Щилдта(???) в книга по С++ в главе об STL. Он там недоумевает-восхищается, что вот, мол, Степанов со товарищи - все в сторону чисто объектов капают, а у них STL вокруг обобщённых "алгоритмов"... и такие результаты! :о) Интересно, что кстати, наиболее интересные результаты именно "на стыке" получаются (использование "объектов-функций"). Здесь как раз акцент на функциональности (смысл функции сам по себе), подкреплённой способностью сохранять "промежуточные результаты" (поля в "объектах"). А сам процесс "вычислений" - над "коллекциями" со стандартизированных доступом к структуре.
надо ещё думать.
в субботу за пивом родилась мысля вообще параметризировать куски уже исполняющегося двоичного кода по типам входных переменных. навроде того, что тип (класс) - и есть набор процедур "модернизации" кода уже откомпилированных функций...
Хотя, может и маразм... :о)
С уважением
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
