Т.е. с тем, что ты балабол, ты не споришь?

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

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

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

Безопасный язык программирования - это так круто звучит из уст маркетолого. Но почему-то это не помешало повесить баг ценой в 2 миллиарда долларов из-за которого упал Arian 5. А казалось бы Ada - куда уж безопаснее то?

Есть такая тенденция, ставить мегабазу на IBM-Z(сейчас Oracle уже свои машины пиарит) а рядом APP-Server на Java ( в одном зале ).

Не поверите - именно так и пишу! Фильтры и сортировки - в СУБД, остальное - апп.сервер. И это неплохо работает! А бегать как **у*дак - то поправить хранимку, то пофиксить аппсервер - нафик не надо. Есть ОДНО место для серверной логики - его и надо юзать.

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

Это совсем так, у всех диалектов SQL есть гораздо больше общего, чем вы пытаетесь представить. В значительном количестве случаев даже если нельзя один и тот же запрос использовать для разных СУБД, можно использовать вручную оттранслированные с диалекта на диалект запросы. Обычно сделать это довольно легко, т.к. это диалекты одного и того же стандартизированного языка SQL. И только при использовании хранимых процедур, специальных типов полей, триггеров, встроенных функций возникают значительные сложности для перехода с одной БД на другую.

Это терпимо, ибо профессионалы пишут на одном языке и команда набирается на нём же. Тем более, что нет никаких причин менять язык. А вот менять СУБД - запросто!

> Какая задача у вас не может быть решена с помощью PL/SQL?

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

Продолжу.

Написал

update mytable a
set fld=123
where not exists(select * from othertable b where b.keyfld=a.keyfld)

В Оракеле работает, а в МойСкуеле уже хрен.

Можно и более изощеренных примеров накидать.

Код хранимой процедуры тоже работает быстрее, если не использует данные из БД. А ещё быстрее - если вообще не использует данные.

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

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

Убрать все обычные циклы, оставить только foreach (range-based for loop) и добавить гибридные циклы с условием и параметрами обхода. И тогда не получится  залезть в 101 элемент + можно добавить автоматические оптимизации, ведь компилятор будет значть что хочет программист. Статический анализ может и не всемогущ, но при правильном проектировании можно избежать всех ошибок в комплтайме.

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

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

Я вообще не плюсовик, всего лишь сишник. А вот знакомые плюсовики - в массе своей очень крутые ребята. И один плюсовик легко обставит троих хипстеров. Написав что-нибудь крутое, сложное, быстрое, алгоритмически интересное и вообще - state of art. В отличие от сайтов-однодневок и каких там еще наколенных прототипов программ.

Иногда попадаются откровенные жгуны, типа забредающего сюда иногда deadfood'а. Этот вообще написал помесь DE с файлокачалкой. Оно еще и работает, хоть нужность этого именно вот в таком виде и не очевидна. И как угодно но это все-таки что-то рабочее. А не какая-то сферическая ОС в вакууме, нерабочий браузерный движок и теоретически-крутая файлуха без единственного пользователя.

Как будто кто-то мешает хранить "как надо":
[CODE]
?- {X =:= 1/10 + 2/10, Y =:= 15/100 + 15/100, X=Y, Z =:= 2/3 + 1/3}, format('~g\n~g\n~g', [X,Y,Z]).
0.3
0.3
1
[/CODE]
или
[CODE]
>>> 0.1 + 0.2 == 0.15 + 0.15, 0.1 + 0.2

(False, 0.30000000000000004)
>>> from fractions import Fraction as frac
>>> x,y,z = frac('1/10'), frac('2/10'), frac('15/100') + frac('15/100')
>>> x+y == z, map(float, [x,y,z])

(True, [0.1, 0.2, 0.3])
[/CODE]

Это ты клоун, я не про NaN говорил, а про 0.1 + 0.2 = 0.300000000000000004. Это в любом языке так.