Никаких же. А С-хейтеры могут уже начать подыскивать ось, написанную не_на_нём.

Использование C только для вычислительных задач, но не для логики.

фортран?

соппсна, http://shootout.alioth.debian.org/

assembler, как много в этом слове..

А какие конкретно недостатки Вы имеете в виду?

кресты там, objc, D... Есть и более экзотические вещи, но я бы в сторону последних двух присмотрелся.

гугль-го.

Си++. Используется, например, в одном институте для вычислений по физ.-мат. моделям гидродинамики.

CUDA ☺

verilog?

modula-2

GWBASIC

C++

...

таки D поддерживаю

pascal

только асм, только хардкор

http://ru.wikipedia.org/wiki/Syllable

Верблюд. O'Caml то есть. У него вполне неплохая производительность.

Даешь ось на хаскеле для небыдла и ценителей прекрасного

FORTRAN 77

Си++

не катит, там все недостатки Си бережно сохранены и к ним щедро добавлены новые.

тут куча вариантов и вопросов,

1). где и как выполняется 1 хост, кластер, SMP.

2). Какие основные операции выполняются,

3). что хочется улучшать concurrency или parallelism

4). есть ли при этом активное взаимодействие с IO

5). и т.д.

при этом выигрывать могут как fortran, так плюсы, а то и специализированные языки, хотя там обычно low-level нод на одном из указанных плюс c.

C++

но лишенные его недостатков?

Смотря каких.

Это хдль, а не яп

А разве у Си есть какие-то недостатки кроме отсутствия нормального наследования структур (чтобы можно было сделать ООП)?

А разве у Си есть какие-то недостатки кроме ...

Для ВЫЧИСЛИТЕЛЬНЫХ задач часто предпочтительнее фортран - работа с массивами реализована принципиально по другому и богатая математическая библиотека.

Смотря какие именно недостатки. Не знаю насколько оно живо, но тут еще не упоминали Cyclone.

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

зачем 77?

Берём любой ЯП, прикручиваем к нему inline c (наподобие inline asm в C), PROFIT!

одобрено местным раввином

и да, отсутствие раздельной компиляции => отсутствие бинарной совместимости

cast VSL

Я думал 90% вычислительных задач решается на F77 или F90.

отсутствие встроенных регэкспов

В системном ЯП?!

отсутствие всякой защиты от ошибок переполнения буфера

Всякой защиты навалом - strncmp, fgets...

отсутствие раздельной компиляции => отсутствие бинарной совместимости

А также отсутствие раздельной компиляции => максимально возможная производительность кода. Отсутствие бинарной совместимости - необходимая плата.

а в 90м или 2008м есть pointerы на функции/процедуры?

А разве у Си есть какие-то недостатки кроме отсутствия нормального наследования структур (чтобы можно было сделать ООП)?

Да и с этим вроде нормально всё при поддержке unnamed fields. Правда, хз - как множественное наследование делается и нормальные таблицы виртуальных методов.

Какие есть у C живые альтернативы для вычислительных программ, требующих максимизации производительности

Фортран же.

В системном ЯП?!

Если система - *nix то регэкспы необходимы

А также отсутствие раздельной компиляции => максимально возможная производительность кода.

Ну вообще по http://shootout.alioth.debian.org/ си частенько сливает фортрану

Ну вообще по http://shootout.alioth.debian.org/ си частенько сливает фортрану

от Intel, интересно было бы посмотреть сравнение и с компилятором С от них

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

10-15 лет гномодевы это делали, и ничо :)
И заметь, как только переехали с православного С на пэтоны, моны, валы, муялы - так сразу же скатились в СГ.

Для меня гном и GTK всегда был СГ. Я язык тут ни при чем, просто оно прибито гвоздами изо всех щелей.

r ещё не советовали?

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

и это также не значит, что ради простой формочки надо в проект кучу сторонних библиотек натаскивать и лепить интерфейсы к другим ЯП

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

Верблюд. O'Caml то есть. У него вполне неплохая производительность

Всегда считал что верблюдом Perl называют...

но лишенные его недостатков?

Эт каких недостатков?

А это, LISP ужо советовали?