[прикладное ПО] замена C

Я бы выбрал Go.

В общем мало данных, только и годится на советы типа «бери мой любимый язык».

Сколько кода в вашем проекте? Сколько данных он обрабатывает и за сколько время? Если время обработки вырастет, то во сколько раз еще приемлемо? ... и т.д.

http://redmonk.com/sogrady/2012/02/08/language-rankings-2-2012/

На осях графика популярность на гитхабчике и число вопросов на стэековерфлоу. Британские ученые такие британские

Будет вылезать ленивость

по постановке задачи ему будет больше вылезать иммутабельность, а не ленивость

хотя я бы, пожалуй, рискнул

Хаскел создан не для скорости

тред откровений

Какие есть альтернативы C?

Octave? Но ооочень медленно.

А если выключить RTTI и исключенния, то и нежирнее будет

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

А чем всё-таки плохи плюсы? Производительность сравнимая с С + OOP есть. С FP наверное не всё так гладко... как в том же haskell (на оном вообще не писал).

Если плюсы сложные - почему бы не попробовать java? правда, в ущерб производительности, но наверное таки побыстрее пузона.

Если вам еле хватает скорости C, то все остальное будет еще медленнее. Ускориться можно только на асме, но это будет еще больше «грязи» в коде и не такой уж и выигрыш в скорости по сравнению с С.

Ну и идите в жопу тогда, попутно говнокодя на поцкале и бейсике.

Самый разумный комментарий. Все остальные комментаторы зачем-то высказывают свои точки зрения, хотя очевидно, что ТС на всё пофик.

Их можно просто не использовать, по идее не должно быть оверхеда никакого.

RTTI добавляется к каждому классу с vtable => юинарники увеличиваются даже если она не используется. Исключения требуют наличия RTTI, по крайней мере в GCC.

С++ реализация будет быстрее

Блин. Я конечно понимаю, что 100-200 кбайт памяти при гигабайтах сейчас - это большая экономия. Да и vtable появляется только у виртуальных классов. И исключения вроде работают без него, если не требуется кастинг объектов по иерархии.

Я конечно понимаю, что 100-200 кбайт памяти

Емнип там экономия больше, особенно когда бинарник тянет на десятки мегабайт.

Да и vtable появляется только у виртуальных классов.

Кэп?

И исключения вроде работают без него, если не требуется кастинг объектов по иерархии.

Там typeid используется, кастинг не причем. Хотя это зависит от реализации, другой компилятор может и не использовать.

Если вам еле хватает скорости C, то все остальное будет еще медленнее. Ускориться можно только на асме, но это будет еще больше «грязи» в коде и не такой уж и выигрыш в скорости по сравнению с С.

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

С++ реализация будет быстрее

Это сферический вакуум. Реализация по Itanium C++ ABI - возможно, быстрее. Реализация через longjmp - скорее всего, медленнее.

Чем плюс плюс тормознее, например? А автор - дурак, что толком ему не нравится в C не ясно. А скорости еле хватает - покупай компьютер круче, пиши нормально, вот рецепт

Любое ООП ВСЕГДА тормознее процедурного аналога. Для сравнения - одна операция присваивания чего-то в классе может порождать цепочку на 3000 операций с предками.

И вот сишную лапшу на кластер натягивать

Неужоль нет ничего готового? И видишь, C++ товарищу плох, жабка тоже, а в лиспах скобочки - боюсь-боюсь

Любое ООП ВСЕГДА тормознее процедурного аналога. Для сравнения - одна операция присваивания чего-то в классе может порождать цепочку на 3000 операций с предками.

Толсто же. ООП не предполагает введения преждевременной пессимизации

А плац-плац разве не в ту же процедурщину конпеляется? Понимаю там, если ООП в рантайме, инфа о классах где-то хранится, ну и прочее там.

Ну даже 1/10 от бинарника. Это тысячные доли.

Не буду утверждать, сейчас не до суг проверять, что int будет перехвачен

Честно сказать, я не знаю, как перехват exception реализован. Но что-то мне говорит, что при нормальном исполнении, при отсутствии необходимости обрабатывать исключения, стоимость try/catch блоков равна 0.

По крайней мере в obj-c от яблока так и есть. не думаю что gcc в c++ глупее

Неужоль нет ничего готового?

Ну есть, но одно дело на хацкеле или лишпе другой вызов функции использовать для распределённого map-reduce, а другое дело сишную кашу под какой-нибудь Кондор переваривать.

почему бы не попробовать java? правда, в ущерб производительности

а кое-где криокамеры до сих пор работают...

при отсутствии необходимости обрабатывать исключения, стоимость try/catch блоков равна 0.

в реальном мире, как известно, shit happens

C++, это же очевидно. Или Lisp/Lua/Python/whatelse + FFI

OCaml уже предлагали и не раз. ИМХО, не просто так. Довольно оптимально было бы.

все хотел покапать.... но такая лень...

В результате погрязли в коде.

freepascal советовали?

Вам нужен альтернативный программист, т.е. умеющий писать на С.

Карго-культ инструментов разработки из профанов или новичков профессионалов не сделает - какой бы язык вы ни взяли, всё равно «погрязнете в коде», т.к. «грязнуть в коде» - это свойство человека, не языка.

ЗЫ. Лучше сделайте нормальный рефакторинг того, что есть. Сэкономите туеву хучу времени и сил.

Люто-бешено плюсую. Два пива этому юзеру за мой счет.

кто спрашивал про объём «проекта»? Ориентировочно 500-750кб я вижу (+ несколько форков под различные задачи). Размер датасета в памяти 15-20гиг.

http://www.ats-lang.org/

Слушаете каких-то хеллоуворлдщиков. mv, таки, дело говорит. Может и найдут они крутого программиста, который силой своего гения сделает как надо, да только любой Вася Пупкин на нормальном языке сделает то же самое за меньшие деньги и время.

не сделает

Да, возможно одному крутому прогеру на С и не справиться

На GObject перетащи.

Fortran 2008

криокамеры?

Vala же

Выбор у нас свободный. Начальство, конечно, не обрадуется экзотическим решениям

нормальные решение начальства в такой ситуации - либо уволить вас нахрен, либо нагнуть на рефакторинг того что есть.

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

На осях графика популярность на гитхабчике и число вопросов на стэековерфлоу.

Это что-то вроде предложения (разработчиков) - то что популярно на разных github, SO, reddit, etc. Спрос работодателей (TIOBE, например) может быть, конечно, другим. Но вот если разработчик[и] сам себе работодатель и напрямую работает с клиентами (для них ведь используемый язык это вторично - главное ТЗ), то, скорее всего, он предпочтёт то, что ему будет удобнее использовать, а не какой-нибудь энтерпрайз ради энтерпрайза. Ну и разница между спросом и предложением продиктована, в первую очередь, уже сложившейся архитектурой и legacy кодом (что не очень существенно в новых, своих, внутренних проектах).

Это что-то вроде предложения (разработчиков) - то что популярно на разных github, SO, reddit, etc.

Я к тому, что к github в компанию нужно было взять еще как минимум SF, а к SO другие кодерские форумы, тогда была бы представительная выборка

Но вот если разработчик[и] сам себе работодатель и напрямую работает с клиентами (для них ведь используемый язык это вторично - главное ТЗ), то, скорее всего, он предпочтёт то, что ему будет удобнее использовать, а не какой-нибудь энтерпрайз ради энтерпрайза.

Согласен, но фриланс не так уж широко распространен.

Правда придется к луа привыкнуть, он совсем без батареек.

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

Если плюсы сложные - почему бы не попробовать java?

http://harmful.cat-v.org/software/c /
http://harmful.cat-v.org/software/java

If you think programming in java is a good idea, then _please_ stop programming.

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

Вообще, стоит указать ещё навыки команды. Помнится, кто-то выкладывал статью о фирме, в которой используется в основном Lisp. Автор статьи там говорил, мол есть смысл такое делать, когда в команде есть >1 продвинутого Lisp-программиста. Для многих «необычных» языков такое утверждение (на мой взгляд) справедливо.

Если же данное условие не выполняется - Java или другой язык, защищённый от «дураков». Использовать новый для всех язык = запороть первую версию программы.

Во всех остальных случаях проще и дешевле будет написать заново.

Плюсую. Это нормальная практика для многих проектов. Если время и человекоресурсы позволяют, так и надо делать. Рефакторить можно только свой код, иначе это last resort. Все кто тут советовал рефакторинг похоже теоретики.

нормальные решение начальства в такой ситуации - либо уволить вас нахрен, либо нагнуть на рефакторинг того что есть.

ты-то что взъелся? Завидно что ли? Слова то какие - «нагнуть», «нахрен». А я тебя адекватом считал.

Я для того и спросил чтобы понять текущее положение дел на поприще ЯП и принять адекватное решение. Я много чего переписал из того что у нас до сих пор работает и многократно убедился что если код говно то нет смысла за него цепляться и нет смысла использовать устаревшие технологии только потому что наши кодеры ничего другого в жизни не видели. И с этим проектом справлюсь.

А не буду справляться с обязанностями - уволят, не волнуйся.

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