Hello Olga.
08 Apr 05 22:36, you wrote to me: ON> Fri Apr 08 2005 07:41, Vladimir V. Teplouhov wrote to Olga Nonova:
ON>>> Тут дело даже не столько в "читаемости" скобочек, сколько в пагубной ON>>> торопливости, с какою можно шлепнуть лишнюю скобочку в текст одним
VVT>> или потерять где-нить при копировании и тп...
ON> Совершенно верно! Потерять скобочку, или спутать ее с волосинкой на экране ON> монитора- ничего не стоит.
там отличия более глубокие, ну а скобочки это просто синтаксис. (хотя меня больше читаемость исходников достает - на чем писать мне давно уже пофиг, все-же после чистого асма кое-какие полезные привычки вырабатываются :) ) Hа примере Цшного препроцессора и generic пакетов особенно заметна разница в подходах - все-же в Ц шли со стороны реализации, от асма, что и заметно... Если на уровне простейших ошибок еще в Ц можно прикрутить приличный контроль, то дальше уже идеология не дает.
Плюс ко всему различные допустимые варианты синтаксиса не дают возможности сделать нормальный контроль.
ON>>> нажатием. Вообще, язык Си рассчитан на торопливых, которые в диком
VVT>> на Ц только извращаться хорошо, ну и проги в 10 строчек писать, VVT>> и то только если каждый день этим занимаешься. Только не понятно VVT>> нафига такое количество мелких поделок :)
ON> Вообще-то, Си хорош. Hо исключительно для машин с неймановской ON> архитектурой. А в гарварде- это и не Си вовсе, а какой-то урод ON> недоделанный.
ну в Ц ничего особенного нет, что бы было сильно завязано на архитектуру.
... VVT>> вообще-то в нормальных языках надо писать end if и тп, VVT>> компилятор сам проверит. Еще можно назначить имя блоку, VVT>> тогда после end надо будет писать и его, компилятор тоже VVT>> это проверит.
ON> Это да,- дисциплинирует знатно.
скорее наоборот - то что компилятор все это проверяет не располагает к аккуратности :) Вот несколько дней в отладчике после Ц или асма начинают наводить на некоторые мысли о стиле программирования :) Потому я бы и не рекомендовал Аду начинающим, хотя фактически писать на ней легче чем на бейсике или скриптах. Вот после большого проекта на асме или Ц переучить на Аду самое то, контролировать степень "спелости" объекта можно по количеству комментариев - если достугнут 50% объема программы, то уже можно, если 80, то совсем хорошо :)
... ON> Я хотела бы вернуться к теме JAVA. Вы знаете примеры использования ON> интерпретаторов байт-кода в мелких однокристаллках типа AVR?
не-а, в мелких почему-то не попадалось кроме тех что я уже писал.
ON> Мне представляется, что здесь та-же самая преграда, что и в случае ON> с Си. Это -неподходящая гарвардская архитектура однокристаллок.
не-а, не совсем это. Скорее просто убогость :) То ОЗУ мало, то еще чего...
ON> В самом деле, выходной из-под JAVA-компилятора байт-код содержит ON> ссылки на ячейки памяти безотносительно к ее типу. По-умолчанию- это ON> ОЗУ, как в неймановской архитектуре. Таким образом, системы с
вот кстати для интерпретатора не фон-неймановская архитектура может быть хороша - интерпретатор в ПЗУ программы, сам код в ОЗУ, в общем вполне возможно что в такой системе даже тормозов не будет, все блоки ведь работают параллельно.
пик для этого не пойдет, AVR точно не смотрел, если ОЗУ мало то тоже. В общем проблема скорее в объеме ОЗУ - если туда засунуть код, то сам интерпретатор хорошо будет сидеть в ПЗУ команд. Hо ОЗУ обычно у однокристалок мало.
Тоесть если код на интерпретацию тянуть из другого места, чем ПЗУ команд которое для хранения данных плохо подходит, то может получиться.
ON> виртуальной JAVA машиной, по-видимому, должны обладать RAM большого ON> обьема, куда загружается коды программы в момент первоначальной
так и есть обычно - такие вещи на ARM и тп обычно делают. Хотя теоретически может быть и для однокристалок интересно...
Кстати на opencores.org валялся жаба-процессор на альтере.
ON> загрузки. Все преимущества гарвардской архитектуры летят к черту, ON> а разумность использования однокристаллок оказывается под очень ON> большим вопросом.
Vladimir