Архив форума

В результате встречи с Виртом решил таки более плотно пообщаться со средой разработки BlackBox и языком Oberon. На сколько я понимаю, идея проекта Информатика-21 в рамках которой к ним приезжал Вирт была в повсеместном внедрении BB Oberon в процесс обучения школьников и студентов. Будучи неравнодушным к этому процессу, я и решил исследовать вопрос...

На мой взгляд, система просто не приспособлена для жизни.
Чтобы на ней преподавать что-то, надо провести достаточно большую работу, чтобы привести его в приемлемое состояние.

Кроме того, BlackBox содержит ряд идеологических ошибок, несовместимых со зрелой жизнью.

В общем, моё мнение - внедрение BlackBox в процесс обучения даст больше хлопот и вреда, чем пользы.

Если это представляет интерес, я могу написать более развёрнуто о том, что же мне не понравилось.

Тема представляет интерес.
Нельзя ли более подробную аргументацию

В личном общении насчет Вирта, Оберона и вопросов преподавания прозвучали мысли о том, что важно уменьшать дистанцию между тем, что преподается, и тем, что студентам пригодится. В свете этой идеи также прозвучали следующие слова о том, что в наименьшей степени полезным является изучение языков Виртовской линейки, поскольку даже приводимый часто в качестве примера Delphi является лишь исключением подтверждающим правило; к тому же это уже не Pascal.

Однако с такими словами сложно согласиться. А именно.

Кто может сказать, что именно студентам пригодится? Я могу утверждать, что будучи хорошо подкованным в технологическом плане (то есть если я буду знать основные алгоритмы, типовые схемы решений, тривиальные и не очень тривиальные приемы программирования), то чтобы переключиться на другой язык программирования мне понадобится 2-3 недели максимум. Причем никакие лекции уже будут не нужны, а нужна будет лишь обычная
справочная документация, чтобы понять, какими средствами я располагаю в конкретном языке. А дальше я могу совершенно спокойно применять приемы объектного проектирования и программирования при работе на ассемблере. Или учитывать тонкости ассемблерной оптимизации команд, работая на языке высокого уровня.
Вывод: учить нужно не языку, а приемам. И вот этому, к сожалению, учат мало...

Я не собираюсь утверждать, что виртовская линейка языков - это то, чем нужно немедленно воспользоваться. Более того, я не думаю, что
произойдет переход в индустриальном программировании на тот же Оберон (языки Java и C# в этом плане более перспективны в силу их
раскрученности). Но...

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

2. Нет смысла спорить, что многие моменты в Паскале и Обероне гораздо проще для понимания с точки зрения преподавания. Приведу несколько примеров.

a) Вот как объяснить начинающему программисту, что такое this в
методе класса? Это непросто. Приходится объяснять, что метод работает в контексте класса, и что this - это ссылка на этот класс.
Неочевидно. И многие не понимают суть при таком подходе. Дальше, как объяснить тому, кто начинает писать на C++, что унарная операция += может быть описана как член класса, но что бинарная операция + должна находиться вне контекста класса? Ведь по сути делаем одно и то же!

А в Обероне нет слова this. Просто нет. Вместо этого ссылка на контекст вызова метода передается одним из аргументов! Что вполне
естественно (и, собственно, после ассемблирования кода на Java, C#,
C++ ссылка this как раз и передается в метод как один из параметров). И объяснять проще! Заодно снимается названный выше вопрос про операции + и +=.

b) Как объяснить разницу между public классом и вложенным классом в Java? Ведь по идее, в обоих случаях идет речь о классе. Тогда в чем
разница? А разница есть, если посмотреть на механизм модулей того же Оберона (сам это осознал, лишь слушая Вирта)! Ведь модули в
терминологии Оберона - это в точности public классы Java. Только
оформленные более разумным образом (наружу выставляется лишь
интерфейс, без навязывания скелета реализации). А все остальные
случаи использования классов в Java - это фактически расширяемые типы в Обероне. Так что понятия оказываются разведены более четко, более грамотно.

Думаю, что можно привести еще целую серию примеров, демонстрирующих сильную идеологическую сторону языковой модели, разработанной Виртом. Но факт остается фактом, просто слепо использовать Оберон, считая, что это панацея от всех бед, нельзя. Нужно, чтобы люди в течение периода обучения успели попробовать работать и на Java, и на C, и на C++ (замечу, что названные три языка имеют принципиальные отличия в технике программирования), но вот базовые принципы программирования может быть по прежнему имеет смысл изучать, используя либо какой-то язык из Виртовской линейки, либо даже какой-то свой язык для описания алгоритмов.

Главное не путать изучение языков с обучением программированию!
Видимо все беды именно из-за того, что эти понятия всё время путаются.
Вот, у нас, например, (матмех УрГУ, МТ) было два курса изучения языков: Pascal и C. И при этом нас никто фактически и не пытался учить собственно программировать... (Возможно потому, что преподаватели в общем-то и сами толком не умели, хотя это всего лишь моё предположение)

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

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

Я, пожалуй, поясню, почему я ринулся изучать Oberon. Я искренне считаю, что ни язык Си, ни Си++ не очень хорошо подходят для обучения _искусству_ программирования.

Очень часто приходится отвлекаться от процесса обучения на всякую
шелуху, которая свойственна Си. Например, очень много дурацких ошибок компилятор не вылавливает во время компиляции и даже во время исполнения.
Например:

1.
int fact(int n) {
return n = 0 ? 1 : n*fact(n-1); // не работат! почему? ;)
}

2.
long a;
scanf("%d", a); // скомпилируется, выполнится, но сработает неправильно

3.
#define MIN(a, b) a < b ? a : b
int a = MIN(1000, 2+2)*2; // чему равно а? 8 или 6?

И список можно продолжать! Те, кто активно пишет на Си, наверное это сделают лучше меня.

Приходится постоянно отвлекаться на то, чтобы пояснить тот или иной баг... Какое уж тут искусство к чёрту!?! Это вовсе не похоже на
нормальный процесс обучения. Миллион оговорок, исключений, поправок превращают процесс обучения искусству создания алгоритмов и программ в процесс изучения языка Си. (который, дай бог, скоро вымрет...)

Я не протестую против изучения языка Си, но я против, чтобы этот курс назывался "программирование". То есть перед тем, как читать курс "Язык Си", надо прочитать курс "Программирование".

И, честно говоря, я просто не знаю, какой язык лучше подходит для обучения именно программированию.
Pascal устарел.
Delphi - платная, да и просто не преспособленная для целей обучения.
FreePascal - не знаю... может быть...
Java - может быть. Но это чисто объектно-ориентиованный язык. А начинать учить, наверное, всё таки нужно с простого структурного программирования... Хотя может быть это лишь стереотип.

Вот я и решил посмотреть на Oberon. К сложалению он тоже далёк от идеала...

1. Основная идеология - вынести всё, что только можно из самого языка в библиотеки. Идеология хорошая: язык становится простым для освоения. Однако она работает только в том случае, если вместе с языком идёт достаточно большой набор стандартных библиотек. Примеры: Java, .NET Framework, дистрибутивы языка Perl, и прочие.
Однако БлэкВокс исповедует минимализм и в области библиотек. В результате, если в Java я ищу нужный класс по документации, то в обероне я вынужден его писать сам.
В свете преподавания Оберона: фактически я не смог найти нормальной библиотеки для работы с вводом/выводом. Самое приемлемое, что я нашёл - это библиотека, написанная в рамках проекта Информатика-21 для создания решений олимпиадных задач. Но предлагаемые этой библиотекой средства просто недостаточны.

Значит перед тем, как начинать преподавать Оберон, чтобы потом не сесть в лужу с вопросом "а как на Обероне сделать то-то?", придётся написать некоторое количество своих библиотек.

2. Избыточный синтаксис языка. Язык предполагает некоторое количество бюрократии, которое призвано сделать программу более читаемой. Например, в конце процедур и модулей, после слова END надо ещё раз написать имя процедуры (или модуля, соотвеитственно).

Однако у меня есть несколько контрдоводов против этой бюрократии.
а) сложнее менять однажды написанный код. А между прочим, переименование методов и переменных - далеко не самая редкая операция в промышленном программировании...
б) просто по-человечески раздражает следовать этой бюрократии!!!
в) это при том, что хорошо написанные программы сами по себе должны быть разделены на сравнительно маленькие процедурки, влезающие на экран. Так что лишняя бюракратия тут понятности нисколько не добавляет, но при этом см пункт б).
г) хорошая среда разработки (с помощью выделением шрифтом или всплывающими подсказками) может куда лучше и удобнее показать к какой же процедуре относиться закрывающий END.
д) да и лишняя проверка при компиляции - вообще говоря замедление компиляции.

3. Ключевые слова должны печататься большими буквами. По задумке создателей, это должно их выделять из остального кода. Кроме того, исключать коллизии пользовательских идентификаторов с вводящимися в язык новыми ключевыми словами.
На практике же нынче принято чтобы среда разработки сама выделяла ключевые слова подсветкой синтаксиса (жирным шрифтом и тп). Коллизии крайне редки, и их можно легко исправить с помощью банальных автоматических рефакторингов (если среда разработки позволяет, а БлэкБокс, конечно же, в отличие от Eclipse, VisualStudio и прочих промышленных вещей, НЕ позволяет...). То есть реально, это просто сильное уменьшение комфорта при наборе программы! А уменьшение комфорта на пустом месте - это не есть хорошее решение...

4. Подсветка синтаксиса. Поскольку ключевые слова итак пишутся большими буквами, то создатели БлэкБокса решили не утруждать себя созданием автоматической подстветки синтаксиса. В результате все программы выглядят плоско (в смысле цвета).

Но они (создатели) пошли ещё дальше! Они сделали из среды разработки какое-то подобие Ворда, позволив программисту самому раскрашивать свой код в разные цвета!!! Ну это просто идеологическая ошибка! Например:
Я раскрашу свой код в ядовито зелёный цвет, а поскольку у моего коллеги на зелёный - аллергия, то он перекрасит его в красный. Я обижусь на него и мы подерёмся. И всё из-за чего? ;-)

5. Формат файлов с исходниками бинарный. Поскольку вместе с исходником надо как-то хранить и то, в какие цвета он раскрашен, то исходник перестаёт быть просто текстовым файлом. Исходник в Блэкбоксе - это бинарный файл, который не очень приятно класть в различные системы контроля версий, и ещё менее приятно сравнивать исходники различных версий. А это в промышленности довольно частая операция. Удобства мы лишились и тут... И всё ради чего? ;-)

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

7. В среде БлэкБокс нет поддержки автоматических рефакторингов. Автоматический рефакториг можно мыслить себе как некоторую трансформацию кода, без изменения его функциональности. Примеры: переименование переменной (и всех ссылок на неё), подпрограммы, типа; выделение подпрограммы из указанного участка кода и пр. В хороших средах разработки, всё это можно делать автоматически - нажал кнопку - переменная переименовалась. Это на самом деле порождает более смелое отношение к процессу написания кода, когда сначала можно не задумываться как назвать подпрограмму, потому что знаешь, что всегда сможешь очень дёшево её переименовать. Собственно, часто понимание как её назвать приходит только после того, как подпрограмма написана.

Так вот, хорошо бы учить детей именно такому, смелому отношению к коду. Блэкбокс этого сделать не сможет.


8. Ненаглядность и неочевидность базовых понятий... Наверное, понятия "объект", "класс", "метод", "событие" и проч. появились не случайно. Мне вот ими мыслить удобнее, чем какими-то там типами, тем более расширяемыми... Мне кажется, что просто объектам и классам учить легче, чем расширяемым типам. И с описанной переменной this у меня никогда вопрособ не было: Это ж МЕТОД ОБЪЕКТА, а не какая-то там процедура в каком-то там контексте. Если это метод обекта, то способ добраться из кода метода до этого объекта просто обязан быть :-)

9. Камень в сторону Pascal-синтаксиса. Как ни крути, а нынче в моде Си-подобный синтаксис... (Java, C#, Perl, JavaScript, ...). Поэтому есть смысл и обучать детей на языке, синтаксис которого не сильно отличным от того, что им придётся использовать на работе. В этом смысле, Оберон в пролёте.

10. Отсутствие в языке механизма обработки исключений (exception-ов). Сам Вирт будучи в УрГУ открытым текстом признался: "В крупних приложениях обработка исключений могла бы быть полезной, сделав программы более простыми и понятными". Тут Оберон в пролёте.

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

Я люблю язык C++, Паша не любит. Позволю себе сказать нескольких слов.

Язык C++ офигенно старый, в нем есть все, чтобы писать практически в любом стиле. От ассемблерного до функционального.

Обучать языку C++ невозможно. Можно и нужно обучать его подмножеству.1. Получишь предупреждение компилятора
2. Хороший стиль диктует писать такое только так return (0 == n) ? ...;Используй объектный/потоковый std::cin, std::out.Не используй макросы вообще. Есть безопасные шаблоны.

PS В языке LISP шаблоны _еще_ опаснее. Только все традиционно заносят это в плюс.Я писал. При хорошем стиле это очень защищенный от таких ошибок язык.Нас с тобой переживет, поспорим? ;) Cobol и тот живой ;)

И вообще. Развитию C++ посвящено огромное количество времени талантливых людей, который язык любят и зарабатывают на нем деньги. Они уже обо всем думали ;) Честно-честно. У него есть неразрешимые недостатки. Но они, IMHO, лежат в промышленной сфере.

Именно так!

Только ещё надо тренировать силу воли, чтобы из подмножества ни дай бог не вылазить :)

А ещё не надо читать то, что другие написали - они-то наверняка другим подмножеством пользуются - не понять их ни черта.

Собственно, возможно поэтому велосипедостроение в С++ и развито так сильно. Только получаются велосипеды, как правило без сидения, и, как ты сам недавно метко подметил, порождают такие велосипеды как правило по большей части гемморой ;)

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

А недостаток такой есть. Но он в сфере промышленного.

Хорошо, убедил. Действительно, ограничимся лишь обучением :-)

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

И, в любом случае, придётся много "бить по рукам", чтобы детки за подмножество не вылазили. А детки бывают любознательными, они книжки всякие читатют, в чужие исходники опять же подглядывают, а там ведь их непременно плохому научат! :-)

По просьбе М.О.Асанова попытаюсь прокомментировать некоторые высказывания. Но на все сразу ответить не могу из-за загруженности.

Общее замечание:
некий американский аспирант китайского происхождения во время беседы в столовке ЦЕРНа ехидно любопытствовал у меня, мол, почему студенты-россияне первым делом всегда сразу профессору кричет "Нет!". Мол, мы, китайцы, всегда сначала выслушаем до конца, запишем, вопросы зададим, а уж потом дома для себя решим ...

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

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

Вообще библиотеки (framework) Оберонов и Блэкбокса по духу достаточно сильно отличаются от привычных для устаревших языков. Это ставит в тупик начинающих, но мОлодежь почему-то не делает вывод, что она, возможно, чего-то не понимает...

Мне не нравятся, когда в технической беседе сходу переходят на личности. Это уязвляет лишь перешедшего.

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

Что касается меня, то Оберон и его среды мне не показались пригодными ни для спортивного ни коммерческого программирования. И я в силу, видимо, своей ограниченности и закомплексованности не вижу в этом языке/среде вообще ничего качественно нового и хорошего.

Если буду не прав, посыплю голову пеплом.

Мои утверждения основаны на фактах: человек не нашел модуль Stores, один из основных в системе, -- и без малейших колебаний "полил" всю работу многих безусловно квалифицированных людей за много лет -- что это, как не безапелляционная самоуверенность? Может ли такое, публично сделанное суждение как-то понравиться этим людям?

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

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

А факты таковы, что в реальных проектах (несколько тысяч строк, серьезная математика, сильно динамические структуры данных размером в несколько гигабайт) была зарегистрирована производительность программирования на Блэкбоксе на порядок превосходящая конкуренцию на С++ (три месяца вместо 3х лет работы крутого С++-программера), при эффективности получившихся программ тоже в 8 раз выше.

На другом реалистическом тесте (полторы тысячи строк численного кода в специальной задаче минимизации в области с dim~2K и соотв. кол-вом ограничений) MS Visual C++ сумел сравняться по эффективности с изоморфным кодом Блэкбокса (в котором, кстати, никогда не отключаются run-time проверки выхода за границы массива и "отладочная" информация) только после включения всех оптимизаций (и надо слышать, как после этого трещит диск при компиляции -- тогда как Блэкбокс компилирует практически мгновенно).

Стабильность и надежность компилятора и среды -- просто легендарна. Ни С++, ни Ява, ни Дельфи близко не стоят с Оберонами по этому параметру. Но такие вещи невозможно увидеть, не имея соотв. опыта. А убедить словами тех, кто не хочет ни в чем убеждаться, -- невозможно.

Все эти "реальные" примеры ни в чём не убеждают.

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

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

Я лично вижу десятки проблем, наличие каждой из которых выбрасывает oberon из списка претендентов на используемый/промышленный язык.

1. Нет библиотек. Контрольный вопрос: есть ORM-маппер?
2. Несовместимость с системами контроля версий. Что дает невозможным командную разработку. Или вы свою написали?
3. Нет достойной IDE. Контрольные вопросы: рефакторинг, интеграция с CVS, полноценный поиск и навигация по коду?
4. В VM Oberon уже появилась компактификация памяти и возвращение ее в OS? Или за годы работы высоквалифицированных специалистов до этого так и не дошли руки?
5. Как обстоят дело с кроссплатформенностью? Как обстоят дела с пресловутой проприетарностью?
6. Есть ли reflection и code emit?
7. Есть ли развитая оконная библиотека?
8. Просто смешной по размерам community языка. К слову, если посмотреть кто-что в Рунете обсуждает касательно Oberon'а, то это будет сплошной флейм. Особенно этим отличается ваша "домашняя" конфа на delphikingdom. Один флейм! Англоязычные ресурсы тоже не высвечивают особой активности профессионалов.
9. Exception'ы. С call-stackэом. Срок диагностирования и устранения проблем в java на порядок меньше C++. Уж как практик вам говорю.

Не хватает? Объясните нам, чьи очи залеплены java, c#, c++, которые мы любим, на которых мы реализуем наши замыслы, с помощью которых мы, в конце концов пишем профессиональные системы и зарабатываем деньги, чем лучше Oberon? Ни одного реального аргумента мною услышано не было.

PS Кстати, как я понял, вы две тысячи строк кода писали три месяца. Да... Язык позволяет писать код с сумасшедшей производительностью. ;)

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

Теперь по делу. За свою неспособность найти Stores прошу прощения. Был действительно неправ. До него всего два клика с главной странички помощи. Так что эту часть пункта моего обвинения можно снять.
То есть пункт то всё ещё остался - библиотек по всей видимости сильно меньше, чем в java, например (Logger? ORM-mapper? ASN-1-Parser? список можно продолжать и продолжать...), но достаточная библиотека ввода/вывода есть - это факт! :-)

Но вот что с остальными пунктами-то? Коментарии были видимо только по самому уязвимому месту моего "нападения". Значит ли это, что на остальные пункты ответить нечем? Если есть, то буду благодарен даже за ссылку на соответсвтущий FAQ или чего-нибудь вроде этого...

Далее. В запредельную эффективность Оберона я просто не верю. Ибо за любым выигрышем в производительности должно что-то стоять. Что стоит за обероном - не понятно. Совершенно понятно почему он компилируется быстрее (в этом Оберон, конечно же очень хорош!), а вот почему выполняется быстрее - не понятно.
Многое зависит от архитектуры и от способов использования средств языка. То есть, например, я с лёгкостью смогу писать на обероне код, в 10-ки раз более медленный, чем на java! :-) Но это же не значит, что java делает оберон по производительности!
Тут, видимо, можно говорить лишь о том, что язык может несколько способствовать выработки более эффективной архитектуры программ, которая естественно, приводит к более эффективным программам. Так что по всей видимости ваши нападки на неэффективность С++ нужно интерпретировать так: "С++ слишком запутанный язык, чтобы чётко понимать насколько эфективен тот или иной кусок кода." или что-то вроде того. С этим можно соглашаться, а можно спорить, но ведь это совсем другая постановка вопроса! Зачем вы выдаёте одно за другое? Мух за котлеты? ;-)

PS.
На всякий случай отмечу: на вас тут никто не нападает. Тут всего лишь обсуждаются минусы Оберона. Вы, как человек много более компетентный в вопросах касающихся Оберона, могли бы попробовать объяснить почему перечисленные минусы таковыми не являются, изменив наше мнение в сторону более верного :-) Но почему-то вместо этого, вы решили устроить обмен колкостями...
Так вот, Ваша враждебная манера ведения разговора, безусловно нисколько не способствует изменению мнения об Оберонах в лучшую сторону. Если Вы даже этого не понимаете, то сложно верить в то, что Вы хорошо всё понимаете в таких сложных вопросах, как разработка программного обеспечения и обучение детей программированию...

Ещё раз. Чтобы опустить бессмысленный спор :-)

Если Вы, не касаясь наших бренных личностей, просто дадите ответы на мои "минусы Оберона", а потом ответы на вопросы Дена, то Вы дадите нам много больше много более полезной информации, чем если будете продолжать обвинять меня (заслуженно! - признаю) в том, что я не нашёл Stores.

Заранее спасибо!

Павел, сожалею, что не наставил смайликов в свое первое сообщение. Думаю, мы могли бы договориться. Но я слишком занят, а bandwidth клавы/домашнего модема недостаточно широк.

Просто попробуйте не требовать доказательств, а сами еще покликать мышкой (то же и Den'у). Be open-minded.
Я вам ответил не на самый уязвимый пункт, а на такой, где абсолютно нет места для двусмысленностей и нет необходимости апеллировать к долговременным эффектам, которых мОлодежь не может ощутить на своей шкуре. Попробуйте экстраполировать.

Кстати, Стругацких я в свое время читал ровно с таким же наивным энтуазизмом, как и вы. Попробуйте себе представить, что вы -- это я 30 лет назад. Или что я -- это вы через 30 лет ;-)

Den'у: мозг человека окончательно созревает в физиологическом смысле где-то к 25 годам. Это медицинский факт. А знание -- сила. Я просто пытаюсь вам важные знания передать. То, что вы встаете от этого на рога -- как раз и есть доказательство незрелости вашего "профессионализма".
Постарайтесь быть самокритичнее -- против природы не попрешь, себе дороже будет.

Я никого не собираюсь с помощью этого форума убеждать переходить на Блэкбокс. Тем более крутых любителей с etc. И в последнюю очередь -- "спортивных программистов". Просто скажу, что лабух в кабаке или на похоронах, зарабатывающий обычно больше бабла за сеанс, чем первая скрипка из филармонии -- тоже музыкант-профессионал, как и скрипач.

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

К тому же учтем, сколько было вбухано в маркетинг java.

У Оберонов в целом и Блэкбокса в частности уже есть ниши, причем быстро растущие -- и причем там, где c/c++/java etc. не катят никак -- ни с библиотеками, ни с тулзовинами.

ATN: Не понял, почему вы ставите в кавычки эпитет "реальные" применительно к моим задачам -- вы же их не видели? Они у меня уж точно не олимпиадные. Кстати, первая из них переводит на новую ступень уровень искусства целую индустрию теор-физических расчетов (слышали про квантовую теорию поля?). Вторая решает 30-летнюю задачу, еще в 98-м году объявленную нерешаемой. С этим алгоритмом будут обрабатывать пентабайты данных с 6-миллиардного ускорителя LHC в CERN на протяжении лет 20. Ну и на всех других ускорителях тоже.

Кстати, сложность в этих задачах не в том, чтобы набить код (какие же у вас, Den, представления о программировании; кстати, я печатаю вслепую на обоих языках 200 знаков в минуту). Мои конкуренты-фанаты с++ до сих пор пытаются менять организацию своих программ, по пути борясь с segviol'ами и утечками памяти, чтобы понять, где они теряют фактор 8 в производительности. Это ответ Павлу насчет производительности. (Интересно, имели ли вы все дело с большими и сложными и сильно-динамическими структурами данных, для которых нужно организовывать custom виртуальную память.)

Кстати, Den, вы опять доказали свою несерьезность -- в PS. Разобраться с этим оставляю вам в качестве домашнего упражнения.

Нет времени -- еще кратко:

Насчет систем контроля версий процитирую многоопытного профессионала: "компонентный подход во многом снимает остроту необходимости контроля версий."

Переносимость: Классический Оберон был перенесен на 6 платформ за 2 года, с безупречным качеством. Блэкбокс для линукса в стадии альфы.

reflection: в Блэкбоксе это модуль Meta.

То, что c java проще работать, чем с с++, неудивительно: она содрана с Оберона (они изучили компилятор Оберона в исходниках не то в 91, не то в 93 г.).

Кстати, JIT-компилятор для Borland's Java VM был написан на Компонентном Паскале в Блэкбоксе. Напишете полноценный компилятор любого Оберона на java? Это мой контрольный вопрос Den'у.

И еще: подавляющее большинство ваших тулзовин либо предназначены для решения ятрогенных или вторичных проблем. Либо просто служат украшением "профессионалам". Они увешиваются ими так же, как девочки -- рюшечками и бантиками. Девочки только с возрастом понимают, что настоящая элегантность основана на минимализме. Так же и "профессионалы".

На сегодня все, пока.

Это не реальные задачи. Это узкоспециализированные задачи, с которыми работают единицы людей. Не замечал, чтобы в каждой школе строили свой коллайдер.

Реальная задача - нарисовать окошко с пользовательским интерфейсом. Сто таких окошек, за день, командой. Реальная задача - веб-приложение, работающее 24/7 в течение 5 лет. И каждый год приложение развивает новый разработчик, без ущерба функциональности и стабильности.

Подобные задачи - 99% современного программирования. Но я понимаю, что они Вам не интересны. Это работа для наивных энтузиастов с несозревшим мозгом.

Нелишним было бы сослаться на автора, чтобы он мог аргументировать.
Аргументы таковы: факультет имеет возможность обучать студента в течении трех лет, поскольку на четвертом и пятом курсах студент уже вне нашего контроля. Имея таким образом жесткое ограничение по времени, нельзя допускать лишний и бесполезный материал к рассмотрению, поскольку фирмы-разработчики судят по нашему уровню исходя из уровня студентов-четверокурсников, которые к ним приходят.Откуда такая уверенность?Что определяет надежность платформы? Почему имеет смысл писать трансляторы именно для этого языка? Почему бы не предложить придумать язык самим?Необходимость в this, parent и так далее возникает только при наличии неоднозначности с именами. Вопросы с операторами действительно требуют сложного рассмотрения, однако таким образом мы платим за богатство языка.Прежде, чем рассматривать объектно-ориентированное программирование неплохо бы познакомить людей с моделью ER. Тогда все сразу встанет на свои места.

Слив засчитан

Так вот. Саша Клепинин, Ден и я в общем-то как раз и есть представители фирм-разработчиков. И, на сколько я понимаю, мы в один голос говорим, что учить надо не конкретным (быстроустаревающим) технологиям, а базовым знаниям и умениям! То есть тратить на изучение языка минимум, а на изучение искусства программирования - оставшийся максимум.

Какие тут ещё могут быть вопросы ala "Откуда уверенность?" ?!?

Я перед своим высказыванием выдержал паузу в надежде, что автор сам поместит свое сообщение, прозвучавшее в рассылке, сюда в форум. А суть, надеюсь, не исказил и себе эти слова не приписал.А почему мы теряем контроль над студентами 4-5 курсов? Может быть просто читаемые курсы не выглядят интересными?Из личного опыта. В процессе алгоритмизации я оперирую не понятиями конкретного языка, а некоторыми сущностями более высокого уровня. И лишь потом думаю о том, как выразить эти сущности средствами конкретного языка. Сам язык, кстати, можно выбирать, исходя из особенностей конкретной модели.Например, наличие неоднозначностей в трактовке тех или иных языковых конструкций, что приводит к тому, что разные компиляторы трактуют одну и ту же конструкцию по-разному. В Обероне, благодаря простоте языка, это, насколько понимаю, просто невозможно.А почему нет? Он простой и реально существующий. Прекрасная возможность познакомиться с тем, как пишутся трансляторы. Прекрасная возможность сравнить свою реализацию с другими имеющимися. Не поручусь за других, но мне бы это было интересно.Так надо придумывать! Это хорошо и правильно! Но прежде чем придумывать новый язык, нужно осознать возможные сложности на уже имеющемся примере.Вот с именами как раз проблем обычно не возникает. Сложно обычно объяснить то, что код работает в контексте класса. То есть существует еще некая неявная сущность, которая влияет на то, как трактуется вроде бы локальная переменная в зависимости от места вызова.А зачем платить, когда можно этого не делать? Я ведь лишь обратил внимание на то, что не всегда тот код, который оформляется как методы, уместно оформлять именно таким способом. А в языках типа Java написание методов навязывается самим языком. Даже если реально код методом быть не должен.Вот не побоюсь признаться, что не курсе, что знаком с моделью ER (как-то ни с чем у меня эта аббревиатура не ассоциируется). Но тем не менее объектно-ориентированным программированием и проектированием владею. Так в чем суть предложения?

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

Чтобы внести в этот тред хоть толику конкретности, могу предложить переписать на C++ вашу легендарную oberon-программу из 2000 строчек. Потом посравниваем. Дайте мне шанс почувствовать прелесть oberon'а. Конфиденциальность ваших исходных кодов гарантирую ;) Я вообще испытываю слабость к вычислительным методам в физике ;) Очень интересно. Заодно и узнаю, что такое сильно-динамические структуры данных.

Не буду сейчас комментировать слова Федора Васильевича, хотя меня тоже несколько покоробил выбранный стиль общения (сам лишь определенным усилием удержался от немедленного ответа в форум). Но удивляет другое: почему-то каждый раз при упоминании Оберона дискуссия принимает форму безудержного обсуждения вопроса "какой язык круче?" с плавным переходом на личности типа "а ты кто такой?". И вот сдается мне, что выяснять "какой язык круче" совершенно бесполезно. Это как сравнивать русский и английский языки и до хрипоты пытаться убедить англичанина, что он говорит на плохом языке.

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

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

Вот в этом, на мой взгляд та суть, на которую стоит обращать внимание. Оберон может иметь (и безусловно имеет) массу достоинств. Столь же безусловно он имеет и недостатки. Но это конкретный язык. Использовать его или нет - зависит от задачи (как и в случае выбора любого другого языка). Что-то не заметили сходу в конкретном языке, не вникли в его суть, не смогли разобраться - это еще не повод сказать, что язык плохой. Врочем, это и не повод утверждать, что те, кто пытались разобраться с языком, не смогли этого сделать в силу своей бездарности. Так что предлагается дискуссию перевести в более конструктивное русло.

Гм... может быть я покажусь глупым, но я таки поспорю :roll:

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

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

Плюсы и минусы
Технологий существует на всете превеликое множество. Если начать все их встраивать в язык, то язык, надо думать, лопнет. Поэтому поддержка языка в кристальной чичтоте кажется разумным и полезным решением. Можно пытаться поддерживать балланс между сложностью языка и количеством встроенных в него технологий, встраивая лишь некоторые, самые-самые нужные технологии. По этому пути вроде как собирается пойти MS. Это видно по её экспериментальным разработкам Linq и Comega.

С другой стороны, введение поддержки sql и xml в сам язык может принести огромную пользу в области качества ПО, так как многие sophisticated ошибки (опечатка в sql-запросе, например), теперь смогут разруливаться прямо на этапе компиляции. Что есть безусловнейшее хорошо!

Другой пример: generics. Хоть они и несут значительное усложнение языка, но зато также переводят ряд ошибок из run-time в compile-time. Кроме того, если generics внедрены в язык "глубоко" (то есть как в C# 2.0, а не как в Java 1.5), то они ещё и дают значительную оптимизацию программ (для просвещённых: оптимизация достигается за счёт отсутствия boxing/unboxing, для базовых типов).

Так что является ли подобное развитие (распухание / засорение / ...) языка добром или злом - вопрос открытый! Не всё тут так однозначно как может показаться...

Предыдущий пост мой!

Я поступаю точно также. Вообще, я вдруг осознал, что программирование - это запись своих мыслей на специальном языке. А так как у каждого свой образ мыслей, то и языки нравятся разные. И стили программирования от этого разнятся.
Поэтому я и против того, чтобы заставлять человека строго придерживаться какого-то одного стиля - это насилие над личностью. Мне вот, например, нравятся некоторые опасные конструкции. Я понимаю, что это потенциальная проблема, но радуюсь, когда такая штука приходится к месту.А и не надо этого объяснять. Суть происходящего понятна на уровне абстракции ООП. А уж как это реализовано технически - не всегда и не всем нужно знать. Так же как мало кому пригодится знание того, как конкретный компилятор реализует exception-ы в C++. Они просто работают.На мой взгляд, это всё очень субъективно. Всегда можно придумать обоснование, почему этот кусок кода должен быть методом. И всегда можно с этим обоснованием не согласиться.
Что касается возможности писать и так, и так, то ведь такая возможность была в C/C++. И от неё уходят, поскольку это множит сущности и добавляет бардака.

SQL вообще враждебная штука ;) Подходит, чтобы быстренько что-то вытянуть из БД прямо в том или ином DB Explorer'е, зато совершенно не подходит, когда схема получения объектов гибкая.

Пусть кинет в меня камень тот, кто не писал:

.. where (1 = 1) ...

;)

SQL must die, короче ;) Удивительно даже, что авторы ORM-надстроек так неохотно вводят объектные механизмы запросов.

Зато SQL, пожалуй, единственный распространенный неимперативный язык. И отсюда многие его беды, обусовленные угадыванием схемы выполнеиня.

PS Так, делюсь наболевшим ;)

Опять же выскажу мысль, что то на чем и как мы программируем обусловлено тем, что могут спаять наши инженеры.

Не могли бы спаять ничего кроме машины Тьюринга - писали бы на BrainFuck (вот, кстати, простой язык ;) и компилятор можно просто отличный написать ;) )

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

Научатся скоро помещать тысячи ядер в один кристалл, вот тогда будем флеймить, что лучше C++ с явными thread'ами, или какой-нибудь Threadable C++.

Научатся делать квантовый сопроцессор - появятся совсем другие языки.

PS Остапа понесло ;)

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

И раз уж такой поклеп пошел:
Den'у: Рассказанная мной история с аспирантом-китайцем -- исторический факт. Утверждение о безапелляционной самоуверенности я обосновал.

(Вот еще, если мало было: было заявлено, что "Система просто неприспособлена для жизни" -- это о системе, на которой:
расчитаны фазированные решетки для истребителя Еврофайтер -- код 1М строк (BAE SYSTEMS);
сделана АСУ крупнейшего в мире каскада ГЭС на Амазноке (Alstom Power);
написан JIT компилятор для Borland's Java VM;
вот еще http://web.archive.org/web/19970227054908/www.oberon.ch/denia/index.html ...)

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

И убежден, что это ваша (от ATN до billg) общая главная проблема -- несусветная гордыня (кстати, смертный грех в христианстве, да и в других религиях осуждается). Именно она вам "залепляет глаза" и мешает видеть очевидные вещи -- а это просто опасно -- и просто по жизни, и профессионально.

Билл Гейтс тоже вон Интернет чуть не профукал, и Оберон (в отличие от Гослинга) вовремя не изучил, теперь вынужден догонять, и еще неизвестно, что из этой истории выйдет. Его гордыня -- ровно той же природы, что и ваша.

И это важнее, чем мелочевка насчет синтаксиса и т.п. Поэтому я с этого и начал -- и посчитал своим долгом как преподавателя вас, еще далеко не безнадежную мОлодежь, предупредить. Что и сделал -- для ясности открытым текстом из-за недостатка времени.

А вы (все вместе) дали вполне достаточно подтверждений моему диагнозу. И не нравится вам (вон что мне приписал А.Клепинин) то, что этот диагноз противоречит вашему само-мнению (см. возражения ATN). И от этого имеет место классический когнитивный диссонанс:
"Доктор плохой" (с) Смертельно больной.
И снова повторю: изучайте психологию.

Леве Плинеру: Вы что же, единственный в большом городе классический университет превращаете в трехгодичное профтехучилище для "фирм-разработчиков"?! Что творится-то, что творится... А еще обижаются...

ATN:Опять: откуда вы знаете сколько??
Не единицы, а тысячи (которые, кстати, учат несчетное число студентов в сотнях университетов по всему миру).
Во-вторых, вы забыли умножить на число таких задач. И это число -- большое.По-моему, это вообще не задача. Конечно, я смотрю с точки зрения Блэкбокса.Про АСУ для ГЭС см. выше. Там тоже 24/7 и много лет. А турбина жахнется -- мало не покажется (в отличие от вашего веб-приложения).

Вот еще:
Швейцарское федеральное траспортное управление устанавливает по всей Швейцарии штучки, в которых наряду с радарами и антеннами, сидит управляющий ими комп с осью XO/2 и соотв. софтом -- все полностью написанно на Обероне-2. Это тоже 24/7, умноженное на O(1000). И это, в отличие от ваших веб-приложений, hard real time.

Кстати, у команды XO/2 года 3 назад случилась возможность провести количественное исследование числа багов в большой системе на Обероне по сравнению с аналогичной по всем параметрам (включая квалификацию разработчиков, объем кода и т.п.) системе, написанной на Ц. Их оценка: плотность багов в 16 раз меньше на Обероне. См. доклад R.Brega на http://cern.ch/oberon.day. (К сожалению, на текст ссылки у меня нет, но где-то было доложено и опубликовано.)
16 раз -- это безоговорочно много.А у нас студенты с аспирантами в проекты не приходят/уходят -- и тут вы Америки не открыли.
Тут-то как раз Обероны с 16-30 страничными описаниями конкурентов не имеют. Люди через 3 дня начинают продуктивно работать. Без ущерба.Откуда статистика такая закидонская??

А вот Майкрософт в июле прошлого года опубликовали другие числа: они оценили число программистов-"непрофессионалов" (это которые вроде меня): их, оказывается, раза в 3 больше, чем профессионалов. С тех пор MS пытается эту рыночную нишу "окучить" -- линейку продуктов выпустили.

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

К счастью, с Оберонами именно на реальных задачаз и можно сосредоточиться -- а не идти на поклон к "крутым программерам", чтобы потом наблюдать segviol'ы под байки о крутизне С++ (у нас в ЦЕРНе таких программеров тоже мешками -- всех уже до потери пульса задолбали своей крутизной; от того и здесь открытым текстом выступаю: потому что вправду задолбали -- и все время слышишь одно и то же, одно и то же...).

Еще Den'у: код пришлю, для пытливой мОлодежи не жалко, если конкурентам не сдадите :-)
Киньте адрес на info21 at inr.ac.ru и дайте несколько дней -- нужно долечить простуду после Великого Турне, уж больно тяжел труд синхронного переводчика.

См. доклад С.Свердлова http://www.inr.ac.ru/~info21/texts/2005-06-27-MGU/szsverdlov.pdf

Боюсь, что это не так. В среде студентов и зачастую в среде выпускников считается важным получать хорошую зарплату, многие начинают работать уже на третьем курсе. Конечно мы можем игнорировать этот факт.По моим ощущениям, основу матмеховских курсов (Циско не в счет) составляет не рассмотрение языка, а как раз изучение алгоритмов. Многие возразят, что в ЯТП/ВМП очень много внимания уделяется именно языку. Я возражу, что мы стараемся выработать навык мыслить алгоритмически, а у многих он отсутствует совсем.То есть все-таки речь идет не о надежности платформы, а о надежности языка. Тогда вопрос снят: c/c++ - самые ужасные языки на свете. Однако изучив c++ можно начинать учить вообще любой язык.Значит так и запишем: Оберон рассматривается как один из многих языков.Вот ты сразу начинаешь вести к тому, как это все реализовано. А можно заходить с другой стороны.Не допускаю возможности сравнения здесь C++ и Java. Определять операторы не-как-методы класса возникает необходимость как правило только для не-своих классов.Разница между наследованием и включением определяется тогда, когда появляется связь "является" (is-a relation) в модели entity-relation. Здесь же можно объяснить, почему можно множественно наследовать только чисто-абстрактные классы C++, то есть интерфейсы, поскольку наследование решает еще и число языковые задачи - доступ к protected и перегрузка.

Известно, что важность библиотек преувеличена в соответсвии с общей мифологизированностью "программирования" (причина чего -- в плохом образовании).

Существует немало реальных примеров, когда люди, достаточно грамотные или мотивированные тяжелыми реальными задачами, оценив какой-нить Оберон, решали, что написать пару (а иногда даже пару сотен) библиотечных модулей под свои задачи (для чего тоже, конечно, нужна добротная квалификация), in the long term, дешевле и эффективнее, чем всю жизнь отлавливать опечатки в логических сравнениях в if и т.п.

Тем более, что библиотеки обычно можно спокойно использовать и из того же Блэкбокса, вызывая соотв. dll. Конечно, бывают какие-то особые ситуации. Но это исключения.

Удивительно, что такая тривиальная мысль (просто вызывать dll) никому из профессионалов до сих пор не пришла в голову. Для Павла: в университетском пакете Блэкбокса на эту тему целое сочинение -- в двух кликах мышки.

А.Клепинин писал:Насчет "какой язык круче" -- в другом посте.
Насчет того, чьи заявления породили дискуссию -- прочитайте ветку еще раз, причем хорошо бы сделать усилие и преодолеть подсознательный инстинкт на тему "свой-чужой".

Отвечу насчет "а ты кто такой".
Возьмем пример, где проблема видна немножко более выпукло, чем в программировании.

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

И есть всякие "народные целители". Что у "народных целителей"? Доказано, например, что большинство средств "народной медицины" в лучшем случае просто бесполезны.
И насчет денег: "народные целители" зарабатывают? Зарабатывают. Пользу приносят? Иногда, может быть. А поскольку проверить трудно, то многие невежды верят, что вылечились благодаря целителю.

(Для сравнения: свежие данные Forrester Research: меньше 3% опрошенных компаний проводили оценку бизнес-эффективности внедренных ИТ-систем. При этом прибыли ИТ-компаний резко растут -- "пипл хавает". Ну ясно, любой цы++ будет катить.)

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

Первый его возглас будет типа "Блин, че тут творится-то?! Вы ж народ гробите!"
А ему в ответ, мол, нехорошо на личности-то переходить. Мы ведь тут деньги зарабатываем, профессионалы, мол, народ-то вон как платит.
Предлагаешь какой-то пенициллин? Да не приспособлен он для реальной жизни, для наших припарок -- вон у нас шкафы припарок на все случаи жизни. А у тебя есть шкаф с припарками? То-то.
Да и своих грибков у нас хватает. После наших-то грибков можно любую плесень изучать.
Ну ладно, хрен с тобой, чтобы побыстрее от тебя отделаться, так и запишем: пенициллин рассматривается как одна из многих припарок. (Лёва Плинер/2005-10-13)

Опять скажете, на личности перехожу?

Начну с двух длинных цитат, сравнением которых и займемся, в педагогических целях.

Павел писал:А теперь фрагмент, вызвавший размышления Павла:

Ф.В.Ткачев писал:Господа, вы все время хотите, чтобы беседа имела технический характер без перехода на личности -- и регулярно демонстрируете неспособность хотя бы не перевирать собеседника. Причем перевираете всегда в одну сторону.

Вот контрольные вопросы:

Где сказано про "запредельную" эффективность Оберона?

Говоря "не верю", в ответ на предъявление конкретных примеров: вы утверждаете, что я лгу, не так ли?

Можете предъявить минимально реалистичную программку в 50 строк на Java, которая будет в 10-ки раз эффективнее изоморфной программки на Обероне? (В Блэкбоксе есть удобные средства измерений.)

Почему изложение фактов (в общем-то, и так очевидных любому приличному специалисту) вы называете "нападками на С++"?

Что именно "одно" я выдал за "другое"?!

Что-то трудно представить себе, как Павел сумеет ответить хотя бы на один из этих вопросов, сохранив лицо.

Теперь будем разжевывать.

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

Поясню для других читателей: чудес не бывает, есть естественный предел для эффективности программ, положенный железом. Чистый код, генерируемый Оберонами, довольно хорошо приближается к этому пределу.
Проект Оберон -- единственный случай в истории ИТ, когда при проектировании серьезного языка не только сразу писалась его формальная грамматика, но и сразу писался компилятор -- так что проблемы с эффективностью компиляции устранялись тут же.
Будем сравнивать с процессом "проектирования" цы++?

Так что за эффективностью Оберона стоит в сущности единственная вещь -- компетентность разработчика. Вот и все.

Далее. На неизоморфном коде, в задачах с серьезной математикой, с большими сильно-динамическими структурами данных, задачи считаются на Обероне в 8 раз быстрее, чем на цы++.

(1) Здесь нигде не говорится про изоморфность кода, хотя Павел её, вероятно, предполагает. Видимо, употребленное мной слово "программирование" для данной аудитории является misleading: Ден уже доказывал, что интерпретирует "программирование" как набивку кода.
Слова про "серьезную математику" должны были насторожить учащихся матмеха: не насторожили.
Объясняю: задачу, о которой идет речь, можно сформулировать как нахождение нетривиальных решений в системах однородных линейных уравнений. При этом: коэффициенты -- ряды Лорана по некоторой символьной переменной с рациональными коэффициентами. Системы огромные. Арифметика должна быть точной. В конце ряды Лорана можно оборвать на некоторой степени, но заранее невозможно предсказать, где именно можно оборвать на промежуточных шагах. Кроме того, неизвестные не равны (они соответствуют узлам некоторой многомерной целочисленной решетки): некоторые лучше подходят на роль независимых неизвестных в нетривиальном решении (за неизвестными скрываются сингулярные многомерные интегралы, которые нужно будет отдельно вычислять); но заранее, не глядя на решение, невозможно дать точное предписание на эту тему. Системы генерятся по возрастающей сложности, пока не будет найдено нетривиальное решение. Потом делаются попытки подобрать оптимальный набор независимых переменных.

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

Постановку задачи знал и мой конкурент цыплюсист, и я (соотв. математика придумана в моей кандидатской, опубликована еще в 1981 г.).
Но алгоритмическое решение ("программирование") мы делали независимо.
Результат, как я уже говорил: моя программа решает системы в 8 раз быстрее, чем цыплюсная. Добавлю, что этот фактор растет с ростом сложности систем.

Ясно, что решение таких задач предполагает

1) очень хорошее понимание соотв. математики (не говоря про общую математико-алгоритмическую культуру);

2) экспериментирование. Кстати, первый мой вариант был медленнее цыплюсного на ~20%. Но просто чистка и упрощение алгоритмов после того, как они были реализованы, когда стало возможным иметь перед глазами полную структуру поведения данных, позволила заменить фрагменты, порождающие сортировки, на слияния последовательностей, что и привело к ускорению в 10 раз. Задачи обгонять цыплюсы не ставилось: они сами бы отсохли и отпали на следующем уровне сложности.

По поводу экспериментирования: вспомним, что здесь говорится о сильно-динамических структурах данных -- т.е. в игру вступают (в случае цыплюсов) висячие указатели, утечки памяти и т.п. -- или соответствующие тулзовины и "работа" с ними. Ничего этого нет в Обероне/Компонентном Паскале, нет в принципе, "нет как класса". Это объясняет, почему у меня решение заняло 3 месяца, а у моего конкурента -- 3 года.

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

Выводы.
Во-первых, нужно научиться внимательно читать/слушать -- а не фантазировать под влиянием слов собеседника.
(Кстати для Павла/2005-10-11: для фантазирующих слушателей невозможно никакой доклад построить так, чтобы он у них ни в каком месте не вызвал отторжения. А какие фантазии могут возникнуть у слушателей в разных регионах земного шара, предсказать невозможно.)

Во-вторых, когда вы пытаетесь возражать собеседнику, нужно научиться опираться на точные цитаты собеседника -- а не на свои фантазии.

Так что же, по-вашему, я "одно" выдал за "другое"?

Как вы помните, я попросил Федора Васильевича Ткачева послать мне
исходник нетривиальной Oberon-программы для переписывания на C++.
И действительно получил его в субботу утром. Я искренно ожидал увидеть
на этом живом примере за что любят Oberon. Хотел увидеть, но так и не
смог.

Итак, я потратил потратив 4 часа своей жизни на разбор статьи, программы
и переписывания ее на C++, я получил следующий результат с точки
зрения сухих цифр.

Сразу замечу, что я просто _тупо_ переписал программу на C++,
ничего не меняя в структуре. Также я ничего не оптимизировал. Легкость
переписывания на C++ была необычайная, что говорит о том, что в
программе не использовано каких-либо конструкций не поддерживаемых
C++.

Oberon C++
Строк кода 1670 768
Байт 42649 13692

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

Самое главное:

Время выполнения 100 итераций алгоритма (Celeron 1.3M)

Oberon C++
Время 20830 2633

Пресловутые 8 раз. Причем я отлично знаю, где выгодать еще десятичный
порядок. Если меня поймают на слове - выиграю.

По поводу утечек памяти, на итерации моей реализации алгоритма ни один
байт не утекает.

Итак, какие выводы можно сделать по результатам моей четырехчасовой
работы? Язык C++ позволяет все то, что позволяет Oberon. Язык С++
позволяет писать программы заведомо более эффективные, чем Oberon. С++
исходный код сам по себе не порождает ошибок, он управляем.

Что я заметил в результате работы со связкой Oberon-BlackBox.

1. Увеличивающаяся allocated memory при скролировании по исходнику
вверх-вниз. Скажите, ради справки, как работают на Oberon'е системы
24/7? Они памяти совсем не выделяют, или у них выделение памяти сплошь
статическое?
2. Нулевые средства навигации по коду. Ну-ле-вые. Может быть фанатам Oberon'а стоит
посмотреть, что умеют среды для лабухов? Тот же Eclipse? Если их
после этого не прошибет суровая мужская слеза...
3. Нулевой intellisence. Опять же.
4. Я не смог пережить цветастость BlackBox, перенес сорцы в текстовые
файлы, Colorer умеет правильно подсвечивать Modula-2, лишь после этого
я смог разбираться.
5. Я так и не смог обнаружить в BlackBox интерактивной отладки.
Фатально, кстати. Как надо смотреть, чтобы ее в BlackBox обнаружить?
6. Я не знаю, о какой легендарной стабильности среды может идти речь,
если первая моя попытка залоггировать 100000 real'ов привела к падению
связки среда+программа. Это называется стабильность? Среда после этого
падения отъела 50Mb и ни байта не уступала. Иногда после второго
запуска одного и того же кода я получал "Null dereference", помогал
только перезапуск среды.
7. Просто долгая программа, которая пишет в Log, насмерть повесила
BlackBox и была остановлена только средствами OS. Для ничего не
умеющей среды BlackBox просто крайне нестабилен.
8. Кстати, отчасти отличный прирост производительности объясняется
тем, что я попутно сократил на пустом месте сложность вашего алгоритма
на порядок за счет использования встроенных контейнеров. Почему я не
смог найти встроенных контейнеров в стандартной библиотеке Oberon?
Зачем вы используете связанные списки там, где это совершенно не
нужно? Наверное, потому что C++ плохой язык?
9. Самый важный цикл правка+компиляция+запуск под BlackBox дольше, чем
Microsoft Visual Studio 7.1. Кстати компилируют они с примерно
одинаковой (на глаз) скоростью.

Еще раз повторю, Федор Васильевич, попробуйте, пожалуйста Java с
Eclipse. Я Оберон попробовал.

Если вас достали ваши CERN'овские программисты на C++, попробуйте
нанять "профессионала". Да, это дороже, но каждый должен заниматься
своим делом.

Мдя. Миллиард леммингов ошибаться не могут. Эти люди умеют считать деньги, в большинстве своем. Естественный отбор решает.

А вообще, я просто своими глазами видел, как качественно и количественно меняется бизнес после грамотного внедрения IT-систем.Выходите на рынок. Вас там ждут. Стоимость игры - 1 триллион долларов.Воспользуйтесь, пожалуйста, каким-нибудь ORM-маппером таким образом.

Могу. Не хочу - достало уже.Я имею наглость работать с проектами на два-три-четыре порядка сложнее ваших на C++, Java. Мне убить себя?Вы фантазируете. Хотя Ден действительно считает, что сложность и функциональность хорошо коррелирует с размером исходного кода.


Федор Васильевич, да поймите вы, что шокируют меня домыслы, что Oberon+BlackBox хоть для чего-то хороши. Назовите мне задачу и окажется, что или C# или Java или C++ подходит лучше (а скорее всего каждый из них). Они промышленные и профессиональные. Они продуманные и используемые. Будь Oberon хоть десять раз хорош, BlackBox убог. И убожество его может быть побежден лишь сотнями человеко-лет профессионалов, которых у Oberon сообщества нет.

Хочешь эффективность - юзай C++. Боишься или не хочешь думать о памяти - кури Java.

Павел писал:Павел, пожалуйста, не надо перекладывасть с больной головы. Еще раз вспомните свой первый пост.
Если бы тут просто студенческий базар был, я бы и не пришел. Но к вашим высказываниям отнеслись серьезно.
А этого делать нельзя. Что я и выразил кратко и прямо. Вот и все.
Когда экзаменатор ставит двойку студенту: это переход на личности?
Или вам не нравится, что я встал в позу экзаменатора? Ну так учиться надо, и хорошенько думать, прежде чем публичные заявления делать, "поливая" работу серьезных людей (в том числе, кстати, тьюринговского лауреата; понимаю, что вам по неопытности трудно представить себе интеллектуальный уровень, который такое лауреатство предполагает, но можно начать с простого уважения; или с такого рассуждения: вы насколько старше и насколько умнее первоклассника? а Вирт насколько вас старше? или думаете, что люди после 25 лет только глупеют?).

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

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

Что же получается -- мы вынуждены платить сложностью рассмотрения за возможность генерировать ошибки? Я лично не хочу за это платить. Никак и ничем.

А.Клепинин писал:Это не мудрость и не объективность, а просто бессилие. Или (скорее всего) подсознательная уступка друзьям-лоббистам цыплюсов.

Программирование (в широком смысле) -- по сути инженерная деятельность (эффективное создание эффективных решений). И, как таковая, имеет критериями эффективность и качество. Кои, разумеется, не всегда легко измерить. Но иногда можно -- см. мое сообщение от 2005-10-13 насчет фактора 16.

Даже естественные языки можно и нужно и полезно сравнивать.
Тем более нужно сравнивать искусственные языки-инструменты -- особенно поучительно сравнивать фантазм Страуструпа (1000 стр.) с уникально точным дизайном Вирта (16 стр).
Я, кстати, переключился на Блэкбокс после 6 лет работы с ц, так что личный опыт сравнить могу легко. Он сильно не в пользу ц в любом варианте.

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

Вот вам еще забавный критерий для сравнения: возьмите изоморфный код на том же ц и Компонентном Паскале, строк 500, и посчитайте, сколько односимвольных опечаток пропустят компиляторы.
Надо ли напоминать, что каждое сравнение == в ц может слишком уж легко, пропуском одного =, превратиться в противнейший баг.

Ден писал:Сначала докажите, что талантливых.
И еще надо разобраться, на чем именно они "зарабатывают деньги": сдается мне, что на невежестве своих менеджеров, а также клиентов, не включающих в свои требования, чтобы системы были реализованы на языках со строгой статической типизацией, гарантирующей подавление количества багов на порядок величины. Кстати, клиенты, которым баги "народных целителей" дорого обходятся, такое требование в заказ вписывают открытым текстом.

Л. Плинер/2005-10-13 писал:Студентов, которые хотят в университете не полноценно учиться (что и без приработка нелегко), а отсиживать до диплома, получая хорошую зарплату -- а потом тряся таким дипломом, претендовать на еще бОльшую -- нужно просто гнать из университета.

Контрольный вопрос: А что делать с профессорами, которые не объясняют это студентам? -- При условии, конечно, что ставится цель иметь качественный университет мирового уровня.

Павел писал:Нет. Это значит только то, что я отвечаю только на то, на что считаю необходимым ответить при том времени, которое имею. Вы ведь слишком легко задаете свои вопросы.

----------
И еще приведу подборку высказываний с данного форума:

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

К идеалу можно стремиться, например, через явно сформулированную и неуклонно проводимую корпоративную политику постепенного исключения небезопасных языков из всех проектов;
а из общих базовых университетских курсов такие языки тем более должны быть исключены. Индустрия только спасибо скажет.ATN, не поленюсь повторить добрый совет: пока вы не забудете, что вы крутой профессионал, вы не начнете им становиться.

Извините за оффтопичность поста. Но очень хочется поставить точки над i.

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

"Перевираете" это, по всей видимости, перчатка в мою сторону. Я мог бы проигнорировать
сей выпад в достойности которого я лично сомневаюсь, но почему-то решил выбрать вариант публичной порки.
Даже не столько потому, что считаю вас недостаточно компетентным человеком в области ЯП, который тем не менее
занимает какой-то там высокий пост, и ничего-из-себя-не-представляющий-я могу с ним достойно по этому поводу поспорить.
Сколько для того, чтобы показать читателям приёмы вашего стиля ведения "диалога", дабы на эти приёмы больше
никто не попадался и, что называется, держали ухо востро и смотрели в корень при разговоре с вами.

Итак, начнём работу над ошибками.

> Где сказано про "запредельную" эффективность Оберона?

В процитированном Вами куска текста напианного вами же. Поясню.

Говориться о некоторых реальных примерах, в которых Oberon даёт выигрыш по параметрам
"скорость разработки" + "скорость выполнения программы" приблизительно на порядок.
"На порядок" - это то, что я назвал "запредельным". Поясню почему я использовал это слово.
Предположим названные вами числа (x12 и x8) относятся именно к языку Оберон
(а не к профессионализму программистов). Допустим я перейду на Оберон.
Тогда я начну писать программы, работающие в 8 раз быстрее за срок в 12 раз меньший.
По логике за это мне должны будут платить как минимум в 12 раз больше!
(И это если они проигнорируют тот факт, что программы стали в 8 раз быстрее)
Прикидывая полученную сумму в уме у меня возникают ассоциации лишь из разряда слов "запредельный", и тп.

Кроме того, словосочетание вырвано из контекста. Строго говоря, я и не утверждал,
что вы говорили про запредельную эффективность Оберона. Но об этом ниже.

А почему вы, собственно, спрашиваете?
Возможно, вы хотите сделать вид, что выставили меня дураком, аппелирующим к тому, о чём вы и не заикались?

>Говоря "не верю", в ответ на предъявление конкретных примеров: вы утверждаете, что я лгу, не так ли?

Нет, не утверждаю. Я стараюсь говорить/писать именно то, что пытаюсь утверждать.
Если бы я утверждал, что вы лжёте, я бы это написал.
Но я сказал лишь, что вы, по всей видимости, путаете и/или смешиваете два понятия:
эффективность компилятора (1) и то, как язык способствует более вбыстрому и эффективному написанию программ (2).
Вы привели некоторые числа и примеры, которые вообще говоря ни о чём не говорят.
И некоторый намёк на это я вам сделал тут:

> я с лёгкостью смогу писать на обероне код, в 10-ки раз более медленный, чем на java!
> Но это же не значит, что java делает оберон по производительности!

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

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

Было бы безупречно, но! Но тот факт, что я вас обвиняю во лжи вы выдумали. Сфантазировали!
Объяснения я привёл.

Ещё раз разберёмся в спорном вопросе. Что может стоять за цифрами x12 и x8?

х12:
1. Человеку платили всё это время деньги и он намерянно затягивал работу.
В этом случае сравнивать те три года с вашими 3 месяцами абсолютно бессмысленно.
2. Человек на протяжении 3х лет занимался далеко не только этой задачей.
Тут тоже сравнение бессмысленно.
3. Человек мог быть менее подкован в теоретическом плане (знать предметную область) и
меньше подготовлен в практическом плане (уметь программирвоать), чем вы.
Тогда это сравнение людей, а не языков.
4. Человек все три года не мог придумать алгоритм решения задачи и лишь под конец третьего года додумался.
Это характеризует скорость мышления этого человека, а вовсе не о свойстве языка, помеченного выше как (2).
5. Человек был вашего уровня знания предметной области и умения программировать,
придумывал правильный алгоритм не дольше вашего, но в процессе реализации всплыли несколько подводных
камней, обход которых занял так много времени на С++, и мало времени на Обероне.
Гм.. учитывая, что С++ позволяет программировать в духе Оберона, это характеризует лишь стиль
программирования, выбранный человеком, и лишь потом (2).
6. Наконец, человек был вашего уровня знания предметной области и умения программировать,
придумывал правильный алгоритм не дольше вашего, но несмотря на это написание заняло
в 12 раз больше чем у вас. Тогда имеет смысл говорить о (2).

Итого, может быть эти числа доказывают (2), а может быть не доказывают ничего.
Обобщенный результат: Эти числа не доказывают ничего.

x8:
1. Человек мог не знать тонкостей выбранного языка, связанных с эффективностью.
В этом случае, числа доказывают (2), но совершенно ничего не говорят об (1).
2. Человек мог придумать неэффективный алгоритм решающий задачу.
Алгоритм - выше всяких языков, поэтому этот вариант просто не говорит нам ничего в свете (1) и (2).
3. Человек мог из каких либо соображений использовать сложные конструкции языка,
потом в них запутаться и выкарапкивался из сложившейся ситуации как мог. В этом случае,
это говорит больше о способностях человека, чем об (2). Об (1) это не говорит ничего.
4. Ваше решение более эфективное, но неверное. Программа работает быстро, почти всегда правильно, но
неверно. Это говорит лишь о ваших качествах и ничего об (1) и (2)
5. И наконец, человек выбрал идеальный алгоритм, написал всё чётко, учтя все тонкости языка,
приводящие к падению производительности, то есть выжал из языка всё, на что тот способен.
Но компилятор создал нечто, работающее в 8 раз медленнее вашего кода на обероне.
Это говорило бы именно об (1)

Итак 1, 3 могут говорить о (2), и лишь 5 может говорить об (1)

По скольку о том, какие варианты имели место быть, вы не сказали, мне пришлось лишь угадывать.
Говоря "не верю", я выражал сомнения по поводу того, что имелся в виду именно 5ый пункт.
Иначе, с вашей стороны было бы несомненно логичнее об этом явно сказать!

Поэтому я решил, что приводя эту статистику, вы имели в виду (2).
(2) - мухи.
(1) - котлеты.
Если вы и не пытались выдать мух за котлеты, то по крайней мере вы их тщательно смешали,
(видимо, чтобы втюрить побольше мух в качестве котлет, но это лишь мои домыслы).

> Здесь нигде не говорится про изоморфность кода, хотя Павел её, вероятно, предполагает.

Как теперь, надеюсь стало очевидно, я пытался предполагать все мыслемые мне варианты.
Так что вы, вероятно, склонны фантазировать.


Далее, смотрим на ваши слова

> Кроме того, сильно подозреваю, что сказалась и общая математическая культура -- точнее, недостаток оной у моего конкурента:

которые означают, что вы сами подозреваете, что человек был не в вашей категории и был менее подкован в теоретическом плане.
То есть сравнивали вы на самом деле себя с ещё кем-то, а не Оберон с С++. Видимо, вы хотели показать таким образом свою крутость?
Или вы хотели выдать свою крутость за крутость языка Оберон?
Прошу прощенья за, возможно, не очень удачное в данном случае, но уже примелькавшееся сравнение, мух за котлеты?

>Можете предъявить минимально реалистичную программку в 50 строк на Java, которая будет в 10-ки раз эффективнее изоморфной программки на Обероне? (В Блэкбоксе есть удобные средства измерений.)

Вы очень непоследовательны. То вы сравниваете с Java, то с C++, каждый раз выбирая более
удачный пример для сравнения. На С++ на сколько я понимаю, пример уже приведён Деном.
Именно поэтому вам нужен пример на Java, а не на С++? Я думаю, что я смогу привести пример на
С# 2.0, работающий быстрее за счёт механизма generics (который, кстати, является усложнением языка,
который так не приветствуется в Обероне).
Думаю, вы сможете сделать это и сами, если разберётесь за счёт чего generics в C# делают полиморфный код быстрее.

> Почему изложение фактов (в общем-то, и так очевидных любому приличному специалисту) вы называете "нападками на С++"?

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

Вне зависимости от моего мнения, мнения профессионалов, мнения народа и самой истины,
то что вы нам привели под личиной фактов, пока они ничего не доказывают,
не претендуют ни на какое другое звание, кроме как "нападки".

Итак, мой ответ: Потому что нападки я склонен называть нападками.

Кроме того тут под фактами, по всеу видимости, вы подразоумеваете уже не свои первоначальные
факты о том как вы в 12 раз быстрее своего конкурента написали в 8 раз более эффективную программу, а
следующие факты:

>Отсюда следует совершенно простая вещь (добавлю, очевидная любому настоящему специалисту,
>к коим, кстати, себя не отношу): С++ настолько сложный язык, что компилятор тоже получается
>очень сложным, и поэтому генерить чистый код сразу, без серьезной оптимизации, невозможно.
>Вот и все. Где здесь нападки? Чему тут можно не верить?

Который, в прочем, остался голословным, но поскольку он звучит более бесспорным,
чем первоначальный, то нападками его назвать сложно. Возможно он даже, как вы и написали,
следует из первоначального факта, но тем не менее из разряда "нападок" его никоим образом
не выводит.

Замена одного факта другим в чистом виде.

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

> Что именно "одно" я выдал за "другое"?!
Как выяснилось, что только не выдали! см выше.

1. (2) выдали за (1). Возможно, "выдали" некорректное с моей стороны выражение.
Правильно говорить "смешали" мух с котлетами. Но от такой замены котлеты на много вкуснее не стали.

2. Свои способности за способности языка. см выше.

3. В процессе диалога одини факты подменились другими фактами - это уже, вообще говоря, и вовсе игра без правил!

Кстати, и тут опять тот же приём, вы хотите сделать вид, что выставили меня лгуном?
Сделать вид, что ничего не подменяли, и тем самым неявно обвинить меня во лжи?
Вы так любите этот приём? Высказать факт, который в контексте обсуждения имеет один смысл,
а потом с лёгкостью сменить смысл на другой и всех "купившихся" обвинить во лжи?

Подытожим.
Тактика ведения боя, применяемая Ф.В.Ткачевым основывается на двух приёмах:
1. Выдать одно за другое.
2. В процессе диалога превратить одно в другое и обвинить собеседников во лжи.

Эти приёмы применяются как отдельно друг от друга, так и в связке,
в которой они работают особенно эффектно.
Кроме того, правда, почти в пределах допустимого используется приём "взять на понт".


Люди, будте бдительны и зрите в корень при беседе с Ф.В.Ткачевым!

PS.
Этот пост написан _лично_ от меня. В нём я представлял исключительно свои мнения.
Поэтому в дальнейшем, уместно говорить, что некий Павел Егоров критиковал г-на Ткачёва,
но абсолютно неуместно подменять "Павел Егоров" на "мат-мех УрГУ" и тому подобные обобщения.
В силу специфики вашего стиля общения вынужден я был обратить на это внимание.

Удивительная синхронность. (см на время 2х предыдущих постов)

Теперь что касается содержания, а не формы.

Ещё раз. Идеи, которые вы излагаете, в принципе не прошли незамеченными. А на мои ошибки указывать не стоит - теряете время - на них уже толково указали другие.

Вашу главную идею все поняли - я мои выводы поспешны, стоит получше приглядеться к языку, нежели это сделал я.

Ну я же потрудился вам прислать. Вам 50 строк жалко? :-) Или не можете? Кстати, вы писали про VM Oberon (2005-10-11). Так в Оберонах обычно нет VM.При чем здесь вы? Я говорил про конкретный проект, и про следующий уровень сложности задач в том проекте. У вас какой-то другой.

Кстати, с чем вы сравниваете? С тем примерчиком, что я вам послал? Так это совсем другой проект.

И неужели на четыре порядка? В 10К раз? 10М строк?
Впрочем, "работать с" может означать что угодно.Зачем же. Мало ли что за деньги приходится делать. Жизнь.
Кстати, опыт показывает, что если есть возможность, то разработать и отладить программу на Обероне, а потом перенести в С++ -- очень эффективно получается. Мне известно по кр. мере несколько таких примеров. Совершенно разных.Нет, не фантазирую. Ваш пост от 2005-10-11.А мне нужно и то, и другое. На фиг мне С++ с Явой, если я могу все в одном Блэкбоксе сделать?!

Плюс мне нужно квантовую теорию поля знать и много чего еще. И доказывать свою крутизну мне не нужно. На фиг тогда я буду время с этими монстрами терять?

Дело не в "боишься или не хочешь думать", а в принципиальной невозможности в важных (в моих задачах) ситуациях обойтись без автоматического управления памятью, если не сваливать независимые модули в одну большую кучу.Ну ладно вам. Хватит заклинаний. Примеры профессионального промышленного использования Блэкбокса я приводил.Это Цыплюсы продуманные???????????????????????????? [для интересующихся: http://www.modulaware.com/mdlt28.htm]
Это Java продуманная???????????????????????????? [для интересующихся: http://www.uclic.ucl.ac.uk/harold/srf/javaspae.html, http://www.softpanorama.org/Lang/java.shtml]

Вы бы, Ден, хоть Бога побоялись.Надо понимать, это месть за Цыплюсы. Ну-ну.

На самом деле Блэкбокс даже немножко сложнее, чем мог бы быть. Но совсем немножко.

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

Почему-то, например, А.Клепинин и Павел с совершенно разумными мыслями про общие курсы вынуждены вести uphill battle.
Причем такое впечатление, что они как бы даже боятся следовать по логике за своими собственными мыслями (моральное давление друзей-цыплюсистов?).

Рискну предложить следующее:
-- поручить Л.Плинеру сосредоточиться на специальном курсе С/С++;
-- А.Клепинин и Павел про общие курсы дело говорят -- надо бы к ним прислушаться;
-- им же (да и всем не до конца закоренелым) пожелать приложить усилия для дальнейшего само-образования, начав с изучения литературы по Оберону. Потому что аналогия с АК-47 и пенициллином для Оберона вполне уместна.

Всем успехов.
Ф.В.Ткачев, член программных комитетов (специализация: образование и промышленные приложения) международных конференций Joint Modular Languages Conference 2003 и 2006 (JMLC'03, JMLC'06).

Короче, если мой конкурент-цыплюсист умнее меня, то Оберон лутше. А если глупее -- то мой выбор Оберона -- рекомендация оному :-)

А тонкости языка программирования я в гробу видал. Не до них. В Обероне, слава Богу, их нет, а мне задачи надо решать. В 12 раз эффективнее, чем конкуренты. Пусть они не верят и причины расследуют. :-)

Павел, будете в Москве, дайте знать. Доболтаем -- за мой счет :-)

Ден, будет любопытно узнать, какие тонкости цыплюсов вы придумаете использовать, чтобы побить мою Компонентно-Паскальную програмку по скорости.

Cheers.

Я ее уже побил. В 8 раз. И могу еще примерно в 10 по ощущениям от раскладки профайлера, избежав ненужных выделений памяти.

Еще раз. Запустите Eclipse, он бесплатен. Посмотрите, подумайте, попробуйте. Вы представления, похоже, не имеете о том, что может уметь среда.Это значит, что этот объем кода и составлет приложение, которое было разработано мною и моей командой (квалификацией которой, кстати, я совсем не доволен) за время меньшее года, которое написано, работает и поддерживается, а также является основой для нашей платформы, на которой уже разрабатывается еще несколько принципиально других приложений.Да, изучил я Оберон. Изучил. По всем позициям без исключения слабее Java. Возразите вы _хоть_ что-нибудь конкртное.

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

Дену:Ага. И в 12 раз быстрее напечатали.

Если уже побили -- пришлите.Избежать ненужных выделений можно и на Ком. Паскале.
Мы говорим про изоморфный код. И не про заморочки с рисованием и с отложенным исполнением, которые в моем примере не убраны.

Дену: про С++ и яву я читал. В опусе про С++ есть спорные мелочи -- но только мелочи.

Еще раз: вы мне предлагаете использовать 1000-страничный монстр + несколькосот-страничный другой монстр, причем в одной задаче -- притом что каждый из них может только одно -- либо эффективный код делать (притом, что надо еще какие-то "тонкости" знать), либо с памятью управляться -- а мне в задаче нужно и то, и другое одновременно.

И эту гору "народной медицины" вы мне предлагаете взамен одного грамотно спроектированного инструмента -- Компонентного Паскаля -- со 30-страничным описанием и лишенного всяких "тонкостей".

Ваше предложение иначе как бредовым невозможно назвать.

Кстати, если понадобится предельная эффективность в каком-нить статическом куске, любой физик знает, что брать нужно фортран 77, а не с++: фортран 77 и проcтой как репа, и оптимизирующие компилеры там на всех платформах такие, что любой с++ отдыхает.

Есть, кстати, и оптимизирующий XDS Oberon. Лет десять уже.

----------------------
Павлу: еще раз о точках над i на свежую голову.

Вы опять приписываете мне "не то". Я ничего не "доказывал". Привел свидетельство из своего опыта (просто ближе).

Очень хорошо, что вы отличаете свидетельство от доказательства. Но это не отменяет того факта, что вполне нетривиальные свидетельства превосходства Оберонов по интегральной эффективности над С++ и Java как в отдельности, так и тем более в комбинации -- такие свидетельства есть, и их отнюдь не мало.

-----
Хочется, чтобы на это раз уже точно было все, пока.

Ушло еще вчера вам в CERN'овский ящик. Если не дошло, могу переслать.Кстати достойного профайлера для Oberon просто нет. Достойным я называю продукты класса JProfiler.Необходимое вам подмножество Java я вам в 30 страниц уложу. "Тонкостей" в процессе работы так обнаружено и не было.Вам ваш Fortran 77 обогнать? Ради спорта? Я просто таких споров десяток видел, обгоняли Fortran 77, как милого.

PS Опять развели. Сейчас будет вам пример на Java в 10 раз быстрее Oberon'а.Используйте Java. Она лучше по _всем_ параметрам.

Добрый день всем!
Извините что не пришел в гости на соревнование школьников, просто так вымотался за неделю что не смог проснуться :( . А в 14 были уже другие дела :(

Искренне жаль, что не смог встретиться лично с г. Виртом и г.Ткачевым, был в командировке в другой стране, иначе бы обязательно зашел :(

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

Итак, мысли
1) Конечно никак не могу одобрить тон дискуссии с переходом на личности. Мне кажется, если бы собеседники априори научились уважать друг друга, это было бы хорошо. Вот смотрите - кто больший профессионал, тот кто 20 лет пишет программы для расчета физических или математических задач, и ему важно уложиться в память, уложиться как можно лучше во время, и программка должна быть по возможности поменьше и побезглючней, ибо через два дня непрерывных расчетов очень обидно узнать про ошибку ? (Я писал такие программы тоже, я в курсе как это делается. Мне даже пришлось научить программу периодически сбрасывать состояние на диск а потом продолжать расчеты с этого места, так как от ресет в руках пьяного дворника никто не застрахован :))
А может профессионал тот, что 10 лет пишет программы, которые должны мало того что работать, так еще интегрироваться с существующей средой, технологиями (windows services, .net, wmi. remoting, ntfs, sql , fax, jsp,jndi, olap, ole db, web services, performance counters... - да что угодно! ) . При этом важна не скорость работы программы, если она разумная (100 или 10 миллисекунд юзер не отличает), а вменяемость кода и его поддержка. То есть через два года любой идиот должен открыть код и смочь добавить новую фичу. Важна также скорость (= стоимость) разработки. И именно для этого подсветка синтаксиса и грамотная архитектура важнее скорости работы компилятора и результирующего кода, как уже писал Павел.

Так кто профи ? Оба. И мне кажется , уж извините за выражение, меряться черти чем (я профессор, а ты кто? Я программист профессиональный, а ты кто ?) просто глупо, как дети, ей богу.

Очень обидно видеть нападки на людей, которых я уважаю и с которыми довелось вместе работать. Да, каждый из них имеет свои недостатки, но это крепкие профи, которые за спиной имеют десятки проектов. Как минимум нападки на Клепинина и Павла (ATN) мне читать противно.

2) Где то я читал мудрую фразу - вот учишь детей программированию, все все понимают. вдруг доходите до темы указатели. Половина народу просто перестает понимать и все! Просто видимо в мозгу нет какой то части , отвечающей за понимание указателей. В этом смысле у меня большой зуб на джаву и сишарп. Ведь в самом то деле указатели есть! Только хитро спрятаны! Мне кажется что без понимания с++ или хотя бы того же классического паскаля нельзя начинать изучать сишарп или джаву, не поймешь что там, в background.

3) На самом деле надо понимать, что есть языки для работы, а есть для изучения. Вот я учил языки в таком порядке - Basic, Pascal, C/C++, assembly language, ну а дальше уже было много чего.. Basiс - это конечно темное прошлое :) НО! Я до сих пор считаю что для обучения программированию не надо начинать с C. Вывод - для обучения и для работы можно (и нужно) использовать разные языки. Ведь если человек способен понять что такое Синглетон на паскале, он наверное и на си поймет? А если не поймет, то нафик такой дурак кому нужен ?
Так что возможно blackbox и хорош для оубчения, надо будет его посмотреть поближе.

4) НО! Я пока не буду использовать blackbox серьезной промышленной задаче, промышленной не в смысле для встроенной в станок системы, а в смысле enterprise. Уж простите, мне нужна нормальная среда с возможностью выхода напрямую на OS API, мне нужно сообщество и форумы для решения моих проблем, мне нужны семинары и мероприятия для обучения себя и встречами с коллегами, мне нужен User Group наконец. Да, монстры рынка нагло гребут со всех деньги, да майкрософт мастдай, но мне чтобы выжить, на до работать на .net или Java потому что сегодня разработчик который сделал гениальный продукт который работает в своем черном ящике (black box:) ) и не интегрируется ни с чем, нафиг никому не нужен! Исключая конечно ситуации, когда задача так прямо и поставлена - сделать черный ящик, который как то внутри себя проработает и докажет теорему Ферма :). Тут спокойно можно выбирать технологию не оглядываясь на окружающий мир.

Мои личные выводы
Если найду время, blackbox посмотрю. Использовать реально не буду, так как работать надо и надо чтобы моя работа была поддерживаема и вменяема.
Возможно, если наконец решусь опять заняться преподаванием за свой счет :) , буду использовать в обучении.

Ден, привет!

Насколько я понял, ты слегка ускорил программу и спользованием контейнеров.

Интересно посмотреть на цифры полностью без оптимизаций, то есть один в один тупо вбитыфй код на С++, такой же, как и на обероне.

P.S. А по эклипсу сам страдаю. Надо же было мелкософтовцам аж в 2005 году с помпой рассказывать про новый фичи в VS, которые я пять лет назад видел в эклипс!

ПриветOK. Вечером попробую.

Прощаю. Блэкбокс не только на OS API выходит, но и на MS Office.

Вот посмотрите, какая снова длинная тирада была (про черный ящик и Ферма), основанная на неявном -- и ошибочном -- предположениях.

Речь шла о том, игрушка или нет Блэкбокс, причем в контексте общих вводных курсов программирования.
И все.
Никто профессиональным программистам ничего не навязывает.

Добрый день.
Наблюдаю дискуссию со стороны уже довольно долго. Хотелось бы высказать ряд мыслей.
-----Для себя, как аксиомы принял следующее мысли: "Все люди разные. И каждый из них достоин уважения. Независимо от заслуг, независимо от ума, независимо от славы, независимо от богатства. Каждый. Наибольшего уважения достоин тот, кто смог реализовать себя. Пусть даже он не самый-самый, и у него нет титулов, но он одолел барьер или прыгает снова и снова, стремясь взять высоту."
Гораздо приятнее сказать человеку: "Слушай, а ведь у тебя есть такие-то сильные стороны и если ты постараешься, то сможешь многое." Можно признать его равным себе, соперником. И как-то глупо говорить: "Да я в твои годы знал атомную физику, а сейчас вообще начальник всех начальников. У меня и сертификат есть." Все люди разные, у каждого свой путь, и все они равны.
-----Очередной набор аксиом: "Абсолютной истины не существует. Истина всегда верна где-то, когда-то и при каких-то условиях. Никакие объекты на сравнимы сами по себе. Для сравнения нужны критерии. Но даже сравнив объекты по ряду критериев мы не можем сравнить сами объекты, так как у них есть несравнимые свойства. А если вспомнить что результат сравнения по критерию - это истина, а абсолютных истин не бывает"
Саша, как мне кажется хотел лишь указать на то, что "самого крутого языка программирования" нет, да и не может быть, как нет и самого совершенного вида существ. И лишь в существовании разных видов морских и сухопутных, хищников и травоядных, в естественном отборе возможна эволюция и приближение к идеалу. И очень огорчительно, что его не поняли и более того обвинили в "бессилии" и "подсознательной уступке друзьям-лоббистам цыплюсов"
-----Надо верить в людей. Они действительно талантливы. Даже если и не все, то что мы теряем веря в них, по сравнению с тем чего лишаемся, когда считаем их бездарями?
-----Люди, и студенты в частности - разные. Каждый ищет в университете что-то свое. Не все из них хотят, да и способны отдать себя чистой науке. И это их право - решать как жить. Неужели они не достойны образования, только потому, что не станут учеными?
Даже тем, кто готов и может двигать вперед науку нужно что-то кушать, нужно где-то жить, да - я, например, согласен отказаться от _больших_ денег в течении 5-10 лет, ради того, чтобы получить как можно больше от университета, но я не могу отказаться от денег вообще. Но почему-то платить мне только за то, что я учусь мне никто не хочет(стипендия вы говорите?).
Возможно не все осознают, когда нужно остановиться, получают все больше и больше, бросают университет. Так надо объяснять студентам именно это, и дать им возможность выбора - не нам решать как лучше для них.
-----Мне кажется, что это не совсем честно - давать совет и не следовать ему. Попробуйте перечитать свои посты и подумать над этим.

Как? Я знаю три пути работы с офисом - VBA, COM. .NET.
Какой путь тут ?
Важные требования
поддержка COM
поддержка web services
поддержка апи вызовов.
ну и до кучи бы поддержку всяких вкусностей, которые есть в net
ACL
WMI
Active Directory services
sockets
эээ куча еще, просто в вголову не все приходит.

Все это есть ?

Pentium IV, 3Ghz HT, 1Gb RAM 533Mhz

BlackBox 1.5 beta (ваш) vs Sun JDK 1.5B5

Oberon

Test begin

Test end:  10000000 4.0001E+7

Run:  38000

Java

C:\My Documents\eclipse\JavaVsOberon>C:\Langs\jre1.5.0_05\bin\java.exe -Xms128M -Xmx1024M ru.denplusplus.ja

vavsoberon.JavaVsOberon

10000000

4.00001E7

Run: 3547

Oberon

MODULE JavaVsOberon;



IMPORT  Log := StdLog, Services;



TYPE

		Item = POINTER TO LIMITED RECORD

			x: REAL

		END;

		

		Position = POINTER TO ARRAY OF LIMITED RECORD

			item : Item;

		END;



PROCEDURE Allocate(n : INTEGER) : Position;

	VAR		

		pos  : Position;

		i    : INTEGER;

		item : Item;

	BEGIN

			NEW(pos, n);

			FOR i := 0 TO n - 1 DO

				NEW(pos[i].item);

			END;

			RETURN pos;

	END Allocate;



PROCEDURE RunBench*;



TYPE



VAR

	i      : INTEGER;

	j      : INTEGER; 

	pos    : Position;

	sum    : REAL;

	pos0   : Position;

	

	begin,

	end  : LONGINT;



BEGIN

	begin := Services.Ticks();

	

	Log.String('Test begin');

	Log.Ln;

	sum := 0.0;

	pos0 := Allocate(10000000);

	FOR i := 0 TO 400000 DO

			pos := Allocate(100);

			FOR j := 0 TO LEN(pos) - 1 DO

				pos[j].item.x := 1.0;

			END;

			FOR j := 0 TO LEN(pos) - 1 DO

				sum := sum + pos[j].item.x;

			END;

	END;	

	Log.String('Test end: ');

	Log.Int(LEN(pos0));

	Log.Real(sum);

	Log.Ln;

	

	end := Services.Ticks();

	Log.String('Run: ');

	Log.Int(end - begin);

	Log.Ln;

	

END RunBench;



END JavaVsOberon.



JavaVsOberon.RunBench

DevDebug.UnloadThis JavaVsOberon

Java

package ru.denplusplus.javavsoberon;



public class JavaVsOberon

{

    private static class Item

    {

        public double x;

    };

    

    private static Item[] Allocate(int n)

    {

        Item[] Result = new Item[n];

        for (int i = 0; i < n; ++i)

            Result[i] = new Item();

        return Result;

    }

    

    public static void main(String[] strings)

    {

        long begin = System.currentTimeMillis();

        

        Item[] pos0 = Allocate(10000000);

        

        double sum = 0.0;

        for (int i = 0; i <= 400000; ++i)

        {        

            Item[] pos = Allocate(100);

            for (int j = 0; j < pos.length; ++j)

                pos[j].x = 1.0;

            for (int j = 0; j < pos.length; ++j)

                sum += pos[j].x;

        }

        System.out.println(pos0.length);

        System.out.println(sum);

        

        long end = System.currentTimeMillis();

        System.out.println("Run: " + (end - begin));        

    }

}

PS Попутно зело углубил свои знания о сборке мусора. И на том спасибо

Жалко что мы отклонились в сторону от оригинальной темы.
Вот скажите, например, что мешало хранить исходный код вместе со всякой лабудой типа раскраски в формате XML?

Вот я работал с системой InstallShield. Ребята не стали выпендриваться, в сделали файл проекта в XML формате.

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

Минус - лишние несколько сотен килобайт на диске, небольшие тормоза при чтении/записи.

Неужели так трудно было сделать ?

Ответа так и не было :(

Ну так щас и диски большие и память есть ....

Надоело уже.

Давайте сконцентрируемся на одном вопросе:

Федор Васильевич, сформулируйте, пожалуйста, преимущества Oberon перед Java. Кроме размера описания (я, кстати, так и не понял, какие конкретно документы вы имеете в виду).

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

PS Вопрос не совсем праздный, моя компания имеет довольно амбициозные планы по программам обучения молодых "профессионалов".

1. Язык прост. Значит он прост для освоения. Значит всякие специалисты, типа физиков, химиков и пр и др могут легко и быстро им овладеть и использовать в своих нуждах.

2. Язык прост. Это значит, что соответствующий плагин к eclipse написать будет проще, чем для той же Java.

3. Язык прост. Поэтому он может использоваться для обучения приёмам программирования, не заморачиваясь особо на всякие идиотские тонкости языка.

4. Язык прост. Поэтому нет необходимости учиться лишь его подмножеству - можно освоить его весь. И при этом всё, что напишут другие будет абсолютно понятно, так так они гарантированно используют то же подмножество языка (совпадающее со всем языком), которое используют и все остальные.

и тд. Неужели фантазии не хватает додумать самим? Зачем эти вопросы? В теории и рекламмных лозунгах, всё должно звучать именно так, на сколько я понимаю.

Ты считаешь, что Java как язык сложнее Oberon?

Мне мой небольшой опыт показал, что сложнее и непродуманнее. Взять хотя бы ту же разделенность объявления и реализации, которую я в минус занесу. Мне вообще Oberon показался нелогичным. Честно-честно.

Кстати, я, может с непривычки, похватал CE на всяких там необязательных точках с запятой перед END'ом. Помнишь про такую нелепую проблему? ;)

Учитывая последние тенденции развития языка - да, сложнее.

Другое дело, что Java мне лично, кажется более гуманистичной. Надо, конечно, собраться с духом и прочитать приведённые тут ссылки про плохости Java, но внутреннее отторжение Оберона у меня было, а внутреннего отторжения Java - нет.

Про CE: где нахватал? Почему проблема нелепая-то? Почему это вообще проблема? :)

Браво, Павел! Слова не мальчика, но мужа :-)

Дену: неужели вы думаете впечатлить меня вашим патологическим JavaVsOberon?
Я просил хотя бы минимально реалистичный пример.

В вашем же любой вменяемый программер сотрет несколько строк и "оптимизирует" его не в 10, а в 400 тысяч раз.

Замените хотя бы Allocate(100) на Allocate( i MOD 100 ).
Программер и такой вариант соптимизирует как за ухом почесать, а что сделает ваш компилятор -- любопытно будет посмотреть.

То же самое про другой тест: вам же mbakirov правильный вопрос задал: че-то вы там соптимизировали, а нужно -- если вы хотите языки сравнивать -- один в один переписать.

Насчет Явы: спросите любого компиляторщика (скажем, в Новосибирске), они вам скажут буквально следующее: в Яве для компиляторщика грабли разложены ровным слоем по всему определению языка.

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

Я немножко жалею, что дал вам рабочие исходники; ваше цепляние к вещам, связанным с промежуточным, рабочим характером кода, не говорит о вашей зрелости.

Насчет университетов.
Откуда только идет чушь, что университеты готовят ученых?!

Задача университетов -- взращивать интеллектуальную элиту, которая умеет:

1) критически мыслить (т.е. владеет систематическими методами анализа в высших формах, которые достигнуты в науках);
2) понимать механизмы, скрытые под поверхностью явлений ("фундаментальные знания");
3) уметь само-обучаться, т.е. взаимодействовать с массивом накопленных знаний.

Все это наиболее полно проявляется в науке. Поэтому те же американские компании наиболее охотно берут людей, не только имеющих PhD, но и прошедших через школу международных исследовательских проектов (post doctoral research).

Те, кто хочет "хорошо зарабатывать" на 4м курсе, пусть берут справку о незаконченном высшем образовании, и не грузят образовательную систему своим присутствием.
Аналогичный механизм credit points существует и в Штатах, например: чтобы взяли, скажем, в полицию, нужно предъявить некоторое количество credit points, примерно эквивалентное 2-3 годам учебы в университете.

Дену. Павел хорошие вещи сказал насчет простоты, но не все. На самом деле он не сказал самого главного:

избыточная сложность = уязвимость.

Это проявляется со временем. Поэтому вам, Ден (21 год?), объективно трудно ощутить это на своей шкуре.
Те, кто как я 25 лет в компутинге, имели возможность набить на этом таких шишек, что как огня избегают свистулек с колокольчиками и оптимизирующих компиляторов.

ИТ отличаются тем, что громоздить избыточную сложность очень легко -- а "пипл хавает".
А чтобы делать хороший (= минималистичный) дизайн -- требуется критическое мышление, направленное не наружу, а внутрь. Такое мышление и создает внутри головы обратную связь, выводящую "систему" на уровень тьюринговского лауреатства. Правда, нужно быть готовым к тому, что премии отнюдь не гарантируются, но на 100% гарантируется, что будете получать по голове "по полной программе для особо одаренных".

Этот пример очень реалистичен. В жизни все именно так и происходит. Инициализация, отъевшая много памяти, а потом большое количество "маленьких" запросов. Именно так.Просили _модельный_ примерСпросите того, спросите сего. У меня нет в Новосибирске знакомых компиляторщиков. Перескажите как-нибудь уж, пожалуйста.Железо у всех одинкаовое. Пока мы работаем не на Oberon OS и не на Oberon PC, все так и будет.Что было сделано для этого. В чем отличие от Java?Таблица виртуальных функций подходит под это определение?

А сборщик мусора?

Отличие от Java?Форум хорошее место для рефлексии? Где я к чему уцепился? К выигрышу в 8 раз?

Еще раз попробую осприть ваш основной тезис на данный момент. Компонентный Паскаль не прост и не ошибкобезопасен, в сравнении с той же Java. Вы не попробовали оспорить что-либо в той дискуссии, которая наметилась у нас с Паша.

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

Знаете, вы тут приводили аналогию. Кажется мне что она имеет место, только надо действующих лиц поменять. Сравнивать надо выпускника ординатуры хорошего медицинского ВУЗа и знахаря со стажем. Очень точная, IMHO аналогия. Я к своим 21ому году имею хорошее образование в области математики и computer science, спортивные успехи, несколько серьезных закрытых проектов, несколько серьезных исследовательских проектов. Я отлично понимаю чему мне надо учиться, где я еще откровенно слаб. Так что аналогия с выпускником ординатуры, IMHO, точная. Вы также имеете замечательное образование, но не совсем в той сфере. У вас есть, без сомнения, опыт знахарства, но он явно "любительский", вы с этим и не спорите.

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

Продолжайте в том же духе...

Обидно то, что вы предлагаете поголовно на детей циркониевые браслетики одеть, прямо в школах.

Затянуло чтение - аж из Турции за кровные еврики внимательно штудировал всю эту увлекательную перепалку.

Поначалу родился афоризм - "Если человек шарлатан, то это надолго".
Но все-таки может быть это несправедливо. Потому что вся переписка проходит в духе "Я тебе про Фому, а ты мне про Ерему". И вот почему - потому, что налицо диалог специалистов из, на самом деле, абсолютно разных областей. Абсолютно! Более далеких друг от друга, чем, ну не знаю, специалисты по полугруппам и вэйвлетам. Там хоть можно сказать, что и то, и другое - математика. Тут же даже такого объединяющего родового понятия не придумать.

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

Народ, мы все друг друга знаем, все отличные проектировщики с большим опытом разработки мощных, промышленных коммерческих приложений. Совершенно ясно, что г-н Ткачев не имеет ни малейшего представления о нашей предметной области, проблематике, повседневных проблемах. Начни я ему рассказывать про "Контур-Экстерн" - он отмахнется. Не увидит в этом ничего сложного!

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

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

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

С этих же позиций, кстати, я считаю что школьников в настоящее время ВООБЩЕ не следует учить программированию. Потому, что удельная доля программистов в общем числе пользователей ПК неизменно падает. Стремительно падает! Сейчас огромна вероятность того, что после школы/после вуза человек попадет на автоматизированное рабочее место, и будет работать, ставить и решать задачи в продвинутой информационной системе. И исчезающе мала вероятность, что он что-то будет программировать. Соответственно, на это и должны мы ориентироваться. Мы должны прививать человеку парадигму мышления, соответствующую жизни в информационном обществе, учить его ставить задачи автоматизированной информационной системе, представлять задачи в нужной для нее форме. Когда-то (в прошлом!) для этого надо было уметь программировать, сейчас - нет. Сейчас надо понимать структуры данных, строить информационную модель задачи и т.д.

На эту тему у меня две статьи есть, но это наверное уже слишком будет оффтопиком. Кому будет интересно, пришлю.

И вообще, если обсужать программу обучения программированию в масштабах страны, то Turbo Pascal куда предпочтительнее Oberon. Oberon, по делу, лишь расширяет модульность и объекто-ориентированность, добавляет сборку мусора. Зато Borland Pascal, так не любимый Виртом, - абсолютно вменяемая, качественная среда, провереная временем, которая работает абсолютно на всех компьютерах. В рамках школьного образования этого языка/компиялтора за глаза хватит, кстати в этих рамках он ничем и не отличаются от Oberon.

От чего ушли, к тому и пришли.

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

Поэтому да, в теории, хорошо бы, чтобы студент все пять или шесть лет только и делал, что учился. А на практике - сейчас и в этой стране такого не бывает. В Германии среднестатистический студент выпускается в 25-26 лет, и без опыта работы. Пардон, но эта крайность тоже не для меня - столько лет из жизни терять...

Это был я.

Рад.
Хорошо пишете. (Зря на меня поклеп, конечно... ну да ладно, как не без этого...)

Пожалуйста, пришлите (info21 ат inr.ac.ru).

Только вот вы пропустили кое-что в перепалке: программистов-непрофессионалов в разы больше, чем профессионалов.
И программируют они сложные вещи:

Компьютинг -- продолжение математики другими средствами.
Тригонометрия, калькулятор, ... списки, объекты ... и т.п.

Спасибо. В чем поклеп-то?Угу. Отправил.Не знаю, как подсчитать, кого больше. Тут опять же взгляды с разных колоколен сталкиваются. По мне, так программистов, работающих в сфере автоматизации бизнес-процессов, гораздо больше, чем программистов, работающих в научной сфере (почему термины "профессионалы" и "непрофессионалы"? профессионалы и те, и те, только области предметные существенно разные).

Чисто эмпирическая прикидка. В городе Екатеринбурге (вроде он так ничем особо не хуже и не лучше других) есть по крайней мере десятка три чисто софтовых фирм: "СКБ Контур", "Наумен", "Восточный Ветер", "УралСистем", "Диас" суть крупнейшие из них, но все знают и множество более мелких фирм (навскидку - "Скип", "Бонус", "Титансофт", "Сплайнекс"... все равно кого-нибудь обижу!) с названиями и без. В пяти вышеуказанных работает по меньшей мере 500 программистов. В остальных - не менее того же количества. Это не считая фрилансерских групп, чистых оффшорщиков. Это не считая веб-студий (тех еще три десятка). Это не считая программистов в фирмах-интеграторах: "Корус", "АСК", "Деком", "Диджитек", "Датакрат", "Датацентр" - а в каждой из них тоже по несколько десятков программистов.
Это не считая фирм, занимающихся 1Сом, где тоже решаются серьезные задачи. Таких фирм еще десятка три, есть среди них весьма крупные - "Эрикос", "Прайм", "Геософт", и программистов, занимающихся промышленной автоматизацией на платформе 1С в городе никак не меньше тысячи. Но и сейчас я еще не посчитал отделы, занимающиееся внедрением и программированием прикладных систем на крупных предприятиях, в отделах АСУ и АИС, в отделах информатизации банков и государственных ведомств...
Не менее 20 неплохих программистов работает в нашем городе в налоговых органах, человек 10 - в Пенсионном фонде. Сотня, не меньше - в ЦУП СвЖД и приближенных к нему структурах.
Не берусь оценить общее число, но точно речь идет о порядке нескольких тысяч программистов, решающих задачи автоматизации бизнес-процессов.

И для всех них важна удобная среда разработки, быстрое рисование презренных формочек и все остальное, вокруг чего мы здесь ломаем копья. И всем им, безусловно, глубоко плевать на компьютинг, тригонометрию, приближенные вычисления и прочие ряды Лорана. Или хотя бы Фурье.

На другую чашу весов кого мы можем положить? Программистов академических институтов? ИММ? ИФМ? И здесь опять же разность колоколен. Я вообще не имею никакого представления об этом мире и никак не могу оценить, сколько их там. Стас Васильев может быть что-нибудь скажет, кто-то еще? Но почему-то мне кажется, что их не тысячи, и вряд ли сотни.

f = N / M

где N - количество всех людей умеющих программировать включая даже тех которые хотябы чуть-чуть умеют программировать и иногда это поделывают, а M - количество людей у которых в трудовой книжке написано: "принят на работу в должности инженер-программист".

Забыл добавить, что N >= M, так что f >= 1.

Вот а почему у вас в логах результат суммирования разный ?
4.0001E7 для BlackBox и
4.00001E7 для Java.

И вот еще для чистоты эксперимента вывод в лог надо вынести за пределы измеряемого времени.

На здоровье.
Хотя бы постоянные повторения про "презренные окошки". Это в мой огород? Напрасно. Я никогда окошки не презирал. Наоборот, считаю большим достоинством оберонообразных сред, что там GUI легко делать (особенно Блэкбокс, где самые нетривильные контролы можно делать с большой легкостью -- правда, учебничка не хватает, факт). В том числе программно генерить и т.п.

Именно это я и имел в виду, когда говорил, что, "окошки -- не проблема".

Далее:Откуда сведения-то? Что ни малейшего? Что отмахнется? Кальянчик покуриваем?

МНе вот совершенно ясно, г-н Волков, что вы не читаете внимательно мои посты. (Откуда и выдумки всякие.) А если бы читали внимательно, то заметили бы ссылку на Microsoft при обсуждении "непрофессионалов". Вас же сей вопрос явно задел? Целое исследование.

Мой источник:

http://news.com.com/2102-1007_3-5248349.html?tag=st.util.print

Story last modified Tue Jun 29 05:45:00 PDT 2004

Microsoft is reaching out to nonprofessional programmers with a revamped line of developer tools, including a free version of its forthcoming SQL Server database.
As expected, the company launched the new Express line of developer tools at its TechEd Europe conference in Amsterdam on Tuesday. The lightweight editions of the tools and database are meant to expand Microsoft's presence among students and hobbyists.

Microsoft said it will release the Express line, which will include stripped-down versions of its Visual Basic, Visual C#, Visual C++ and Visual J++ products, in the first half of next year. At the same time, the company plans to launch a free version of its database software, called SQL Server Express Edition, along with a new product, Visual Web Developer 2005 Express Edition, for building Web sites and Web services.

The tools will be priced in the "tens of dollars," said John Montgomery, director of marketing for Microsoft's developer division. The full versions of Microsoft's tools targeted at professionals can cost nearly $2,000.

Montgomery said Microsoft is targeting a large population of people--the company estimates that there are 18 million nonprofessional programmers, compared with 6 million professionals--who want cheap or free products appropriate for building business applications. Often, nonprofessionals use Web-oriented tools, such as FrontPage or Macromedia Flash, which are suitable for front-end design but not database-driven business applications, he said.

The move to offer low-cost tools is also intended to blunt the growing popularity of open-source .....

Вот еще насчет floating point в Java:

How JAVA's Floating-Point Hurts Everyone Everywhere
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

Автор, между прочим, человек N1 в мире по floaing point.

Это к вопросу об афористичном мышлении.

Смотрите, как вы элегантно подтасовываете суждения, г-н Волков.
Откуда вы знаете, что я "неспециалист" в ИТ-образовании? Просто факты: я лично провел группу школьников с 9 по 11 класс в формате школьных уроков информатики. Двое сейчас на ВМК МГУ, третий в МИФИ на соотв. факультете, еще двое -- на мехмате МГУ. 4й год читаю с/к на физфаке МГУ. 4й год интенсивно общаюсь с преподами всех уровней. И ни один из моих тезисов касательно образования не выдуман из головы, ни один не сделан без "сверки" с другими специалистами.

Но несмотря даже на это, я вот внимательно читаю ваши статьи. Желаю и вам научиться внимательно слушать и слышать оппонентов, не делая разных предположений.

Ден: если человек "фатально" нуждается в интерактивном отладчике при программировании, то никакое его гнутье пальцев не заставит меня признать его грамотным программистом.

Тип

Position = POINTER TO ARRAY OF LIMITED RECORD

	item : Item;

END;

и тип

Item[]

есть принципиально разные вещи.

Типу Item[] соответсвует тип

Items = POINTER TO ARRAY OF Item;

А модификатор LIMITED там вообще не нужен поскольку никакого экспорта не производится.

Вот аналог на C#:

class Program

{

	sealed class Item

	{ 

		public double x;

	}



	static Item[] Allocate (int count)

	{

		Item[] a = new Item[count]; 

		for (int i = 0; i < a.Length; i++)

		{

			a[i] = new Item();

		}

		return a;

	}



	static void Main(string[] args)

	{

		const int N = 1000000;

		const int M = 100;

		const int K = 1000000;



		int t = System.Environment.TickCount;

		Item[] backgroundItems = Allocate(N);

        double sum = 0.0; 

        for (int i = 0; i < K; i++)

        {        

			Item[] a = Allocate(M);

			for (int j = 0; j < a.Length; j++)

			{

				a[j].x = 1.0;

			}

			for (int j = 0; j < a.Length; j++)

			{

				sum += a[j].x;

			}

        } 

        t = System.Environment.TickCount - t;



        System.Console.WriteLine("do not forget about background items (" + backgroundItems[12345].x + ")");

        System.Console.WriteLine("N = " + N);

        System.Console.WriteLine("M = " + M);

        System.Console.WriteLine("K = " + K);

        System.Console.WriteLine("sum = " + sum);

        System.Console.WriteLine("t = " + t);

        System.Console.ReadLine();

	}

}

Изоморфная программа на языке Component Pascal:

MODULE Program;



	IMPORT L := StdLog,  S := Services;

	

	TYPE

		Item = POINTER TO RECORD

			x: REAL

		END;

		

		Items = POINTER TO ARRAY OF Item;

		

	PROCEDURE Allocate (count: INTEGER): Items;

		VAR i: INTEGER; a: Items;

	BEGIN

		NEW(a, count);

		FOR i := 0 TO LEN(a)-1 DO NEW(a[i]) END;

		RETURN a

	END Allocate;

	

	PROCEDURE Main*;

		CONST N = 1000000; M = 100; K = 1000000;

		VAR i, j: INTEGER; a: Items;

			sum: REAL; t: LONGINT;

			backgroundItems: Items;

	BEGIN

		t := S.Ticks();

		backgroundItems := Allocate(N);

		sum := 0.0;

		FOR i := 1 TO K DO

			a := Allocate(M);

			FOR j := 0 TO LEN(a)-1 DO a[j].x := 1.0 END;

			FOR j := 0 TO LEN(a)-1 DO sum := sum + a[j].x END;

		END;

		t := S.Ticks() - t;

		L.String("do not forget about background items ("); 

		L.Real(backgroundItems[12345].x); L.String(")"); L.Ln;

		L.String("N = "); L.Int(N); L.Ln;

		L.String("M = "); L.Int(M); L.Ln;

		L.String("K = "); L.Int(K); L.Ln;

		L.String("sum = "); L.Real(sum); L.Ln;

		L.String("t = "); L.Int(t); L.Ln;

	END Main;

	

END Program.

Эти программы тестируют производительность сборщиков мусора в режиме большого количества N фоновых объектов. В этом режиме сборщик мусора в BlackBox проигрывает сборщикам мусора в .Net и в Java в несколько раз поскольку не ранжирует объекты по поколениям.

Деление объектов по поколениям - есть эвристический алгоритм. Существуют задачи когда это деление бесполезно. В этом случае сборщик мусора в BlackBox, наоборот, будет опережать в несколько раз сборщики мусора в .Net и в Java.

Много всего накопилось.
Наверное, скоро это заставит пожалеть о том, что ввязался в этот спор :-) Что, впрочем, характерно для любого спора.

Ну во-первых: совершенно не понял рассуждения про N, которое больше M. Там явная передержка какая-то. Ведь никто не говорил про M, как про подмножество N, что ж их в этом случае-то сравнивать? А говорили про программистов, занятых в автоматизации бизнес-процессов, и про программистов, занятых вычислениями и иными задачами научного характера. И говорили о том, что первых, видимо, больше, а потому (здесь не очень очевидная связка, спорная сама по себе, но все же...) наверное их "интересы" в большей степени должны учитываться при обучении будущего IT-специалиста. Так что все эти рассуждения считаю примером некорректного ведения диалога.

Во-вторых: про кальян. Из Турции я вернулся, побывал в Екатеринбурге, сейчас в Москве. Ну да неважно. Речь о том, что Вы _действительно_ не имеете представления о нашей проблематике.
Рассказываю: система "Контур-Экстерн" обеспечивает защищенный, юридически значимый электронный документооборот налогоплательщиков и налоговых органов на всей территории России, автоматизируя процесс представления налоговых деклараций через Интернет. Система поддерживает порядка 200 форм налоговой и бухгалтерской отчетности, около 15000 показателей, 5000 контрольных соотношений. Абонентами системы являются порядка 65000 юридических лиц и индивидуальных предпринимателей от Калининграда до Южно-Сахалинска (ежемесячно прибавляется 3000-5000 новых абонентов). Ежеквартальные объемы документооборота достигают двух миллионов электронных документов. Вопрос к человеку, имеющему представление о проблематике разработки систем такого рода: оцените трудозатраты в человеко-годах, объем кода в мегабайтах, количество сотрудников технической поддержки в человеках. Если по хотя бы по двум из этих трех параметров Вы ошибетесь меньше, чем на порядок, я съем свой галстук (шляпы, увы, вышли из моды).

И при чем тут цитата про 18 миллионов "непрофессионалов" и 6 миллионов "профессионалов", мне кажется, из моего поста, и последующей попытки подсчета, ясно, кого я пытался считать.

В-третьих: Про то, "кто тут профессионал в IT-образовании". На мой взгляд, налицо как раз иллюстрация тезиса о том, что "мы все учили понемногу". Тут почти каждый из участников форума может вполне достойными результатами на ниве обучения школьников информатике похвастаться. Но давайте все-таки каждый будет профессионалом в чем-нибудь одном. Кстати, контрольный вопрос: Ваших школьников 9-11 класса Вы на базе Оберона учили?

Ну да ладно. Я в общем и целом сформулировал мысли по поводу обсуждаемой темы, а сильно спорить по этому поводу не очень хочется.

Всего доброго!

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

Речь не об ученых, а, в т.ч. о тех девочках, которые, начав с картинок для web-прожекта, начинают учить javaScript. Плюс профессионалы науки и образования в Академии и МГУ обязаны размышлять не о том, какую книжку порекомендовать девочке сейчас, а что будет через 20 лет (например).
Кстати, мои текущие планы как раз такого порядка: ускоритель LHC/CERN, 2007-2022.
А проблема вполне конкретная: студенты не умеют, в школах не учат. Где учат -- исключения из правила. Вот и все.На базе Компонентного Паскаля.Если будет время и желание, напишите на info21 -- встретимся и поболтаем (пятница для меня хороший день). Пройдемся по вашим текстам.

ЛВ: комментарий к статьям выложен на форум проекта Информатика-21:
http://www.delphikingdom.com/asp/talktopic.asp?ID=339&Order=0&Count=10&pNo=1

А ваш афоризм остается вашим должком.