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

У luajit'а шикарнейший ffi из тех что я видал, глубоко прошитый в компилятор. Поговаривают даже, что вызовы работают как нативные. Если старый код трогать неохота, охота только писать новый, то будет самое оно. Правда придется к луа привыкнуть, он совсем без батареек.

«улучшенная» Java это Clojure (http://clojure.org/)

разные инструменты решают разные задачи.

Глубокая мысль.

Если ты считаешь что си это вершина ЯП то ты не прав.

Я так не считаю, я считаю, что «вершина ЯП» - это бессмысленное словосочетание, намекающие на наличие у высказывающего ошибочного представления о некой «иерархии ЯП».

Я написал с чем у нас сложности.

Я прочел. Ничего си-специфичного в описании проблем нет.

Есть языки которые берут эти сложности на себя.

Нет никаких «сложностей», есть разные модели вычисления. Если вы не осилили решить задачу в модели вычислений Си (которая, надо заметить, довольно дубова), то шансы, что вы ВНЕЗАПНО осилите те же самые вычисления в другой модели близки нулю.

Есть конкретный спектр задач для который Си не самый удачный выбор, типа парсинга 100500 скриптами 9К конфигов в вечном цикле. Но под вашу задачу - графы/строки с ограничениями по памяти/времени си подходит идеально.

Я видел с добрый десяток попыток переписать и улучшить™ проекты с языка1 на язык2 «потому что язык2 - мегакруто и там куча супертехнологий». Всегда получались те же яйца только в профиль и на порядок хуже. Мой вывод - в 99% процентов реальной причиной переписывания является некомпетность - незнание либо инструмента, либо конкретного решения, либо и то, и другое вместе.

А насколько у программы сложная логика? Если задачка чисто вычислительная, то часто «на ура» идет матричный подход.

Так что стоит косить глазом в сторону Matlab, или в бесплатном варианте – на Scilab. К тому же там масса встроенных функций для почти любых известных методов вычмата. Octave – из той же оперы, только у него свои проблемы, из известных мне – он существенно тормознее матлаба, а некоторые функции написаны на фортране и не позволяют рекурсивных вызовов. Julia, судя по описанию, из той же оперы, но очень-очень новый язык, в разработку пускать рановато.

Если пройтись по требованиям из первого сообщения:

• графы – это матрицы, все путем;
• строки – ничего определенного сказать нельзя, надо проверять на живых примерах;
• память, указатели и границы – проблема почти полностью отсутствует, большинство операций можно сделать без индексов, на уровне матричных вычислений, а если проблема всплывает – никаких сегфолтов, сразу напишет: «Шеф, вышли на встречку, сбрасывай скорость»;
• ООП и перегрузка – вот их нет, в Матлабе, правда, ООП появилось в середине двухтысячных, но, во-первых, неудобно, во-вторых, насколько мне известно, в бесплатных аналогах и такого нет;
• именованные аргументы - нет, но есть опциональные.

По скорости: если честно, с действительно суровыми задачами ни разу сталкиваться не приходилось, но, в целом, скорость вполне достойная, ведь «высоким штилем» пишет только конечный программист. Сами встроенные функции, которые и занимаются вычислениями, как правило, написаны на нативных языках с соответствующей скоростью.

Правда, пометка про скорость соответствует и шикарным библиотекам SciPy/NumPy. Гибкость питона и скорость нативных матриц – это ого-го какая силища. Из встреченных минусов – рисовалка графиков несколько тормознее, чем в Matlab-подобных средах, ну да это дело наживное. А еще мне в свое время помогла вот эта табличка: http://www.scipy.org/NumPy_for_Matlab_Users, ее можно и при беглом ознакомлении использовать.

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

графы – это матрицы, все путем;

там траверсинг жёсткий с поиском похожих подграфов итп. Поэтому нам матрицы не подходят.

К сожалению готовых тулзов под наши задачи нет.

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

Ну а наш domain это поисковые технологии. Логика несложная, рутины много.

D никак не родится, остальное либо эзотерика

я прихожу к выводу что это не самые страшные проблемы. Главное понять на чём мы сможем довести проект до конца. А то что выбранный инструментарий может подохнуть через пару лет.. Да и хер с ним, у меня каждый пару месяцев жизнь круто меняется, поэтому нет необходимости планировать настолько далеко вперёд.

переименовать все файлы с *.c на *.cpp и писать оставшуюся часть на крестах самое дешевое решение для ленивых

Может, С++ не лучший выбор для построения гуев

Можно поинтересоваться, а чем вам Qt/C++ не угодил? Вполне себе удобная штука.

Либо C++, либо Haskell. Последний как питон, только побыстрее.

Последний как питон

O_O. Чтож, давно хотел его попробовать. Но вот сходство с питоном как-то сомнительно.

перепишите на С заново

с использованием glib.

а вообще если ты не инвалид займись чем нибудь другим жизнь одна что бы ее на это говно тратить (я про работу программистом)

«Познание стран мира — украшение и пища человеческих умов.» Леонардо да Винчи

«Самые достойные мужи избежали оков целого света, за ними шли те, которые избежали привязанности к определенному месту, за ними — те, которые избежали соблазнов плоти, за ними — те, которые смогли избежать злословия.» Конфуций

может C + статический анализатор?

Главное понять на чём мы сможем довести проект до конца. А то что выбранный инструментарий может подохнуть через пару лет.. Да и хер с ним

Мде. Тогда я голосую за Nemerle :)

Если проект доволно крупный и работает как надо, по моему есть только два пути: 1) Переписать с C на C, предварительно обдумав рефакторинг + использовать либы решающие рутинные вопросы + вынести логику на любой скриптовой язык. 2) C++

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

ну вот щас идёт рефакторинг.

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

экзотическим решениям

Транслятор с Euphoria на C.

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

После data mining на любом языке с автоматическим управлением памятью ой как ощутимо.

наконец-то хоть кто-то меня понимает :(

Это дело привычки и дисциплинированности.

Haskell. Последний как питон

Проходи, толстячок

а почему не плюсы? При правильном подходе не медленнее С, и много вкусных плюшек.

Это дело привычки и дисциплинированности.

Можно каждый день 8 рабочих часов и на колу сидеть, это дело привычки и дисциплинированности, но можно ведь и в кожанном кресле.

наконец-то хоть кто-то меня понимает :(

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

а почему не плюсы?

потому что есть пост-плюсовые языки которые сделаны с оглядкой на плюсы и не повторяют их «ошибок».

Графы? Neo4j </thread>

Это дело привычки и дисциплинированности.

Как раз сейчас читаю статью про D:

«If there is one thing that decades of computing have taught us, it must be that discipline-oriented programming does not scale».

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

С++ - самый быстрый вариант, если не сильно накосячите, будет так же, как С. Писать сильно удобнее, ежели умеючи.

Java - если не накосячите, будет быстрее всяких пайтонов. Писать просто. Неинтересно правда, зато работает.

Питон - тормоза тормозные. Смысла его использовать там, где нужна скорость, не вижу.

Всё остальное маргинальщина. Ну можно хаскель заюзать, но тут совсем уметь надо, да и тоже маргинальщина по сути.

С++ - самый быстрый вариант, если не сильно накосячите, будет так же, как С.

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

Ну можно хаскель заюзать

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

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

си или кресты + питон

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

Нужен альтернативный ЯП.

такой уже есть, называется - Common Lisp.

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

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

К тому же, кто data mining писал на Си и на каком-нибудь ФЯП, у того вопросов просто не возникает, на чём лучше писать этот самый mining.

си или кресты + питон

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

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

Затрудняюсь что ли бо сказать о лиспе в виду очевидных причин, но насколько я понял никакого data mining там нет, а просто еще одна очередная числодробилка с продвинутой логикой.

Затрудняюсь что ли бо сказать о лиспе в виду очевидных причин, но насколько я понял никакого data mining там нет, а просто еще одна очередная числодробилка с продвинутой логикой.

«Есть программа ... которая работает с большими графами».

«там траверсинг жёсткий с поиском похожих подграфов итп.»

Тупой тред какой-то. Тупой тред - тупой ответ: жаба! жаба! Интерпрайз!

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

http://redmonk.com/sogrady/2012/02/08/language-rankings-2-2012/ - такая же маргинальщина как Scala, например.

Привет! Вижу тебя в этом треде, значит теперь это лиспосрач?

не бывает тупых вопросов, бывают тупые ответы типа твоего.

А люди крутят всякие Garbage collector'ы всякие. Зачем? И зачем C? Только ассемблер, только хардкор

осемблэр

Ты обиделсо? Вопросов типа твоего на ЛОРе навалом! ООПа хотишь? Ну запили его в C, епт

тебя пацаны на раёне заждались

O_O. Чтож, давно хотел его попробовать.

Не рекомендую. Будет вылезать ленивость в виде падения производительности и расхода памяти. А производительность тебе критична.

Да, и кривая обучения у хаскеля крутая.