Какой язык нижнего уровня следующего поколения лучше всего подходит для переноса кодовой базы? [закрыто]

Comparing C* to Cobol is questionable

Comparing C* to Cobol may lead to the wrong conclusion. C was perfect for its day, a huge leap forward on its introduction, and it still gets the job done today.

I would sum up Cobol on my most charitable day with "nice try".

C and C++ will survive for a long time because they fit the bill well as implementation languages. This won't ever really change.

Also, consider that the main negative issue with C/C++ is the lack of memory safety. This tends to be less and less of a problem as codes mature. This means there will not be a serious reason to replace the old codes.

I expect that software systems will grow outwards from C. Look at the hierarchy today:

• application written in a framework such as Rails
• application back-end written in Ruby, PHP, Python, C#, whatever
• Ruby, PHP, Python, or C# run-time implementation (written in C*)
• OS kernel (written in C89)

I don't think the old layers will vanish, and I think legacy higher layers written in C and C++ will simply be supported that way for an indefinite period of time, eventually being phased out for their replacements written in Ruby, Python, C#, or a future development.

Ознакомьтесь с Комплектом разработки программного обеспечения Intel® Cilk ++ , если вы хотите заинтересовать вас разработкой C ++ / многоядерных процессоров. Я также не думаю, что в ближайшее время исчезнут C или C ++.

Существует бесчисленное множество машин, на которых работает программное обеспечение C ++, я не вижу, чтобы они выключались сразу. Если C ++ встанет на путь COBOL, появится огромный рынок для миграции приложений. Будут разработаны специализированные инструменты для перевода приложений C ++ на популярный язык того времени (Z ++ ???).

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

Как сказал дсимча, способ D в настоящее время рискован. Тем не менее, у этого языка есть огромный потенциал, он низкоуровневый, и я испытал значительно лучшую производительность с D (вместо C ++). Возможно, что люди думают о динамических языках.

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

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

Я бы не сосредоточился на языке, а больше на библиотеках, окружающих его. C ++ в сочетании с библиотеками boost - отличный выбор. Люди, которые разрабатывают на C ++, как правило, лучше разбираются в вычислениях, я сам начал с Java, которая упростила мою жизнь, скрывая многие фундаментальные вещи, и это хорошо, однако я действительно начал понимать программирование только после того, как изучил C / C ++ (указатели и т. Д.).

Я признаю, что C ++ может быть сложным (например, управление памятью), поэтому я думаю, что хорошо иметь "дополнительный" язык, где производительность не важна, а удобочитаемость (== ремонтопригодность) имеет высокие оценки: Для этого я рекомендую Python.

C ++ - он относительно молодой и обновленный ... Имеет большое количество поставщиков компиляторов и получил постоянно улучшается.

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

D многообещающий, но все еще очень новые и нестабильные спецификации и библиотеки.

Go родился несколько недель назад ... Никогда не используйте ничего из версии 0 для больших важных проектов. Также он значительно более ограничен C ++ или D .

Придерживайтесь C и C ++. Я не думаю, что он идет по пути COBOL, он работает так же хорошо, как и все остальное, и у вас не будет проблем с поиском людей, которые будут писать код на C и C ++.

Мы понятия не имеем, найдет ли Go признание. Просто быть с Google, вероятно, будет недостаточно.

D? Ну, об этом говорят кое-что приятное, но и это не будет популярным. Никакой пользовательской базы не о чем говорить. D занимает 20-е место в рейтинге TIOBE Index и быстро падает.

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

Java находится на вершине, и я был бы удивлен, если бы в ближайшие 20 лет он ушел далеко. Он не считается языком системного программирования, но работает достаточно хорошо, так что есть несколько задач, которые вы бы выполняли на C ++, но не могли бы на Java. Конечно, в наши дни никто не хочет поручать программистам работу, выполняемую (безупречно и часто более эффективно) сборщиком мусора. Я, например, считал Java значительным шагом вперед по сравнению с C ++ с точки зрения эффективности программирования.

Я весьма впечатлен Ruby . Это элегантный, выразительный язык: вы можете многого добиться, не используя слишком много кода, но этот код по-прежнему остается в основном разборчивым. Один из основных принципов Ruby - быть последовательным и не преподносить разработчикам сюрпризов. Это очень хорошая идея, ИМО, и она повышает производительность. Во время большой шумихи вокруг Rails (которая, возможно, все еще продолжается), я отказался от Ruby, потому что его эталонная реализация ужасно медленная. Тем не менее, JRuby люди из Sun сделали это невероятно быстро на JVM, так что теперь это ' s определенно заслуживает внимания. Ruby предоставляет замыкания и хороший набор возможностей функционального программирования (почему это важно, см. Ниже), хотя на самом деле он не считается языком программирования FP. Индекс TIOBE: 10 и продолжает расти.

На будущее следует учесть тот факт, что производители процессоров столкнулись с ограничением производительности, наложенным физикой. Каждое Рождество больше не доступен на 30% более быстрый процессор, как это было в прошлом. Итак, теперь для повышения производительности вам нужно больше ядер. Разработке программного обеспечения потребуется вся возможная помощь в поддержке многоядерного параллельного программирования. C ++ оставляет вас в основном наедине с этим, а решения Java ужасны по современным стандартам.

Ввиду этого там ' Это определенная тенденция к функциональному программированию (которое устраняет большую часть проблем, связанных с параллелизмом), а также к языкам с лучшей поддержкой параллелизма. Erlang был написан специально для этого, а также для возможности менять местами код в работающей программе (Эрикссон требовал невероятного времени безотказной работы). Scala похожа на Java, но с гораздо более сильной поддержкой функционального программирования и параллелизма. Clojure , то же самое, но это Lisp, и он даже не входит в топ-50 (пока !!).

Scala был разработан академиками и показывает это: он сложен и откровенно педантичен в отношении типов данных; он пытается быть швейцарским армейским ножом языков программирования. Я считаю, что многим программистам со средним уровнем интеллекта будет сложно освоить Scala. Ruby - это меньше FP и мало внимания уделяется параллелизму, но это прагматично, весело и легко выполнить работу. Кроме того, при работе на JVM в библиотеках Java имеется огромное количество кода, с которым Ruby может взаимодействовать. Итак:

Я бы сделал ставку на Ruby, с небольшим шансом на Scala. Но есть масса альтернатив!

Если вы верите в принципы бережливого производства, вам следует стремиться «принять решение как можно позже». Момент должен быть последним ответственным моментом, то есть моментом, когда неспособность принять решение устраняет важную альтернативу.

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

Обновление 2019 г .: C ++ останется в течение следующих 10 лет ... (если нет, я исправлю этот ответ, когда он перестанет быть актуальным .... )

Причина, по которой компании сегодня работают с COBOL, заключается в том, что они уже написали миллионы кодов COBOL. если бы они могли его бросить - они сделают это сразу, с другой стороны - компании работают с C / C ++ как часть своих потребностей и в новых проектах, использующих этот язык, b / c они не могут / не хотят использовать java / c # любой другой язык на основе фреймворка, поэтому COBOL здесь не аналог.

C и C ++ - в значительной степени непревзойденная комбинация, когда дело доходит до родных / неуправляемых / "низкоуровневых" языков.

Не потому, что это лучшие языки, отнюдь не так, а потому, что они там, они делают свою работу, и они достаточно хороши . Нет никаких сомнений в том, что D, например, во многих отношениях лучше C ++. Но не получается в самом важном: совместимости со всем существующим кодом C ++. Без этого требования в любом случае большая часть этого кода была бы написана на управляемом языке. Единственная причина, по которой так много кодовых баз сегодня используют C ++, заключается в том, что они использовали его в прошлом году, и было бы слишком сложно переключиться на что-то другое. Но , если и , когда они переключаются, они обычно не переключаются на D. Они переключаются на C #, Java или Python.

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

Итак, C и C ++ никуда не денутся. Маловероятно, что C будет развиваться дальше. Он такой, как есть, и одна из ниш, которую он должен заполнить, - «простота даже для разработчиков компиляторов». Ни один другой язык не сможет превзойти его в этой нише, даже если они никогда больше не пересмотрят стандарт.

C ++ развивается гораздо более радикально, с приближением C ++ 0x, а у них уже есть огромный список функций они хотят сделать потом . C ++ - это ни в коем случае не тупик.

Оба языка никуда не денутся. Возможно, через 50 лет их заменят другие языки, но этого не произойдет в этом десятилетии.

Итак, C и C ++ никуда не денутся. Маловероятно, что C будет развиваться дальше. Он такой, как есть, и одна из ниш, которую он должен заполнить, - «простота даже для разработчиков компиляторов». Ни один другой язык не сможет превзойти его в этой нише, даже если они никогда больше не пересмотрят стандарт.

C ++ развивается гораздо более радикально, с приближением C ++ 0x, а у них уже есть огромный список функций они хотят сделать потом . C ++ - это ни в коем случае не тупик.

Оба языка никуда не денутся. Возможно, через 50 лет их заменят другие языки, но этого не произойдет в этом десятилетии.

Итак, C и C ++ никуда не денутся. C вряд ли получит дальнейшее развитие. Он такой, как есть, и одна из ниш, которую он должен заполнить, - «простота даже для разработчиков компиляторов». Ни один другой язык, скорее всего, не превзойдет его в этой нише, даже если они никогда больше не пересмотрят стандарт.

C ++ развивается гораздо более радикально, с приближением C ++ 0x, и у них уже есть огромный список функций они хотят сделать потом . C ++ - это ни в коем случае не тупик.

Оба языка никуда не денутся. Возможно, через 50 лет их заменят другие языки, но этого не произойдет в этом десятилетии.

Итак, C и C ++ никуда не денутся. C вряд ли получит дальнейшее развитие. Он такой, как есть, и одна из ниш, которую он должен заполнить, - «простота даже для разработчиков компиляторов». Ни один другой язык не сможет превзойти его в этой нише, даже если они никогда больше не пересмотрят стандарт.

C ++ развивается гораздо более радикально, с приближением C ++ 0x, а у них уже есть огромный список функций они хотят сделать потом . C ++ - это ни в коем случае не тупик.

Оба языка никуда не денутся. Возможно, через 50 лет их заменят другие языки, но этого не произойдет в этом десятилетии.

Итак, C и C ++ никуда не денутся. C вряд ли получит дальнейшее развитие. Он такой, как есть, и одна из ниш, которую он должен заполнить, - это «простота даже для разработчиков компиляторов». Ни один другой язык, скорее всего, не превзойдет его в этой нише, даже если они никогда больше не пересмотрят стандарт.

C ++ развивается гораздо более радикально, с приближением C ++ 0x, и у них уже есть огромный список функций они хотят сделать потом . C ++ - это ни в коем случае не тупик.

Оба языка никуда не денутся. Возможно, через 50 лет их заменят другие языки, но этого не произойдет в этом десятилетии.

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

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

В настоящее время я регулярно использую D. Я бы пока не рекомендовал его людям, пишущим производственный код, потому что он слишком передовой. Мне это сходит с рук, потому что большая часть моего кода - это исследовательские прототипы в биоинформатике. Однако язык начинает стабилизироваться. Андрей Александреску выпускает книгу под названием «Язык программирования D» в марте следующего года, и прямо сейчас есть стремление стабилизировать спецификацию для версии 2 языка как раз ко времени выпуска книги.

Хотя D не является формальным надмножеством языка C, это то, что я бы назвал идиоматическим надмножеством, за исключением отсутствия препроцессора. Другими словами, любой код, написанный на собственно C (игнорируя препроцессор), можно тривиально транслировать в D без переделки, потому что такие концепции C, как указатели и встроенный ASM, присутствуют и работают в D так же, как и в C. D также поддерживает прямое связывание с кодом C, а стандартная библиотека D включает в себя всю стандартную библиотеку C.

Кроме того, несмотря на отсутствие библиотек в D, потому что это все еще передовой язык, это мечта разработчика библиотеки из-за его возможностей метапрограммирования. Если это произойдет, вероятно, у него будут довольно впечатляющие библиотеки. Для предварительного просмотра см. Std.range или std.algorithm в стандартной библиотеке D2 (Phobos). В качестве другого примера я реализовал модель параллелизма, подобную OpenMP (параллельный foreach, параллельное отображение, параллельное сокращение, будущее), как чистую библиотеку в D, без какой-либо специальной поддержки компилятора. (См. http://cis.jhu.edu/~dsimcha/parallelFuture.html )

Учитывая, что вас больше всего интересуют долгосрочные перспективы, я бы сказал, что дайте D 6 месяцев для стабилизации (учитывая Андрея и текущие усилия по стабилизации языка, версия 2 к тому времени должна быть стабильной), а затем внимательно посмотрите на нее.

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

Java. For most low level things Java is fine these days. Why go with a partial solution to C/C++ such as D or Go when you can have something as safe and easy to develop with as Java? If you are looking for a real time solution, D and Go are definitely not it, not to mention they are probably even less supported than Java.

Java is now a system programming language. I don't see how you can consider anything with unsafe constructs such as pointers "next gen". The only reason those insecure constructs ever existed is because it was the pragmatic approach to building a turing complete language. There was no concern of representing the memory in discrete objects, because they just wanted to build something that worked. There are already hard and soft realtime applications in Java, a variety of hardware bytecode processors, and over 2 billion mobile devices running Java. At most all you would have to do is add some constructs for interoperability with devices, which wouldn't be that much code; even in C/C++ you'd still have to add these constructs...

What are you programming? 8-bit microcontrollers with 1KB ram? In that case, it would be pointless to use anything other than the assembler for that platform...