Ответ на »сообщение 1059« (AVC)
___________________________
Такое чувство, что бы M$ не делала, всегда получается Basic.
5+!!! :)

2) А кто поручится за надёжность самого программиста - самого слабого звена в любом языке. Или первоклассник, первокурсник и кандидат пишут программы на Обероне на одинаковом уровне?

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

Who is Mr Kladov? :)
Автор KOL. http://kolmck.net

В Обероне использование низкоуровневых средств обязательно предполагает явный импорт SYSTEM.
Unsafe тоже указывается явно. :) Но статья интересная.

Но народ требует Си.
Не народ - рынок. Народу в общем-то пофиг.

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

... попытался поучаствовать в этом.
К сожалению, лично у меня не получилось. (И это очень жаль.)

Нужно решать конкретные задачи.

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

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

Что случилось с замечательным сайтом Р.Богатырева www.oberon2005.ru ? :(

Ничего особенного: сколько сайтов, где энтузиазма авторов хватило на полгода... это ж тяжеленное дело, full-time job, тем более с таким "европейским" замахом...

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

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

... попытался поучаствовать в этом.
К сожалению, лично у меня не получилось. (И это очень жаль.)

Нужно решать конкретные задачи.

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

Что случилось с замечательным сайтом Р.Богатырева www.oberon2005.ru ? :(

Ничего особенного: сколько сайтов, где энтузиазма авторов хватило на полгода... это ж тяжеленное дело, full-time job, тем более с таким "европейским" замахом...

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


А что мешает Вам в Обероне использовать безумства адресной арифметики? Средств для этого достаточно...

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

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


Такое чувство, что бы M$ не делала, всегда получается Basic.

Оказывается, в статье примерно так и написано.

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

В чем причина таких прорех и как они могут быть устранены? Дело в том, что в отношении названий пространств имен в Си# не действует общее, признанное еще со времен Алгола-60 правило, согласно которому любой идентификатор в программе не может быть использован без предварительного описания.

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

Ответ на »сообщение 1052« (AVC)
___________________________
Java и C# считаются вполне "надежными" языками
требуется сочетание еще более высокой надежности и эффективности
Это сильно напоминает 19 уровней критичности ошибки в T-SQL.
1) Не совсем представляю, как можно "надёжность 17-го уровня" (йава, шарп) отличить от "надёжности уровня 18бис" (оберон).

Есть любопытная статья Свердлова "Язык программирования Си#: критическая оценка".
http://www.pcweek.ru/?ID=56274
(Там несколько страниц, придется листать.)
Заглянем, к примеру, на страницу "Пространства имен".
http://www.pcweek.ru/?ID=65948
Цитата:


Компилируем заново Print.cs, запускаем, получаем тот же результат (а как же иначе): csc /reference:Hello.dll Print.cs

Print.exe

Привет!

Теперь, ничего не меняя в уже написанном коде Print.cs и Hello.cs, подключаем к трансляции Print.cs еще одну библиотеку (A.dll). В реальной задаче это могло понадобиться, когда программе Print стали нужны какие-то средства, имеющиеся в библиотеке A.dll. Компилируем и запускаем Print: csc /reference:Hello.dll,A.dll Print.cs

Print.exe

2.7182818284590451

Но что это? Вместо “Привета” (ведь мы ничего не меняли в программе, при компиляции по-прежнему упомянули библиотеку Hello.dll, которая оставалась на том же месте) выведено какое-то число (5*)!

Дело в том, что, к нашему несчастью, во вновь подключенной библиотеке оказалось определено пространство имен A, в нем класс B, а в нем — доступное статическое поле C. В реальной ситуации в библиотеке A.dll могли быть определены также и другие классы и пространства имен. В нашем же примере A.dll была получена компиляцией файла A.cs:

// Эта программа хранится в файле A.cs namespace A {

public class B {

public static double C = 2.71828182845904523;

}

}

Теперь в операторе Console.WriteLine (A.B.C); программы Print идентификатор A воспринимается как обозначающий пространство имен A, а не класс A пространства имен Hello! Язык Си# подвел нас. Причем дважды.

Такое чувство, что бы M$ не делала, всегда получается Basic.



2) А кто поручится за надёжность самого программиста - самого слабого звена в любом языке. Или первоклассник, первокурсник и кандидат пишут программы на Обероне на одинаковом уровне?

Ну и...


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

Who is Mr Kladov? :)

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

В C# есть директива unsafe - т.е. программист может, если ему очень хочется, написать фрагмент "опасного" кода. В Оберонах этого нет (или я об этом еще не знаю :))

В Оберонах Вы можете писать процедуры прямо в машинных кодах - как Вам это? :о)) Это "опасный код"?


В C/C++ вообще можно использовать "арифметику указателей" и забывать освобождать динамическую память. Следовательно, надежность C#, в котором есть авт. сборка мусора и "защита" в форме "unsafe" выше, чем у C/C++, а надежность Оберонов, соответственно, еще выше.

А что мешает Вам в Обероне использовать безумства адресной арифметики? Средств для этого достаточно...


Но в программе на VBA у меня был пример такого кода, в котором программист ошибся в имени переменной, а Basic этого не заметил - он принял эту переменную за новую, только необъявленную!

Ну так для всяких там Бейсиков и Фортранов это вполне типично.
Но, грят, в Visual Basic есть таки директива, принуждающая программиста явно обьявлять все переменные с указанием их типов.

Так что, как заметил "Гость", самое слабое звено в любой системе - человек...

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

В C# есть директива unsafe - т.е. программист может, если ему очень хочется, написать фрагмент "опасного" кода. В Оберонах этого нет
О, придумал! Надо всегда не писать директиву unsafe!

В C/C++ вообще можно использовать "арифметику указателей" и забывать освобождать динамическую память.
В данном случае речь не шла о C++ - только о C#, Java, Oberon.

(Что касается ужасных указателей... Ну, ладно, неохота начинать. Всё равно речь не о С++.)

Следовательно, надежность C#, в котором есть авт. сборка мусора и "защита" в форме "unsafe" выше, чем у C/C++, а надежность Оберонов, соответственно, еще выше.
Т.е. если не пользоваться unsafe (как, к примеру, не разгонять процессор), то по-вашему выходит, что Шарп и Оберон равны по надёжности?

Главное, что можно делать относительные оценки надежности.
Я бы ещё добавил - субъективные, т.к. объективных (т.е. в числах) вряд ли можно попросить.

программист ошибся в имени переменной, а Basic этого не заметил - он принял эту переменную за новую, только необъявленную! Вот "надежность" таких языков можно принять равной нулю.
Вы не поверите, но большинство программистов на западе (не будем сейчас углубляться в словесные понты вроде кодер/девелопер/кульный хацкер) пишут именно на этом.
Как и практически вся российская бухгалтерия работает на таком же языке.
Т.о. надёжность отнюдь не нулевая, хотя внимание безусловно требуется.
Точно так же можно перепутать переменные MyVar2 и MyVar3.