Я знаю одного, его ник в ЖЖ nabbla1. Он придумал взвешенное симметричное троичное БПФ. Оно на доли процента медленнее классического БПФ с основанием 2^N, но, при этом, гораздо лучше работает при расчёте антенн - У НЕГО ЕСТЬ ЦЕНТРАЛЬНАЯ ТОЧКА.

А он, между тем, даже пока не кандидат наук.

Это плохо. что критический код пишут на с++. Ибо результат работы непредсказуем. Я сам с этим столкнулся. А разбирать код какой получиться из-за условной компиляции из разных файлов - я не мазохист, увольте с этой должности. Я предпочту "ленивый" качественный однозначный код.
По поводу многословности Паскаля (да хотя бы FPC) - я просто не понимаю, про что говорите. Язык вполне устоявшийся, команды практически стандартизированы, необходимые вещи появляются, если надо. А вот С++ четкого набора команд нет. Я уже привел ссылку, где все разобрано по полочкам. Для написания приложений (а тем более критических приложений), нужен точный ясный инструмент, который выдает ОДНОЗНАЧНЫЙ код и результат. С/С++ таким похвастаться не может. В это ссылке, что привел С/С++ не относят к языкам высокого уровня. Потому что он язык чуть выше ассемблера.
Кстати, ракеты летают не на С/С++. Российские. А на собственном коде, к коду вопросов нет, есть вопросы к железу. Так и тут. НЕЛЬЗЯ использовать С/С++ для критических приложений. НЕЛЬЗЯ. Даже заведомо отлаженный и протестированный С/С++ код может содержать баг, который вылезет в самый неприятный момент. Сам на это натыкался. Баг был в сторонней библиотеке.

Ссылку можно?

Я уже по ЖЖ вижу, что человек мыслит нестандартно.

На что ссылку, у него же тег в ЖЖ есть "Уравновешенное троичное БПФ", нажимай, всё покажут!

Вы повторяетесь, не аргументируя. И опять мешаете в кучу С и С++. По Вашей ссылке намешано вообще всё подряд: от претензий к реализации некоторых механизмов в С и претензий к ООП в принципе до анекдотов и чьих-то высказываний. По стилю - это больше похоже на политическую пропаганду в форме листовки "для своих", чем на обсуждение какого-то технического вопроса.
До кучи Вы, похоже, полагаете, что Паскаль каким-то чудом не подпадает _под ту же самую_ критику и почему-то думаете, что он пригоден для реализации современных больших проектов и/или как замена С++.

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

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

Подытоживая свою... гм... точку зрения:
а) почти вся критика С/С++ переносима и на Паскаль/его наследников (добавляясь к их собственным недостаткам), разумеется не мешая всё в кучу: С - к Паскалю, а С++ - всё же сравниваем с его наследниками;
б) у С++ - была/есть масса сильных сторон, которых Вы не видите и/или не понимаете(и которых у того же Паскаля нет), он быстро стал индустриальным стандартом вовсе не просто так (и это НЕСМОТРЯ на то, что Паскаль для многих язык первичного обучения, выбор и усилия по переходу люди принимали сознательно);
в) С++ понемногу уходит из индустрии, времена меняются; например, сейчас во многих случаях дешевле платить накладные расходы рантайм того же сборщика мусора, чем мучаться с потенциальными проблемами аллокации памяти, и это лишь один пример из очевидного.

Уже читаю. Он хорошо объясняет БПФ _вообще_.

C++11 успешно решает эту проблему. delete становится ненужным, а у new появляются серьёзные альтернативы.

Не догнал, что тут нового?
Смарт поинтеры с перегрузкой new/delete - не предлагать. Не вчера придумано, и проблемы в полной мере не решает.

Возможность по гнилому поинтеру тихо изменить уже освобождённый кусок памяти у нас осталась. А что нам нужно ещё для полного счастья?
Манагед код в этом смысле всё-таки даёт возможность прибить такое на месте преступления (и баг, и программиста). С++ - нет.

Например, emplace. Конструирование объекта по месту хранения в контейнере. В таком сценарии new просто не нужен. Невероятно удобно, между прочим.

Не могу спорить: штука реально клёвая.
Но это ж косметика. Гололёд лечим увеличением холодильника - мол, меньше по улице шляться надо.
С одной стороны, и рассуждение верно, и удобство растёт.
Но с другой: гололёд-то - никуда не делся. Навернуться можно по-прежнему, только повод для выхода будет иной.

Ещё раз упомяну слова Страуструпа про C++11: "I find a higher-level style of programming more natural than before and as efficient as ever."
То есть, на C++11 можно писать в высокоуровневом стиле, но без каких либо потерь в скорости.
Да и, всё те же unique_ptr/shared_ptr/weak_ptr заставляют задуматься, зачем вообще нужны простые поинтеры. Конечно, пока что ещё нужны, для non-owning применений. Но и это когда-нибудь изменится.
Кстати, я нисколько не утверждаю, что управляемые языки плохи. Чем ближе к пользователю, тем выше уровень языка должен быть.

Нас всех забанят.

Я тут вас почитал, сижу, недоумеваю, как у меня система в 3 млн.строк кода на С++ вообще работает...

Александр, если не тайна сколько времени эта система в 3 млн.строк кода на С++ писалась и отлаживалась.
Интересно мнение от реального разработчика.
А то пишут часто, что с отладкой пары миллионов строк кода C++ можно больше времени потерять, чем потратить на написание.

это верно для любого языка

Да нормально работает, я полагаю.

Отлаживать пласпласный код просто несколько более муторно, чем, скажем, тот же C#.
Не знаю, уж насколько это важно для расчётных задач.

Да не тайна, в общем-то. Мы в своё время в конце 90-х (ещё до меня) дали возможность паре толковых программистов полностью сосредоточиться на концепции новой платформы. На концепцию ушла пара лет, ещё несколько лет - на перенос прикладного ПО на новую платформу. Платформа и ПО, естественно, развиваются непрерывно. Естественно, баги эпизодически вылавливаем, есть "специальный человек", который занят исключительно тестированием. Но платформа построена так, что почти всё обвязано самодиагностикой, а, допустим, сигналы у нас пишутся в архивы, т.е. воспроизвести ситуацию, в которой возникает ошибка, можно достаточно легко. В общем, ребята заняты в основном не поиском и устранением ошибок, а прикладными вопросами, например, применением платформы под новые задачи, валидацией входных данных и т.п.

1) Претензии к утверждению, что с и с++ являются языками высокого уровня, коими они не являются
2) Стандарт на С еще может и быть, а вот на С++ - какой это стандарт, если на выходе код работает как карта ляжет? Я это не теоретически говорю, а с практической точки зрения, ибо сам столкнулся.
3) Для программирования критического кода инструмент должен быть прямой как железная дорога, а не плутать по лесным тропинкам по лесу. Т.е. логика должна просматриваться в одном файле, а не размазана по разным. Претензия к С/С++ в том, что при компиляции получается неоднозначный код и результат (опять же в зависимости от настроек директив компилятора).
Этого что мало? Этого уже достаточно, чтобы поставить крест на С++ как инструмента для написания критического программного обеспечения.
Про Паскаль, тот который FPC. Он развивается, выходят новые релизы. Мне он очень нравится. Я сейчас на нем пишу. Так как он делается на базе С , то в коде можно переключаться и делать вставки как на Асме, так и на чистом С. Почему пересел с Delphi на Lazarus? Переносимость кода на Линукс. Если пишешь на Паскале получаешь логически чистый код, ибо код читается и компилируется однозначно. ДА, может нет того богатого инструментария - а он нужен для прикладников? Может это наоборот благо, а не беда. Если смотреть на объем кода, который генерирует Lazarus (которым так любят хвастаться Сишники), если это очень критично, то вместо LCL библиотек можно задействовать KOL, тем более, что Lazarus это позволяет. Так что Lazarus/FPC очень даже современный мощный инструмент высокого уровня, который может спокойно заменить С++, без ущерба (а то и где-то даже обставив) за счет меньшей трудоёмкости при отладке.
А то, что вместо С++, начинают использовать Java и С# - это признак того, что не всё так сладко с С++.

Superwad, простите, от директив компиллятора будет зависеть генерация любого кода из исходников. По поводу "логики в одном файле" - бейте код на элементарные функции с обвязкой при падении, выдерживайте логику проекта и будет Вам счастье.
Сам пишу на Паскале, но я то пишу коротенькие программки, состоящие из пары модулей и десятка функций максимум. В код в логике проекта переводят уже программисты, и вот как раз их код вполне читаем, хотя я на С++ и не пишу...
И ещё одно. По поводу исполнения стороннего кода. Мы сознательно в проекте отказались от использования большей части сторонних API - именно там зарыта неоднозначность исполнения, ребята пишут всё сами. Зато это даёт очень неплохую кроссплатформенность - система работает под несколькими версиями Винды и Линукса. Частичное использование "сторонних" dll остаётся, в основном, потому, что "наука" пишет преимущественно на фортране и переучить её очень сложно, приходится жёстко оговаривать директивы компиллятора фортрана, чтобы dll-ка подхватывалась без сбоев. Но и тут мы потихоньку приходим к общему знаменателю, когда практически все входные/выходные параметры передаются в качестве параметров функций, а не через коммон-блоки, а ребята генерят исполняемый код для разных сортов топлива уже в двух вариациях: в фортрановский и сишный исходники (для математики это оказалось совсем не сложно)...

1) Вы опровергаете мнение всего мира авторитетной ссылкой на самого себя. Методологически это очень неверный подход. В науке и технике это прокатывает исключительно редко и только при исключительно репутации человека в данной области.
2) О, блин... я-то думал, при каком-то сложном портинге вылезла какая-то нетривиальная разница между тулчейнами... А, оказывается, Вы обиделись на мир после того, как лично накосячили с опциями компиляции. Ну, что тут можно сказать? Не хочу Вас пугать, но если Вы выберетесь из своей песочницы, Вы можете столкнуться не только со своими косяками, но и с реальными проблемами. Даже это - не проблема _языков,_ но чтоб объяснить это, Вас нужно вытащить из песочницы и ваших игрушек к взрослым дядям с игрушками посложнее.
3) У Вас в руках три кубика стандартных библиотек и Вы можете их свободно переносить из песочницы в песочницу. Представьте себе, что мир не исчерпывается песочницами, а машины - состоят из частей сложнее, чем ровный гладкий кубик. Что Вы будете делать, если потребуется заставить Ваш код прямо завтра работать на MIPS или, блин, том же Эльбрусе-4? Выравнивание элементов? Внезапный big-endian? Процессор не поддерживает побайтовую индексацию, а у Вас всё построено на строках? Вы полагаете, что дяди за Вас решат ВСЕ проблемы так, чтоб Вы даже не задумывались о том, куда и что Вы компилируете?
Нет, вот тут и возникают всякого рода настройки и опции, кнопочки и переключатели, кои Вы, не разобравшись в том, зачем они, ничтоже сумняшися назвали недостатком и нестандартностью. Вы ударную дрель видели? Вот она, если ударник включить - тоже непредсказуемо мешает сверлить деревяшки. Нестандарт. Не то, что Вы от дрели ожидали.
Игры в песочнице подразумевают гладкие кубики с ровными гранями удобных размеров, для Вас их умные дяди вырезали и отполировали, подогнав соразмерно песочнице. Вы даёте советы дядям, о том, как нужно конструировать машины из этой песочницы на примере этих пирамидок. А у дядей кубики к друг другу не подходят, клей отваливается, и резьбу приходится нарезать самостоятельно по месту, и так, чтобы метрическая работала с дюймовой. Вы вообще представляете себе, на КАКОМ разнообразии машин и окружений работает С/С++? Нет? Ну что ж Вы говорите всякие глупости-то про то, что у Вас любые два кубика из трёх друг другу подходят один в один предсказуемо?

Вот Ява изначально задумана переносимой. Очень умные дяди сильно подумали, крепко выругались, плюнули и изобразили для этого машинно-независимый байт-код и стековую машину. Не только поэтому, конечно... Но и проблем переносимости хватило.

Конечно, с С++ всё не идеально. Далеко всё не идеально. Конечно, с# и Ява появились не просто так.
Но как я уже говорил, все проблемы неуправляемого кода применимы к наследникам Паскаля в полной мере.
По Вашим же словам, Вы с ними не сталкивались, и даже не представляете пока тех проблем, из-за которых люди переходят на c#.
Значит Ваши программы слишком простые и маленькие для этого - и это хорошо.


Но зачем тогда Вам "точка зрения" и votum separatum в вопросе, который перед Вами никогда даже не вставал? Вот это непонятно.

скорее бы пришел лесник...

в кои-то веки я не влез в этот срач)

Я вот подумал, что форумом ошибся...

Просьба это перенести куда нибудь, там с удовольствием продолжим. Обсуждение кодов, Паскаля и всего такого прочего. А тот тут вроде как БН обсуждают а не компиляторы.

Лесник, АУ?

ждите терпеливо. ик

я бы поставил плюсик, но тут так нельзя. Поэтому - просто полностью поддерживаю. На форуме про атомные реакторы я предпочитаю читать про ядерные реакторы, а не за политику и холивары о ЯП

1) Я писал, что логика в С++ размазана по двум файлам .с и .h. Чтобы восстановить логику нужно анализировать сразу два файла. Это хорошо для диверсантов - тот кто будет анализировать - психушка обеспечена
2) Ссылку что я приводил, разные люди(не мое мнение!), пишут об очень большой сложности С++ и неоднозначности работы полученного кода. Язык С вообще пишут, что это низкоуровневый, создан для улучшения написания системных вещей вместо Асма.
3) Если начать бить код на блоки (ибо это разумно, т.н. unix-way принцип), то... получаем Паскаль с его модульной структурой.
4) Насчет сторонних библиотек - просто привел пример, как написанная на С++ библиотека неоднозначно вызывалась из Паскаля из-за неработающего механизма вызова из вне перегружаемых функций, ибо эта вещь не зависит от настроек компилятора (хотя и это тоже может зависит - я решил проблему через функцию-прокладку и директиву компилятора этой функции-прокладки использовать только чистый синтаксис С), а зависит от конкретной реализации С++ компилятора (привет стандартизации!). На бумаге все красиво, на деле как с забором - на заборе написано три буквы, а за ним дрова лежат. Так и тут ситуация.
5) Я стараюсь задачи выносить в разные программы - так удобнее и быстрее компилировать на старом компьютере (то что есть на работе). "Правильно готовить программу на С++" (с) Татарин - у меня просто нет на это лишнего времени, мне надо сразу нормально работающий код с минимальными затратами. Поэтому использую бритву Оккамы, я выбираю более простое решение, тем более что результат то получается один, а затраты то разные.
Вот, соприкоснувшись с таким поведением кода и расхлябанностью программистов с высоты своей колокольни и говорю, что с++ надо пристрелить на подступах, ибо нужны решения которые дадут однозначно правильный результат при ЛЮБЫХ условиях, а не только при "правильном" приготовлении.
ЗЫ. "Если бы программисты были строителями, то случайно залетевший дятел в город привел бы к гибели цивилизацию" (с) Народное.

Уважаемый Superwad, огромная к Вам просьба: пожалуйста, дождитесь, когда лесник вернётся из своего леса и выделит обсуждение языков программирования в отдельную тему. Не сомневаюсь, что после этого у присутствующих очень быстро найдётся, что Вам ответить по каждому пункту.

Пока что лишь замечу, сознательно не конкретизируя, что многое из того, что Вы (и не только Вы) называете недостатками C++, является естественным и даже неизбежным продолжением его достоинств.

Не готов обсуждать достоинства и недостатки именно языков. Однако вчера расчётное ядро нашей СВРК получило паспорт Ростехнадзора... Ну и референтный опыт на 20+ блоках чего-то стоит, наверное.

Давно пора! Поздравляю

Спасибо, Саша!
Весело быть первыми в своём роде

Обсуждая C++ и C.

Ну во первых, удивительно но языки эти переносимы неплохо. На том же C даже на БЭСМ-6 умудрились компилятор сделать.

Во вторых, тут выше совершенно верно замечено, КАК надо писать сложные системы на C++ - небольшая команда ОЧЕНЬ квалифицированных специалистов должна создать фреймворк и внутренние стандарты. После чего уже даже и быдлокодеры смогут свои куски добавлять. Основной отличие жабы в том, что там быдлокодеры могут писать изначально, причем оно даже работать будет (но как крокодил, низенько - низенько).

А если кто помнит, то Пентагон ведь озадачился как-то проблемой _сделать такой язык, чтобы был сам себе фреймворком - заставлял писать надежно_. И породил он язык Ада. И... не вышел каменный цветок, хотя как я понимаю, многие встроенные системы на нем пишутся или пытались писать.

В общем, подход с _фреймворк делает небольшая команда, все пользуются_ и _язык С++_ крайне правильный. Потому что - ну например, на JAVA написать надежный код - к сожалению, почти невозможно. То есть все абсолютно коды на JAVA которые я например когда то видел - имеют кучу ошибок, но самое главное - они крайне зависят от интерпретатора, и никто не гарантирует того, что через год программа не сломается. У нас (системщиков) есть правило - _все что написанно на JAVA - рано или поздно слопает память или зависнет, а потому его надо перевызывать регулярно_ (последняя история - у нас зависла карточка управления сервером, которая имела интерфейс на JAVA внутри себя - ну и как легко догадаться, через 2 года работы там что-то кончилось и она стала говорить что мол ошибка... А новые карточки идут со встроенным регулярным перевызовом, потому что авторы уже поняли, что невозможно обеспечить надежную многолетнюю работу, а эта штука работает всегда когда включен шнур питания. И поэтому встроенные системы писать на ней - очень сильно рисковать. На C++ - высокий порог вхождения, легко наляпать такое, что и бригада гуру не разберется, но зато при правильном фреймворке и внутренних стандартах - код будет крайне надежен, куда надежнее чем на JAVA или C#, потому что все ошибки вылезут сразу, а не как JAVA через полгода работы...

Хотя кстати с Ada идея была неплоха. Сделать строгий язык для отвественного программирования.

(Да, спасибо что лесник пришел. )

Это вопрос религиозный, так что без меня.


Ну а в чём проблема-то? Будет ли работать амперметр, если воткнуть его в 220? Ну, как карта ляжет. Да, некоторые конструкции C++ в некоторых случаях приводят к неопределённому поведению (undefined behavior). Например, выход за границы массива или двойное освобождение памяти. И что?
Обычно неопределённое поведение возникает в ситуациях, когда на вход какой-то функции поданы некорректные данные, т.е. программа _уже_ работает неправильно. И в этой ситуации уже не важно, что будет дальше: ошибка уже случилась, правильного результата уже не будет, на каком бы языке мы ни писали.


Вы про .h/.cpp? Как правило, интерфейс компонента описан в h-файле, а реализация - в cpp. Исключение - шаблонные (template) классы и методы, которые всегда лежат в h-файле. Но если в проекте появился код с шаблонами, значит, Вы уже залезли на территорию, на которой конкурентов C++ можно пересчитать по пальцам.


Если Вам нужен однозначный результат, то зачем Вам вообще программа? Напишите константу.


Но это, обратите внимание, нестандарт, и привязывает Вас к определённому компилятору. Это, конечно, снимает множество проблем, но в дискуссии о языках не спортивно. C++ использует несколько другой подход:
1. Из кода на C++ можно вызвать любую функцию, имеющую интерфейс, описанный на языке C. Независимо от того, на каком языке эта функция реализована: на C, на C++, на ассемблере или на фортране.
2. Функцию, описанную (declared) на языке C, можно без проблем реализовать на C++.
3. Функции с интерфейсом на C++, реализованные в разных компонентах, совместимы, если они скомпилированы одним и тем же компилятором с одними и теми же настройками.


Про эту однозначность уже анекдоты сложены. :-) Анекдот такой:



Нужен. Вот на соседнем форуме ещё один любитель паскаля жалуется: в России сейчас внедряется ГИС ЖКЖ, данные в неё надо передавать по протоколу SOAP (т.е. подписать XML по ГОСТ и отправить по протоколу HTTP). И выясняется, что подходящих инструментов для этого на паскале нет (хотя и HTTP, и XML, и ГОСТ существуют давным-давно), а подтянуть существующие из других мест он не может.


Просто те преимущества, которые этот язык предоставляет, нужны не всем и не всегда.

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

Леснику - большое спасибо за отдельную поляну

А теперь по существу.
Анекдот про дятла - увы это уже не шутка, а суровая реальность, констатация факта.
Качество программного кода сейчас - ниже плинтуса в основной своей массе.
Использование С++ - это поездка на авто без тормозов и систем безопасности (защиты). Вы когда нибудь ездили по общественным дорогам без тормозов? А мне приходилось, и не одну тысячу км отмахал с одним ручником (машина такая - образец гиганта французской мысли, потому ручник у неё на передние колеса и является стояночно-аварийным тормозом), что уже на уровне рефлексов иногда рука тянется к ручнику затормозить вместо ножного тормоза, особенно на светофорах.
И если уж коснулись автомобильной тематики, то для написания исполнительного кода для критически важных систем управления реального времени используют специально заточенный С, в котором нет освобождения памяти под переменными и прочие ограничения. Но даже применяя специализированный софт, умудряются допускать ошибки.
Так и тут - а есть ли нормальный специализированный софт, который позволяет на корню пресечь многие ошибки, какие можно опустить на ровном месте на С++. И не надо про правильно приготовленные программы и высокую квалификацию программистов - залететь можно на элементарном. ( Правило Мэрфи еще никто не опроверг - "Если деталь может быть вставлена неправильно - то неправильно она будет и вставлена". Если может быть допущена глупая случайная ошибка на ровном месте - то она обязательно будет. Пример - да есть тут один, прочитал на одном форуме -авиадвигатель для пассажирского боинга, прошел капремонт на сертифицированном предприятии, прошел обкатку (причем люди то опытные были, профи) - заметили на складе лишние трубочки - резко тормознули отгрузку - забыли установить после разборки, а если бы поставили на самолет ).

Не удержался. Качество программного продукта определяется в первую очередь методологией, что включает корректным подходом к тестированию (во всех видах), review кода и использования правильных стандартов разработки (в частности тем, какие языковые конструкции можно использовать и какие нельзя). При правильном применении этого подхода – язык разработки глубоко вторичен. При нарушениях в этом процессе (проблемы с тестированием, отсутствие review кода и так далее) – у проекта уже такие проблемы, что выбор "правильного" языка здесь мало поможет. Если критичный код не покрыт 100% тестами, то рано или поздно проблема выстрелит вне зависимости от языка.

На самом деле это касается не только программных продуктов, но и практически любой деятельности. Если сразу правильно "огородить" участок и потом не выходить за пределы, как бы ни хотелось, то вероятность наткнуться на грабли уменьшается на порядки.

По поводу покрытия тестами. Строго говоря даже 100% покрытие тестами не гарантирует отсутсвие багов, если ошибка в логике.

Это разумеется – но это уже валидация требований и другие виды тестирования. Речь же изначально шла про "стрельбу в ногу" в "неправильных" языках.

Именно. По факту имеем, например, редкие переходные процессы, сочетание параметров и сигналов для которых заранее предусмотреть не удаётся. В этих экзотических ситуациях система не падает, но вот отдельные параметры расчёта могут быть неадекватными. На этот случай спасает запись всех входящих сигналов в автоматическом режиме и возможность проигрывания ситуации на архиве таких сигналов - есть на чём тестировать откорректированные алгоритмы/логику.

Выстрелить в ногу можно где угодно. Но одно дело - автоматом ступню отстрелить, и совсем другое - три литра нитроглицерина уронить на ту же ногу.
Бегать, конечно, после такого в любом случае не выйдет, да и выживаемость в первом случае тоже под вопросом.

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

Вот тут опять выплыл С++
Почему никому не нравится язык программирования C++ ?
Краткая выдержка:
1) Язык С имеет четкую постановку задачи и цель, для чего он заточен. У С++ вообще ничего нет. (Даже у Object Pascal который сейчас развивают и то есть конкретные цели - и его под это затачивают)
2) Очень сложный язык - высокий порог вхождения.
3) Неоднозначность кода и получения результата - эдакая обезьяна с гранатой.
4) Писать можно - но для получения нормального результата надо ввалить огромное количество ограничений
5) Долго не могли довести до ума компиляторы - слишком сложный язык и отлавливание всех ситуаций - крайне гемморойный и неблагодарный процесс (да еще и супер трудоемкий).
И все это для того, чтобы написать программы, которые пишутся на других языках с меньшими затратами???
И нафига, спрашивается???