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

Ответ 1

D и Go, вероятно, станут такими популярными, как Python и Ruby. Каждый из них заполняет нишу, и хотя D должен был стать полноценной заменой С++, он, вероятно, никогда не получит достаточную массу, чтобы отодвинуть С++. Не говоря уже о том, что они оба не стабильны/достаточно зрелы, и неизвестно, будете ли вы поддерживать эти языки через 10-20 лет для тогдашних аппаратных и операционных систем. Учитывая, что C/С++ является в значительной степени скомпилированным языком и используется в подавляющем большинстве операционных систем и приложений с собственным кодом, очень маловероятно, что в обозримом будущем оно исчезнет.

Ответ 2

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

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

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

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

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

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

Ответ 3

В настоящее время я использую 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 для небольших производственных проектов, если вы не находитесь в очень опасной среде, Более крупные проекты, которые обязательно должны иметь хорошую поддержку инструментальной и библиотечной поддержки, все равно должны ждать.

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

Ознакомьтесь с Intel® Cilk ++ Software Development Kit, если вы хотите заинтересовать вас разработкой С++/Multi-Core. Я не вижу, чтобы C или С++ уходили в ближайшее время.

Ответ 12

Сравнение C * с Cobol сомнительно

Сравнение C * с Cobol может привести к ошибочному выводу. C был идеален для своего дня, огромный шаг вперед по его введению, и он по-прежнему выполняет свою работу сегодня.

Я бы подвел итог Cobol в самый благотворительный день с "хорошей попыткой".

C и С++ выживут долгое время, потому что они хорошо подбирают законопроект, как языки реализации. Это никогда не изменится.

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

Я ожидаю, что программные системы будут расти наружу от C. Посмотрите на иерархию сегодня:

• написанное в рамках Rails
• сервер приложений, написанный на Ruby, PHP, Python, С#, любой
• Реализация Ruby, PHP, Python или С# (написана на C *)
• Ядро ОС (написанное на C89)

Я не думаю, что старые слои исчезнут, и я думаю, что прежние более высокие уровни, написанные на C и С++, будут просто поддерживаться таким образом в течение неопределенного периода времени, в конечном счете постепенно прекращаться для их замещений, написанных на Ruby, Python, С# или будущей разработки.

Ответ 13

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

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

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

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

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

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

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

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

Моя ставка будет на Ruby с внешним шансом на Scala. Но есть много альтернатив!

Ответ 14

Java. Для большинства вещей низкого уровня Java в наши дни прекрасен. Зачем идти с частичным решением для C/С++, например D или Go, когда вы можете иметь что-то безопасное и легкое в разработке с Java? Если вы ищете решение в режиме реального времени, D и Go определенно не так, не говоря уже о том, что они, вероятно, даже менее поддерживаются, чем Java.

Java теперь является языком системного программирования. Я не вижу, как вы можете рассматривать что-либо с небезопасными конструкциями, такими как указатели "следующий ген". Единственная причина, по которой эти небезопасные конструкции когда-либо существовали, заключается в том, что это был прагматичный подход к построению полного языка. Не было никакой озабоченности представлять память в дискретных объектах, потому что они просто хотели создать что-то, что сработало. В Java уже существуют жесткие и мягкие приложения реального времени, различные аппаратные процессоры байт-кода и более 2 миллиардов мобильных устройств, работающих на Java. В большинстве случаев вам нужно будет добавить некоторые конструкции для взаимодействия с устройствами, что не будет таким большим количеством кода; даже в C/С++ вам все равно придется добавлять эти конструкции...

Что вы программируете? 8-разрядные микроконтроллеры с 1 КБ баром? В этом случае было бы бессмысленно использовать что-либо, кроме ассемблера для этой платформы...