Ну чего там с языками программирования и технологиями?

Ну если "некие библиотеки" это например "голый код", без всяких зависимостей - то сколько делфи не корми а у фортрана все равно длиннее

Вопрос только в том, насколько у автора много ненужного времени. если очень много то можно и под 16-битные версии делать и гордиться длинной поддержкой.
Если же там что то вроде интерфейса - то пардон, кросс платформенный UI это кал обычно. Я пытался писать на wxWindows/Qt, интерфейс который пишут "универсальным" либо везде плохонький, либо хорош на одной системе и полный кал на других.
Ну и плюс к тому, паскаль/дельфи в нашем веке это все таки очень старый язык. Поддерживать старый софт еще смысл имеет (см Фортран, Кобол). Писать новый - это уже сильно "на фаната"

Обе это какие из четырех? макость/айось, без часов и телевизора? Телевизор конечно мало кому нужен, а вот часы нынче это сильно модно и востребовано (хотя я лично не понимаю их. )

Помню, как мы с тобой задорно кидались какашками на тему кодировки русского языка )
И как ты не хотел признавать что utf8 полезнее чем 1251 )))

 

Хорошее замечание. Но проблема вроде как решена - фп языки не полагаются на jvm для этого, они стараются использовать специальные технологии (трамплины, например) чтобы обойти эту проблему.

 

Они дженерики сделали только 2010 кажется. Когда в c# и даже java они уже давно были. Сделали анонимные функции но лучше бы не делали, даже на кой то сделали возможность перегрузки операторов. Причем по синтаксису геморрой как по мне. Delphi пользуются в основном для поддержки какого то древнего старья. Ни одного нового нормального проекта на ней припомню.

 

GC да, изначально. VM это скорее свойство не самого языка а его реализации. Первые лиспы были интерпретаторами, вряд ли там рядом была VM.

 

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

 

Байткод вроде на них и появился впервые.
А так были даже специализированные lisp - машины.

 

Не согласен. Таки с/c++ это основной системный язык наиболее близкий к асму и делать его обратно несовместимым это неразумно. Таки это не php, python и прочие недокомпилируемые языки.
Если выпустить компилятор который не будет компилировать старые программы это полный бред. На чем ядра систем компилить будете? На питоне? Практически все системы написаны на c/c++ с вкраплениями асма. А все остальное языковое г. плавает выше

 

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

А можно вопрос - только ты за последние 10-20 лет скомпилировал ядер систем на С++? Не на Си, претензий к которому нет, а именно на С++?

 

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

 

В Дельфях не принято таскать с собой внешние зависимости в библиотеки общего пользования (кроме широкого набора системных либ, естественно).
И правильно. Так потенциальных глюков меньше.

Фортран конечно это моща, но узкоспециализированная. В отличие от.

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

Ну так в дельфях несколько видов гуев. И нативные и кроссплатформенный, и веб. Можно выбрать что тебе больше подходит. При этом отличатся будут только соответствующие библиотеки а не ядро ПО.
Написал ядро и оно может работать под любой ОС.
А ГУЙ можно сбоку прикрутить на событиях. Либо единый, либо нативный, либо даже сразу несколько. В т.ч. и веб-овский.

Qt это такое... да. На мой взгляд его чересчур усложнили.
Гигантский адовый комбайн.

Можно подумать это что-то плохое. Главное что на месте не стоит, а постоянно развивается.

Я эту песню уже лет 20 слышу. Delphi уже лет 20 как умер, ага.
А на чем новое ПО писать - это вопрос, по большей части, человека/команды а не языка. Я про языки широкого профиля говорю, конечно, а не про узкоспециализированные.
На чем твоя команда лучше пишет - на том и надо писать.

Угу макость/айось c разной битностью и наборами инструкций.
А что там с яблочными часами и телеком - без понятия. В РФ с "яблоками" в корпоративном секторе вообще почти никак.
Но под ардуинки всякие на дельфях пишут, знаю.

Там был спор скорей на тему "что приятней" а не "что полезней".

Давно это было. (с)

Это вопрос актуальности твоих знаний. Ну а возможности таковы, что написать можно почти все что угодно.

 

Тут речь о том что к примеру в паскале или c# сообщения вполне конкретно обычно говорят где и что не нравится, вот в c++ такое скорей исключение. Чаще компилятор ругается на что то абстрактное и совершенно не там где причина.
Причем в старом добром C все куда прозрачный было.

 

Как много у нас тут оказывается погромистов
При таком изобилии новые версии МА должны расти как грибы после дождя

 

Ну не совсем разные, таки с++ вышел из С и как называл его создатель С с классами. Которые по сути те же структуры, но с полями доступа и виртуальными таблицами.
Основная разница в том что С это чисто функциональный язык, С++ объектный.
Сам я конечно ядер не писал, не мой уровень, (таки да в ядрах в преимущественно С, что Win что в Unix/Linux), но остальная обвязка идет С/С++

 

Угу. Это при компиляции шаблонов. Пока продерешься через портянку сообщения об ошибке на весь экран.

 

Наткнулся тут:

https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

Energy Efficiency across Programming Languages
How Do Energy, Time, and Memory Relate?

 

Чисто функциональный это haskel. C это императивный ну или процедурное программирование.

С учётом работы меньшей склонности к ошибкам при работе с памятью и прочих синтаксических сахаров у rust много шансов обойти c++ и c со временем IMHO

 

с той поры ну ооооочень много добавили )

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

С++ с натяжкой можно назвать ОО языком, хотя он скорее мультипарадигменный.

 

Ну как бы никто не спорит что чем ближе язык к железу тем более эффективную программу по отношению к ресурсам можно получить )
Когда время программиста не учитывается совсем.

От если мы возьмем не только исполнение, но и написание - тогда низкоуровневые языки будут рулить куда меньше. Ибо обычная ситуация будет "месяц писать/фиксить и секунда исполнения" против "день писать, сразу заработало правильно и минута исполнения".
Понятно, что когда пишут числодробилку "на 50 лет" как разные LAPACK и BLAS, то можно и нужно писать их на си/фортране/подобном.
А другие задачи? Когда речь не о том чтобы "дернуть готовую библиотеку" а "написать самому"?

Например, Рома, я вполне верю что на паскале с нуля, не подглядывая, qsort написать еще можно. И двоичное балансированное дерево тоже можно, хотя и геморрой. А что то уровнем посложнее - уже займет дни/недели/месяцы, ибо большую часть времени займет написание "синтаксического мусора" а не описание задачи.
И то решение будет сильно дырявым, потому что языки роде си встретив конструкцию "4061*4061*4061" тихо и честно сделают ее отрицательным числом (это же так близко к железу !), а программист упомнить каждую такую переменную просто не может и каждый случай проверками не обложил).
А если паскалю включить ovrerflow checking" то вдруг выяснится что хваленое быстродейстие куда то исчезло, ибо паскаль перестал полагаться "на авось" и тратит то же время на проверки (я тут уже не уверен, у паскаля есть такие проверки?) что и другие языки.

 

А зачем писать то, что уже ранее написано?
Устоявшимся языкам уже десятилетия. "Базовые" задачи все написаны давно.

Ну тут ты откровенно придумывать начал.
Результат 4061*4061*4061 зависит исключительно от используемого типа данных. И если программист этого не понимает - ему цена пятак в базарный день.
На эту тему куча ржача про сложение в яваскрипте.
На не типизированную константу в виде 4061*4061*4061 в дельфях компилятор скажет: Overflow in conversion or arithmetic operation
А вопрос влияния на скорость от "overflow checking" не стоит где-то со времен Pentium-1 и 2000 года.
Обычно даже нет смысла что-то собирать не в дебаге. Разницы по скорости ты не заметишь.
Более того кое-где в коде overflow checking принудительно отключают директивами компилятора. Например, в расчете контрольных сумм.

 

А зачем вообще программирование нужно если все уже написано?

Нет. Просто много лет опыта в индустрии.