История изменений
Исправление byko3y, (текущая версия) :
ИМХО случилось Borland и её тотальное страдание фигнёй после Dephi7
Беда случилась где-то в конце 90-х, поскольку еще в 1995 году паскаль был там, где сейчас питон и Си:
https://www.tiobe.com/tiobe-index/
Что случилось между 1995 и 2000 — ума не приложу.
Потом пошёл какой-то трэш и угар и среда вернулась в во что-то более-менее внятное где-то к XE2
Да, XE2 заметно подняло престиж.
А тем временем случилось x64, которое Делфи не умел ну очень долго
Да, это беда большая. Они тащат старый хорошо отлаженный компилятор и отладчик, а новый отладчки x64 — это лютейший глюкодром, который у меня регулярно зависал.
Unicode, ARM, Android
Надо сказать, что проблема юникода не так уж и проста, и многие языки/либы решают ее неоптимальным способом. В итоге в стандартной либе добавили поле кодировки и размера элемента всем строкам, плюс наклепали кучу функций для работы с ними и преобразования между форматами, а это есть весьма большая работа, но результат мне намного симпатишнее костыльных приемов многих сей, вроде utf-8. В частности, ты можешь сделать str[i] и быть уверенным, что пока у тебя в строке обычный печатный текст, то ты получишь символ с этим самым индексом. Отсюда хорошая производительность работы со строками в любой кодировке — а ведь именно это является коньком паскалевых строк.
Тем не менее, насколько я знаю, у embedded FPC довольно популярен
Он популярен там, где нужен Си, но на самом деле не нужен и тяжести наследия нет, а C++ избыточен. Все-таки писать на паскале намного приятнее, чем на Си.
Исходная версия byko3y, :
ИМХО случилось Borland и её тотальное страдание фигнёй после Dephi7
Беда случилась где-то в конце 90-х, поскольку еще в 1995 году паскаль был там, где сейчас питон и Си:
https://www.tiobe.com/tiobe-index/
Что случилось между 1995 и 2000 — ума не приложу.
Потом пошёл какой-то трэш и угар и среда вернулась в во что-то более-менее внятное где-то к XE2
Да, XE2 заметно подняло престиж.
А тем временем случилось x64, которое Делфи не умел ну очень долго
Да, это беда большая. Они тащат старый хорошо отлаженный компилятор и отладчик, а новый отладчки x64 — это лютейший глюкодром, который у меня регулярно зависал.
Unicode, ARM, Android
Надо сказать, что проблема юникода не так уж и проста, и многие языки/либы решают ее неоптимальным способом. В итоге в стандартной либе добавили поле кодировки и размера элемента всем строкам, плюс наклепали кучу функций для работы с ними и преобразования между форматами, а это есть весьма большая работа, но результат мне намного симпатишнее костыльных приемов многих сей, вроде utf-8. В частности, ты можешь сделать «str» и быть уверенным, что пока у тебя в строке обычный печатный текст, то ты получишь символ с этим самым индексом. Отсюда хорошая производительность работы со строками в любой кодировке — а ведь именно это является коньком паскалевых строк.
Тем не менее, насколько я знаю, у embedded FPC довольно популярен
Он популярен там, где нужен Си, но на самом деле не нужен и тяжести наследия нет, а C++ избыточен. Все-таки писать на паскале намного приятнее, чем на Си.