Ответ на »сообщение 1073« (гость)
___________________________

ИМХО, редактор влияет (иногда сильно) на удобство кодирования, но не надежность программы.
Один редактор (в широком смысле этого слова - IDE в целом) покажет и неиспользуемые переменные, и недоступный код, и сам подскажет методы. (Builder, Delphi, VS).

Другой (1С к примеру) - только грубые синтаксические ошибки (специфика такая).

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

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

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

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

Меня скорее интересует Ваша точка зрения о чудесных (на мой взгляд -- мифических) возможностях IDE в деле обеспечения надежности.
Вот Вам простой вопрос ("на засыпку" :) ): почему практически в любой IDE для Си/Си++ есть пункт меню "Перестроить все" (Rebuild all)?
Почему недостаточно простого пункта "Собрать проект" (Build/Make)?

Ответ на »сообщение 1074« (гость)
___________________________

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

Ответ на »сообщение 1073« (гость)
___________________________
Заметьте: когда возникли и начали распространяться си, очевидно покупатели тоже считали, что этих возможностей им - выше крыши.
А через девять лет оказалось, что далеко не выше - и надо всякого ещё.

Ответ на »сообщение 1070« (AVC)
___________________________
ИМХО, редактор влияет (иногда сильно) на удобство кодирования, но не надежность программы.
Один редактор (в широком смысле этого слова - IDE в целом) покажет и неиспользуемые переменные, и недоступный код, и сам подскажет методы. (Builder, Delphi, VS).

Другой (1С к примеру) - только грубые синтаксические ошибки (специфика такая).

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

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

Ответ на »сообщение 1071« (Андрей Хохлов)
___________________________
Два реальных примера, когда компилятор [Java] ничем не может помочь:
Отличные примеры! Если программист сам не знает, чего хочет, то никакой язык его не спасёт.

А ещё можно в Delphi вместо
Label1.Caption := s;
присвоить
Labe1.Name := s;
- и тоже с синтаксисом всё в порядке.

А в Обероне вместо переменной i2 можно написать i3 - и тоже не будет ошибки.

Или вы предлагаете делать по отдельному типу для каждой переменной?

Если программист захочет написать неправильно - он это сделает, преодолев все преграды.

По поводу устойчивости к опискам и опечаткам. Два реальных примера, когда компилятор [Java] ничем не может помочь:

//if (blk.equals("CTLS"))
  if (blk.getName().equals("CTLS"))

  StringBuffer text = new StringBuffer();
  ...
//text.append(cmds.get(i));  //cmds - экземпляр Vector<Command>
  text.append(cmds.get(i).text);

Это результат перегрузки ф-ий, если отвлечься от нее, никто не мешает перепутать порядок следования однотипных аргументов следующей процедуры

  PROCEDURE P(X,Y: INTEGER);

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


Роль редактора в обеспечении надежности мне вообще неясна.
...
Прежде всего выяснить, из чего складывается надежность, затем "взвесить" составляющие.
речь ведь шла, насколько я понял, не только о редакторе а о среде программирования в целом
скажем этот уже не раз упоминавшийся пример Свердлова с коллизией имён классов и неймспейсов в С# не пройдёт мимо FxCop'a

Редактор упоминался.
ИМХО, редактор влияет (иногда сильно) на удобство кодирования, но не надежность программы.

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

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

Роль редактора в обеспечении надежности мне вообще неясна.
...
Прежде всего выяснить, из чего складывается надежность, затем "взвесить" составляющие.
речь ведь шла, насколько я понял, не только о редакторе а о среде программирования в целом
скажем этот уже не раз упоминавшийся пример Свердлова с коллизией имён классов и неймспейсов в С# не пройдёт мимо FxCop'a

Ответ на »сообщение 1066« (гость)
___________________________


Я к тому, что "надёжность" средства разработки определяется. образно говоря, на 60% программистом (внимательность, знание инструмента), на 30 - средой (редактором), ну и на 10 - языком. (Цифры, разумеется, образные).

Это действительно интересный вопрос (от чего зависит надежность), хотелось бы немного "помусолить" его. :)
Для начала неплохо бы уточнить, что такое надежность.
Дать хоть какое-то рабочее определение.
Среди оберонщиков распространена точка зрения, что надежность -- это "инварианты, принятые всерьез".
Прежде всего -- инварианты памяти.
Речь идет о безопасности типов (с памятью можно обращаться только в соответствии с типом занимающей ее переменной) и предотвращении ошибок при работе с указателями (сборке мусора).
Мне кажется, что роль языка здесь превышает 10% (и даже 20%, названных Ильей Ермаковым).
Роль редактора в обеспечении надежности мне вообще неясна.

Все это пока ИМХО.
Как бы то ни было, вопрос о надежности интересный, хорошо бы его рассмотреть повнимательнее.
Прежде всего выяснить, из чего складывается надежность, затем "взвесить" составляющие.

Ответ на »сообщение 1066« (гость)
___________________________
По поводу влияния языка на надежность...
Да, все верно - 60% надежности - это человек. И только 10% предотвращает компилятор языка (я думаю, что в количественном отношении не 10%, а побольше, может быть, даже 20%, приходящихся на глупые описки). Но ведь мы ведем речь не просто о роли компилятора языка в поиске ошибок, а о влиянии языка на мышление.
Вель тут своеобразный цикл получается, самоиндукция - язык структурирует определенным образом мышление, поощряет какой-либо стиль проектирования и написания кода, дает ту систему координат, в которой решаем задачи - влияние на мышление неоспоримо. И программист с тем или иным образом заточенным мышлением берется решать задачу. И строит либо надежную и расширяемую систему, либо рухлядь... Вот вам и влияние языка на те самые 60% человеческого фактора... Изучая Оберон вкупе с конкретными примерами систем, на нем написанных, программист "всасывает с молоком" ювелирный стиль проектирования и кодирования. Изучая трухлявый, раздутый язык, человек привыкает писать точно такие же программы. Кроме того, потом он считает эту трухлявость и раздутость обязательным качеством "хорошего" языка, среды и т.п. - и ни о чем другом слышать не хочет...