Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 275
Можно найти кусочек паскаля в nim-lang
При чем тут именно паскаль, если все аргументы каксаются исключительно статической типизации. Можно было бы в статье заменить паскаль на С/C++/Java/C# и никакие аргументы бы не поменялись.
Цитата:
ни одного неявного преобразования, ни одной возможности случайно записать не тот тип
C и производные, говорите?
А тут очередная ошибка автора статьи. Неявные преобразования есть и в паскале: https://wiki.freepascal.org/Typecast:
implicit typecasting
Да, С чуть повальяжнее тут, но не принципиально.
Неявные преобразования в Паскале являются лишь синтаксическим сахаром, который позволяет преобразовать одни числовые типы в другие числовые типы и одни строковые в другие строковые. Но не позволяет неявно преобразовать строку в число при математических операциях. Вдобавок ко всему, сложение двух строк, с числами внутри, никогда не даст в результате число, а не строку.
Но, справедливости ради, вручную переопределить операторы между строкой и числом можно, если нужно, но это не является стандартом
Вдобавок ко всему, сложение двух строк, с числами внутри, никогда не даст в результате число, а не строку.
Вы C с javascript не путаете? В си строки не преобразуются в числа. Там есть арифметика указателей, но складывать 2 строки так не получиться.
Я говорил немного в отрыве от Си. Я говорил в целом о неявном преобразовании
Насколько помню, в Си можно сделать Char++. В Паскале напрямую так сделать нельзя.
В паскале нет ++. Там есть inc. И оно отлично работает. Вот этот код выведет b:
program Hello;
var
c: char;
begin
c := 'a';
inc(c);
writeln (c);
end.Вот складывать целые и char нельзя. И вообще сложение символов дает строку в паскале.
Но это детали, совсем не те, о которых статья автора. Да, си чуть менее строгий с приведениями типов, но автора напрягает именно динамическая типизация.
Автор пишет, что его напрягает динамическая типизация, но в пример приводит выражение '42'+10, которое к динамической типизации не имеет никакого отношения (это пример нестрогой типизации, которая может сочетаться как с динамической, так и со статической).
Хм.. как насчет такого кода:
// PascalABC.NET
Print('c' + 5,. 'x' * 10) // c5 xxxxxxxxxx
В си нет строк, так что конечно нельзя складывать то, чего нет.
Это "чуть" является основой одной из классификаций языков программирования (сильная типизация против слабой), и было чуть ли не первым, что замечалось при переходе между Паскалем и Си.
int i=1;
char a='A';
i=a;
воспроизведите на Паскале.
int i=1;
char a='A';
i=a;воспроизведите на Паскале.
А в чем проблема? i=ord(a);
И сразу видно намерение программиста: он хочет присвоить i значение ASCII-кода символа, хранящегося в a. Здесь, конечно, тоже есть неявное преобразование типов (longint в int), но по крайней мере и компилятору, и человеку понятно, что программист хотел сделать именно это, а не ошибся с типом или именем переменной.
Именно эту разницу я и хотел показать примером - там, где C использует неявное преобразование, в Паскале нужно либо явное, либо вообще используются совершенно другие конструкции (ord ведь вообще не преобразование типов). Одинакового конечного результата можно добиться и там, и там. Но в Паскале это именно что явно выраженное намерение программиста, а в C то ли так и надо, то ли человек ошибся/опечатался. С одной стороны, где-то удобнее, с другой - более широкое поле для ошибок.
i=a;
в Си будет преобразованием из byte в int и не более того. В Паскале переменную типа Byte, в переменную типа Integer можно же присвоить?
byte в integer - да
char в byte - да
char в integer - напрямую нет, либо через байт, либо через взятие по адресу, либо явно через ord
з.ы. в принципе вся типобезопасность паскаля отключается если начать работать с указателями, можно взять адрес переменной любого типа, и заставить работать с этим адресом как любой другой тип данных.
var
a:byte;
b:char;
c:integer;
begin
a :=65;
b := @a;
c := @b;
write(a,b,c,byte(c));
end.
//вывод: 65 A ??? 65
??? - мусор в три байта, и один байт = 65.
kotlin надо брать
Ну, помилуйте, батенька, не требуйте от малыша сразу слишком многого. Вот малыш вчера узнал про Pascal. Глядишь, завтра ему кто-нибудь расскажет про существование C. Он и так находится в культурном шоке: оказывается, кроме JavaScript в мире существуют и другие языки программирования! Дайте уму время переварить эту информацию, а там, глядишь, он дозреет и до получения новой информации.
У с есть грешки - технически к указателю на строку можно прибавить целое. Смысл не тот, что в пайтоне, но компилятор не обругает, а программа с UB то ли напишет фигню, то ли вывалится.
На C++ аналогично и расширенно перегрузками. И да, можно писать по-новому, но стрелять себе в ногу никто не мешает.
Впрочем, в паскале через mem тоже никто не мешает в ногу стрелять. А через union и указатели в борланд-разновидностях можно переписывать память типов другими типами, и компилятор тоже не заругается.
Оба языка следят за владением памятью
Только для локальных переменных. В паскале, точно так же как в C, можно выделять данные в куче и работать с указателями. Там точно так же можно 2 раза удалить что-то или работать с данными после удаления. Паскаль гарантирует не больше чем C.
Rust к паскалю настолько же близок, как и к С++.
Вот Java - да - со своим сборщиком мусара сам следит за памятью. Но в паскале сборщика мусора не было.
Иронично, что в свои следующие языки (Modula-2+/3 и Oberon-2) Вирт добавил сборку мусора, но за 30+ последовавших лет её не стали бэкпортить ни в одну реализацию Паскаля
Сборка мусора в паскале сломает очень много старого кода.
в модуле-2 сборки мусора вроде не было, после неё появилась
так это и есть "после неё", версия 2+, ныне умершая.
вот кстати текущая живая реализация
https://gm2.nongnu.org/homepage.html
в ней, согласно Стандарту Modula-2, сборки мусора нет (или я не нашёл)
Да ну? Как насчет PascalАВС.NЕТ? Конечно, по факту он - упрощенный C# в паскалевском синтаксисе, но сборщик мусора в .NET есть, если Вы в курсе.
Паскаль гарантирует не больше чем C.
В отличии от С в Паскале нет неопределенного поведения.
В отличии от С в Паскале нет неопределенного поведения.
Разве в паскале нельзя использовать неинициализированную переменную? Или нельзя прочитать\записать в освобожденую память?
А где здесь не определенное поведение? Поведение будет как раз ожидаемое. Я думаю речь шла о другом
Хм, запрошенные мною две ситуации, это же классическое UB, https://en.cppreference.com/w/cpp/language/ub.html + https://en.cppreference.com/w/c/memory/free.html
На этапе компиляции у переменной появляется адрес в памяти, место резервируется, а без инициализации там просто будут какие-то левые данные. Тут вообще никакого УБ! Запись в освобожденную память тоже норм, т.к. физически она по освобожденным адресам осталась на месте - пиши/читай, пока ОС не видит криминала.
могу предположить, что в определение UB вы вкладываете чтото отличное от общепринятого, например использование переменной до её инициализации приводит к неопределённому поведению.
Цитата, на которую вы ссылаетесь, начинается так:
В языке Си ...
* * *
Я в реальной жизни встречал программу, которая работает много десятков лет, сначала на Фортране, потом на Паскале, используя значение переменной до инициализации (там потом в итоге получается, что это значение никуда не идёт). Современный компилятор C/C++ такую программу запросто бы порушил.
С точки зрения семантики Фортрана и Паскаля, переменная – это просто именованная ячейка памяти, которая всегда имеет какое-то значение.
В паскале это не UB в терминах C. В C чтение неинициализированной переменной имеет полное право отформатировать диск. Этого на практике, конечно, обычно не происходит, но вот
int a;
if (g()) a = 0;
if (a == 0) printf("%d", a);Вполне может вывести что-то, отличное от нуля - компилятор видит, что "если в 
вообще что-то записали, то туда точно записали 0, так что проверку условия можно выкинуть", при этом в printf передать реальный адрес. Т.е. получится поведение, которое нельзя обеспечить никаким значением переменной.
В паскале такое невозможно - там у переменной всегда на самом деле есть какое-то значение. И аналог третьей строчки либо не выведет ничего, либо выведет 0.
Компилятор решает, будет УБ или нет. Если компилятор видит объявление переменной, но при обращении к ней без инициализации считает нужным пропустить резервирование памяти под переменную и выкинуть код обращения, то программист утирается и довольствуется отмазкой - ну это же УБ, вот почему у меня последовательность выполнения протекла. Вот такие нынче понятия, жрите кактус с утроенной силой!
Объявленная переменная в Pascal уже зарезервировала память. Там есть адрес, там есть выделенная область, просто данные там не затерты нулями, а содержится то, что там было ранее. Следовательно чтение и запись туда никак не сможет вызвать UB в понимании Си.
Ну и если читать где-то такую переменную, то анализатор покажет WARNING.
Измените свой пример немного...int *a;ifa = 0;if (a == 0) printf("%d", a);
Теперь тут есть UB т.к. адрес который будет в переменной - мусор. и кто и как с этим мусором работает и кому он принадлежит - нам не известно. а т.к. сравнение приводит к ветвлению и операция вполне себе не атомарна - поведение может быть любым =)
Усугубляет все немножко то что вы неявно работает со значением по адресу а не с самим адресом(хотя какзалось бы...)..
На самом деле, именно объявление бесполезных действий (таких, как чтение из неинициализированной переменной) неопределёнными позволяет компилятору мощно оптимизировать код (например, выкинуть проверку условия в примере выше).
Доопределить поведение для любого синтаксически допустимого кода -- не составляет никакого труда; но стандартизаторы Си его намеренно не доопределяют, чтобы оставить компиляторам возможность оптимизировать код.
Про запись в освобожденную память - оно бы может так было, если бы физическая была память доступна приложению напрямую. Но при работе с операционной системой это не так
Типизация от этого спасти не может. Из плюсов Паскаля, что он помогал аккуратно применять типизированные переменные и препятствовал арифметике указателей. Для своего времени это был шаг вперёд большой.
Но те задачи, за которые взялся Rust в Паскале не были решены и не могли быть решены в то время
Неициализированные переменные в PascalАВС.NЕТ использовать можно, но .NET-среда их все равно инициализирует. Конечно, всегда найдется оригинал, который описывает объект, но не создает его, но и это мгновенно отлавливается средой.
Ну какая вам разница, написано ли в стандарте, что программа будет работать "непонятно как" при некорректном коде, или что программа будет работать неправильно. Паскаль точно так же не ловит use-after-free при компиляции.
В паскале таки есть сборщик мусора, не полноценный, но лучше , чем ничего - конкретно строки, динамические массивы и объекты интерфейсов уничтожаются сами
Нет. В Delphi есть пул строк со сборкой мусора. В Паскале ничего это нет (насколько я помню, для не-констант 256 байт памяти на строку выделялось). Просто строки и массивы можно было в стеке размещать. Просто и изящно (впрочем это не изобретение Паскаля и стек решает задачу только применительно к статическим переменным заданного размера)
Вы снова открываете холивар "строгая типизация против не строгой".
Мне кажется, тут надо понимать, как использовать преимущества выбранного языка, а не указывать на недостатки. Кто-то отметит, что отсутствие автоматического кастования - это слабость языка. В Паскале вообще нельзя перегрузить оператор "+", чтобы такое реализовать.
А вот взять к примеру Lua - не строгая типизация в нём - заранее продуманная фича. И вообще вся философия языка на этом построена, что всё что угодно - в первую очередь таблица, а уж потом данные каких-то типов.
Или, например то, что в PHP выражение "1abc" + 2 будет равно 3, это тоже фича. Кому надо типизацию построже - отключит нотисы или укажет явно типы данных.
А Паскаль попросту устарел. Да и на свои программы на нём конца 90-х - начала 2000-х не могу смотреть без боли, хотя в своё время много чего успел на нём написать, в т.ч. околосистемного. Режет глаза в основном кодстайл тех времён.
Так что даже сейчас я бы не хотел советовать его новичкам, тот же python для основ программирования куда лучше, хотя бы по тому что учит писать сразу красивый код.
тот же python для основ программирования куда лучше, хотя бы по тому что учит писать сразу красивый код
так это он сейчас красивым кажется, как и код на Pascal из 2000-х. а лет через 20 будете джуниорам рассказывать, как нашли свой исходник на python из 2025 и ужаснулись...
Ну мне код на Pascal сразу же (как только я познакомился с C) казался некрасивым чисто визуально.
Зашумление ключевыми словами, когда за begin ... end логики не видно (не смотря на то, что долгое время на Pascal) продолжал писать.
Так что код на Pascal - из-за его синтаксиса - действительно не образец изящества.
Судить о красоте кода по фигурным скобкам и begin .. end -- всё равно что судить о красоте поэмы по цвету её обложки
А для вас визуальная зашумлённость/незашумлённость синтаксиса - по важности эквивалентна цвету обложки поэмы?
Я ваше "экспертное мнение" правильно понял?
А в чем захламленность? Чем это отличается от того, если там будут "{}"? При том что для try/catch вы вынуждены ставить ещё одни операторные скобки, а в Pascal - нет. Для указания выражения в условиях и циклах - всегда требуется указать "()", а в Pascal - нет.
> зашумлённость
...а в чём захламлённость
... определите что синтаксис критически зашумлён (другой собеседник)
... не зашумлёнными у них считается -2%{2+.2/@*\/10.3??2*+ (третий собеседник)
В чём смысл перевирать мои слова? Это форма демонстрации социальной righteousness через "посмотрите какой он плохой", и не важно, он такого не говорил и вы пытаетесь пинать соломенное чучело, или в этом есть другой смысл?
> в чём зашумлённость / чем плох стиль?
Сам стиль мне не нравится.
Причём не просто "вкусовщина" - а за длинными именами и двойными вместо четверных пробелами поток управления не схватывается "на лету". TListBoxChatList / TListBoxItemChat - визуально трудноотличимы. И уже если вы эти первоочередные проблемы зашумлённости подчистите - излишне громоздкие и отвелекающие внимание begin / end начнут бросаться в глаза.
То есть тут в целом должно быть вдвое меньше символов.
Все плюсы (быстро напрогать POC и возможно MVP) и минусы (программа после некоторого количества десятков тысяч строк становится труднорасширяемой) - программирования в окошках Дельйей оставим вне контекста рассуждения.
Но в целом - так и хочется JSONChats сгенерировать отдельной ф-ией.
Для меня, если в коде используются везде сокращения: вместо ListBox - lb, вместо ListItem - li, вместо Json - js, и прочее - это говнокод. Откровенный говнокод.
А вообще, подобное приплетать к языку - глупость. Это не зависит от языка. Это стиль написания, который зависит от человека.
"если вы в innermost loop итератор называете не li, а ListItem - это значит, что за свою жизнь вы написали мало циклов".
ListItem - li, вместо Json - js
li - выглядит отлично
js - не знаю, мне не видится это общепринятым обозначением (но это очень далеко от области моих интересов и профессии - я системный программист).
Вообще почти идеальным для меня выглядит библиотечный код Хаскеля:
1. Ввести хорошо устоявшиеся короткие обозначения (имеющие довольно очевидные базовые истоки в предметной области)
2. Использовать их - за счёт минимума лексической зашумлённости - при взгляде на код сразу видно важное: структура кода (а не JSONListBoxItem (и думай что тут лексический шум, а что нужно)), что очень экономит время.
Я всегда и везде пишу полные имена. А на моем счету десятки огромных и сотни больших (до 500к строк) проектов
Я всегда и везде пишу полные имена. А на моем счету десятки огромных и сотни больших (до 500к строк) проектов
Написано так, будто вы это самолично написали (иначе девочка технический писатель может засчитать себе сотни проектов к которым она только документацию по ГОСТ оформляла).
Давайте подсчитаем:
500к строк * 200 (минимум от "сотни") = 100_000_000 строк кода.
100_000_000 / 30(лет стажа) / 365(дней в году) = 9500 строк кода каждый божий день.
Э... надо осетра урезать. Или быть существенно аккуратнее в формулировках.
Во-первых, ДО 500к - это проекты 50к, 100к и т.д.
А стажа у меня всего 12 лет.
Кода я очень много написал за это время. Мой репозиторий легко это подтвердит.
больших (до 500к строк) проектов
Во-первых, ДО 500к - это проекты 50к, 100к и т.д.
"Скидка до 90%".
Но вещь подорожала в 2 раза!
"но -100% скидки это до 90%, так что технически мы не соврали".
Вести диалог с человеком, который "технически не соврал", но разброс его цифр сходу разнится в 10 раз - пустая трата времени.
За сим прощаюсь.
Это ваше личное заблуждение. Потому что фраза "количество чего-то до N размером" - это не вводящая в заблуждение фраза, а вплоне уместная и общепринятая. Потому что смысл её в том, чтобы показать количество чего-то, размером до N.
И почти в каждом таком проекте будет хотя бы один, написанный мной, цикл.
Сам Вирт в последующих языках убрал избыточные begin в половине конструкций
А вы бы сначала определили понятие "зашумлённый синтаксис" и то, как определить, что синтаксис как-то критически зашумлён, или не зашумлён вообще.
Наверное не зашумленым у них считается всякие гольф на perl/ruby, типа -2%{2+.2/@*\/10.3??2*+
Каждая закорючка что-то да делает, а про читаемость кода никто не думает, на мой взгляд любой код на Pascal, тем более Rust на порядок более читабелен, чем типичный код C/C++
Но давайте напишите на C/C++/Java например объявление функции
Procedure Foo(const a,b,c,d,e:Word),
Хочу сравнить зашумленность, сколько раз встречу const unsigned int вместо одного const Word?
Обожаю я рунет. Везде, где движок общалки (форум, соцсеть) дает возможность обосрать пишущего, его обязательно обосрут.
Вирт делал свой язык специально для студиков. И не современных, а тех, кому сейчас уже за 70. Поэтому его язык такой многословный. Надо ему сказать спасибо, что в его языке не надо писать clauses вида:
Please, be so kind prepare to follow these instructions. Are you ready? So, begin with ..., then do ..., after that do ..., and in the end, please do .. . Thank you.C же делали суровые мужики, которые с помощью ЯП хотели деньги зарабатывать, а не показывать, насколько виртуозно они владеют языком Шекспира. Поэтому в C нет таких длинных слов, он обходится скобочками.
Язык не создавался "для студиков" это заблуждение. Pascal создавался не "для кого-то", а с целью создать язык, который легко изучить и писать на нём. Это уже впоследствии язык стали применить именно для обучения программированию, потому что это было намного удобнее
Да, вы правы, специально "для студиков" он не создавался. Но это заблуждение, как вы справедливо выразились, у нас в ходу.
Вообще, Pascal по своим keywords сильно напоминает BASIC. С оглядкой на него, видимо, и делался. Не знаю, может, на персоналки 1970-х годов тогда C не завезли, поэтому американских студентов учили на BASIC и на Pascal.
Но когда таки C на персоналки завезли, Pascal утратил ореол какой-то своей особости, и стал точно таким же языком, как и все остальные. Хошь учи Pascal, хошь C - разницы нет.
А вот в России 1990-х Pascal стал почему-то особенно популярен именно в вузах. Видимо, нашим не рассказали, что кроме него есть еще другие языки.
Не знаю, может, на персоналки 1970-х годов тогда C не завезли, поэтому американских студентов учили на BASIC и на Pascal.
Студенты 1970-х и даже 80-х учились не на персоналках, а на больших компьютерах; и Бейсик, и Паскаль создавались именно для них. Первая реализация Паскаля для персоналки -- это конец 1979, так что "персоналки 1970-х годов" ну никак не могли внести вклад в популярность Паскаля.
Вирт делал свой язык специально для студиков. Поэтому его язык такой многословный. C же делали суровые мужики, которые с помощью ЯП хотели деньги зарабатывать, а не показывать, насколько виртуозно они владеют языком Шекспира.
На самом деле, причина намного прозаичнее: Вирт писал Паскаль для CDC-6000 с полумегабайтом памяти, и мог себе позволить понятный синтаксис; а Ритчи писал Си для PDP-11 с 4 КБ, и вынужден был экономить каждый байт.
Я помню переход с бейсика и ассемблера на паскаль 35 лет назад. Было ощущение, что пишешь кучу бойлерплейт-кода. Но потом программы стали больше – и строгая типизация начала реально помогать.
Сейчас, кстати, со строгой типизацией ещё лучше: есть вывод типов, о котором тогда и не мечталось.
Питон и сейчас выглядит ужасно)
В старом Паскале нельзя, в новом - можно
В новом - да. Но это уже не классический паскаль. Это его развитие. Покажите мне код перегрузки операторов, который скомпилируется в Borland Turbo Pascal 7.1 (вроде бы это последняя версия того самого классического паскаля), я полностью с вами соглашусь. Дальнейшее развитие - это уже Delphi а также Free Pascal и Lazarus или даже Pascal ABC где все пошли своим путём, это уже диалекты. Причём не факт что совместимые друг с другом.
Так ведь Borland Turbo Pascal не закончился когда-то, а просто сменил название и до сих пор развивается. Брать одну старую какую-то версию не совсем честно. Delphi ничего не изменил или потерял от своих старых версий, а лишь расширил. Всё, что можно сказать о старом Турбо Паскале, можно сказать и о Delphi
Pascal, в лице его потомка - Delphi, развивается и имеет большое количество новых возможностей. И перегрузка операторов и инлайн переменные и введение типов и анонимные функции и более удобную работу с динамическим массивами и прочее, прочее
Оба языка следят за владением памятью (в Pascal — статически, в Rust — через систему ownership).
Очень странная формулировка. Система владения в Rust - тоже статическая. Также там есть и динамическая, через типы с ref-count (Rc) и т.д. Статической системы владения в Pascal нет, и вообще я не знаю ЯП кроме раста где она бы существовала. В паскале есть динамическая система владения, через типы с ref-counting как и в расте. Статическая типизация здесь ни при чём. Также в обоих ЯП есть освобождение локальных переменных, видимо это и имелось в виду под "статическим владением" в паскале.
ПС: классический пример когда человек пишет на Rust как на паскале :( Из проблем, например, что переменная min в такой реализации должна быть мутабельной. А почему собственно? Это же неизменяемый минимум неизменяемого массива.
let min = [4, 7, 1, 9, 3].iter().min().expect("bad array");
assert!(min == &1);
Так ведь min в коде поста вычисляется вручную и значение меняется по ходу перечисления массива
Да, но после этого никак не объявляется, что значение min после вычислений зафиксировано и менять его нельзя. Точнее это можно сделать, используя такую фичу Rust как ре-декларация переменных, но это некрасивый хак:
let mut min = some_value;
let min = min;
Её семантически нельзя менять, т.к. минимальный элемент ведь не изменится, однако по коду, там как и должно стоит мутабельная переменная. Потому что в данном алгоритме нужна именно она. Внутри функции min тоже находится мутабельная переменная, которая потом возвращается как результат выполнения
Её семантически нельзя менять
Семантически-то нельзя, но компилятор этому не помешает, в отличие от иммутабельного min:
let mut min = data[0];
// вычисляем минимум как раньше
assert!(min == &1);
// 1000 строк
min = &2; // ну мало ли захотели другой какой-то минимум посчитать
// ещё 1000 строк
println!("Минимум массива [4 7 1 9 3]: {}", min); // ой забыли что min менялся
И лучше бы её вообще не отдавать наружу функции min как мутабельную, если мы уж пишем min руками:
let min = data.iter().reduce(|min_internal, x| cmp::min(min_internal, x))
.expect("bad array");
Хуже то, что вместе с введением статики мы получаем негибкость и хрупкость программ, а также теряем удобную разработку через образ как в Lisp и Smalltalk. Поэтому подход Python, подсмотренный у Newspeak и такого человека как Gilad Bracha, выглядит нормальным компромиссом. Пусть будут pluggable types, только не надо, чтоб они влияли на рантайм.
Хуже то, что вместе с введением статики мы получаем негибкость и хрупкость программ
Ну негибкость-то понятно. Но хрупкость? В лучшем случае, мы получим приложение, которое работает "непонятно как" вместо того, чтобы упасть. Мне кажется, что в подавляющем большинстве случаев, мы хотим второе.
теряем удобную разработку через образ как в Lisp и Smalltalk
Подход, конечно, классный. Но был ли он когда-нибудь хоть сколько-то распространен, чтобы говорить о "потере"? Вероятно, сколько его было в той нише, столько и осталось.
Что из этого есть в современном питоне?
Вообще, мне кажется, современные динамические языки скорее взяли худшие черты, профукав преимущества. Поэтому популярнейшие из них типа питона и js скорее смещаются в сторону статики.
Динамизм ли определяет мощь лиспа? В некоторой степени, но без гомоиконичности магии не будет.
Пусть будут pluggable types, только не надо, чтоб они влияли на рантайм.
Что до рантайма – динамика скорее ассоциируется с некоторым пенальти по производительности. Учитывая, что современные массовые практики использования динамических языков не пользуются главными преимуществами, а скорее стреляют себе в ногу, то я скорее за ограничение распространения динамических рантаймов.
А более динамические юзкейсы, мне кажется, уползают в сторону каких-нибудь Jupyter (и org-babel для тех кто знает толк).
Динамические типы не дают пенальти по производительности при разогретом JIT, что было доказано командой языка Self на практике. Они сделали JIT, когда ещё термина такого не было.
Наверное имеется в виду что в Питоне может быть условная статика вроде type hints, вплоть до пометок в комментариях а-ля Doxygen, которые позволяет некоему внешнему мета-инструменту производить моделирование и согласование типов. Поэтому сам язык выступает как кристалл с динамикой который может быть вставлен в оправу со статикой или её эквивалентом. Важен именно сам подход, а далее под него уже отдельный инструмент либо сам компилятор либо IDE либо рантайм (как раз на случай падения, привет assert-ам проверкам int overflow и границам итераторов из мира статики).
Ну, тайпхинты и внешний верификатор типов сейчас много где появляются. Поскольку были упомянуты Newspeak и разработка через образ – я подумал, что речь именно об этом.
Правда, про Newspeak я особо ничего не знаю, но при упоминании рядом с лиспом и смоллтолком, я подумал именно про образ.
В какой-то момент мне нужно было поиграться с данными, и я решил попробовать что-то похожее, начал искать какие-нибудь REPL-alike тулы и подходы. Но все что находил, было похоже либо на игрушку, либо было для clojure, то есть опять-таки сводилость к лиспу.
В сторону питона я не особо копал, скорее искал что-то вокруг js – подумал сейчас, вдруг пропустил там что-то важное.
А в тот раз, потыкавшись, я вернулся к понятному окружению emacs, поиграл с данными через org-babel и успокоился до следующего раза.
Может быть, кода в следующий раз вопрос встанет, снова попробую копнуть, уже в сторону clojure или внимательнее поищу какие-нибудь пайплайны вокруг elisp.
А можно узнать, в чем "негибкость" проявляется?
Наверное, на примере C# лучше всего видно, что его дженерики несколько ограничены. Конечно, Haskell в этом плане поинтереснее, но даже этот язык не предел выразительности в плане типов (привет Idris и зависимые типы). И вот поэтому мне нравится подход с несколькими разными "подключаемыми" системами типов.
Мне всё ещё не совсем понятно. Можно как-то конкретнее?
Что-то не могу придумать нормальный пример. Ну, например Система F более гибкая чем просто типизированное лямбда-исчисление.
Типы давно уже достигли оптимума в соотношении польза-удобство. Зависимые типы уже могут сделать написание типа сложнее, чем решение самой задачи, поэтому за 30 (если не 40) лет разговоров они дальше специализированных языков не ушли и никогда не уйдут.
Достигли дна, но снизу уже постучали. Нейросети - это отдельный тип данных, ещё более динамический. Добавить ещё определения вроде |int,float> соответствующие кубиту, который говорит, что переменная вроде бы int но ещё и не float, об этом знает только кот Шрёдингера. Ну а если по существу - то компромисс между моделированием, моделью и встраиваемыми явными и неявными элементами. Статика также содержит проверки как и динамика, вопрос куда тянуть этот канат это дело скорости разработки умноженной на эффективность кода нежели уже языка или библиотеки.
Пожалуйста хватит называть типобезопасностью просто статические типы и невозможность сложить строку и число. Динамически типизированные языки никогда не должны были стать популярными
К сожалению, должны. Когда дешевизна разработчиков имеет более высокое значение, чем качество.
Динамически типизированные языки всё ещё заставляют думать о типах, только гораздо сложнее - не видя и не контролируя их в коде. Так что это более требовательные к разработчикам языки
Без типов разрабатывать что-то большое как раз сложнее
Откройте практически любую библиотеку на питоне, там будет все с типами. Почему? Потому что так проще и понятнее, а значит дешевле и быстрее
А так же обёртки, типа .NET Framework, сборщики мусора, разбросанные в памяти данные, простейшие типы, обернутые в классы, миллион операций для простейших действий с данными и ещё миллион под капотом, тысячекратная потеря производительности при использовании всего этого хлама. Люди перебросили всю ответственность на рантаймы, не желая контролировать свои данные и ход выполнения. Это да, это - современные реалии. Для исполнения сотни строчек кода нужен обвес вокруг исполняемого файла в виде манифестов, библиотек, кучи мусора, без которого, на самом деле, всё способно отлично работать
А нужно ли это тысячекратное ускорение в прикладных задачах? Современные процессоры вполне переваривают все эти обвязки, вызванные особеностями высокоуровевых ЯП. А если требуется добиться максимальной скорости в узких местах, тот же .NET позволяет переложить выполнение кода в unsafe-область при помощи CLR, либо же P/Invoke. А там, пожалуйста, и SSE, и AVX-512 и прочие прелести...
И нужно и нет. Если для поднятия условного калькулятора тянется миллион абстракций и мусора - это выглядит просто глупо. Я могу понять такой подход для задач, где без этого можно просто утонуть, потеряв видение глобальной задачи, пока занимаешься реализацией относительно стандартных конструкций, здесь пожалуй можно закрыть глаза на некоторую избыточность.
А нужно ли это тысячекратное ускорение .. ?
Просто нужно помнить, что вместо 10 000 серверов, можно было бы обойтись 10.
Вот и всё.
Сможете ли привести пример на каком языке, в какие сроки (конечно же короткие), какими специалистами можно написать бэк для какого нибудь онлайн массмаркета, где не будет этих тысяч абстракций и обвесов, при этом время реакции для поддержки программы и создания новых фич будет минимальным. Мне кажется, что только языки высокого уровня на это способны.
А вообще, наверное, для каждой задачи свои инструменты и языки, если хочется быть ближе к "железу", то нужно идти и прогать железки, а не заниматься "оптимизацией" того же веба, где клиент лишнюю секунду на загрузке данных может и подождать.
Почему же ностальгия. А как же FreePascal?
Если уж речь пошла про Rust и типобезопасность - то не использовать Option в функции возвращающей минимум - осквернение типизации.
В целом - Pascal прекрасный учебный язык, но его время ушло (Python уже обзавёлся типизацией), закопайте уже стюардессу.
На Паскале , благодаря его продуманности, программы очень быстро компилировались. В старые добрые времена (конец 80-х, начало 90-х) это преимущество было важнее многих других, заметно увеличивая скорость разработки (примерно как Питон впоследствии). А программы, на нем написанные, работали, увы, медленнее.
Сейчас большинство популярных языков не смогут похвастаться скоростью выше, чем у того старого Паскаля.
Скоростью чего? Компиляции?
Так Pascal был "однопроходной", поэтому и скорость выше
Нет, скоростью работы конечного кода
вообще говоря сейчас вряд ли кто то из команды Pascal/Delphi занимается объёмом работы по оптимизации компилятора особенно под новые SSE/AVX, не говоря уже про GPU-расширения и др. Это задача уже либо монстров GCC (откуда скорее всего и заимствовано ядро оптимизации инструкций) или наборов компиляторов Intel, но для C/C++/Fortran или Microsoft для C/C#/VB. Скорее всё максимум застряло на MMX в 90-х на пике Borland. Сейчас же Pascal это скорее обёртка над сгенерированным C вплоть до файла в памяти и нативной прямой оптимизацией языка под процессор никто не занимается.
Но это не так.
SIMD / SSE + SSE2 + SSE3, AMD-SSE4A - поддерживаются с XE4 (2013)
SSE4.1 и SSE4.2, AMD 3DNow - c XE5
AVX2 и AVX-512 - с D10+ (2015)
Под кроссплатформу вообще используется LLVM и его преимущества
А всё остальное вообще вами откуда-то выдумано
Это просто предположение, хорошо если так. Просто оптимизатор под процессор очень не тривиальная штуковина, особенно с учётом особенностей кеша, порядка команд, векторных расширений, и отдельной командой для языка, не входящего в Топ-10 его явно невозможно мейнтейнить (собственный компилятор). Скорее всего там взят GCC на уровне Generic/Gimple, который уже сам на выходе поддерживает указанное с фронтендом на bison/flex.
Вы не правы. Delphi - это древний продукт, написанный в свое время с нуля. Никакой "оберткой над C" она никогда не была. У них есть отдельный C++Builder - вот его-то с какой-то натяжкой можно назвать "оберткой над Delphi". У них в их C++ даже расширения специальные есть, например
__propertyчтобы поддерживать фичи из Delphi.
какое прямо восхитительное невежество =)
Просто исходя из этого, там предстоит довольно большой объём работ и в комментарии указан один из вариантов решения проблемы =)
На Паскале , благодаря его продуманности, программы очень быстро компилировались.
Ну С++ знатно обделались с "синтаксическими шаблонами" и их инстанцированием (есил что - C-define работает на лексическом уровен, С++ template на синтаксическом, Interface / rust Trait / haskell typeclass - на семантическом).
Собственно это один из важных факторов появления Go.
А программы, на нем написанные, работали, увы, медленнее.
Просто Borland написали довольно слабый компилятор, в сравнении с icc / gcc / MSVC.
Ну так это началось довольно давно. Изначально как интерпретатор (стр. 128/248). Та самая P-машина (взятая за основу под Go). Вообщем если бы Pascal ещё в то время свернул по пути Python, как некий Бэйсик с классами, может быть сейчас он и был в топе. Но решили все усилия похоже пустить на эффективность, а это очень затратно хоть и занятно.
Какой ещё "Бэйсик с классами"? По вашей ссылке никаких классов нет, да и не было их "ещё в то время".
"Паскаль с классами" (Object Pascal) появился в 1986 году
У @TimurZhoraev ссылка на документ 1980, и "ещё в то время" Object Pascal не было даже в планах.
Имеется в виду то, что к тому времени были по меньшей мере Smalltalk а также Simula (которая почти что Паскаль). Бейсик с классами в плане того что упростить синтаксис и ввести на то время нечто новое, хотя бы управление объектами. То есть в начале-середине 80-х время на раскачку вполне себе было. С++ появился в 83-м, то есть как раз примерно +- в то время. Концептуально-теоретически проработан ещё раньше. Всё равно что сейчас эволюция ИИ за эти 5 лет. По ссылке приведён пример того, что изначально язык для простейших ПК был интерпретатром, как и Бэйсик для Спектрума (примерно в то же время появившийся) умещающийся в 16 кБ УФ-ПЗУ. Потом заострили внимание на компиляторе и похоже не смогли что-то добавить ключевое в язык, что он проиграл по факту гонку Плюсам и Питонам. Взлёт был похоже по одной причине - участие в школьной программе.
Simula (которая почти что Паскаль)
Сходство в использовании begin и end, и прочего унаследованного из Алгола синтаксического оформления?
На таком уровне рассмотрения и Java почти что Си :)
Так и есть с точки зрения лексера и синтаксических единиц. Главный постулат - язык должен быть легко читаемым и в глаза при просмотре по диагонали бросаться то что нужно для осознания того что происходит. И чем меньше синтаксической ряби тем лучше, но и предельные варианты языка уровня регекспов также не вариант. Золотая середина в этом плане уже изобретена, включая лёгкость кодогенерации и отладки. Зрительно тяжело ставить точки остановки на begin-end даже если они автоматом переносятся на +- строку, это выглядит как артефакт. Плюс, допустим, поставил и запомнил строку 94 на которой begin а по факту это 95, с которой начинается код. Но 94 я уже прописал где-нибудь в кодогенераторе или автоматическом дебаггере. Гораздо удобнее визуально разделять слова и символы нежели подсветку синтаксиса.
Кстати идея - превратить Паскаль в Питон, когда в IDE сделать begin-end белым шрифтом на белом фоне. Плюс для некой автоматизации сложно будет парсить begin_my_variable begin_of_segment в отличие от {} которые есть уникальная синтаксическая единица. В Паскале сочли что этим самым проще отсекать комменты, включая (**), чем группировать код или создавать области видимости. Про := уже и говорить не приходится. Статистически = гораздо чаще и удобнее как присваивание, а == реже в условных операторах. То что наиболее часто используется должно быть в один клик или нажатие. Можно было бы вполне сделать как в Maxima : это присваивание а = это равенство или сравнение. Работа с указателем удобна жирным и посредине * а не ^ который где-то в верхнем регистре и можно спутать с возведением в степень, ставшей стандартной даже на калькуляторе. Плюс имя^ и ^тип не читабельно, тип объявляется единожды а переменная может использоваться часто. Зрительно ^var было бы лучшее решение как *ptr, сначала видно что это указатель а потом что за имя. Но похоже задача стояла сделать что-то зеркальное С. Пользователь ленив и это надо было учитывать.
Зрительно ^var было бы лучшее решение как *ptr
В Паскале намного лучше сделано, чем в Си. Допустим, у нас есть указатель p на структуру с полем f. Хотим получить структуру, в Паскале пишем p^, в Си *p. Теперь добавим доступ к полю: в Паскале разыменовали указатель p^ и добавили доступ к полю .f, получили p^.f; в Си разыменовали указатель *p, нужно добавить доступ к полю, приоритет операторов бьёт по рукам, и получаем изумительно неэргономичный код (*p).f. Само собой, эта нелепость синтаксиса никого не устраивала, и пришлось делать сахарок ->.
В то время P-машина работала недопустимо неэффективно для коммерческого программирования.
Проблема серьезная. Языков программирования, много, но ошибки все теже. Какое-то топтание на месте. Либо яп, более менее читаемый (JS) но нет обязательной типизации, либо есть, но очень плохо читаемый (rust), либо она не обязательна но везде $ (php 8 испортили уже), либо в языке бесконечное множество стандартов и он не читаемый (c++), либо бесконечное количество проверок на err (go). Нет одновремено стабильности, читаемости, производительности, гениальной простоты с гибкостью, с zero trust подходом. И null, полезная вроде явление, но сколько в этом проблем.
Я не доволен и думаю что когда нибудь, будет новый яп, в котором учтут проблемы и опыт прошлых лет.
Что не так с Котлином, например? или с C#?
Котлин слишком избыточен и переусложнен. Наверное он повторит судьбу яп Perl.
в C# сейчас нет алгебраческих типов и контроля мутельности переменных. Ну и рантайм с GC, что ограничивает применение в системном программировании.
C++ CLR, P/Invoke, unsafe и AOT compilation.. Но да, алгебраических типов нет, вотж беда для универсального и кроссплатформенного языка программирования, имеющего брата F#, в котором есть конкретно это или что-то подобное и они могут взаимодействовать друг с другом.. (Сш и фш)
C++ CLR, P/Invoke, unsafe и AOT compilation
Причем тут C# и C++ CLR? Мы про язык говорим, а вы перечисляете возможности рантайма. Ну и AOT compilation и возможность вызывать нативные библиотеки это не какой-то уникальная фича, которую можно было бы считать поводом для гордости.
вотж беда для универсального и кроссплатформенного языка программирования
Довольно странное заявление когда рядом есть еще десяток универсальных и кроссплатформенных языков.
что и со Свифтом. языки фактически прибитые к платформе
К какой платформе, к линуксу? А это плохо?
очевидно же: свифт прибит к эплу, котлин к андроиду, шарп к винде (хоть и портировали лучше остальных, но популярность на неродных платформах под вопросом)
а на других - извините, тулчейн неполный, инфраструктуры нет, библиотек нет, вызов системных функций нетривиален...
свифт прибит к эплу
Единственное верное утверждение
котлин к андроиду
Котлин это JVM, каким образом он прибит к андроиду? Вы можете программу на котлине хоть на стиральной машине запустить.
шарп к винде
Практически все новые продукты на .net, в том числе у майкрософт, имеют линукс как целевую платформу. Чем именно он "прибит"?
тулчейн неполный, инфраструктуры нет, библиотек нет
Это какого тулчейна у джавы нет на линукс? Или у .net? Каких именно библиотек нет? Хотя бы одну можно назвать?
вызов системных функций нетривиален.
И чем же syscall в JVM через JNΙ или P/Invoke в .net так не тривиалено отличается от syscall вызова в С++?
Это какого тулчейна у джавы нет на линукс? Или у .net? Каких именно библиотек нет? Хотя бы одну можно назвать?
А зачем приплетаем Яву? Речь о котлине. Пусть отличие в языке и минимальный, но писать полпрограммы (например интерфейс) придётся на Яве.
Так можно писать и на Расте с ассемблером вперемешку, проблем нет (с)
Что именно мешает вам писать UI /"интерфейс" целиком на котлине? На остальные вопросы ответов нет, правильно понял?
В смысле берём main на Котлине и вызываем методы, скажем JavaFX?
Я же сказал: можно, но мало кому нужно.
По дотнету, пока Студия не будет работать нативно на том же линухе, это останется нишевым и малораспространенным применением.
В смысле берём main на Котлине и вызываем методы, скажем JavaFX?
Например или изначально пишет на котлине через Compose Multiplatform.
Студия не будет работать нативно на том же линухе
В чем проблема использовать Rider на линуксе?
это останется нишевым и малораспространенным применением.
Зачем вообщем вам студия чтобы писать на .net? Что такого от нее вам нужно, чего вы просто командную строку и LSP сервер получить не можете?
Кстати, в процессе чтения этой статьи поймал себя на мысли, что Pascal намного понятней синтаксически. Там почти нет магии, можно читать буквально что написано.
JS более читаем, чем Rust? Серьёзно?
JS рождался как срипт на коленке для придания динамичности статичному HTML.
Кто тогда в Netscape думал, что это скриптовое простенькое Ховно (на момент создания) будет когда-то всерьёз использоваться для серьёзной разработки интерфейсов или тем более на серверах?!
Но беда в том, что в погоне за дешевыми кодерами (даже без профильного образования) и веб-кросплатформенностью т.н. "эффективные мЭЭнеджеры" сделали ставку на веб-мординг - ну и понеслась.
С другой стороны чистый Pascal язык сугубо академический. На нём почти ничего массово не писали.
Тот Pascal которым до сих пор пользуются - это Object Pascal (Delphi / Lazarus).
А в ObjectPascal как раз испокон веков для удобства хранения любых типов есть динамический тип данных Variant .Этот тип по реализации несколько отличается от dynamic в C# или Dart, и по скорости работы конечного кода чуть более эффективен.
НО при его использовании тоже запросто словить ошибку времени выполнения.var
V1, V2, V3: Variant;
begin
V1 := 'aaa';
V2 := 1;
V3 := V1 + V2; // Здесь будет EVariantError во время исполнения...
Другое дело, что в таких языках как ObjectPascal объявляя переменную как Variant вы как бы понимаете зачем вы это делаете, а значит и осознаёте свою ответственность.
Тогда как в скриптовых и изначально динамических убожествах типа JS у вас просто нет выбора.
А когда в больших проектах на JS осознали "масштаб трагедии", то и стали прикручивать и продвигать всякие костыли типа TypeScript.
Кстати, хорошо хоть Google сейчас активно пытается исправить часть бед динамических скрипто-убожеств, активно продвигая такие языки и opensource библиотеки со строгой статической типизацией как Go или Dart (Flutter).
Js стал ассемблером web. Дикий шаг назад.
Человек предполагает, а Бог располагает.
Лучше бы готовый object pascal использовали )
Проблема статики - это изначально непоколебимый, единственный выбор руководящей и направляющей линии партии архитектуры. Это годно для нечто того, чей лайфтайм будет отсчитываться по количеству трудовых договоров прошедших через одну рабочую станцию и сопроводителя этого дела, включая их внуков. Что-то вроде Oracle-SQL, POSIX-OS, AWS и прочая статическая мелюзга для обработки динамики. А когда нужно в продакшн выпустить миллион экземпляров кликалок, с заменой пиктограммок по вайбу из тик-тока, то исходя из входного билета, требований к этому работнику получается что скриптоубожества становятся незаменимым инструментом для руководителя, и как ни парадоксально, конечного юзера бабы Клавы, даже если приходится набирать 8-800 с вопросом "у меня зависло куда нажать".
Статическая типизация никак не мешает выбирать любую архитектуру и писать любой сложности проекты
Зато мешает руководителю выбирать время, требуемое на разработку и квалификацию участников. Чтобы слово руководитель не раздражало, его можно заменить на систему управления и моделирования (тестирования) проекта. Статика вообще говоря не нужна для разработки при условии, что имеется разработчик с идеальной памятью и предсказуемым поведением функций с заданными ограничениями, он полностью знает как пройдёт Var от запуска до последнего деструктора. В ином случае она превращается в синтаксический сахар, не имеющий отношения к выполняемым функциям. Количество информации, требуемой для надёжной работы не изменяется при статике и динамике. В первом случае указывается явно, наряду с assertion и флажками, во втором - прячется в механизмы реализации и исключения. Быстродействие же не является определяющим, но желаемым, относительно скорости разработки и внедрения.
Статика вообще говоря не нужна для разработки при условии, что имеется разработчик с идеальной памятью и предсказуемым поведением функций с заданными ограничениями, он полностью знает как пройдёт Var от запуска до последнего деструктора
Во-первых, такого разработчика быть не может. Во-вторых, помимо одного "всезнающего" разработчика будут и другие, которые будут читать код. В-третьих, если взять случайный участок кода, то без подробного анализа с самого начала не будет понятно, какого типа эта переменная и как с ней работать.
Статика полезна и тем, что ограничивает выделяемую память, а не только подсказывает тип.
А скорость написания кода вообще не зависит от того, есть статика, или нет
Разработчик такой может быть, у которого есть соответствующий инструмент, анализирующий этот код и производящий его моделирование. Инструмент анализирует, показывая, что любой объект не выходит за пределы области аллокации, не имеет висячих ссылок или Null-pointer-ов на действующий объект а также что по завершению стек вновь как новый. А далее там что угодно. Явный пример - это union. Очень часто используется для экономии памяти с использованием приведения типов и размещения объектов с шагом 
, например, когда имеется пара входных матриц 640 на 480 основная и буфер, далее осуществляется всяческое преобразование этих пикселей. Так вот эти буферы размером 
попарно используется простым приведением для всего остального в процессе обработки, вплоть до того что туда вполне можно гвоздями (static/reinterpret cast) прибить хоть std::list<std::pair<int, int>> МоиXY по результатам вычислений. Та же ситуация с числодробилками-численными методами и прочими нейросетями. Всё. Больше для статики места нет нигде, int-float-double. Тот же Fortran элегантнейшим образом спрашивает про тип данных не как что это, а сколько для этого нужно.
Статика в необходимой мере сама не знает сколько у неё памяти до встречи с линкёром и размещением согласно map, задаваемой тоже внешним источником, который также надо проверять. Чтобы не ошибиться, выбрали (впаяли) чип с номером 6 или 8, 32 там флеша кБ или 64. Забыл про sizeof() и захардкодил константой? Это не проблемы компилятора.
Вот в этом очень грубо и есть основная беда таких типов данных, что им даётся malloc/free этикетка с мелькающим всюду параметром Length за которой надо вручную следить, особенно если это выскакивает любым боком по указателю изнутри какой-нибудь функции. В любом ином случае (вплоть до искусственных глобальных макро, анализирующих первичную аллокацию внутри процедур из разряда #define malloc MyMalloc) это превращается... в самописный "динамический код" на базе статического. В подавляющем большинстве случаев это изобретение велосипеда, который давным давно встроен, апробирован, содержит все заплатки во всех динамических языках. Более того, масштабируемость. Ну вот забыл поменять int16 на int32 и в самый удобный момент положительные становятся отрицательными. Аллокация объектов прилетающих по последовательным портам для неизвестных типов данных - туда же. Слоты, обёртки, перегрузка, проверка типа, изменение объекта во времени выполнения без лишних копипастов по памяти - это существенно сокращает время. Включая гипотетический компилятор (включая ИИ) который может динамику превратить в статику глобально или локально для ускорения, застолбив длину объекта его строгим типом.
Динамическая типизация (когда прямо числа со строками можно складывать) мне не нравится (а еще больше не нравится отсутствие явного объявления переменных, когда просто пишут в коде vairable=10 и неизвестно новая это переменная или старая, или вообще опечатка как у меня).
С другой стороны, максимально строгая типизация тоже не нравится. Когда на каждый чих нужно писать явное преобразование, код становится загроможденным этими преобразованиями.
Предпочитаю золотую середину. Что-то близкое к С/С++, возможно построже чем C, но однозначно слабее чем Rust. В частности, удобно когда числа разных типов преобразуются друг в друга неявно; также довольно удобно когда 0==false а неноль==true. В остальном же пожалуй лучше явные преобразования типов.
Если сюда ещё добавить прямой и обратный код, то получим что +0 это false а -0 это true, так что в строгой типизации надо ещё и этот атрибут указывать чтобы для полного ощущения так сказать помимо дополнительного кода. Туда же floating point с нулевой мантиссой и не нулевой экспонентой.
Почему что у вас, что в статье путается динамическая и строгая типизация?
Давайте поясним. Есть три деления типизаций:
1. динамическая и статическая
2. строгая и нестрогая
3. явная и неявная
Динамичекая, если упрашать, - это программист может записать в переменную строкового типа число.
Нестрогая - программа автоматически приведёт переменную к ожидаемому типу. Если функция принимает число, а в неё передали строку, то строка преобразуется в число.
Явная - при объявлении переменной необходимо указать тип
Динамическая типизация - это не противоложность строгой. Так у python - строгая динамическая типизация
Всё верно. А в PL/I – нестрогая статическая.
Говоря чуть точнее, при динамической типизации типы присваиваются не переменным, а только конкретным значениям.
Согласен с вами, я хотя и знаю эту теорию, но написал неверно (хотя там главной мыслью было просто выразить свое предпочтение умеренно-строгой статической типизации). Наверное потому что с питоном дела практически не имел, а на "чисто-бытовом" уровне это воспринимается так - вот есть "скриптовые" языки, там можно с переменными делать (почти) все что угодно, а вот "компилируемые" где все статическое, строгое и компилятор ругается. Но конечно на самом деле есть и строгая динамическая, и нестрогая статическая, и к интерпретации/компиляции это отношения не имеет.
Можно ещё добавить
4. Сущности без типизации - подстановки, сигналы, события, макросы, шаблоны, директивы, "нечто" получаемой внутри нейросети как некий вектор значений, несущий семантику описания данных.
С точки зрения конкретной реализации этих механизмов ещё проще:
1. sizeof() + идентификатор класса ClassID компилятор формирует самостоятельно. Class ID автоматом присваиваемый компилятором + интегральные типы (к которым сводится любой класс). Class ID (но не обязательно sizeof) меняется в рантайм? ClassID вшит неявно в объект как физическая переменная в памяти? Динамика. ClassID используется как индекс в массиве виртуальных функций? Динамическое поведение (наследование).
2. Согласование идентификаторов - имеется встроенный или пользовательский operator, для которого определены входные и выходные Class ID.
operator+(
,
){return 
} "записывается" компилятором как шаблон c=f(a,b) и если он встречается то осуществляется преобразование, если такого шаблона нет - ошибка на этапе компиляции.
3. sizeof() (но не обязательно ClassID, например, по умолчанию всё int) задаётся пользователем
TrueScript от создателя Turbo Pascal )
Не грех вспомнить эту полезную статью:
На самом деле код на Pascal/Delphi читается настолько легко вовсе не из-за типизации, а потому, что там явно видно, в каком порядке этот код выполняются. Весь поток выполнения представлен в явном виде, его никто не прячет, и алгоритмы сразу как на ладони: сперва выполняется это, потом выполнение переходит сюда, потом вот в эту функцию...
Тогда как на C# или JS мы получаем стейт-машину худшего свойства. Программа нарезана на крошечные фрагменты, которые вызываются через события. То есть выполнился кусок кода, и... И управление ушло в никуда, в среду (фреймворк), который потом его вернёт... куда-нибудь. Чтобы разобраться, куда именно, придётся приложить существенно больше умственных усилий, нежели при изучении Pascal-кода.
А когда всё это сверху заполировано промисами, да ещё динамическим связыванием, так что из кода вообще ни хрена непонятно, что именно лежит в данной переменной и куда уйдёт управление при вызове метода some_method этой переменной - это ад. А в C# с его LINQ получаем ад вдвойне, потому что даже сами вызовы части методов заметены под ковёр - их неявно осуществляет сам фреймворк, и нет простого способа сообразить, что же тут вызвалось.
Стейт-машины - вообще натуральное зло, в них крайне тяжело разбираться. Это как с расшифровкой генома, который хоть и содержит полный алгоритм построения организма, но оформлен этот алгоритм в виде стейт-машины, поэтому задача восстановления внешнего вида произвольного организма по его полностью расшифрованному геному не решена до сих пор.
В своём дипломе на делфи я написал настолько лютый колбек хелл с логикой, раскиданной по обработчикам нажатий кнопок, что до сих пор вспоминать страшно. На жс я такого уровня лютости так и не достиг)
Все верно. Еще лучше будет читаться код PASCAL\DELPHI когда логика не раскидана по обработчикам событий и упорядочена в виде процедур, функций и т п.
Забавно, что вы противопоставляете JS и Delphi. Типичные Delphi-приложения очень похожи на single page web app, со стейтом и обработчиками событий, с вёрсткой отдельно от поведенческого кода.
Вот только в Delphi обработчики события являются лишь точкой входа. После того, как событие случилось, весь дальнейший алгоритм прослеживается легко. Потому что у Delphi есть два важных архитектурных преимущества перед браузерной платформой.
Первое - он позволяет читать внешнее состояние, не выходя из функции. Тогда как JS не позволяет выполнить что-то вроде getMouseState() или isLeftButtonClicked() - для этого сперва надо выйти из функции, а потом зайти уже в другое событие. В итоге на ровном месте имеем тонны входов-выходов "в никуда" только чтобы считать состояние того или иного внешнего объекта.
Второе - Delphi позволяет обработать накопившуюся очередь событий, также не выходя из функции, просто банальным запуском ProcessMessages(). В итоге для долгого расчёта можно сделать, к примеру, индикатор прогресса с кнопкой "отмена" без существенного усложнения алгоритма и тонн мелких функций, распиханных по обработчикам событий.
Собственно, JS'овские "лапша из коллбэков", потом (по мере развития языка) "лапша из промисов", а потом те же промисы, но перекрашенные в async/await - это как раз и есть кривая попытка закрыть данные архитектурные изъяны.
Второе - Delphi позволяет обработать накопившуюся очередь событий, также не выходя из функции, просто банальным запуском ProcessMessages().
Это проблема. То же самое есть в Objective C – и приводит к сложно обнаружимым багам вроде не срабатывающих таймеров и дедлоков.
По возможности следует избегать использования этого инструмента.
Первое - он позволяет читать внешнее состояние, не выходя из функции.
Это одновременно и преимущество и проблема с наличием костыля в виде копирования состояния объекта при асинхронном взаимодействии. Для многопроцессорной обработки это превратится в удвоение/троение/четверение всего. Тем более ещё засаливается что копировать - всю цепочку владения или сам объект. Поэтому уж лучше в кнопку внедрить очередь в которую ставится событие с меткой времени и читается до востребования, заодно таймаут можно посчитать.
Те, кто действительно пишет на C#, не замечают большей части описанных вами страданий. Бывает, конечно, что люди стреляют себе в ногу, не понимая, как работают итераторы или IQueryable. Но выстрелить себе в ногу и в других языках есть много срособов.
Завидую я молодым.
Чел родился в 2000 каком-то году. С 3-х лет стал интересоваться компьютерами. Ну, то есть, они просто были частью его повседневной жизни: он спал с телефоном в обнимку, под каждой подушкой, на каждом столе лежал планшет, а по квартире он ходил, спотыкаясь о батины старые компы. С 5 лет он узнал, что компы можно программировать! Ты пишешь ему текст, а он по этому тексту что-то делает, как по инструкции! Ахренеть! Но текст надо писать не на русском мате, а на особом мате, называемом javascript. И вот на 20-м году жизни он узнал, что кроме javascript, оказывается, существуют другой мат, на котором компу можно писать инструкции! Шок! Сенсация! И в этом мате есть такая удивительная хрень, как типы! Но это не те типы, которые в подворотне дают тебе в морду и отбирают твой телефон, а это особые типы: они обозначают, что за данные можно хранить в переменной. Переменная может быть Integer, String, Float - это всё не одно и то же! И такой трюк позволяет отловить некоторые ошибки еще до запуска программы! Шок! Сенсация! А в javascript никаких типов нет.
Так вот. Я этому челу щас подвезу еще одну шок-сенсацию. Таких матов, где есть типы, придумано не один, а несколько. Кроме того, они на выходе позволяют получить отдельный exe, и им не нужен для работы ни Chrome, ни NodeJS! Шок! Сенсация! Кроме Pascal есть еще C++, C#, Visual Basic и даже Java! И у всех у них есть типы!
Эх, завидую я молодым. Сколько у них еще открытий впереди...
Дело в том, что инструменты, отказавшиеся от матов ещё были в конце 50-х в виде Лиспа и Фортрана с Бэйсиком, даже те что с матами уже существуют полвека. То есть принципиально нового особо ничего и нет кроме синтаксического сахара. Многопоточность и многопроцессорность уже также обыграли в 90е. Сейчас ощущается некий застой. Все новые фишки крутятся в основном уже вокруг мелкой оптимизации, всяких JIT, GIL, asyncio и прочих штуковин из разряда RS-485 образца 80-х. Самое невероятное - что до сих пор не появилось нормальной IDE, которая бы не занималась надстройкой над всем этим делом а представляла непосредственную работу с предметной областью. С Вебом ещё как-то дело шевелится, а что касается эмбеддеров там да, если отмотать на 30 лет назад то символ "дискета" на кнопке "сохранить" поменяли на стрелочку вниз.
Самое невероятное - что до сих пор не появилось нормальной IDE, которая бы не занималась надстройкой над всем этим делом а представляла непосредственную работу с предметной областью.
О, чую вам понравится https://en.wikipedia.org/wiki/LabVIEW
Она идеальна но только в рамках поддержки платформы. Если что-то нужно измерить, поуправлять осциллом/спектрографом, мелкими ПЛК, стендами для студентов, нарисовать кнопки-слайдеры - это и используется. С другой стороны сложность отладки и скорость приготовления данных с кодом плюс взаимодействие со сторонними источниками. Лабвью хорош своей инфраструктурой и проверенными обезглюченными решениями по работе с аппаратурой. В этом плане NI можно взять как пример - и среда разработки и то для чего разрабатывается, включая даже Веб. Вот так надо делать интро в язык без лишней шелухи, кратко, лаконично и по-делу. Однако LabWiev закрыт и не имеет стандарта как язык, хотя сертификаты на аппаратуру - вполне. Из наших графических это Дракон. Из стандартизированных UML ISO/IEC 19505-2, к нему были продукты а-ля Rational Rose, но уже завяли.
Поставил + за сравнение RUST с паскалем. Хотя меня он подкупил управлением памятью, но подсознательно с паскалем как первым языком матчится и с PL/SQL от Oracle, который копия Ada. Согласен про сравнение с С. На все остальные языки я бы обобщал аккуратнее. С библиотеками в паскале тоже приключений хватало. У меня в школьном проекте они динамически автономных компилятором компилировались, например. Но это уже не про паскаль от Вирта.
Не понимаю восторгов. Абсолютно то же самое будет и в C++, и в Java. Pascal тут вообще не уникален.
Паскаль уже тем хорош, что он ум в порядок приводит!
А ещё это ламповые воспоминания из детства, когда компы были без винчестеров, ты приходил в школе в дискаб, загружал ДОС и Волков-коммандер с дискетки... И ваял :)
Помнится, в Turbo Pascal (Borland Pascal) была интересная "фича" - неинициализованные переменные хранят мусор. Но в debug-режиме неинициализованные переменные обнуляются.
В итоге у тебя прекрасно работает все в дебаггере, но при релизной сборке вдруг ломается... И дебагер, опять же, не поможет - в нем все прекрасно работает.
Но зато и плюс некоторый есть - убитый вечер (или несколько) и куча нервов жестко научили тщательно следить за инициализацией переменных.
Но в целом, Pascal мало чем отличается от всех других языков со строгой статической типизацией.
Забавно, для меня этот прикол (код работает в дебаге, но не работает в релизе – проверяй инициализацию переменных) ассоциируется с C++, в Паскале я с этим почему-то вообще не сталкивался (хотя использовал паскаль и дельфи достаточно много).
В C/C++, на сколько помню, неинициализованные переменные не обнулялись в дебаге (если говорить про Turbo C/Turbo C++/Borland C++) - так что если не работало, то не работало сразу. Хотя и бывало, что в дебаге работало, а в релизе нет из-за различий в режимах компиляции - в переменные попадал разный "мусор".
С Delphi тоже не помню подобных приколов (хотя не скажу, что много с ним работал - предпочитал C++ Builder), но на сколько знаю, там подобное поведение тоже было.
Visual C++ – кажется, 6.0. Локальные переменные в дебаге обнулялись, в релизе нет. В итоге приобрёл привычку всегда инициализировать переменную в момент объявления.
Почему я не сталкивался с таким ни в Паскале (Турбо паскаль, потом Борланд 7.0), ни в Дельфи (кажется, до 3 или 5 пользовался) – не знаю.
Потом дебаггеры научились инициализировать области памяти шаблонами вроде 0xAAAA, 0xA5A5A5, 0x55555 ... (в двоичном 101010101010...) чтобы можно было явно видеть что где затирается лишнее при memory view.
Не знаю какую там типобезопасность вы теряли, но долгое время холивар был между Паскалем и C++ и С++ в ней победил, когда появились типобезопасные библиотеки на шаблонах. Ну и с имплементацией ISO стандартов Паскаля проблемы. Деривативы а ля Object Pascal/Delphi спеки по сей день не имеют насколько мне известно.
Ошибки в паскале были не сказать чтобы прям сильно полезным, а уж если что-то падает, то даже stacktrace было проблемно получить. А там в нулевых по нескольку ядер на процессор и широкие регистры завезли - стартанула эпоха параллелизма, за которой Паскали не сказать чтобы поспевают, если конечно не писать ручками asm вставки.
А вообще, помимо C++ многие использовали Ada для типобезопасности и там ограничений по типам есть побольше и повкуснее. Очень рекомендую хотя бы посмотреть на него.
А сравнивать паскаль с динамическими языками а ля JS/Python/Lua это странно как минимум - разные ниши, разное назначение, разная история развития.
Абсолютно верно! Крайний вариант ISO/IEC 10206:1991. То есть почти 34 года уже ничего не меняется в плане продвижения по этой лестнице. Но это лучше чем вообще ничего (как у Pyton/JS/Go/Java...). Но с другой стороны если делать какой-то проект под ключ со стандартизацией и сертификацией то потребуется собственно тулкит который поддерживает идиомы 91-го года. Вообщем даже С имеет не то что 21й век но и борется с плюсами какой год будет в версиях C23/26/28... в ISO/IEC 9899. Скорее всего там была заслуга Apple которая делала этот промоушен Паскаля так сказать.
Достаточно зайти на преемника Borland Embarcadero. Видно что в поддержке есть даже наш сайт FireMonkey (ответ Qt?), на котором в основном всё заострено на одноимённом фреймворке, частично использующем Паскаль. Судя по активности что-то как-то маловато вопросов с периодичностью 1-2 в месяц, аналогично и тут, вместо крупных порталов дискорды, слэки, телега. По всей видимости идут отчаянные попытки завязать всё это на Веб, но там ниша уже занята и с каждым днём, с каждым новым аддоном для JS/Python/Go/PHP/С++ теряется целый кусок работ. Здесь всё застыло в 2020 году. Большинство вопросов связаны с поддержкой древних систем, скорее всего из разряда самописных ПЛК-подобных панелях оператора на базе ПК, там была хорошая ниша у Делфи.
Вообщем зрелище конечно душераздирающее (С) когда объём работ в миллионы строк и человеко-часов становится невостребованным. Даже Fortran ISO/IEC 1539-1:2023 (!!!) -библиотеки вроде rkf45 живее всех. Единственное что может спасти - срочно попарсить всё это наследие в абстрактное синтаксическое дерево и отдать ИИ с целью извлечения новых знаний из имеющихся алгоритмов.
Ну и вдогонку то чего нет в школе или универе - значит потом не будет и в компаниях. Потому как руководителю сказать вот тебе год на изучение старого нового языка (а-ля Кобол) в настоящих реалиях непозволительная роскошь. Плюс спросить не у кого, поддержка адресная, вообщем всё помаленьку скатится в опенсоурс на любителя из разряда что там в прошивке ZX-Spectrum. Из профессиональной разработки, к сожалению, такие инструменты уходят беспощадно и довольно быстро.
Достаточно зайти на преемника Borland Embarcadero
ну вот как-то так Embracodero фактически монополизовал нишу Delphi/Pascal и изжил опенсорс на языке. Там и со стороны торговых марок препоны и со стороны доступности софта. Чтобы заниматься разработкой на этих языках нужно отвалить баблишко этим ребятам за использование RAD студии. Как писал выше - релизы у них нерегулярные, иногда довольно паршивого качества, а баги которые надо чинятся как черепахи. В итоге народ посмотрел на всё это и постепенно стал слазить с Эмбракодеры на всякое разное на другие языки, где опенсорс жив.
ПЛК-подобных панелях оператора
вспомнил как тут помнится статью публиковали про то какой чудесный делфи язык, у них там какие-то станки прошивку на делфи используют и хоть ты отверткой ядро у процессора выковыряй на живую, код на делфи всё переживёт и восстановится в рабочее состояние. Каким автомагическим способом оно там всё это делало вопрошали всей секцией комментариев. Сама статья при этом была вполне хорошей.
FireMonkey полностью написан на Delphi, а не "частично использует Pascal". Он полностью нативный для Delphi и исходный код доступен с самого низа фреймворка - с платформенных модулей.
Для опенсорс проектов использовать может Community версию, а для коммерческой разработки не слишком сложно отдать один раз 100к рублей и пользоваться сколько угодно. И платить только за последующие обновления, если требуется
Вполне может быть, но необходимо выделить нюанс, связанный разделением Delphi<->Pascal. Такой как пропиретарный компилятор Delphi. Object Pascal вроде как открытый в этом же репозитории но... датируется всё 21-м годом, а если распаковать сырцы и отсортировать все файлы pas (всё таки Паскаль это self-hosting язык умеющий компилировать сам себя (Delphi под вопросом, вполне возможно что туда и С затесался)), то можно обнаружить что несмотря на датировку создания файлов 21-м годом, внутри что-то вроде 2011, особенно в папках x86/assembler, Florian Klaempfl and Peter Vreman 2008, или даже 2002, Jonas Maebe, Eric Codere, Pierre Muller, Olivier Coursiere, FPC team до 2015, приятно видеть что в разработке участвовали кто-то из наших Yury Sidorov 2013, Dmitry Boyarintsev, Nikolay Nikolov присутствуют также интересные фичи вроде "Converted to pascal using Chelper". Вообщем рассвет пришёлся действительно на начало нулевых, там же и AVX расширения и SSE. То есть основные работы по ядру компилятора сделаны на период с 2000 до 2009 года. С тех пор уже прошло почти 20 лет и новых каких-то релизов по ходу дела не особо предвидится. На гите также что-то не особо активная обстановка. Предающийся забвению опенсорс - это очень тревожный знак. Так что утилита Phelper, конвертирующая .pas в .с будет как раз актуальной.
Free Pascal - это отдельная ветка Паскаля и она развивается тоже регулярно. Смотрите на коммиты, а не на дату создания.
Delphi не открытый язык и не даёт исходники компилятора. Однако все RTL исходники открыты для владельцев среды разработки. Не для переборки, а для изучения и "перегрузки", если потребуется.
В разработке и развитии FMX тоже участвуют наши разработчики, например, Ярослав Бровин. Я тоже принимаю участие, через него и через общую платформу заявок.
Скрытый текст
Заявки тут тоже регулярные. Как на баги, так и на добавление фич
Коммиты в основном носят эффект дополнений нежели каких-либо кардинальных изменений в базовой версии с датой копирайта или заметки автора. О рабочем времени на этот проект авторы кстати интересным образом жаловались ещё аж в 2009м году. В итоге похоже всё встало на LLVM. Интересно в настоящее время понимает в том колоссальном объёме содержимое ядра компилятора с тем же активным участием по существу вопросов связанных с кодогенерацией. Скорее всего исходя из запросов выше речь идёт об IDE а не о внутренностях Delphi. Одно дело баг Mouse Event в дебаггере где-то что-то не подсветилось, другое дело ответ на запрос "мне пожалуйста оптимизируйте XOR EAX,EAX в NOP". Без непрерывного процесса обучения длиной в 10-15 лет и погружения в тему в этом случае ничего человеком уже не сделать (в надежде на ИИ). В других языках благодаря массовости есть молодые специалисты в нужном количестве и должной квалификации, которые могут объять необъятное (количеством). Не просто "я могу кликом пересобрать Линух" а по существу решить новаторские задачи. Если опенсорус сообщество увядает по ключевым аспектам, естественным образом "стареет", то соответственно за ним очень быстро потянется и коммерция. Необходим платёжеспособный спрос, а кто его обеспечит? Два пенсионера ("Я под DOS такое вытворял", три пионера "мне интересно что это" для хайпа, один мейнтейнер какой-то вундервафли управления котлоагрегатом под W2000-XP "работает - не трогай", один грантоед включивший покупку ПО в заявку для "визуализации результатов моделирования визуализации". Так что главный ресурс это конечно то, что можно использовать как учебник и видеть от этого эффективность и скорость результата.
Fpc вносят крупные обновления, как и Delphi. Вам нужно для начала нормально разобраться в вопросе. А сейчас вы выглядете слишком глупо. Ведь этот срез запросов по Делфи - это последние запросы. Запросы там разные, от расширения синтаксиса (например, недавно добавили тернарный оператор из этих запросов), до оптимизации и ошибок кодогенерации.
Судя по вашим рассуждениям, вы незнание буквально ничего о текущих положениях дел FPC и Delphi. Я не понимаю, зачем вы вообще пытаетесь рассуждать на эту тему. Ощущение, что вы используете ИИ для этого, который слабо сам "понимает" актуальность инструментов.
FPC использует систему транков для обкатки обновлений. Delphi обычную систему обновлений и крупных релизов (релиз, апдейт, патч). И все они это делают регулярно.
Книги по Delphi тоже публикуются, в том числе на русском языке (как минимум по версии прошлого года). Регулярно ведутся вебинары (открытые и закрытые и сейчас только на английском).
Вообще-то первой более менее нормальной по качеству кода версией Fpc была 3.0. Потом в 3.2 ещё чуть подтянули, но и все - стагнация на 5 лет. Разве что платформы добавляют.
Дельфи в этом плане гораздо лучше конечно.
Разве является глупостью попытка помочь так сказать сформулировать отзыв, предположения, образные сущности и указать на ключевые аспекты, которые, ИМХО, разумеется необходимо хоть как-то учесть. Была такая история с Code Composer Studio для DSP TI, версии то 3, потом 3.3, глюки шли с любым JTAG-ом, работать было невозможно, особенно если нужно было построить графики по значениям в памяти. Не важно что там было Black Hawk или Sauris или ещё что. Так вот руководству видимо надоело лицезреть на самоделки самой компании и привлекли внешний инструмент - теперь это сделано на базе Eclipse. Есть поддержка со стороны среды открытого исходного кода и широкое коммьюнити, поэтому это взлетает до сих пор, хотя прошло уже более десятка лет. Поэтому открытие сырцов для Delphi - это неизбежность. Фактически все языки уже давным давно это сделали. Так как это представляет и академический и инженерный интерес, ничего особо такого там нет, если ещё на этом фоне проморгать ИИ и его уже прямую способность к оптимизации Abstract Syntax Tree с обратной связью на язык то это уже будет финиш, кому нужны датасеты двадцатилетней давности.
Ближе к делу:
1_ Языки типа Cobol, Simula, Pascal и другие аналогичные с почти что человеческим языком писались в то наивное время когда роботы были как живые и про них снимали кино. То есть тогда это были первые шаги "промтов" которые можно компилировать прямо в двоичку или интерпретировать без нейросетей. Поэтому синтаксис оказался перегружен словами и предложениями, похожие на язык общения. Плюс были ещё древние терминалы которые не понимали всякие #$%{} и прочие новомодные символы, и клавиатуры их не содержащие, а представляли набор ASCII-7 или даже меньшей битности чтобы вместить только цифры и алфавит. В С только недавно убрали т. наз. триграфы-диграфы. Поэтому проще было всё сделать словами. Питонисты и С пошли иным путём, они на то время да и сейчас сделали совершенно правильный (и похоже единственный) выбор по упрощению всего, вплоть до того, что оператор это скорее хоткей нежели синтаксическая единица, особенно в Питоне, где табуляция это открытие области видимости вместе с :. В этой концепции язык - это диалог с машиной а не человек-человек. В Паскале же этот момент как-то упустили он стал похож скорее на LISP с морем скобок, заменяемых на триграфы begin-end (уверен что IDE уже сама как T9 при нажатии на b или e это всё ставит автоматом - тогда зачем?) Если присвоить используется чаще то зачем для него два действия := вместо одного. Поэтому уставший от этого юзер нашёл то, что в процессе эволюции позволило ему делать то же самое проще и быстрее. И его, уверяю, бесполезно переделывать под догмы, созданные полвека назад в бурно развивающейся отрасли. Их нельзя было приколачивать гвоздями. Можно было бы сделать 2-3 ветки со своими стандартами, включая ISO/IEC. С никак в этом плане не мешает С++. Был бы Pascal^2 например или что-то такое. Тем более пренебрежение опенсорс коммьюнити даже со стороны коммерческой компании - очень плохой тон. Что Pascal, Object Pascal всякие .org это где-то там, якобы обязаны сами что-то бесплатно ваять для кого-то, а не единая команда создающая общий продукт.
2_ Актуальность. Я уже привёл выше примеры застывших сайтов. Не должны быть какие-то левые лазейки для поддержки продукта, это должен быть портал. Если студент зайдёт на learndelphi что он там увидит особенно в разделе books, classes, 2020 год? В саппорт тут же редирект на embarcadero на заполнение формочек, где FAQ (он вообще не заполнен). Если на этот сайт посмотреть со стороны то выглядит как онлайн-казино с какими-то картинками. В разделе Sample Project for Beginners выкидывает сюда с замечательной надписью по всем папкам "5 years ago". Такое даже у ардуинщиков на уровне оксюморона. В разделе News 2024 год, под многими видео нет комментариев, даже под "How to Make Your Apps Look Like Million Dollars?". Это конечно весело, но для разработчиков из компании это как сиюминутная ситуация нежели стратегия. Сказать "Build Windows apps 10x faster with less code" всё равно что потерять, если нет ссылки отвечающей тут же на вопрос "Как". "Award winning" - какой Award, где, в каком году. Потрясающая надпись "Licensed for use until your individual revenue from C++Builder applications or company revenue reaches $5,000 US", это как видно? По налоговой отчётности или банковской выписке организации? Кто это проверяет? Такое надо хотя бы звёздочкой снабжать и мелким шрифтом внизу.
3_ Какие основополагающие преимущества даёт IDE и фреймворк по сравнению с конкурентами (раз уж это не академический а всё-таки коммерческий продукт), тот же Qt или нативный OpenGL/Vulkan теперь уже/DirectX, плюс OpenCL/CUDA и удобство с нейронками (на дворе 21й век если что), грубо говоря сколько я провожусь с фреймворком и сколько например с этим, в пару кликов и команд чтобы обучить, было был неплохо что-то предоставить из автоматизации разметки данных и картинок, нативная поддержка мультипроцессорности, нормальные быстрые очереди, семафоры, асинхронный ввод-вывод, драйверы без костылей, интрисики для целевой платформы. Что делается для поддержки платёжеспособности клиентов (как они этим инструментом и что могут заработать). Зачем ещё до сих пор нужны оффлайн-интерфейсы когда веб повсюду а для промышленности уже давно запилили свои ПЛК-системы на том же Qt и даже Web, который как оказался даже надёжнее в локальной сети чем самоделки, так как там взаимодействие идёт по более надёжному протоколу чем if(состояние кнопки). Не говоря уже о том что появляются железобетонные на ASIC-ах нечто вроде NeoChromVG для 2D всяких панелей, вот под что-то такое бы взлетело а не только под ПК и с подходом к проектированию из 90-х.
4_ Какие принципиально новые подходы к проектированию ПО используются помимо непосредственно кода. Что делается для анализа данных, документации, сопровождения проекта, своя система анализа версий помимо гитов, автоматизация копипастов, визуализация версионирования, эффективный Object Picking, таймауты для операций, удобство по разбиению классов на другие, синхронизация классов и пространств имён с файло-папочной системой, сборка из нескольких файлов одного, сама новаторская система сборки помимо механизмов make и cmake.
Вот это всё что должно бросаться в глаза для профессиональных разработчиков, школьников-студентов и просто интересующихся из разряда научпоп. Считайте уделённое время на этот пост помощью проекту :D
Почему вы опять продолжаете дискуссию не зная ничего об окружении Delphi и RAD Studio?
Нужно ИЗУЧАТЬ! Вы же, сейчас, будто впервые узнали об инструменте и пытаетесь угадать его недостатки. И зная синтаксис Паскаля кинули камень в огород операторных скобок и знака присвоения. Ни то ни другое не является никакой проблемой, сложностью или неудобством. Вам просто кажется, что {} или пробелы удобнее, но это не так. Знак присвоения - тоже. Знак = нигде не является операцией, вне языков программирования, это знак фактического состояния, а не операции. А знак := является общепринятым алгебраическим знаком операции присвоения значения.
Фреймворк FMX является кроссплатформенным, не требует никаких зависимостей в виде dll в любом виде сборки. Он также использует GPU отрисовку и поддерживает DirectX, Direct2D, OpenGL, OpengGLES, Metal, Cairo, GDI, Vulkan, Skia. Имеет множество инструментов для кроссплатформенного создания GUI, удобные механизмы анимации, поддерживает DisplaySync для плавной анимации на мобильных устройствах, поддерживает гибкую стилизацию элементов на подобии CSS, но с визуальным дизайнером этих стилей. Штатная RTL в полной мере поддерживает кроссплатформенный поддержку, в том числе большого количества провайдеров баз данных, работы с ОС, железом и прочим. Бинарные файлы на выходе имеют размер до 10 мб под любую платформу. И это один бинарный файл.
Разработка на FMX во многом превосходит Qt в простоте создания кроссплатформенных приложений, GUI и взаимодействия с устройством.
Нужно ИЗУЧАТЬ!
Конечный пользователь до этого рано или поздно додумается. Но есть цена входного билета с самым ценным ресурсом - временем.
А знак := является общепринятым алгебраическим знаком операции присвоения значения
Человеку надо писать программу а не разбираться в терминологии параллельной области знаний. Речь идёт о инструкции для ЭВМ, чтобы она выполнила копирование rhs в lhs, в одно нажатие "=". Остальное это уже символьные вычисления, где = это значок для solve/subst, хотя и не обязательный (по умолчанию выражение присвоено нулю a=b и a-b тождественны, не требуется a-b=0), HDL-языки, где есть блокирующее и неблокирующее присваивание <= и = - тут уже можно потрудиться нажать "<" лишний раз.
Он также использует GPU отрисовку...
Отлично! В этой ветке наконец-то пользователи узнают преимущества. Надо тогда сразу вставить на сайте ссылку сюда, чтобы людям было понятнее с чем имеют дело.
Бинарные файлы на выходе имеют размер до 10 мб под любую платформу.
В любом случае потребуется apt get install freeglut3-dev libglew-dev mesa-utils и иже с ними для разработки, включая заголовочники для винды, несмотря на наличие либ уже от производителей железа. Это не преимущество а констатация факта наличия внешних API. Можно сходу скопипастить что-то такое, скомпилировать это дело gcc gl.c -lGL -lGLEW -L /usr/local/lib/ -lglfw и получить двоичник в 18 килобайт.
Разработка на FMX во многом превосходит Qt в простоте создания
Простота - это когда то, что делается вручную спрятано в реализацию. Асинхронная кнопка, таймеры-таймауты, отсутствие зависаний, очереди-семафоры, мультипроцессинг в пару букв, векторный рендеринг, управление памятью GPU в несколько слов. Тут работает "закон сохранения количества информации". Всё что делается вручную уходит в IDE и наоборот. Так вот это абсолютно не очевидно так как имеется посредник в виде языка программирования который напрямую всё это не поддерживает. Поэтому этот фактор весьма субъективный.
":=" не делает разработку медленнее. Это абсолютное заблуждение. Это не сложнее, не требует усилий, не усложняет читаемость. begin/end - тоже самое. Это синтаксис. Нет смысла размусоливать тему "лучше бы сделали так", потому что сделано уже так. begin/end обычный операторные скобки и их Delphi требуется писать намного меньше, чем в других языках. try/except/finally - не требует операторных скобок. Конструкторы классов не требуют операторных скобок. if/then, repeat/until - не требуют операторных скобок. Как и не требуется указание обычных скобок в выражении условия или цикла.
В Delphi всё это намного проще
for var i := 1 to 10 do <код>
while <условие> do <код>
repeat
<многострочный код>
until <условие>
if <условие> then <код>
try
<многострочный код>
except/finally
<обработка исключения>/<код>
end;Вместо
for (выражение 1; выражение 2; выражение 3)
{
<код>
}
while (условие)
{
<код>
}
do
{
<код>
}
while (условие);
if (условие)
{
<код>
}
try
{
<код>
}
catch (Exception e)
{
<обработка исключения>/<код>
}Даже если многострочный код, в C# и других Си-подобных мусора больше
for var i := 1 to 10 do
begin
<многострочный код>
end;
while <условие> do
begin
<многострочный код>
end;
repeat
<многострочный код>
until <условие>
if <условие> then
begin
<многострочный код>
end;
try
<многострочный код>
except/finally
<обработка исключения>/<код>
end;Это намного читабельнее, чем Си-подобный язык.
В любом случае потребуется apt get install freeglut3-dev libglew-dev mesa-utils и иже с ними для разработки, включая заголовочники для винды
Нет не надо. Для Линукс требуется установить базовые библиотеки, если они отсутствуют, типа zlib, mesa, да. Для всего остального не надо. Delphi не требуются заголовочные файлы. Зачем? Они на Си. Всё что нужно в Delphi с собой. Остальное Delphi получит при создании подключения к целевой машине (Mac/Linux).
Delphi не использует ни make ни cmake ни прочую хрень. Он самодостаточен и не требует подобного геморроя.
Простота - это когда тебе не нужно делать ничего лишнего для создания рабочего приложения. В Delphi достаточно открыть среду разработки, создать проект и нажать "Запуск". Всё. Приложение соберется за пол секунды, будет иметься исполнительный файл и запустится. Для создания обработчика кнопки не нужно создавать сигналы или прочую ерунду. Для многопоточной работы есть таски и пул потоков, синхронизация с ожиданием и без.
Асинхронная кнопка, таймеры-таймауты, отсутствие зависаний, очереди-семафоры, мультипроцессинг в пару букв, векторный рендеринг,
Всё это есть из коробки, а управление памятью GPU - бесполезная и не нужная функция, т.к. бэкендов отрисовки много, они абсолютно разные и общую абстракцию для них невозможно нормально создать. Это должно и делается автоматически. Текстуры имеют возможность кэшироваться, битмапы не клонируются, а используют счетчик ссылок, память освобождается по мере необходимости.
"Мультипроцессинг" - тоже полная чушь, вышедшая из под крыла багов и тормознутости Питона. Нет смысла в мультипроцессорности, если ты можешь легко создавать и управлять потоками, кроме обеспечения безопасности или отказоустойчивости. При этом, работа с пайплайнами очевидно имеется и не вызывает никаких проблем.
Простота - это, никогда не видеть, не писать и не использовать подобное: "gcc gl.c -lGL -lGLEW -L /usr/local/lib/ -lglfw". В Delphi ты никогда не сталкиваешься с подобным.
Зачем ещё до сих пор нужны оффлайн-интерфейсы когда веб повсюду а для промышленности уже давно запилили свои ПЛК-системы на том же Qt и даже Web, который как оказался даже надёжнее в локальной сети чем самоделки, так как там взаимодействие идёт по более надёжному протоколу чем if(состояние кнопки).
Кто ограничивает вас в оффлайн интерфейсах? Интерфейс не характеризуется таким словом. Это характеристика самой программы. А никто не мешает вам создавать программу, которая взаимодействует с бэкендом или является клиентом для какого-то устройства.
Вы хотя бы в мой репозиторий зайдите и посмотрите какие открытые проекты лично я делал на Delphi.
В разделе Sample Project for Beginners выкидывает сюда с замечательной надписью по всем папкам "5 years ago". Такое даже у ардуинщиков на уровне оксюморона.
Потому что это раздел для версии 10.4.Именно тогда она вышла.
Зайдите в раздел свежей версии и вы увидите совсем другую картину
Вы даже не попытались что-то самостоятельно посмотреть.
Достаточно открыть аккаунт Embarcadero в GitHub и всё это можно найти и увидеть.
В этой концепции язык - это диалог с машиной а не человек-человек. В Паскале же этот момент как-то упустили он стал похож скорее на LISP с морем скобок, заменяемых на триграфы begin-end (уверен что IDE уже сама как T9 при нажатии на b или e это всё ставит автоматом - тогда зачем?)
Код - это общение не только человек-машина, но и человек-человек, потому что НИКТО НЕ ПИШЕТ ОДНОРАЗОВЫЙ КОД. Его дописывают, исправляют, читают и изучают. Его всегда нужно читать.
По поводу активности на форуме, а давно вы сами форумом пользовались? Я не пользуюсь форумами вообще.
Вся активность происходит в чатах. В данном случае Телеграмм и Дискорд. В телеграмм активность регулярная. Это русскоязычная группа. Помимо нее есть общая, международная группа, где также регулярно обсуждается этот фреймворк. Я в них активный участник и модератор. А также являюсь специалистом и не официальным амбассадором этого фреймворка.
Отдельно есть и общая Delphi/Lazarus группа, в которой ежедневная активность.
Форум позволяет по крайней мере проиндексировать ответы и скормить их ИИ. То есть "я хочу на Паскале написать функцию, возвращающую треугольник Паскаля". И что есть энтузиасты которые с удовольствием это разжуют на полстраницы (как здесь). То есть идёт обуждение большим фронтом коммьюнити особенно там где имеется опенсорс. Обозначенные Вами инструменты (фреймворк) не являются неотъемлемой частью языка. Речь идёт именно про давным давно назревшую проблему открытия Delphi в опенсорс, которая позволила бы снять пласт проблем поддержки языка и сосредоточиться на его продвижении. Где Паскаль-CPAN или Паскаль-Pip? Можно ли в 2 клика скачать нативную библиотеку а не разбросанные по гитам репы наподобие того как это ломом-палкой, но сделано в Ардуине (вопрос про эмбеддед-Паскаль, кстати в том компиляторе где-то мелькали AVR/Cortex-ы), пособие уровня яслей "мигаю светодиодом", то есть те вещи, над которыми не надо думать и которые привлекают так сказать широкую общественность. Тогда количество переходит в качество. Вот этих ключевых моментов нет нигде, может плохо искал, да и искаться это не должно тяжело а быть железобетонно проиндексировано в поисковиках, мануалы, даташиты и прочее (включая железо под Паскаль). Не просто "вот вам нечто, делайте с этим что хотите", а скажем, Репка-Расберри с установленным Паскалем. То есть если мы говорим про коммерческую составляющую - она должна быть дружелюбной к пользователю! А не "идите отсюда, мы сами лучше знаем что нужно".
Вы опять демонстрируете не знаете предметной области.
В Delphi есть штатный пакетный менеджер - GetIt. Есть встроенный GUI, есть GetItCmd для консольной работы.
Есть и сторонние пакетный менеджеры, например BOSS и DPM.
Компания Embarcadero публикует все изменения и исправления по списку заявок на публичном wiki по языку. Гуглим "Delphi docwiki".
Всё доступные платформы указываются в редакции среды разработки, которую использует разработчик. А при установке можно выбрать все нужные платформы и SDK для них. Для Raspberry pi используется отдельный проект от компании TMS, которая расширяет среду для сборки под эту платформу. А так же сборку Electron приложений на Delphi и WPA приложений.
Телеграм группа тоже индексируется и доступен ИИ. Смотрим например на сервис telq.org.
Delphi не является опенсорс и речи пока об опенсорс не идёт. При этом библиотеки опенсорс для него существуют и процветают.
Вы бы хотя бы для начала зашли на официальный сайт, wiki, блог. Вы задаёте очень странные вопросы.
В Delphi из коробки есть всё, что есть в других инструментах и всё, что нужно: и пакетный менеджер и менеджер платформ и развитая среда разработки с мощным отладчиком и удаленным отладчиком с удаленным деплоингом. Есть публичное API для разработки плагинов под среду разработки, которое может дать доступ и при компиляции и при работе с кодом и расширение инструментала среды.
Публикация в официальный пакетный менеджер свободная. Владельцы платных редакций имеют доступ к ЗБТ новой версии среды разработки и могут влиять на разработку.
Вы должны наконец понять, что Delphi не закрыт от всех, а слышит всех, развивается и успешно продается.
демонстрируете не знаете предметной области
Совершенно верно! Что пользователь, зашедший на страничку сайта ничего не знает а хочет узнать. Так почему бы не сказать руководству чтобы пункты 1-6 разместили на сайте как золотые слова? Вот я и помог решить главную проблему как привлечь тех кто хочет заняться делом. Кратко, лаконично, снимает главные вопросы. Но что я вижу изначально? Какой дополнительно Гугл, ИИ, ДакДакГоу, Альтависта (привет тем кто в курсе) я должен применить к ресурсу чтобы прочитать сказанное? Методологически сайт не способствует привлечению желающих а служит как баннер на выставке, который включают на экране и уходят на кофе-чай в закуток с микроволновкой.
В Delphi из коробки есть всё, что есть в других инструментах
Так если это всё есть в других инструментах тогда зачем это нужно? Где явные примеры уровня п. 1-6 показывающие эти преимущества. Пользователь ничего не должен искать! Это должно быть на первом месте. Я захожу сюда или сюда и даже сюда, скачиваю что мне нужно. Хорошо, последуем примеру, воспользуемся поисковиком. Пишу то что пишут везде "Delphi Marketplace". Первая же ссылка. Так. Стоп, это же Microsoft, хотя есть реф на pypl. Хорошо, пишем более предметно "delphi modules library", странно, а где строка поиска, а где коммьюнити которые пишет свои либы пусть даже для кросскомпиляции с троянами, но свои.
Удалённая отладка - это было преимуществом где-то в начале нулевых. GDB справляется с этим вставкой айпишника, не говоря уже про банальный RDP и JTAG-и с Ethernet-ом. То есть как некий флаг крутости это уже не очень. Автоматизация удалённого развёртывания опять-таки на обычных инструментах вроде гитов и докеров. Необходимо указать что явно привносится в этот процесс. Нет нечто того что создавало бы впечатление о целостном продукте. Попытка взяться за всё (IDE для Плюсов, Питонов, Яв, коих уже 100500, включая заточенных уже изначально под Винду например) без коммьюнити, без развития самого Delphi, плагины которого должны просочиться во все IDE-шки, закончится "No Longer Supported". Берём поиск "delphi for eclipse" что видим? Грустный смайлик. "delphi for VS Code" видим авторский (!) плагин Alessandro Fragnani для VS а не самой компании.
Плохо искали. Всё есть на офф. сайте. Все разделы. От покупки и просмотра возможностей, до ссылок на блог, showcase, документацию и онлайн пакетный менеджер.
EMbarcadero НЕ предоставляет компилятор и RTL отдельно от среды разработки. Для Delphi ОДНА единственная среда разработки - RAD Studio. Достаточно её скачать и ВСЁ. Абсолютно всё, о чем вы спрашиваете уже вам доступно. Есть и оффлайн документация и ссылки на обучающие материалы внутри среды разработки. Походи по главному меню и найди то, что тебе нужно:
Преимущество удаленной отладки в том, что достаточно установить одну программу на целевой машине, запустить её и просто создать подключение. А далее вообще ничего делать не надо. Из самой среды разработки напрямую, как при разработке локально, всё запускается и отлаживается с одной кнопки.
Преимущество в том, что всё работает из среды разработки и никуда не надо лезть, чтоб что-то настроить, отладить и запустить. Ты просто переключаешь между платформами и делаешь то, что тебе нужно. Всё сделано и продумано заранее.
RAD Studio - это среда исключительно для Delphi и C++ Builder. Там нет никакого Питона или Явы. Embarcadero курирует отдельные две опенсорс среды PyScripter и Dev C++. Они не являются целью данного разговора. Это отдаленные проекты сторонних разработчиков.
И нет никакого смысла создавать плагины для VS, VS Code или прочих IDE/блокнотов, потому что ты не можешь использовать Delphi не установив RAD Studio.
это жопенсорс - бери фпц и пиши сам. не забудь потом выложить на гитхаб и сто лет исправлять ошибки =)
ишь ты, масленица, дельфи ему выложи....
Дело не в опенсоурсе а в том, чтобы застолбить Delphi в ISO/IEC, чтобы можно было привлечь на рынок и других игроков (пусть даже формально конкурирующее юрлицо), так как стандарт не может быть пропиретарным. Поэтому тот Паскаль 1991 года является первым и последним открытым проектом. Но почему-то никто не издаёт компиляторы кроме наследников Borland и коммьюнити FPC. Да и сейчас спустя 34 года кому это нужно. Пока что это игра в одни ворота и практика единственного поставщика - это ограничивает энтерпрайз, который всегда должен иметь возможность выбора по меньшей мере двух. То есть о крупных игроках при таком раскладе можно думать только по очень хорошей дружеской договорённости на короткую дистанцию.
Но почему-то никто не издаёт компиляторы кроме наследников Borland и коммьюнити FPC
Опять дилетантские заявления.
Имеется достаточно, в том числе свободных, реализаций Паскаля, Модулы-2,-3 и всяких Оберонов.
Это должен быть образно говоря не файл yet_another_supercompiler, содержащий внутри вызов gcc а достаточно крупные компании предоставляющие помимо софта его поддержку, услуги итд. Ну вроде как Intel C/++/Fortran Compiler, тот же gcc, который имеет кучу тестов на соответствие ISO/IEC или по крайней мере компании которые их проведут собрав исходники и дав по ним экспертное заключение а-ля ФСТЭК. Для себя можно что угодно по принципу залил, мигает, крутит и ладно. Для энтерпрайза же важно что поставщик даст какую-то бумагу, на которой будет соответствие стандартам, прохождение тестов, подпись и печать. Что для разработки ПО используются аттестованные лицензированные инструменты а не скачанные за углом "гигабайт всего за 100".
ISO стандарт языка никак не гарантирует ничего кроме того, что твой код соберется. Энтерпрайзу это совершенно не требуется. Код всегда пишется под конкретной версией. У C++ есть несколько компиляторов, которые ведут себя по-разному с одним и тем же кодом. Вот это - проблема.
Крупные компании в состоянии себе компилятор написать, не то что готовый прогнать через тесты (которые обычно тоже есть) и сопровождать.
Сертификация отдельная тема и мало кому из коммерческих структур нужна.
Купив один раз RAD Studio Delphi, тебе не надо ничего продлять для разработки. Это не подписочная система. Можно лишь оплатить для получения обновлений мажорных версий. Тебя никто не ограничивает.
У вас на КДПВ ошибка, в коде на мониторе - использование неинициализированной переменной, в строке
min := data[i];
Про "код" на бумажке вообще молчу )
На экране ноутбука вроде "0", но остальное плохо видно
Если автор не читал, то люто рекомендую классический MIT Structure and Interpretation of Computer Programs (SICP) https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html Schema - язык строго типизированный и красивый. Ну и книга прекрасно прочищает мозги. И с ООП и с DSL.
Ну и современный Ocaml, как хороший компромисс между строгостью и практичностью https://ocaml.org/manual/5.4/index.html
Сегодня мы снова приходим к этому — через Rust, Swift, TypeScript. Мы возвращаем уважение к типам, потому что устали от хаоса.
Ирония в том, что ответ на этот хаос был у нас с самого начала — в старом, строгом, занудном Pascal.
Это якобы "типовое занудство" было испокон создания языков программирования.
Тупо потому, что на базовом уровне железа процессор как минимум только примитивными типами - машинно-разрядными integer, double (а в древние времена и без double) и ещё машинно разрядными указателями и оперирует.
А когда вы добавляете любую динамику, то она тут же тянет за собой необходимость отдельного сохранения доп. данных, их проверки и косвенного вызова некоторых лишних процедур для понимания с чем собственно мы имеем сейчас дело - а это всё лишнее время, время, время, которое суммируется в достаточно большие задержки.
Вообще, IMHO сейчас, к большому сожалению, народилось уже целое взрослое поколение т.н. "программистов", которые вообще крайне слабо себе представляют как именно работает конечный машинный код на процессорах (причём не важно на какой архитектуре - на x86/64 ли, на ARM ли, на другой ли).
В основном это самоучки со стороны, без профильного образования, въехавшие каким-то боком в профессию на волне IT-бума тупо за деньгой. И львиная доля из них как раз и есть мамкины скрипто-кодеры на JS или Питоне, но так же и часть Жабистов, C-Шарпистов и т.п.
Иногда из общения с такими "профессионалами" просто диву даёшься, какую чушь они несут на собеседованиях или пишут в свои блогах.
Это похоже на такой же ужас, как если бы ваш лечаший врач никогда не изучал основы органической химии, биологии, анатомии, и не проходил интернатуру, а так по быстрому нахватался бы знаний из пары книг и советов от друзей, и приступил бы к вашему лечению )))
Может быть на сотом пациенте он бы чего-то бы и понял, почитал бы и глубже поучил бы, но первые минимум сто (включая вас) точно бы лежали уже в деревянных ящиках.
Ребята из университетов хотя бы сначала базовую школу булевой алгебры, алгоритмов, архитектур, ассемблеров, C/C++, операционок, синтаксически анализаторов и т.п. так или иначе проходят, а уже потом пересаживаются на тот же JS при насущной необходимости.
А вот причина стремительного взлёта полно-динамического скриптинга типа JS только одна - это идея быстрого кроссплатформенного ВЕБ-мордошлёпства, а вовсе не удобства сплошной динамики без статики.
Эта идея, во-первых, очень понравилась т.н. "эффективным менеджерам" на рубеже 2000-х,
а во-вторых, надо признать, что на рубеже 2000-х и последующие лет ~15 хороших альтернатив-то почти и не было.
С++Qt был достаточно сложен, и долгое время покрывал только десктоп. Да и сам современный С++ слишком заковырист и опасен для большинства описанных выше "мамкиных кодеров" без хорошего образования и большого опыта разработки.
QML же деятели из Qt запустили уже существенно позже.Многочисленные Java фреймворки тормозили нещадно и особой красотой не обладали. А JavaFX тоже уже позже стартанул, но как-то до сих пор особо и не взлетел.
C# был долгое время без кроссплатформы, а десктоповый GUI у них и до сих пор без кроссплатформы без сторонних решений. Ну а с Вебом у MS вечная чехорда, то чистый ASP.NET, то Razor, то Blazor, завтра ещё что-нибудь.
Borland Kylix забросил по причине убытков. Embarcadero со своим мега-глючным FMX тоже делала все как будто нехотя и медленно, хотя кто-то сейчас мобилки уже и на этом пишет. И между прочим, вроде бы древний и замшелый Delphi/Object Pascal сейчас на 10-м месте в рейтинге TIOBE.
А в это время и на этом фоне с начала 2000-х "мамкины кодеры" очень быстро могли осваивать ВЕБ и JS и это было относительно безопасно для производственного процесса и очень выгодно для т.н. эффективных мЭ-Э-Энеджеров.
Сейчас есть надежда, что, например, благодаря денежным вливаниям серьёзно взлетит такой фреймворк(язык) как Flutter(Dart) для красивого, современного, безопасного, кроссплатформенного и производительного мордошлёпства (включая и идентичную отрисовку в Веб поверх Canvas).
А может появится что-то ещё лучше этого. Короче, "будем посмотреть" (tm)...
НО если проект Flutter+Dart стараниями Google взлетит, то тогда велика вероятность, что HTML+JS погонят SSаными тряпками из кросплатформенного мордошлёпства и тем более с серверов туда, где ему изначально самое место - на поддержку динамики ВЕБ-сайтов.
Но пока здесь ключевое слово - #если ))
На Qt с их QML надежды не много. Да, там очень хорошее конечное быстродействие и очень объёмная библиотека, но как ни крути без знания C++ всё равно соваться не желательно, что как бы уже повышает порог вхождения.
Ну а Delphi/Lazarus (Object Pascal) при всём моём глубочайшем уважении, какой там фреймворк уже не прикрути, уже вряд ли снова станет майнстримом.
Слишком уж архаичен синтаксис. Много чисто исторических затычек из разряда "так уж повелось" и т.п.
ХОТЯ В НЕКОТОРЫХ НИШАХ ОН ПО ПРЕЖНЕМУ ХОРОШ, поскольку при грамотном использовании даёт быстродействие найтивного кода сравнимое с Си/C++ при гораздо меньшей вероятности выстрелить самому себе в ногу.
Я использую Delphi + FMX для создания десктопа и кроссплатформенных приложений. Прекрасно справляется
А можно названия этих приложений?
Для поиска?
Из публичных есть MinesweeperFMX, который можно найти в Google Play, App Store, RuStore и ещё других магазинах. Есть ChatGPT клиент. Открытый, для всех платформ (корме iOS), который был создан ещё до официального и многих других аналогов. Было ещё приложение VKAudioPlayer на Андроид и Windows, до блокировки API VK для музыки. Хотя можно и сейчас использовать, обходными путями, но я не обновляю приложение.
Есть альтернативный GUI для пакетного менеджера Delphi (HGMGetIt).
Недавно писал приложение для прослушивания музыки из своего личного Google Drive (Strato). Не до конца доделан.
Открытый TOTP аутентификатор (HGM Authenticator).
ColorToStrNew - приложение для получения цвета с экрана и работы с цветом.
HyperHacks - если найдешь такое приложение в сети. Это приложение для использования платных закрытых читов для игр через инжектирование. При чем инжектирование там реализовано без наличия dll на диске, напрямую из памяти. По этому, антивирусы его не определяли как вредонос. И игры тоже, т.к. dll погружалась напрямую в память, без видимого импорта.
По поводу Flutter+Dart не всё так однозначно. Это взлетает только благодаря неповоротливости W3C, проворности WebASM и превращения браузера фактически в отдельную ОС где каждый разработчик браузеров пишет плюшки которые первые взбредут и становятся общеупотребимым де-факто. Как только займутся зоопарком из CSS/JS/HTML/JVM и производных, которые раньше назывались Marcomedia Flash / Silverlight и выпустят необходимый стандарт, тогда останется только то, что собственно будет его поддерживать, включая синхронизацию с беком, где также наведут порядок с TLS/HTTPS и прочими S. И это будет даже не язык программирования а его, скажем так, спецификация, включая протоколы. Отсюда тут же выскочит фреймворк который позволит это сделать в два клика для фронта и бека а какой ЯП для него будет это уже вопрос десятый. Скажут что должна быть полноценная асинхронка, сборка мусора, межпроцессное взаимодействие (чтобы несколько табов одного сайта не превращали память в схрон одинаковых объектов), корректные деструкторы с сохранением сессий, идентификаторы и временные метки - значит тут же возникнет ЯП, теперь это уже не проблема скормить файлик грамматики тому же Питону.
Ооо, а какую статью чел напишет когда узнает о настоящей типобезопасности? О том что существует язык где разделены nullable и notnull типы?
Давайте я ему скажу, а вы через месяц мне доложите что он там накорябает.
Язык называется Kotlin, и это просто лучшее (c# не дотянул до java, а kotlin это шаг вперёд от java)
Не понял названия статьи... Ничего не потеряли вместе с Pascal - множество разработчиков по всему миру реализуют отличные приложения на FreePascal
Что думаете по явные объявления типов локальных переменных? В паскале такого не было, а появилось в относительно свежих языках или let в расте или auto в C++. В плане написание кода удобнее, но что насчет читаемости?
Я жив :)
Паскаль форева :)
Я ещё застал холивары «Pascal vs C». Отчётливо помню, что у апологетов С никаких доводов, кроме криков про «свободу» и завываний про «философию» и прочих эмоций - не было.
Что имеем по итогу. ОКАЗЫВАЕТСЯ(!), в критических применениях на С пришлось натянуть MISRA, в результате чего «лёгким движением руки брюки (зачёркнуто) С превращается… Превращается С…» В Паскаль! Только с кучей неочевидных, контринтуитивных, противоречащих математике и здравому смыслу «правил и соглашений». Например, вот КАКОЙ ИДИОТ придумал приводить все »целочисленные типы по умолчанию» к Integer, а не к старшему типу в операции? (Старшинство: float в порядке убывания точности, далее знаковые целые так же, далее беззнаковые целые так же). Вот кому нужен в низкоуровневом жонглировании регистрами в полностью беззнаковой математике этот всратый знаковый интежер?
Далее, с одной стороны С так же точно трахает мозги с типами итд в очевидных ситуациях, когда ты точно понимашель что происходит в коде. Но с другой стороны - оставляет КУЧУ неочевидных возможностей выстрелить себе в ногу, которые - та-даммм! Ошибкой компиляции не являются.
Вот такая вот «свобода». А в Паскале если НАДО - то можно и флоат прочесть побайтно итд, но с другой стороны - он не позволяет накосячить неосознанно.
Очень жаль, что Паскаль не получил такого широкого распространения. Прекрасный язык для критичных приложений.
То, что программу тридцатилетней давности можно скомпилировать на современном компиляторе без ошибок и предупреждений, говорит о том, что язык не развивался. Даже в Java, где обратная совместимость возведена в ранг религии (что я считаю ошибкой, мешающей инновациям), сколько-нибудь сложные программы плюнут минимум предупреждениями (иногда и ошибками, если постараться). Просто потому что язык совершенствовался. Паскаль же просто избежал этого. Он что, был совершенством и идеалом уже тридцать лет назад, что избежал развития в принципе? Хранил девственность всё это время?
Нет, он родил множество наследников.
Если точнее, все это наследники его отца, Алгола.
Вот именно. Но наследники рождаются не просто так. Как правило, они компенсируют какие-то дефекты предком. Если в итоге родитель оказывается на обочине - дефекты были фатальными. Но по сути, как вы правильно заметили, даже наследниками Паскаль не обзавелся. И практически не развивался всё это время. Значит, реальная потребность в этом языке является очень низкой.
То чувство, когда просто пишешь на Java
Идеальный язык для обучения, особенно в сочетании с книгой дяди Никлауса Вирта
Даёшь Object Pascal c корутинами! Да хоть бы с многопоточностью.. /sarcasm
Иной раз хорошую статью зачем-то минусуют. Здесь же статья про статическую типизацию, автор зачем-то достал Паскаль и стоит с ним как с писаной торбой. За что столько плюсов? Представь сюда любой язык со статической типизацией - смысл не изменится
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что потеряли вместе с Pascal: типобезопасность, которую мы недооценили