Здравствуйте, TimurSPB, Вы писали:
TSP>В теории красиво и правильно. Согласен полностью. TSP>Но вот от стыковки C# с C++ я удовольствие испытал весьма сомнительное.
За шарп не скажу, но сам я недавно сопрягал С++ с Питоном (а лет 15 назад — с Tcl), особых проблем не заметил, кроме детских проблем самого питона (многопоточность — это смерть, лучше ею не пользоваться в питоне вообще) + его специфические вещи типа счетчиков ссылок.
Но тут, конечно, Boost.Python сильно выручает, с ним очень приятно все программить.
Здравствуйте, jazzer, Вы писали:
J>Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy),
Ну-ну. Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее. На С++ пока не переписывал. Там чистая матричная алгебра.
Здравствуйте, okman, Вы писали:
O>Нативные языки по своей природе ограниченны, потому что упираются в нижележащие O>возможности архитектуры и операционной системы. Плюс некоторый "сахар" в виде O>языковых средств (шаблоны в С++) и набора библиотек, но не больше. O>Концепция компилируемых языков во многих отношениях свой ресурс исчерпала и дальше O>двигаться просто некуда. Новые задачи не решаются совершенствованием компилятора и O>добавлением новых библиотек.
Не трогая C# с его LINQ и лямбдой, ограничусь Явой и С++. Что такое есть в Яве, чего нет в С++ ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, okman, Вы писали:
O>>Нативные языки по своей природе ограниченны, потому что упираются в нижележащие O>>возможности архитектуры и операционной системы. Плюс некоторый "сахар" в виде O>>языковых средств (шаблоны в С++) и набора библиотек, но не больше. O>>Концепция компилируемых языков во многих отношениях свой ресурс исчерпала и дальше O>>двигаться просто некуда. Новые задачи не решаются совершенствованием компилятора и O>>добавлением новых библиотек.
PD>Не трогая C# с его LINQ и лямбдой, ограничусь Явой и С++. Что такое есть в Яве, чего нет в С++ ?
виртуальная машина (бинарный стандарт как следствие)
рантайм-рефлексия
рантайм-подмена/подгрузка кода
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, jazzer, Вы писали:
J>>Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy),
PD>Ну-ну. Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее. На С++ пока не переписывал. Там чистая матричная алгебра.
Ты эти пакеты используешь "голыми" или под ними что-то лежит?
Они ж работают поверх всяких нативных лапаков/атласов/MKL и т.д, а это все дюже скоростные библиотеки.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, monax, Вы писали: LVV>1. Трансляция в виртуальную машину много легче, чем в реальную железную. Так как виртуальную машину можно сделать настолько удобной, насколько вообще можно.
Трансляции в виртуальную машину нет. Есть трансляция в машинные команды или промежуточный язык. Кстати, в промежуточный язык можно транслировать и нативный код — АЛМО напомнить ?
LVV>2. Коды виртуальной машины можно обрабатывать как угодно — от чистой интерпретации до чистой компиляции в нативный код.
И что ? Одно из двух : либо промежуточный язык будет достаточно близок к машинному, либо просядет скорость и существенно.
LVV>3. Опять же если компиляция, то ее можно выполнять самыми разными способами, хоть макроподстановкой.
?
LVV>4. Реализация виртуальной машины на другой платформе гораздо легче, чем реализация полноценного компилятора. Отвязываемся от зависимости по формату исполняемого файла.
Формат исполняемого файла по сравнению с собственно компиляцией и линковкой — мелочи и пустяки, маленький участок линкера переписать.
LVV>5. Виртуальная машина позволяет писать разные части системы на разных языках, собирая их потом без проблем.
И обычная тоже. Это вообще свойство языков, а не машины. Например, С и Pascal , С и Fortran -77 сопрягались без проблем, C++ и Object Pascal — уже с проблемами из-за разного подхода к реализации объектов.
LVV>6. Для виртуальной машины легко реализовать сопутствующие вещи: отладчик, профайлер — у меня студенты на лабах делают. LVV>И сборку мусора проще реализовать — это важно для прикладного программирования. Ошибок с памятью меньше будет.
Это свойство языка, а не виртуальной машины. Вполне можно представить себе (да наверное и существует) язык с нативным кодом и сборкой мусора. Просто в нем не должно быть указателей.
PD>Это свойство языка, а не виртуальной машины. Вполне можно представить себе (да наверное и существует) язык с нативным кодом и сборкой мусора.
Прошу прощения, что вмешиваюсь, похоже очень на D.
Здравствуйте, monax, Вы писали:
M>Новые языки программирования растут как грибы после дождя. Старые набирают комьюнити. На вскидку популярные языки, которые на слуху: C, C++, C#, Java, VisualBasic, PHP, Python, Perl, JavaScript, lisp, scala, Deplhi, erlang, D, Dart, ObjectiveC, ActionScript, Lua, Ruby — какие-то из них мало используются (D), но всё равно на слуху. Так вот, большинство из этих языков интерпретируемые или компилятся в свой байт-код, нативный код из коробки дают C, C++, ObjC, Delphi, D и всё. Почему так мало языков, которые компилятся в нативный код?
Ничего нового не произошло. То же самое было 10 и 20 и 30 лет назад. И тогда были программисты, которые писали на Фортране и С/C++, и программисты, которые писали на Бейсике. И вторых всегда было больше, чем первых.
ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках.
Здравствуйте, jazzer, Вы писали:
PD>>Не трогая C# с его LINQ и лямбдой, ограничусь Явой и С++. Что такое есть в Яве, чего нет в С++ ? J>виртуальная машина (бинарный стандарт как следствие)
С этим соглашусь, но я имел в виду возможности языка.
J>рантайм-рефлексия
Да, в С++ убого. Но могло бы быть лучше.
J>рантайм-подмена/подгрузка кода
Она таки часто нужна ?
В общем, кое-что есть, согласен, но по большому счету мало отличий.
Здравствуйте, jazzer, Вы писали:
PD>>Ну-ну. Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее. На С++ пока не переписывал. Там чистая матричная алгебра.
J>Ты эти пакеты используешь "голыми" или под ними что-то лежит?
Ничего не лежит. Консольное приложение на Питоне, формирует матрицы, вызывает NumPy и SciPy. Как библиотеки реализованы — не интересовался, просто скачал их и вставил вызовы.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И обычная тоже. Это вообще свойство языков, а не машины. Например, С и Pascal , С и Fortran -77 сопрягались без проблем, C++ и Object Pascal — уже с проблемами из-за разного подхода к реализации объектов.
Позанудствую: я не смог прикрутить MS Fortran 5.0 к Borland C не то 2.0, не то 3.1, не помню. За исключением простейшего случая: в вызываемую порпрограмму на Фортране не передавалось никаких параметров. А вот MS C — без проблем. Там С- и фортрановские модули шли вперемешку, и все работало.
PD>ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках.
Не скажите. Тиражные вещи также пишутся и не на нативном коде. Даже для программистов. Например ide от jetbrains. Просто увеличивается отношение объем задачи / время, затраченное на выполнение этой задачи. Поэтому там, где есть смысл пожертвовать временем машины — жертвуют. Там, где нет, — нет. немножко кэпствую, простите.
Здравствуйте, Privalov, Вы писали:
P>Позанудствую: я не смог прикрутить MS Fortran 5.0 к Borland C не то 2.0, не то 3.1, не помню. За исключением простейшего случая: в вызываемую порпрограмму на Фортране не передавалось никаких параметров. А вот MS C — без проблем. Там С- и фортрановские модули шли вперемешку, и все работало.
+1. Я тоже на Борланд не пробовал, а VC6 с Fortan Compaq скрестил без проблем. Благо и IDE одна и та же. Отлаживалось на ура : F11 и мы из С попадаем в Фортран.
Здравствуйте, BrainSlug, Вы писали:
PD>>ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках. BS> Не скажите. Тиражные вещи также пишутся и не на нативном коде. Даже для программистов. Например ide от jetbrains. Просто увеличивается отношение объем задачи / время, затраченное на выполнение этой задачи. Поэтому там, где есть смысл пожертвовать временем машины — жертвуют. Там, где нет, — нет. немножко кэпствую, простите.
Я не спорю, что такие программы есть, но их процент ничтожно мал. Кстати, могу еще один пример привести — Visual Studio IDE, начиная с 2003. До сих пор с тоской вспоминаю VS6 — она летала на тогдашних машинах, а эта тормозит на нынешних, и памяти жрет неимоверно больше. А возможностей (для С++) добавилось хорошо если процентов 50.
PD>Я не спорю, что такие программы есть, но их процент ничтожно мал. Кстати, могу еще один пример привести — Visual Studio IDE, начиная с 2003. До сих пор с тоской вспоминаю VS6 — она летала на тогдашних машинах, а эта тормозит на нынешних, и памяти жрет неимоверно больше. А возможностей (для С++) добавилось хорошо если процентов 50.
Да, действительно. У меня на домашнем до сих пор 6 стоит .
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>+1. Я тоже на Борланд не пробовал, а VC6 с Fortan Compaq скрестил без проблем. Благо и IDE одна и та же. Отлаживалось на ура : F11 и мы из С попадаем в Фортран.
Единственная вещь, которую я так и не сделал — доступ из C к безымянному COMMON-блоку. Правда, у меня есть отмазка: у нас никто безымянных COMMON-блоков не использовал.
Здравствуйте, Privalov, Вы писали:
P>Единственная вещь, которую я так и не сделал — доступ из C к безымянному COMMON-блоку. Правда, у меня есть отмазка: у нас никто безымянных COMMON-блоков не использовал.
У меня другое не получилось. Строки в Фортране
CHARACTER S(100)
и в скобках константа. А я очень хотел размер вычислять, и мог — в C-части, но вот вернуть обратно в Фортран не мог. Пришлось по максимуму заказать.
Здравствуйте, maykie, Вы писали:
M>В нативных Segmentation fault получить. Заметно проще, учитывая наличие почти во всех них Null Pointer'а. Есть исключения вроде Eiffel если не ошибаюсь, но они нафиг никому не нужны. В явах NPE получить тоже не проблема, но там хотя бы красивая трассировка стека будет вместо всяких "память не может быть read"
Безопасность программ это свойство языка, а не среды исполнения. Попробуйте получить сегфолт в хаскелле, например, который компилируется в нейтив.
Здравствуйте, jazzer, Вы писали:
J>А нативщикам остается писать начинку, которой будет рулить какой-нть скрипт, и этот скрипт предоставит удобный и прозрачный DSL для решаемой задачи. J>И это хорошо. J>И пусть таких языков будет больше — людям жить будет легче, и программить смогут даже админы (перл, питон), которым для их поделок нафиг не нужны вяские петтерны и прочие радости "настоящего" программирования.
Легкость разработки и компиляция/интерпретация это вообще ортогональные понятия.
Здравствуйте, Pavel Dvorkin, Вы писали:
LVV>>6. Для виртуальной машины легко реализовать сопутствующие вещи: отладчик, профайлер — у меня студенты на лабах делают. LVV>>И сборку мусора проще реализовать — это важно для прикладного программирования. Ошибок с памятью меньше будет.
PD>Это свойство языка, а не виртуальной машины. Вполне можно представить себе (да наверное и существует) язык с нативным кодом и сборкой мусора. Просто в нем не должно быть указателей.
Точней голых указателей. Умные могут быть. Причем даже не проблема в плюсах сделать менеджер памяти такой как в шарпе : с моментальным выделением памяти и отсутствием фрагментации. Но тогда и при удаленее он будет временами надолго подтупливать запуская сборку мусора.
