1. Заметьте, речь у AVC шла о сравнении Oberona с Java и C#.
О C/C++ даже слова исходно не было - эти языки я вообще упомянул в совершенно другом контексте.

Однако дискуссия конечно свернула в привычную сторону: Oberon vs C/C++.

2. За все 5 лет, что писал под 1С (тот же Visual Basic) проблема неожиданно возникших посреди функции переменных возникли раза два. И решились в течение получаса - при пошаговой отладке. Видимо, значимость проблемы надёжности языка как такового сильно преувеличена.
Как и смертельная ненадёжность языков типа VB вообще, кстати.

3. Как я и ожидал, "неприятный" пример с Label1.Caption/Label1.Name и i2/i3 проигнорировали.
Т.е. что глупость можно написать в самом чудесном и надёжном языке. И что, как мне кажется, будь один язык хоть в 300 раз надёжнее другого, за счёт человечьего фактора  надёжность системы в целом возрастёт, условно скажем, всего-то на четверть.

Ответ на »сообщение 1084« (Илья Ермаков)
___________________________
И по поводу RISC - если не ошибаюсь, то те самые Эльбрусы как раз-таки были близки к RISC...

Ответ на »сообщение 1081« (captain cobalt)
___________________________

Ответ на »сообщение 1079« (Илья Ермаков)
___________________________
Так это как раз-таки проблемы железа - отставание от требуемого уровня близости к выскоуровневым языкам.

Задача железа - быстрее считать и потреблять меньше энергии.
Всё.
Остальное проблемы компилятора.


Вот именно - быстрее считать... Специализированный под языки высокого уровня процессор будет "считать" приложения гораздо быстрее... Есть же примеры LISP- и Smalltalk-процессоров. Естественно, процессор под конкретный язык - на сегодняшний день неудачная идея, но общие механизмы, такие как дескрипторы типов, безопасная работа в общем адресном пространстве и т.п. - чем плохо их начилие на аппаратном уровне?

Ответ на »сообщение 1076« (AVC)
___________________________
"С этого момента подробнее, пожалуйста" (c). :)
IDE -- всего-лишь GUI-вая "нашлепка" над системой программирования.
А что подробнее-то? Компилятор борланда можно запускать хть из IDE, хоть из командной строки. Текст писать хоть в Borland IDE, хоть в Notepade.
Вы хотите сказать, что шансы программиста лопухнуться в чём-нибудь одинаковы?

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

Ответ на »сообщение 1081« (captain cobalt)
___________________________
Микрокод - это аппаратная интерпретация на микропрограмме.
А из тех небольших обрывочных сведений об Эльбрусе-1,2 я понял, что там выполнялась предкомпиляция небольшими блоками...

Ответ на »сообщение 1079« (Илья Ермаков)
___________________________
Так это как раз-таки проблемы железа - отставание от требуемого уровня близости к выскоуровневым языкам.

Задача железа - быстрее считать и потреблять меньше энергии.
Всё.
Остальное проблемы компилятора.

аппаратный JIT, не слабо, да?

Это называется микрокод. Весьма распространён.
Николай Вальтерович предпочитал RISC.
См. процессор Ceres и целевой процессор в "Compiler Construction".

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


По поводу аргумента близости Си к железу... Так это как раз-таки проблемы железа - отставание от требуемого уровня близости к выскоуровневым языкам.

А в чем именно состоит близость Си к железу?
Какие пункты можно перечислить?
(ИМХО, может иметься в виду сишная адресная арифметика, т.к. в остальном синтаксические деревья, порождаемые компилятором Си, не отличаются от синтаксических деревьев для иных языков.)


А если всем фанатам копания в битах сказать, что уже в 70-х годах существовали компьютеры, для которых не было ассемблера ВООБЩЕ? Эльбрус-1, Эльбрус-2, используемые в ПРО и оборонке - автокод Эль-76, высокоуровневый алголоподобный язык, приложения хранятся в байт-коде, который перед выполнением транслируется процессором в микрокоманды - аппаратный JIT, не слабо, да? Для 76-то года? :-) Эти идеи тесно связаны с Ершовым, который в тот период активно общался с Виртом - вот вам и взаимовлияние советской и швейцарской школ :-)


Это действительно не слабо!
Интересно, я как-то в эту сторону не смотрел...


Кто же виноват, что современные Интели и прочая не дотягивают и еще долго не дотянут по своим идеям до этого уровня? Вот и сидит ассемблерная братия, и роется в Сях и иже с ними...

А в каком (ориентировочно) направлении следовало бы "продвигать" архитектуру (под влиянием старой книжки Г.Майерса "Advances in computer architecture" :) )?
Например, известно, что Вирт считает сложные наборы инструкций неудачной идеей:
http://www.rsdn.ru/article/philosophy/virt.xml#E1G
Хотя именно на RISC его знаменитый однопроходный метод компиляции (с delayed code emission) несколько уступает компиляции с отдельной фазой оптимизации: большое число регистров общего назначения оптимальнее распределять с помощью раскраски графа.

Ответ на »сообщение 1078« (AVC)
___________________________
По поводу аргумента близости Си к железу... Так это как раз-таки проблемы железа - отставание от требуемого уровня близости к выскоуровневым языкам.
А если всем фанатам копания в битах сказать, что уже в 70-х годах существовали компьютеры, для которых не было ассемблера ВООБЩЕ? Эльбрус-1, Эльбрус-2, используемые в ПРО и оборонке - автокод Эль-76, высокоуровневый алголоподобный язык, приложения хранятся в байт-коде, который перед выполнением транслируется процессором в микрокоманды - аппаратный JIT, не слабо, да? Для 76-то года? :-) Эти идеи тесно связаны с Ершовым, который в тот период активно общался с Виртом - вот вам и взаимовлияние советской и швейцарской школ :-)

Кто же виноват, что современные Интели и прочая не дотягивают и еще долго не дотянут по своим идеям до этого уровня? Вот и сидит ассемблерная братия, и роется в Сях и иже с ними...

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

Ответ на »сообщение 1075« (Сергей Перовский)
___________________________

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

А вот не надо.

Спросите Главного конструктора Н.В.Чистякова и Нач. отдела системного программирования ПО ИПМ <ГЛОНАСС> А.А.Колташева.

Да и ближе есть эксперт -- AVC.

Если меня возвели в ранг эксперта, то в качестве такового ("халиф на час" :) ) я бы разделил два процитированных утверждения уважаемого Сергея Перовского.
Первое ([i]Си появился, как язык системного программирования[/i]) совершенно бесспорно. Это как бы констатация факта.
Второе оценивается как истинное большинством людей.
Т.к. для нас важно не количество, а качество, то можно выделить:
а) "теоретиков", вроде Таненбаума, противопоставляющего в своей книге "Операционные системы: разработка и реализация" язык Си таким языкам как Паскаль, Модула 3 и Ява;
б) "практиков", вроде Торвальдса, яростно обороняющего Си-шное ядро Линукса даже от посягательств Си++.
Таненбаум квалифицирует Си как "мощный, эффективный и предсказуемый", причем под "предсказуемостью" понимается прежде всего отсутствие в Си сборки мусора (в отличие от Явы; Оберон, естественно, даже не рассматривается).
Могу предположить, что "мощность и эффективность" означают близость к языку ассемблера (наличие битовых операций, возможность произвольного приведения типов, неограниченное использование указателей и знаменитая адресная арифметика).
Популярная характеристика Си как высокоуровневого ассемблера, ИМХО, совершенно верна.
В принципе, готов разбирать каждую особенность Си в отдельности, но заслуживающей внимания особенностью Си (как языка, с точки зрения системного программирования) пока что считаю только отсутствие сборки мусора. :)
Возможно, решающим фактором является популярность Си и его "вездесущность" (сам немного приложил руку :) ).

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

Ответ на »сообщение 1075« (Сергей Перовский)
___________________________

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

А вот не надо.

Спросите Главного конструктора Н.В.Чистякова и Нач. отдела системного программирования ПО ИПМ <ГЛОНАСС> А.А.Колташева.

Да и ближе есть эксперт -- AVC.