Комментарии 469
Паскаль тяжело назвать мертвым. Он все еще частенько юзается в энтерпрайзе (Delphi) и энтузиасты продолжают на нем пилить всякие штуки
да скорее всего для чего-то нового и серьезного уже практически никогда не будут выбраны эти технологии. легаси не в счет как и старые привычки ) либо я упустил что-то еще
Зря Вы так.
Под WIndows быстрее, чем на Delphi, не знаю на чём можно написать ПО для работы с специфическими данными заказчика под Windows XP/7/8/10/11.
Ключевое тут - быстро. А ещё лучше - очень быстро. И про кроссплатформенность речь не идёт, как правило. Главное, чтобы под WIndows работало. С флэшки. Заказчику нет никакого дела до того, на чём программист реализовал его хотелку. И в качестве аргумента "На хххх программировать я учился ххх лет и в связи с этим ПО будет стоить ххх денег" приниматься заказчиком не будет. Тут больше сработает принцип "Посмотреть на дом, как жена одета и дети, на чем приехал и назвать цену "Вам не дорого и мне не дёшево"". Речь правда о небольших заказчиках.
На Delphi (10.3) до сих пор пишу.
Ещё можно добавить, имхо, Delphi - лучший язык программирования, как первый. В плане синтаксиса достаточно простой и очень приятный, при этом все современные концепции присутствуют.
Ещё бы не был он столь многословным - цены б ему не было.
То же самое хотел написать: в какой-то момент люди выбирают Си-подобные языки потому, что там есть сокращённый синтаксис, да и в целом меньше букв надо нажимать.
С моей точки зрения, проблема в обратном - в "читабельности" программ программ написанных на Паскале (и его "родственниках"). Современные IDE хорошо помогают с печатанием кода. Код с большим количеством зарезервированных слов наподобие BEGIN ... END нашему мозгу труднее парсить нежели { .. }. Хотя, персонально, моим самый любимый языком является ADA и подобные строго типизированные языки.
Мало какой язык может соревноваться в плане читаемости с Паскаль.
{}, int[], Arr[::c] и подобные конструкции вообще не предназначены для человеческого мозга.
Тут ситуация, как со стенографией: если не знать, что значат все эти значки, нифига не понятно, но если её освоить, можно писать заметно быстрее.
А так же помнить кучу нюанов из-за компромисных решений разработчиков С\С++: например в зависимости от контекста *имя может быть как именем указателя, так и значением под указателем, разнофункциональность слова static и т.д.
"Стерпится - слюбится".
Если синтаксис "SELECT * FROM A LEFT JOIN B" заменить на "# * @ A < ? B", SQL-щики будут довольны?
С таким утрированием можно в другую сторону пойти и заменить = на EQUALS := на ASSIGN 1 на ONE и т.п.
И будет у нас
if (a LESS then b) then
begin
a ASSIGN b PLUS FOUR TWO OP_END
end OP_END
Стало лучше?
Получился примерно COBOL если что :).
Но вообще - если вспомнить какое количество ошибок возникло из-за '=' и '==' в разных языках - то ASSIGN уже не кажется хтоническим злом )))
Я не утрирую.
Человеку всегда легче работать с интуитивно понятными вещами. Интуитивно понятно что "=" и "equals" это одно и то же.
Вот у нас есть две крайности: многословный SQL и лаконичный Regex. На чём пишется быстрее и какой код получается более читаемым?
Человеку всегда легче работать с интуитивно понятными вещами. Интуитивно понятно что "=" и "equals" это одно и то же.
Не надо говорить за всех. Мне вот это не было интуитивно понятно. Меня так научили, это да. Но интуиция тут вообще не при чём.
Я скажу: простые запросы и простые регекспы одинаково хорошо читаются. Сложные запросы также сложно читаются, как и сложные регекспы.
Чуть-чуть схитрил: это с учётом, что большинство движков регулярок поддерживает расширенный синтаксис с пропуском whitespace и комментариями. Классический синтаксис быстро становится нечитаемым с ростом регулярки.
можно писать заметно быстрее
критична не скорость, с которой вы пишете, а скорость, с которой вы думаете :)))
Мало какой язык может соревноваться в плане читаемости с Паскаль.
Это точно, Pascal — самый лучший ЯП для начального обучения основам программирования и ООП, кто бы что ни говорил. Хорошая читаемость текста программы, четко выраженная модульность, явная типизация переменных, наглядное представление объектов при ООП (в отличие от др. ЯП) и т.д. Далеко не все школьники и студенты могут начать изучение программирования с ООП на C++ или Python; а вот на Pascal — значительно легче.
ЯП Pascal — живее всех живых (как бы кто его ни хоронил) и до сих пор используется во мн. серьезных проектах (хотя с годами почему-то все реже), выходят новые версии (в т.ч. в этом году) ЯП (Free Pascal, GNU Pascal и др.) и сред разработки (Embarcadero Delphi, Lazarus, PascalABC.NET и др.)
Небольшое уточнение. PascalABC.NET - это не только среда разработки, но и прежде всего диалект языка программирования Паскаль с весьма большими расширениями.
Про восприятие школьниками Паскаля - полностью поддерживаю - наш опыт говорит, что его синтаксис воспринимается и читается начинающими легко.
Как прошедший этот путь школьник скажу - в других языках многие понятия довольно абстрактны, та же функция это некий "объект который можно вызвать". У объекта можно взять ссылку, манипулировать им... А что в паскале? Есть ПРОЦЕДУРА которая ничего не возвращает, а есть ФУНКЦИЯ которая возвращает результат.
Во многих языках переменная такой же абстрактный тип, она может быть статической, глобальной, множественно-определяемой, константной лалала... В паскале же у тебя все переменные одного типа хранятся в одном месте, а если надо создать переменную на стеке то ты явно пишешь var n : integer; и этот "var" сразу в глаза бросается и сразу всё становится понятно.
И неподготовленным мозгам паскальные "абстракции" воспринимаются легче, а к многословности привыкаешь.
UPD Хотя я в итоге слез с него, ибо его конструкции с условиями и циклами довольно ограниченные. Я помню что не смог найти как итерироваться по какой-то формуле, надо было либо использовать математику либо while циклы с каким-то лишним кодом.
Деление на процедуры и функции как говорит наш опыт хорошо воспринимается начинающими.
А про переменные - современных школьников мы учим вначале в стиле с автовыведением типа:
var n := 10;
var x := ReadInteger;
Явные типы вводятся потом и в ограниченном числе задач. Это позволяет понизить сложность.
Кстати именно для цикла с шагом, о котором Вы наверное говорили, мы вводили конструкцию
for var i:=1 to 10 step 2 do
Начинающие её также отлично воспринимают
По-моему, автовыведение типа – это весьма сложная для новичков концепция, которую ваши ученики вряд ли полностью понимают. Рад, если я ошибаюсь.
Я иногда занимаюсь репетиторскими занятиями по программированию со студентами, далеко не новичками, и я просто открывал им глаза, объясняя различие в семантике оператора присваивания в языках со статической и с динамической типизацией. Вообще это проходит на институтских занятиях мимо многих. А тут ещё более хитрый случай.
Ошибаетесь. Школьники, даже младшие (6-7 класс у нас), отлично понимают, что в записи
var n := 10;
var a := 2.5;в ячейку памяти n записывается целое, а в ячейку памяти a - вещественное.
В языках с динамической типизацией конечно имя связывается со значением, и это может вызывать удивление. Но здесь никаких проблем с усвоением нет. Приучаешь вс время задавать вопрос, какого типа данная переменная. Система intellisense кстати позволяет это подглядеть, просто наведя в редакторе курсор мыши на имя. Поэтому у нас тут никогда не возникает проблем с объяснением. А когда объясняем школьникам постарше, какого типа скажем
var gr := a.GroupBy(p -> p.Age);то тут говорим сакральное "здесь сложно - это знать необязательно, надо знать лишь, что можно сделать с результатом".
Ошибаетесь. Школьники, даже младшие (6-7 класс у нас), отлично понимают, что в записи
var n := 10;
var a := 2.5;в ячейку памяти n записывается целое, а в ячейку памяти a - вещественное.
Это-то (поверхностно) понять несложно, это прямо буквально на экране написано. Сложно понять, что происходит при дальнейших присваиваниях.
Вы задайте им мой вопрос ниже, вот и посмотрим, отлично понимают или не очень.
Так и в других языках циклы вполне себе красиво записываются, например Python:
for i in range(1, 11, 2): ...Или например Scala
for (i <- 1 to 10 by 2) { ... }Или Kotlin:
for (i in 1..10 step 2) { ... }Попробуйте попросить своих учеников интерпретировать следующий код:
var x := 1;
var y := 1/2;
x := x+y;Если у вас хотя бы половина учеников при таком подходе сможет правильно назвать результат, я удивлюсь. Зато не удивлюсь, если вообще никто.
а в чëм тут может быть сложность?
В том, что в последнем присваивании не совпадают типы справа и слева, оба из которых вводятся неявно и вдобавок не вполне очевидным образом. Результатом в данном случае будет ошибка компиляции.
Конечно, профессиональный программист это легко поймёт, но для новичка, который не акцентируется на типизации, это сложный вопрос.
Хотя тут ещё какой профессиональный программист. Двое из трёх джунов отвечают, что в операторе языка Си
float f = 1/3;в результате получится 0.3333333
Плохой пример, потому что невнимательный человек даст верный ответ из ошибочных соображений.
А так тут вроде всё довольно логично. Именно так и работает машинная система представлений чисел, Си тут не особо причём. Если мы типизируем машинными типами (что, я согласен, для обучения новичков вообще-то не нужно), то так и должно быть.
Все три результата равны 1 (младшая половина результата умножения ff..ff на себя), или я чего-то не догоняю? Вроде проверил на натуре.
Вот не можете вы в простоте ничего написать. Я в тайге сижу с мобильником, мне тяжело очень обвязку дописывать.
У плюсов есть правило что в вычислениях целочисленные аргументы вначале приводятся к int (или unsigned int) а уже потом результат кастится обратно в то что там пользователь запросил. Поэтому в первых двух вариантах будет возвращено все 16 / 32 бита результата а в третьем только последние 32. Все потому что не у всех CPU есть регистры по 8/16 бит и на каком-нибудь ARM данные загружаются в 32-битный регистр и арифметические операции проводятся над ним.
Да ладно, я давно на Си плотно не писал и его не преподаю. Но мне что-то кажется, что эта тема с промоушеном до int не сразу в языке появилась.
Здесь пишут, что требование integer promotion впервые появилось в C99. Поскольку я Си углублённо изучал до того, то, видимо, не уследил.
gcc со старыми стандартами работает путём реверсного проектирования от существующей ситуации, все неопределённости разрешая в пользу современных стандартов. В этом отношении бессмысленно смотреть на его понимание. А clang повторяет gcc. Когда вернусь домой на следующей неделе, попробую запустить настоящие компиляторы тех времён.
Но возможность была, это факт. В то время было неопределённое поведение, как я понимаю.
Да, попробованные мной компиляторы (16-разрядный Turbo C для DOS и 8-разрядный Aztech C для CP/M-80) тоже фактически делают integer promotion (хотя довольно странно для 8-разрядного компилятора промотить выражения в 16-разрядный int).
Но Вашу задачу это не делает разрешимой, так как разрядность int может быть любой.
Я бы сказал, что ожидаемый результат именно третий.
Попробую. В сентябре уже :)
Но мы учим, что в Паскале при делении целого на целое результат вещественный. Учим, что целому нельзя присвоить вещественное. Просим посмотреть тип y в среде при наведении курсора мыши - он будет real.
И здесь - центральный вопрос - "так почему же этот код не компилируется?"
Я вас уверяю, найдётся школьник который ответит точно.
Просто это вопрос методики - как учить. Если учим на статически типизированных языках, то вопрос о типах - важнейший. И дети быстро это хватают.
Методически кстати можно попросить написать типы явно в первых двух строках:
var x: integer := 1;
var y: real := 1/2;Центральный вопрос здесь вообще понять, что код не скомпилируется. А почему – уже легче разобраться.
В других языках ещё могло бы и неожиданно округлиться, но на Паскале мне сложно сейчас придумать такой пример за долгим отсутствием практики.
Ну, код не скомпилируется потому что мы запустим компилятор, и он выдаст: "Нельзя преобразовать тип real к integer". И тут начнут догадываться, что что-то не так с типами :)
Вот ошибка, которую школьники допускают чаще:
var s := 0;
loop 10 do
begin
var x := ReadReal;
s += x
end;И здесь эту характерную ошибку приходится объяснять. Но после двух-трех раз они научаются такие ошибки исправлять.
Конечно Вы правы: новые возможности влекут за собой новые проблемы - и где найти баланс...
Ну с компилятором-то несложно ответить. Это вопрос для ответа в уме :)
В вашем примере по сути то же самое, что в моём.
Всё же, я поддержу другого. Лучше в качестве затравки дать базовую запись с явным определением типа, а потом сказать в духе "ну можно эту запись сократить ибо компилятор умный и сам может понять что вы ему пишите - *пример*"
Просто надо базу знать, хотя бы на уровне "о мне чотатам объясняли за это когда-то". Иначе персонаж будет уметь "писать код" а не "программировать".
Это зависит от методики - поверьте. Мы 20 лет учим разных школьников - методика менялась. Факт тот, что типы надо упоминать обязательно - но чуть позже чем на первом занятии.
Что же касается студентов - то да - обязательно. У нас студенты, пришедшие на 1 курс с бэкграундом Питона испытывают ломку, когда сразу начинают программировать на статически типизированных языках с компилятором. Основной вопрос: "а что, еще и какие-то типы в программировании есть?". Это - ломка, и порой время на неё превосходит время освоения у тех, кто учится программировать с чистого листа.
У нас студенты, пришедшие на 1 курс с бэкграундом Питона испытывают ломку, когда сразу начинают программировать на статически типизированных языках с компилятором
Потому что нет нормального ЯП для обучения, в котором требования компилятора шли бы по нарастающей.
Ну здесь конечно тема холивара - что такое нормальный язык программирования для обучения :) У всех представление об этом сильно разное :)
Ну здесь конечно тема холивара — что такое нормальный язык программирования для обучения :) У всех представление об этом сильно разное :)
Она холиварная, когда приходится выбирать из уже существующих. Если же про сферический ЯП для обучения в вакууме, то будет всего два варианта — для обучения "сверху" (когда сначала учатся выдавать результат) и для обучения "снизу" (когда начинается с алгоритмов).
Просто я очень долго мучал свои мозги, пытаясь понять как лучше себя чему-то учить.
В плане организации знаний лучше подходит метод "вот мы учим это, но есть что-то ещё", ибо ты заранее подготавливаешь себя о неполноте твоих знаний. А метод "добавления", который вы используете, работает только на эмоции(мотивацию) и работоспособность, но не на качество. Хотя, может это важно для молодняка, но и первый способ можно рассказывать так, чтоб заинтересовать людей.
ЗЫ у меня не 20 лет опыта, от силы 3-4, но спиногрызов учил и вполне успешно, за одним но... Мои методы хоть и давали почти 100% выхлоп, но приличное количество людей уходят. Я до сих пор не понимаю почему они уходят если у них всё получается... Это даже к студентам относиться...
Вы правы - школьников надо прежде всего заинтересовать, ввести в профессию. Какие-то более глубокие связи у них начинают формироваться лишь позже.
А студентов конечно учат по-другому. Младший курс - в основном приучаем соблюдать спецификацию, старшие - там уже посвободнее. Но это опять таки - не темя комментариев к этой статье про почти мёртвые языки программирования :)
Это зависит от методики — поверьте. Мы 20 лет учим разных школьников — методика менялась. Факт тот, что типы надо упоминать обязательно — но чуть позже чем на первом занятии.
Что же касается студентов — то да — обязательно. У нас студенты, пришедшие на 1 курс с бэкграундом Питона испытывают ломку, когда сразу начинают программировать на статически типизированных языках с компилятором. Основной вопрос: "а что, еще и какие-то типы в программировании есть?". Это — ломка, и порой время на неё превосходит время освоения у тех, кто учится программировать с чистого листа.
На Хабре в далеком 2012г. пробегала статья (ссылка у меня с тех пор осталась в закладках) — очень полезна для студентов и школьников:
Ликбез по типизации в языках программирования
Попадалась эта статья. Ну, для школьников имхо это сложно. Это хорошо для тех, кто уже знает несколько языков программирования.
Автор статьи несколько запутался в терминологии, называя ассемблер бестиповым языком и утверждая, что он работает исключительно с битовыми последовательностями. Например, результаты некоторых команд вещественной арифметики не определены на битовом уровне.
Ассемблер обычного процессора - типичный слабо типизированный язык с парой десятков встроенных типов.
Лучше в качестве затравки дать базовую запись с явным определением типа, а потом сказать в духе "ну можно эту запись сократить ибо компилятор умный и сам может понять что вы ему пишите — пример"
Еще лучше сначала давать вообще без указания типов, но использовать один тип данных. А потом уже вводить другие типы данных вместе со строгой типизацией. Ну и в компилятор галочки добавлять по мере изучения новых подходов.
это нужно просто знать и это спецификация конкретного компилятора - что он будет делать при разных типах. Некоторые могут неявно приводить к одному из типов, некоторые выдавать предупреждения, а некоторые ошибку.
Не у меня были именно итераторы. Для этого только Foreach подходит. И то, там итераторы довольно ограниченные, в С++ в этом плане можно больше ужаса создать.
Зато много вопросов к локальности переменных и вообще градаций локальности данных
Код с большим количеством зарезервированных слов наподобие BEGIN ... END нашему мозгу труднее и все парсить нежели
Может быть, мой мозг какой-то нестандартный, но ему как раз код с большим количеством слов вместо мелких значков разбирать проще. Смотришь - и все сразу видишь. И в глаазах не рябит.
Мозг понимает картинки быстрее, чем слова. Письменность с многобуквенными словами появилась позднее, чем 1 картинка = 1 слово. Используется более древний и значит более отточенный эволюцией механизм сличения картинок.
Так что мозгу действительно проще разбирать несколько видов скобок, чем begin end. Если он знает их смысл.
Не случайно люди любят эмоджи и всякие стикеры в переписках. 1 картинка считывается быстрее, чем слово или несколько.
Я воспринимаю begin..end по цвету, цвет воспринимается ещё быстрее чем картинки. Где больше синенького, там служебные слова. Там где черненькое, там операции над переменными.
Есть ещё такой аспект. Если у человека не идеальное зрение, ему трудно быстро сосчитать скобки. Четыре скобки или пять? Попробуйте определить на глазок.
Мозг понимает картинки быстрее, чем слова
Фокус в том, что часто используемые слова в программе (те же begin и end) воспринимаются как картинки, а не как последовательность символов, которую нужно еще прочитать. Причем как большие, хорошо различаемые между собой картинки. А от скобок этих в глазах рябит, поскольку они просто теряются на экране. Одиночную скобку в строке могу и не заметить с первого взгляда. Да еще не очень хорошо отличаются друг от друга при быстром взгляде на экран: круглые, фигурные, квадратные - слишком мелкие и похожие друг на друга.
Действительно, большое количество begin-end нагружает программу, но обычно их много не бывает. К тому же, эквивалентная программа на C с большим количеством }}}} в конце тоже не очень читабельно. А все современные IDE подсвечивают парность операторных скобок, что конечно улучшает восприятие
тут и дело привычки конечно многое значит. я всегда с ужасом смотрел на C и Java после Delphi. В Delphi всë структурировано и читабельно, в C/Java всë намешано в кучу. Всегда была ассоцияция как будто код запихнули в миксер, хорошо перемещали и сказав вот читайте. скобки вместо begin end это мелочи.
Велика ли разница:
procedure ReverseArray(var arr: array of integer);
begin
var i := 0;
var j := high(arr);
var temp := 0;
while i < j do begin
temp := arr[i];
arr[i] := arr[j];
arr[j] := temp;
Inc(i);
Dec(j);
end;
end;public static void reverseArray(int[] arr) {
int start = 0;
int end = arr.length - 1;
int temp;
while (start < end) {
temp = arr[start];
arr[start] = arr[end];
arr[end] = temp;
start++;
end--;
}
}
Меня больше всего напрягали в паскале именно эти begin end, когда учился в универе. С++ нравился именно из-за {}, вместо паскалевской конструкции.
begin end ставятся при помощи хоткеев, вручную набирать не обязательно.
begin...end гораздо нагляднее разделяет код на смысловые блоки, чем {}. Код становится более читабельным.
Например:
while i < j do begin
temp := arr[i];
arr[i] := arr[j];
arr[j] := temp;
Inc(i);
Dec(j);
end;Начало смыслового блока while i < j do begin визуально уравновешивается end в конце. Всё что между ними - это операции над переменными. Таким образом код получается структурированным и читаемым.
Когда пишете
while (i < j) {
temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
i++;
j--;
}вы видите начало конструкции, но приходится всматриваться где она заканчивается.
рисую отчеты в фастрепорте и вот там меня подбешивают эти бегиненды, да можно перейти на c-подобный синтаксис, но паскль привычней.
Удобство побеждает ленность.
… Или можно просто вызвать arr.reverse() и не думать об индексах вообще /s
Интересно, есть ли какие-то исследования на этот предмет? Что лучше с т.з. когнитивной нагрузки - большее количество native text или меньшее количество спецсимволов - в идеале еще и с разбивкой по "уровню подготовленности"?
Т.е. мы-то понятно - 30 лет за компом, кто к чему привык, то и "удобно\лучше", а вот без этого "стокгольмского синдрома"? Для диспетчеров\операторов точно знаю, достаточно масштабные исследования проводились - а вот для программистов я хз... было бы интересно.
Я думаю, что лучше спецсимволы. Они сильнее выделяются по начертанию.
Парсинг картинок более древний механизм мозга (а значит более развитый). Письменность с многобуквенными словами появилась позднее.
Не случайно у людей популярны всякие эмоджи в переписках. Скорость восприятия одной выделяющейся картинки выше, чем скорость восприятия слова (которое по факту есть последовательность из нескольких картинок).
Спецсимволы выделяются сильнее на фоне всяких имён переменных и т. п.
Я думаю, что begin end хорошо воспринимается именно из-за подсвечивания. То есть человек может ориентироваться не только на начертание, но и на цвет. И это ускоряет восприятие, а не "нативность".
Но при этом иероглифическая письменность проиграла фонетической - именно по причине большей когнитивной нагрузки.
Тут еще такой момент, что native text в программировании использует те же нейронные связи, что и обычный текст в жизни, а спецсимволы за пределами кодинга не используются примерно нигде - т.е. даже если "абстрактно-вакуумно '{' воспринимается лучше 'begin' (А это мы еще про шрифты и различия между '{([' на письме не говорим!) - то наша нейросеточка тупо лучше обучена на распознавание этого самого begin'а".
В общем, выглядит как тема для ха-аарошего такого исследования ).
иероглифическая письменность проиграла фонетической
认真的 ?
Во-первых, иероглифы использует больше миллиарда человек. Так что проиграла условно.
Во-вторых, сравните количество иероглифов и количество спецсимволов в С-подобных языках. Кстати, в Pascal тоже есть спецсимволы, просто чуть меньше. Всего лишь на 2-3 (begin, end, array of).
В-третьих, иероглифическую письменность дольше учат, зато быстрее читают. Буквы выигрывают именно по порогу входа. Однако, столь высокий порог входа обусловлен количеством и сложностью начертания от руки (компьютеры стали массовыми совсем недавно и, внезапно, сейчас бум эмоджи, которые чем-то похожи на иероглифы - 1 символ = много смысла). Спецсимволов в С немного и они простой формы.
Да-да, тут я должен сказать, что корпус написанных на фонетических языках текстов порядково превосходит записанный иероглифическим письмом бла-бла-бла - но не буду. - совсем уж в сторону уйдем, при том что всем в общем-то все понятно и ратующих за всеобщий переход на иероглифическую письменность разве что 1,5 депутата на всю Россию найдется.
По поводу "много\не много" - гляньте на плюсы и добавьте перегрузку операторов чтоб совсем хорошо стало.
Кстати, а эмодзи - вообще дикий костыль, порожденный отсутствием сколько-нибудь вменяемых средств ввода в современных телефонах.
Было, я плохо помню, но делали исследования типо "количество ошибок на программу" или что-то такое. Многословные языки выигрывали всегда, за них топили многие крупные игроки в "те" времена, но... Юниксоиды поверили в С и все кто мечтал о свободном ПО писали именно на нём. В итоге, как писали выше, "эмодзи победили".
И единственное что мне приходит на ум в виде "промежуточной версии в эволюции" это Java. Где и символьный синтаксис и миллиарды спецслов.
Приходится тыкать на скобочки, чтобы они подсвечивались. Иначе в сложных конструкциях не понять,какая скобка к чему относится.
В редакторе PascalABC.NET при помощи хоткея wb <Shift-пробел> набирается вся конструкция
while do
begin
end;
<повтор - удалено>
вы видите начало конструкции, но приходится всматриваться где она заканчивается
Смотрите на отступы, и тогда скобки или begin\end не будут играть разницы.
Вдобавок можно добавлять пустые строки в код, и строка с } выглядит практически как пустая.
while i < j do begin
temp := arr[i];
arr[i] := arr[j];
arr[j] := temp;
Inc(i);
Dec(j);
end;
while i < j do begin
temp := arr[i];
arr[i] := arr[j];
arr[j] := temp;
Inc(i);
Dec(j);
end; while (i < j) {
temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
i++;
j--;
}
while (i < j) {
temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
i++;
j--;
} while (i < j):
temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
i++;
j--;
while (i < j):
temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
i++;
j--;На мой взгляд, begin и end выглядят как шум.
У меня свои личные требования к синтаксису:
- служебные слова (if, then, while, begin), операторы (+, <, =, ==), переменные (a, b, temp, socket, canvas) и классы (TSocket, TCanvas) должны быть визуально легко различимы друг от друга.
- поэтому это плохая практика, когда специальный символ "{" используется в качестве служебного слова. Специальные символы надо зарезервировать для операторов.
- это нехорошо когда начало блока while { легко различимо на странице, но приходится искать конец блока }.
- критические важные элементы кода должны занимать достаточно много места на экране. Неправильно, когда критически важный элемент кода выглядит как малозаметная точечка. Если это правило нарушается, то при чтении кода (а особенно при редактировании чужого кода) приходится вглядываться в каждую точечку.
- односимвольные элементы кода должны иметь защиту от дурака. Точка, двоеточие, скобка, фигурная скобка должны иметь однозначный смысл. Они не должны менять своё значение в зависимости от контекста.
- синтаксис должен быть интуитивно понятен. Почему-то иконки стараются делать интуитивно понятными, а элементы синтаксиса делают контринтуитивными и предлагают просто это запомнить и смириться. Но ваше подсознание всё равно продолжит протестовать против контринтуитивных символов.
На мой взгляд, begin и end выглядят как шум.
Согласен, тем более что с 1978 года begin зачастую не нужен:
while i < j dovar··········temp := arr[i];·····begin··········arr[i] := arr[j];··········arr[j] := temp;·····end;·····Inc(i);·····Dec(j);
end;
Синтаксис -- условный: нижний регистр из DECWRL Modula-2, объявление "по месту" из Modula-3
P.S. "·····" -- борьба с "улучшенным" режимом редактирования Хабра. Исправлю, если расскажите, как жить без них... Спасибо!
Причем с современным autocomplition'ом\сниппетами\live templates\контролем операторных скобок и пр на большую часть этого примерно пофиг.
Велика ли разница:
Когда int и var и на таком маленьком куске, то не велика. Вопрос всегда ли у вас только int или бывают и названия классов подлиннее?
var i := 0;
var j := high(arr);
var temp := 0;
Теперь так в Delphi можно делать? В классическом Pascal и в (старых?) Delphi был отдельно блок var в начале каждой функции, процедуры или юнита/программы.
Да. Но есть нюанс:
if true then begin
var i: integer;
var j := 0;
i := j;
end;
x := i; // ОШИБКА! переменная i определена только внутри конструкции ifПри таком объявлении переменная будет видна только внутри своей синтаксической конструкции.
Супер. Спасибо! Нашел в доках этот раздел, фича языка называется inline variable declaration. Действительно получается, что и среда разработки, и язык, живее всех живых и активно поддерживаются.
При таком объявлении переменная будет видна только внутри своей синтаксической конструкции.
Все верно, так и должно быть. В других языках именно таким образом и происходит.
Дельфийский код сейчас выглядит так:
class function TUtils.zip<T1, T2>(e1: TArray<T1>; e2: TArray<T2>): Enumerable<Tuple<T1, T2>>;
begin
var aArray : TArray< Tuple<T1,T2> > := [];
for var i: Integer := 0 to Length(e1) - 1 do
aArray := aArray + [ Tuple<T1,T2>.Create(e1[i],e2[i]) ] ;
Result := Enumerable<Tuple<T1,T2>>.Create(aArray);
end;
class function TUtils.zip<T1, T2>(e1: TList<T1>; e2: TArray<T2>): Enumerable<Tuple<T1, T2>>;
begin
var aArray : TArray< Tuple<T1,T2> > := [];
for var i: Integer := 0 to e1.Count- 1 do
aArray := aArray + [ Tuple<T1,T2>.Create(e1[i],e2[i]) ] ;
Result := Enumerable<Tuple<T1,T2>>.Create(aArray);
end;https://github.com/Pigrecos/TensorFlow.Delphi/blob/main/src/Tensorflow.Utils.pas
В PascalABC.NET так можно было делать с 2007 года. В Delphi 11 с 2021 года такая возможность тоже появилась (подсмотрели :), как и возможность писать
for var i:=1 to 10 do
Эта возможность появилась с Delphi 10.3 - 2019 вроде год
Помнится, я скачивал Delphi 10.3 - и там ничего этого не было, в примерах тем более, хотя в блогах писали, что есть.
Удивительно, но Embarcadero не ценит и не рекламирует свои же новшества. Как-то там у них всё запущено...
В 10.3 это было экспериментально. Даже анализатор не понимал что за хрень тут написана, и подсвечивал всё ошибками. Но компиляция проходила корректно и код работал.
В 10.4 всё это начало штатно работать и с анализатором. И можно считать, что именно с этой версии, официально инлайн объявление работает.
И вот тогда уже начали рекламировать это.
Embarcadero не объявляла об это функции в 10.3 именно по этому. Т.е. в компиляторе было уже готово, а вот на уровне среды - ещё нет)
Но именно 10.3 является стартом для новых фич.
После неё, появились: как уже говорили, инлайн объявление, выведение типов, инлайн методов (интерсинки), новые инструкции процессоров, поддержка М2 процессоров, методы инициализации и финализации записей (record), что позволяет реализовать очень быстро и легко смарт-поинтеры, указание чисел вида 1_000_000 (т.е. с разделителем), двоичные числа %1001001, переход на LSP и т.д.
Вот здесь есть список нововведений до 11 версии
https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Help_of_Previous_Versions
А слева можно открыть и нововведения 11
Да, я перечитывал это не раз. Хорошие современные изменения. Паскаль при всём желании нельзя назвать почти мертвым языком как вынесено в заголовок
Паскаль при всём желании нельзя назвать почти мертвым языком как вынесено в заголовок
Он мертвый не потому, что плохой, а потому что крайне мало используется и пока в нем не появляется каких-то киллер-фич, чтобы на него переходить.
В продакшне - да, абсолютно с Вами согласен.
Однако современные школьники на PascalABC.NET вполне успешно сдают ЕГЭ и имеют конкурентные преимущества. Так что в других сферах он не так уж мёртв
Для десктопа он и сейчас один из лучших инструментов, один из неплохих для мобильных и пригоден для веба (там разные способы создания веб-приложений).
Но сейчас процент создания софта на десктоп куда ниже, чем раньше. Сейчас больше всего полагаются на веб. А для веб, он пригоден, но не так сильно развит.
Сам язык хорош и фреймворки для него могут легко составлять конкуренцию не только WinForms, но и WPF, Avalonia, Qt и Flutter.
Т.е. есть всё, чтобы создать полноценный продукт. Стоит только вопрос цены, т.к. язык и среда платные для коммерческой разработки.
PascalABC - это совершенно другой Паскаль, основанный на дотнете и использующий его функционал. В нам даже лямбды есть и LINQ. И работа с WPF.
Несомненно, другой.
Лямбд в Delphi не хватает - это точно :) Понимаю конечно, что это сложно реализовывать.
Но реализация автовыведения типа и внутриблочных переменных (или как они их называют inline) никак не связана с .NET. И это конечно в промышленном языке могло быть сделано значительно раньше чем в 2019 году.
Лямбды думаю скоро будут. Анонимные функций уже давно есть. Грубо говоря, нужна просто краткая форма записи.
А Паскаль абц написан на дотнете и использует его для работы. Там почти все взято из Шарпа)
Ну, от анонимных функций до лямбд - это большая работа. Во-первых, надо где-то размещать эти автогенерируемые лямбдами анонимные функции (внешняя, метод класса, статический метод класса). Во-вторых, захват переменных из разных контекстов. Так что еще это из разряда пожеланий. Хорошая новость - то, что на захваченную переменную можно ссылаться по адресу - в NET это невозможно, и приходится огород городить.
В PascalABC.NET конечно многое взято из C# - но надо понимать, что C# - хороший современный язык - из него грех было не взять, а во-вторых, разработчик C# - один из бывших разработчиков Delphi (операции is и as вошли в C# практически без изменений). Ну и лямбды скажем невозможно просто было взять из .NET (кроме разве что базовых типов Func, Predicate, Action) - это всё требовалось писать руками.
В делфи все это работает уже. Захват переменных в том числе.
Сейчас в делфи анонимные функции отличаются от лямбд только тем, что записываются полной записью.
Передавать их давно можно с захватом переменных.
Да, посмотрел. Тогда полдела сделано. Теперь нужен алгоритм выведения типа при наличии обобщений и нескольких перегруженных версий. Это будет какая-то модификация алгоритма Хиндли-Милнера. Потому что в анонимных функциях все типы указываются явно - это резко всё упрощает.
Это тоже уже работает)
Или я не совсем понял о чем вы
Наверное всё-таки нет. Речь о следующем. В таком коде
a.Select(x -> x.MethodFun) у лямбды нет явных типов - они выводятся компилятором. Select - обобщенный метод, который имеет огромное количество перегрузок. Необходимо выбрать самую подходящую - aaa.Select<T,T1>(fun: T -> T1) - и вывести типовые переменные. В данном случае тип T (это тип параметра x) выводится по типу компонент aaa, потом задается вопрос, есть ли у типа T метод MethodFun без параметров, и его возвращаемое значение становится типом T1. А если что-то сломалось, то ошибка не кидается, а выбирается менее подходящая перегрузка и всё повторяется.
Думаю, в Delphi именно этого нет, иначе бы короткие лямбды они бы уже сделали.
В Делфи в данном случае нужно указать вручную.
Т.е. сейчас это может работать так:
a.Select(procedure(x: TTypeX) begin x.MethodFun end))Ну да, это практически убивает идею цепочки методов и делает практически невозможным код
a.GroupBy(x -> x.Age).Select(g -> (g.Key,g.Count))Здесь во второй лямбде тип группы g непомерно сложный для ручного использования и даже если его писать, то чисто технически он может находиться в другом модуле, который придется неожиданно подключать.
Такой код вполне можно написать. Проблем в этом нет. А подключать модуль с типами нужно и для первого примера.
Единственная проблема - это не удобно писать. Т.е. необходима всё же больше краткая форма, нежели выведение типов. Не думаю, что писать (x: TPerson -> x.Age).Select(g: TGroupBy -> TPair.Create(g.Key, g.Count) сложно. Вполне в духе Паскаля.
Сейчас же это будет выглядеть так
a.GroupBy(
function(x: TPreson): integer
begin
Result := x.Age;
end
).Select<TPair<integer, integer>>(
function(g: TGroupByItem): TPair<integer, integer>
begin
Result := TPair.Create(g.Key, g.Count)
end);Вот специально попробовал написать это в PascalABC.NET с явным указанием типа:
begin
var a := Arr(1..5);
a.GroupBy(function(x: integer): integer -> x mod 2)
.Select(function(gr: System.Linq.IGrouping<integer,integer>): (integer,integer) -> (gr.Key,gr.Count))
.Print
end.Несколько раз ошибался, потому что тип gr неочевиден. Это всё несомненно должен делать компилятор
Нет, не может быть. Всё равно в какой-то момент на втором этапе компиляции шаблонов C++ когда будут инстанцироваться конкретные типы - в этот момент должны быть выведены все типы в параметрах и возвращаемом значении лямбды. Волшебства не случится - даже в C++. Это всё языки со статической типизацией - и Паскаль, и C# и C++ - типы шаблонов должны быть получены до запуска программы. Лишь в Питоне это будет отложено до этапа выполнения и если что не так - упадёт.
Это появилось в ноябре 1988 года.
Без излишнего VAR , кстати
Только в Modula-3. И ещё раньше в Ada
В паскалевском ReverseArray var перед параметром - лишняя - там массив и так передается по ссылке во всех известных диалектах Паскаля.
И для лучшей читаемости рекомендуют писать begin с новой строчки и end под begin. Как и { } во многих правилах написания кода. Но дело вкуса - я понимаю.
Велика
public static void Reverse<T>(this T[] arr)
{
for (int start = 0, end = arr.length - 1; start < end; ++start, --end)
{
Swap(ref arr[start], ref arr[end]);
}
}
private static void Swap<T>(ref T a, ref T b) {...}Выше я приводил код без оптимизации.
В оптимизированном коде Delphi нет никаких лишних телодвижений:
procedure Reverse(arr: TArray<integer>);
begin
var s := low(arr) - 1;
var e := high(arr) + 1;
while ( IncF( s ) < DecF( e )) do SwapArr(arr[s], arr[e]);
end;
procedure SwapArr( var a, b: integer ); {...}
PascalABC (за качество не ручаюсь)
a := a.Reverse.ToArray;
На c# + wpf/winforms можно сделать как минимум не медленнее, с меньшим количеством багов и плюс людей умеющих писать код найти куда проще, ибо их больше. Да и можно использовать лучшие IDE для разработки.
На Delphi сам писал. Лет 15 назад... Практический смысл делать что то новое на этом примерно тогда и закончился.
"на c# + wpf/winforms" - сделать можно не медленнее, имея заметно больше опыта. У дельфи (был) уровень входа у плинтуса, а с шарпом я работал и простым назвать вообще не могу..
Конечно, у шарпа перспектив больше, включая кроссплатформенность.
Чем он сложнее? Для входа не обязательно сразу знать все фичи языка, формошлепство там точно такое же - рисуешь в редакторе форму дважды кликаешь на кнопку и пишешь обработчик. И что то начнет работать. А дальше stackoverflow driven development (инфы по шарпу и винформам там вангую побольше будет). Плюс куча готового кода в nuget вообще для любых хотелок, на дельфи придется велосипеды изобретать.
Короче то же самое все, только IDE продвинутые за вас половину багов найдут и код читаемее получается.
Как человек который делал проги на Делфи и сейчас делаю на c# (wpf), скажу что написать простую мелкую прогу, с нормальным интерфейсом, логикой, работой с БД на Делфи в разы быстрее, там формошлепство в разы удобнее (чем в Вин Форм) - одно привязка с вытягиванием по сторонам чего стоит, и в целом обработка событий интуитивней.
А уж WPF (особенно с MVVM) это вообще не про простоту и быстроту - это про ручную разметку, команду, ООП, патерны и прочее.
Естественно при большом опыте и набором готовых решений где угодно можно быстро что-то наклепать, но в делфи уровень требований к опыту в разы ниже. Очень жаль, что язык "умер".
Делфи кроссплатформенный
Если нужно быстро сделать пару формочек, связанных с каким-то железом (принтеры, сканеры штрих-кода, кассовые аппараты, дисковые массивы, разные мониторы, промышленные станки), то Delphi/Lazarus - неплохой выбор.
... а потом молиться, чтобы это не надо было развивать и поддерживать хотя бы лет 5...
...я недавно икнул, когда меня попросили обновить корпоративную софтину, а у неё дефолтный значёк от Delphi... но когда я в архиве нашёл исходники с таким же именем от 96-го года, я был реально озадачен... а рядом нашёл ещё более ранние исходники с похожим названием, на Pascal, под DOS. Так что кто-то вполне может "это" не только поддерживать хотя бы лет 5, но даже и портировать на "родственные" языки (правда, не завидую той команде, которая интерфейсы перерисовывала, даже если и TurboVision использовался - всё равно много править)...
Развивать и поддерживать софт нужно при любом языке программирования. А умение разбираться в старом коде (своём и чужом) - одно из обязательных умений хорошего программиста.
На c# + wpf/winforms можно сделать как минимум не медленнее
Ну как бы и да, и нет. Если речь идёт о создании чего-то простого, то без разницы. Если нужно приложение со сложным развитым GUI, библиотека Delphi намного богаче чем то, что доступно на WinForms или тем более мертворождённом WFP. Плюс, на Delphi приложение всё-таки будет нативным, без прослойки в виде дотнета. С другой стороны, на дотнете есть из коробки EF, и я не в курсе, есть ли сейчас что-то подобное в современной Delphi. Старые приблуды вроде Bold, это не то.
JIT-компиляция не считается. Проблемы с производительностью остаются всё те же, по крайней мере, для десктопных приложений, а не для серверных, которые раз "прогрелись" и после этого продолжают работать.
Поясните пожалуйста, о каких проблемах с производительностью идет речь? Какие то стереотипы времен .net framework 2.0
Я про банально отзывчивость UI приложения. Разница на не слишком шустрых машинах видна невооружённым взглядом, даже без тестов.
Разница между чем и чем конкретно?
Это ж какой археотех должен быть, чтоб на нем WPF'ный UI тормозил - не СУБД, не сетевка, не ФС - а вот прям сам UI? Причем если мы за сравнение с delphi - то это какое-то бизнес-приложение должно быть, а они свистопердельными анимациями, мягко говоря, не прегружены...
Пример можно?
Да без проблем. DataGrid на 100 столбцов и 5000 строк, находящийся в DataTemplate для TabControl-а.
При переключении вкладок можно отойти чай заварить. Несмотря на ухищрения с виртуализацией (которые, к слову, сводят с ума прокрутку)
"Локи, а НАХРЕНА?!" (Безотносительно "тормозит или нет" - у меня вот сейчас проверил - html'ка на 500к ячеек минуту грузилась) - зачем так делать? Что полезного можно получить с такого, гм, интерфейса? Оно ж даже на диспетчерскую видеостену - неадекватно будет...
А на экране одновременно сколько видно? Все 50 тыщ?
Ну так "во вьюшку" и в WPF можно кучу чего запихать. Проблемы начнутся только если это всё одновременно отрисовывать надо будет.
Проблема в дефолтном ВПФ гриде очевидно.
Переписывайте, штош
У меня, кстати, он из 32-бит процесса вылетал по памяти. Пляски с бубном вокруг виртуализации с этим помогли, но с торможением - нет. Надо его менять.
Искать-фильтровать — это одно, а показывать — совсем другое
Либо виртуализация настроена неправильно либо грид удаляется из дерева и пересоздается либо хз что еще, тут не к фреймворку вопросы а к тому кто код писал. Профилятор в помощь.
Да тормозит в сравнении, как ни печально. И WPF и драйверы к СУБД тоже (ODAC например).
Цена прогресса, чтобы археотех вытеснять.
Чтобы не жаловаться на криворуких, можно банально сравнить работу VS6.0 или Delphi c современной VS >2015
можно банально сравнить работу VS6.0 или Delphi c современной VS >2015
VS6.0 это уже просто блокнот по сравнению с 2022. VS Code и то функциональнее. К скорости работы непосредственно интерфейса обоих у меня претензий нет никаких. Проблема с VS в другом - там из за кривой архитектуры (тянущейся я так понимаю собственно с 6.0) очень много выполняется на UI-потоке того что по уму должно делаться в фоне. От этого и лаги все, и это было и до перехода интерфейса на WPF, на 700 проектах в солюшне любая VS умирает. В последних версиях вроде понемногу решают это, плюс процесс наконец то стал 64-битный.
Ну и VS 6.0 не на дельфи написана.
Лично у меня лагал VS 2021 на ввод символа до 0.7 секунд на i7-8750H (который так-то дум этернал в 120фпс может), на дефолтном шаблоне "Hello World" в консольном приложении.
При том, что "тормозной электрон" VSCode от тех же майков, проблемы инпут лага не имеет вовсе.
Мне кажется, что 64 бита позволят вижле и дальше просто обновляться, без перелопачивания, т.к. крашей на больших проектах не будет, а разработка то дорожает, нужно купить капутер помощней.
Хотели пруф - я предложил пруф.
Вопрос "зачем" немного в другой плоскости лежит.
Не совсем понятно пруфом чего именно это подразумевалось. 5000 строк одновременно ни на один экран не влезает, отображение длинных списков всегда эффективно решается виртуализацией, без нее тормозить будет независимо от того как и на чем вы делаете UI, а влезающее на экран количество строк отрисует без тормозов любой UI-фреймворк. Я лично с нуля делал древовидный грид на avalonia ui (не wpf но суть та же, и это .net), и ничего не тормозит ни на 5 строках ни на 5 тысячах ни на 5 миллионах, и с прокруткой порядок. Потому что на экране отображается от силы 100, а это не требует большого количества вычислительных ресурсов, элементы переиспользуются, а доступ к списку по индексу это операция O(1). С виртуализацией строк хоть 5 миллиардов может быть, лишь бы данные в память влезли.
Да в сообщении выше вопрос был:
Это ж какой археотех должен быть, чтоб на нем WPF'ный UI тормозил - не СУБД, не сетевка, не ФС - а вот прям сам UI?
Я привёл пример торможения.
Предлагаю не развивать эту тему вопросами целесообразности, она действительно невелика.
Я привёл пример торможения.
Так такое и на дельфи тромозить будет и на чистом С с ассемблерными вставками, если не предпринять меры оптимизации. Все же изначально речь шла про проблемы с производительностью в .net, но данная задача решается на .net без проблем с производительностью.
Прояснения позиции для - я не утверждаю, что "UI на .net не тормозит НИКОГДА" - у меня ощущение что в той области, где delphi является условным конкурентом C# (Корпоративная бизнесуха под Windows) разницы в производительности примерно "нет" - что конечно не исключает возможности написания тормозючего глюкалова вот прям на чем угодно.
Предполагаю, что там, где эта разница на самом деле критична - ни шарпу, ни delphi делать особо нечего, а в типовой gui'шной бизнесухе задержки возникают нихрена не из-за рантайма или там gc...
библиотека Delphi намного богаче чем то, что доступно
Если зацикливаться только на том что из коробки, то все равно упретесь в написание велосипедов. При этом сторонних библиотек для дотнета доступно куда больше.
мертворождённом WFP
Почему мертворожденном? На нем создано очень много приложений. Да и XAML весьма удобен если хочется сделать более менее продвинутые и архитектурно корректные вещи в UI, пытаясь делать которые что на винформах что на дельфи у вас будут в основном файлы по 3000 строк, велосипеды и говнокод.
Если нужно приложение со сложным развитым GUI, библиотека Delphi намного богаче чем то, что доступно на WinForms или тем более мертворождённом WFP
Под .Net в целом и WPF в частности сейчас столько опенсорса что ситуация скорее обратная.
Qt - современный Delphi
Только не в плане написания интерфейса, по сравнению с Delphi это просто кошмар.
А если к Delphi докупить DeveloperExpress - то до сих пор ничего радом стоящего нет ни у кого. Это просто совсем другой уровень возможностей и интерфейса.
Но да - за Qt в общем случае платить не надо. Ну пока не потребуется что-то хотя бы уровня вывода графиков.
Qt Designer имхо примерно столь же удобен сколь и визуальный редактор Delphi
К этому вопросов нет. И на этом всё заканчивается.
Но достаточно взглянуть на список компонентов даже тех, что идут в комплекте с Delphi чтобы понять насколько глубока пропасть между Qt и Delphi.
Если бы кто-то повторил компоненты даже из классической 7 версии - то тогда да, это был бы прорыв в Qt. Но пока Qt сделала платным даже простенький компонент для вывода графиков.
P.S. Под интерфейсом я имел в виду интерфейс приложения, а не среды разработки.
Мне кажется что рисование графиков это не очень распространенный use-case и для него (как и вообще для дата-аналитики) сегодня лучше подходит Python + PyQt чем плюсы или дельфи.
Ну вот я написал на Qt приложение для работы с железом.
Мне сразу потребовалась графика на OpenGL. В Qt в принципе не проблема. Хотя под Delhi можно найти готовые решения и пользоваться, а не вспоминать написание шейдеров даже для простейшего приложения.
И мне потребовался вывод графиков кучи параметров. И вот тут приехали, я попробовал их компонент, работает, неплохо, не TСhart конечно, но неплохо. Благо что распространять и продавать приложение не нужно.
А для чего ещё нужно desktop приложение ? :-)
А так я только за Qt. Потому что когда в железе все на Си или С++,
то писать интерфейс обмена предпочтительнее с приложением на том же С++.
Ну тут you got me :D я бы свой велосипед сделал для подобного графика, вряд ли там нужно что-то хитрое. Или взял бы одну из thirdparty если нужно было бы что-то более сложное.
В Qt с OpenGL намного проще чем в Delphi, а если не хочется возиться с шейдерами то есть QGraphicsScene и Qt3D.
Вот кто бы написал статью на хабре как правильно пользоваться QGraphicsScene и Qt3D :-)
А на велосипед не было времени, надо было быстро что-то работающее собрать. Просто странно что в той же Delphi это уже лет 20 как норма. А тут всё никак.
Да ладно? Проще? TViewport3D кидаешь из готовых компонентов. Появляется сцена. Дальше кидаешь 3д примитивы, модели, камеры, освещение, настраиваешь анимацию и все это в дизайнтайм. Нажимаешь запустить и оно работает вообще без единой строчки кода.
Кроссплатформенно, кстати.
Все это есть и в Qt3D. С целой Qt 3D Studio чтобы упростить эту работу. Естественно кроссплатформенно - я даже в виде веб-странички Qt приложение запускал. Но вообще говоря мое "проще" относилось конкретно к интеграции с OpenGL. Лично мне зачастую больше нравится работать на более низком уровне и контролировать что происходит напрямую чем пытаться настроить под себя стандартные примитивы.
Для Qt есть бесплатный QCustomPlot.
Да, вроде пробовал, но возможности сильно порезаны :-(
Из того что быстро гуглится есть еще JKQTPlotter и QWT. Последний вроде как специально для кейсов подобных описанному Вами предназначается
Еще Qwt
Lazarus кросплатформенный живее всех живых
Lazarus спасал в этом плане долгие годы. Но теперь FMX компилируется под линукс, по этому, можно писать прямо на Delphi.
Тут ключевой момент - в наличии людей, готовых это писать и потом сопровождать - а их на рынке примерно... нет. Т.е. вообще конечно есть - и даже пишут\сопровождают что-то - но вот "на рынке" нёма. Соответственно нет новых проектов -> нет джунов, которые будут на них набивать руку, нет... да ничего примерно нет - "отрицательная обратная связь".
А сам по себе delphi да, все еще если не "хорош", то вполне неплох для ряда применений даже адекватен... в отрыве от рыночной ситуации.
Вот выйду на пенсию, буду сопровождать проекты на Дельфи =)
Есть вероятность не дождаться :). Был у меня не так давно кейс с заменой внутрицеховой автоматизации на delphi на современную вебню - просто по тому, что главный автоматизатор на пенсию собрался.
Оно даже работало и работало адекватно, и под задачи модернизировалось - но влезать в legacy-проект с 10+ летней историей, связанный с непрерывным производством желающих не нашлось. Вот уже второй год в процессе замены, если я не ошибаюсь :).
Из моего опыта, проблема обычно в "цене". Нет проблем разобраться в легаси, если есть время, оплата и доступ. И с 20+ можно нормально работать и переносить.
Как говорил один из моих начальников - "Можно ракету в космос запустить! Да можно одним напильником! Да один человек справится! Если этот человек - не ты." :)
На определенном уровне примерно ВСЕ становится "вопросом цены", дело не в том, что "сопровождать это невозможно", а в том что бизнес заранее посчитал и решил что с т.з. "цены" дешевле будет периписать с нуля, чем тащить мертвую лошадь.
И про кроссплатформенность речь не идёт, как правило.
А сейчас и кроссплатформенность не вопрос. Современный Delphi поддерживает разработку под большое количество платформ, в том числе и мобильных.
Еще есть Lazarus со своим LCL (аналог vcl).
подтверждаю: два дня назад все-таки замахался делать работу ручками т.к. ее периодичность и объемность со временем тали лишь расти. За вечер на коленке на делфях собрал софтину, раздал причастным коллегам, показал куда нажимать.
И, все.
Теперь можно страдать над чем-то другим))
Да и с кроссплатформенностью не все так плохо. Есть FPC. Есть Lazarus - он прямо Delphi проекты понимает. Я видел проекты, которые им собираются под разные платформы.
Я согласен и с оценкой Delphi, и с тем что Pascal хоронить рано.
Мне пару месяцев назад была нужна специфичная софтина которая читает данные с последовательного порта и особым образом их визуализирует. Взял Lazarus под Ubuntu, скормил ему свои библиотеки рисования графиков, которые писал ещё будучи студентом под Delphi в далёких 97-98 годах (25!!!! лет назад), добавил простую логику обмена с последовательным портом, фигак фигак и заработало. Мало того, при желании можно скомпилировать и под Windows. Так что говорить и смерти Паскаля, imho, преждевременно.
Kylix (=Delphi for Linux) я увидел еще во времена, когда основным кроссплатформенным инструментом были Java и Perl
А сейчас есть как платное кроссплатформенное, так и вполне себе бесплатный Lazarus.
В плане производительности разницы практически нет.
Как по мне, единственная проблема Delphi - это ценовая политика Embarcadero. Что бы поставить его на предприятии, придётся отвалить немаленькую сумму за Delphi, DexExpress и ещё пачку полезных пакетов.
А вот кадры - вообще не проблема. Язык на столько прост, что можно спокойно сажать вчерашнего студента и он сможет писать достаточно сложный продукт почти с ходу.
а давайте вы теперь будете не с флешки запускать софтину, а из браузера вот отсюда?
Я встречал полноценное микросервисное веб приложение, написанное полностью на Delphi. И я даже не знаю, что меня пугало больше - само существование этого приложения или то, на сколько просто оно было написано.
Как по мне, единственная проблема Delphi
Вообще то нет.
На сегодняшний день безопасность языка Дельфи осталась на уровне С++93.
Весьма дисгармонирует с понижением средней квалификации корпоратив-кодера.
Безопасность в чем?
Безопасность в написании программ от непреднамеренных ошибок программирования. Прежде всего при работе с указателями, а также неинициализированные данные, выход за границы массивов итп .
Подробнее писал в статьях
Язык живет не только за счет энтузиастов. Язык развивают в Embarcadero. И довольно стремительно. За последние пару лет было очень много нововведений, из-за которых, можно написать код, который не будет работать в более ранних версиях. Проводятся вебинары (и на русском языке). Буквально на прошлой неделе был. Выпускаются книги и обновляются ресурсы для обучения.
Много было сделано для работы в кроссплатформе. Поддержка М2 и работа с новым API Win11 была добавлена даже раньше, чем в C# (по M2 не помню точно).
Так это не все изменения по кроссплатформе, а только демонстрирующие актуальность. Нововведения можно увидеть в бэклогах или в справке.
По всем старым версиям и слева по актуальной версии https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Help_of_Previous_Versions
А новая уже в Бете, но что там нового я не могу сказать из-за NDA
Нет, я вас тоже понимаю и в этом плане тоже не совсем согласен с политикой Эмбы. Сейчас очевидно мало публичных выступлений и рекламы. Но я также надеюсь, что это изменится в будущем. Сейчас, курс разработки на оптимизацию и улучшение инструментов. Так что здесь по факту мало что интересного рассказать можно. Правятся критичные для работоспособности баги, правится среда, догоняется упущенный прогресс и т.д. С каждой версией почти у нас теряется обратная совместимость. Старый код можно открыть в новой среде, а новый код в старой уже нет. На протяжении последних нескольких обновлениях именно так сейчас. И вот это меня очень радует, хоть и приводит к небольшим проблемам.
Под WIndows быстрее, чем на Delphi, не знаю на чём можно написать ПО для работы с специфическими данными заказчика под Windows XP/7/8/10/11
Несмотря на то, что Microsoft переманили Андерса Хейлсберга и так появился C#, в Dephi 20-летней давности форму приложения накидать удобнее, чем в сегодняшнем шарпе.
С ностальгией вспоминаю Дельфи, долгое время использовал его как основной язык программирования. Но на сегодняшний момент он безнадежно устарел. Насчет быстроты я с вами согласен. Можно быстро и качественно накидать простенькую утилитку на VCL. Язык вполне может и сейчас использоваться для небольших десктопных проектов с GUI. Но написать серьезное приложение на дельфи - это боль и страдание.
Конечно можно, но зачем? Ссылки, которые вы дали, опубликованы 15+ лет назад. Мотивацию можно легко проверить, открыв любой сайт с предложениями о работе. Все сразу станет ясно.
Вообще не понимаю, почему многие программисты так упорно цепляются за устаревшие технологии. Переход с дельфи на какой-нибудь .NET/C# для хорошего инженера вопрос нескольких месяцев. Изучение парочки нужных фрейморков полгода-год. Эти инвестиции с лихвой окупятся при первом же поиске работы.
P.S. Раньше думал, что оставлю дельфи написать что-то для души. Не вышло. Тот же питон оказался банально проще для написания консольных мелких утилит и различной автоматизации. Ну а C# с бесплатной VS на голову удобнее и стабильнее RAD Delphi студио. Единственное, что там осталось действительно на высоте - это быстрое создание GUI на VCL, особенно для работы с данными. Ах, компоненты DevExpress - любовь всей жизни :-)
Delphi так же как и VS имеет бесплатную редакцию IDE для работы.
Фреймворки для Делфи актуальные и современные. VCL - не является устаревшей технологией. Это всё ещё базовая технология создания нативных приложений в Windows (не факт что это не изменится, глядя на Win11 и WinUI).
Но помимо VCL есть фреймворк FMX, который не основывается и не привязан к VCL и позволяет создавать кроссплатформенный софт (с возможностью оставить нативный для платформы вид приложения).
Более того, есть несколько Web фреймворков, которые так же с конструктором позволяют создавать сайты или веб сервисы.
Устаревшие технологии это та версия Делфи, на которой вы с ним расстались. Только Делфи как и C# или Питон на месте не стоит.
Qt с Qt Creator тоже позволяет накидать формочку за несколько минут, а потом городить логику в onClick listener.
Ещё есть C# c WPF. Который наверное даже популярнее Qt под Windows.
энтузиасты продолжают на нем пилить всякие штуки
Например команда энтузиастов пишет на нем ZCAD (хабро-статья с упоминанием о нем, в YouTube)!
Так что не спешите Pascal хоронить)
Ещё есть популярная DAW Fl Studio от Image-Line.
Delphi — это не Pascal. И даже Object Pascal — не Pascal, просто Apple получили благословение Вирта на переименование своего Clascal.
А Pascal как язык для практического применения — мёртвый от рождения. Как сказал сам Вирт, “Главная проблема Pascal в том, что слишком многие восприняли его слишком серьёзно”. Это язык для обучения. А для работы Вирт сделал Modula (2).
Консольное приложение Дельфи - чистый Паскаль, и, поверьте, бодренько так используется, например, мной. Вот помру - станет мёртвый.
Если используете тип string (не строковые литералы), то уже не классический Паскаль, а расширения типа "Турбо Паскакаль от фирмы Борман"(Ц), а с некоторыми конструкциями - уже Object Pascal/Delphi (начиная версии с 7й язык тоже так назвали, чтобы всех запутать, OP остался во всяких FreePascal и VirtualPascal). Консоль - это окружение исполнения и интерфейс, ограничение на использование языковых возможностей в остальных аспектах не накладывается, консольные приложения вполне могут быть и сложными и очень даже привязанными к конкретному компилятору из-за особенностей реализации.
Быстрее.. в некоторых случаях на Перле быстрее сделать программу, чем запускать среду.
“Чистый Pascal” — это тот, который описан в документе ISO/IEC 7185:1990. Delphi не соответствует этому документу. И никогда не соответствовал. И дело не в том, что в Delphi есть значительно больше, а ровно наоборот — в Delphi нет того, что должно быть в реализации, чтобы называться “чистым Pascal”. Для успокоения всех ценителей могу лишь сообщить — я вообще не встречал ни одной реализации Pascal, которая соответствовала бы упомянутому документу. Таким образом, “чистый Pascal” — это несуществующий сферический конь в вакууме. Мёртвый от рождения язык.
Gnu Pascal соответствует и существует.
Возможно, и FreePascal в ISO режиме.
Modula
Сделал язык для работы, которым никто не пользуется?)
Идеи из Modula повлияли на развитие Pascal.
Россиянский GPS под названием ГЛОНАСС подойдёт как пример, что никто не пользуется? :)
Нет. Я пользуюсь.
А для науки и вовсе, чем больше навигационных сетей одновременно доступно - тем лучше.
А я что-то сказал против ГЛОНАСС? Ты не заметил, что речь идёт не о навигационной сети, а об использовании Modula-2, на котором ПО ГЛОНАСС и написано, которое я и привёл как опровержение мнению@Areso, что Modula-2 никто не использует?
Давай читать внимательно, осознавая прочитанное прежде чем писать комментарии в духе ущёмлённого патриотизма и размахивать минусодубинкой.
Извини, погорячился. Перечитай пожалуйста, свой предыдущий пост. Как его поймёт человек, который не в теме?
Окей, кто-то пользуется.
Но число видимых проектов не очень велико. Потому что работы для embedded C программистов я вижу много, а вот то, что где-то в дебрях Роскосмоса использовали Modula-2 для спутников ГЛОНАСС я не знал.
А Pascal как язык для практического применения — мёртвый от рождения. Как сказал сам Вирт, “Главная проблема Pascal в том, что слишком многие восприняли его слишком серьёзно”. Это язык для обучения.
Покажите где сказано, что Паскаль создавался для обучения. Откуда вы это вообще придумали? Паскаль использовался для обучения, а не создавался для него. Это совершенно разные вещи.
Всё равно что сказать, что компьютеры созданы для обучения, потому что их используют для обучения.
В конце концов есть SCL/ ST (IEC 61131-3), который живее всех живых и смерти его в обозримом будущем не предвидится.
Много ссылок на Фортран, а сам Фортран не перечислен в десятке. Хотя это источник императивного программирования, как такового.
Тут, действительно, много неясного с определением современного статуса языка. Я, например, никогда не слышал о Pharo, зато три разных обновлявшихся в текущем году компилятора PL/I знаю. Хотя не считаю PL/I особо актуальным языком (к сожалению).
На мой взгляд, современный язык должен иметь кросс-платформенный компилятор/интерпретатор. Вокруг него должны устраивать конференции или ещё какие-либо мероприятия. Ну и для позиционирования у него должен быть сайт в современном дизайне. Плюс удобный тулинг и поддержка со стороны IDE или LSP хотя бы.
Pharo этим критериям удовлетворяет, Delphi тем более, а вот по PL/I мне сходу ничего кроме пары сайтов аля "привет из 90-х" (
"Pharo is an open source, cross-platform implementation of the classic Smalltalk-80 programming language and runtime"
https://days.pharo.org/
https://newcomers.pharo.org/
Delphi удовлетворяет критерию кроссплатформенности???
Ну напишите на Delphi программу для macOS или на Pharo для z/OS.
На delphi можно писать для macos, это вполне официальная фича, насколько оно адекватно в итоге получится не в курсе, но точно знаю что отлаживать написанное через одно место придется потому что их ide есть только для windows (2023 год на дворе). В общем мне очень жаль тех кому приходится легаси на дельфи еще и под макось тащить.
Отлаживать очень просто. IDE запускается на компьютере с WIndows, приложение запускается на компе с MacOS. Далее IDE подключается к порту на Маке и приложение отлаживается через сеть.
Очень просто это я в IDE на маке пишу код, там же нажимаю F5 и программа просто запускается под дебаггером. Кунг-фу с двумя компьютерами или виртуалками это не "очень просто", это клоунада.
У вас весь код на одном компьютере, и вы можете с этого компьютера отладить этот код под Windows, Android, iOS, MacOS и Linux. Выглядит отнюдь не как клоунада.
Или лучше ставить 3 отдельных IDE под Windows, MacOS и Linux и копировать код на 3 компа? Это не клоунада?
Выглядит
Именно что только выглядит, на бумаге в маркетинговых методичках. Ровно до тех пор пока вы не попробуете. Потому что по факту с GUI приложением вам придется постоянно переключаться между двумя компами, потому что IDE на одном, а приложение на втором, да еще и в самой операционке что то постоянно потыкать надо - где то файлы почистить, где то настройки поменять, где то текст скопировать.
Или лучше ставить 3 отдельных IDE под Windows, MacOS и Linux и копировать код на 3 компа? Это не клоунада?
Представьте себе, даже на одном компе бывает несколько копий репозитория с разными бранчами.
Я и так постоянно переключаюсь между тремя экранами, которые подключены к двум компам. Вообще не проблема.
Переключаться на второй комп чтобы там например в фоне ютуб запустить и переключаться чтобы отлаживать приложение это заметно отличающиеся сценарии. Ну вот допустим понадобилось скопировать текст из отладчика в текстбокс отлаживамого приложения, ну или наоборот из приложения в отладчик чтобы условие для брейкпоинта назначить. Что вы будете делать? Набирать руками? Да что там текст, вы с двумя мышами предлагаете работать что ли? Могу поинтересоваться, насколько часто вы кроссплатформенные UI приложения через сеть отлаживаете вообще? Потому что мне сама фраза о том что надо использовать 2 компа там где можно использовать один кажется каким то архаичным пережитком.
Переключаться на второй комп чтобы там например в фоне ютуб запустить и переключаться чтобы отлаживать приложение это заметно отличающиеся сценарии
Отличия пренебрежимо малы.
Ну вот допустим понадобилось скопировать текст из отладчика в текстбокс отлаживамого приложения, ну или наоборот из приложения в отладчик чтобы условие для брейкпоинта назначить. Что вы будете делать?
Делал по-разному. Самое простое: сохранять в расшаренный текстовый файл.
Да что там текст, вы с двумя мышами предлагаете работать что ли?
На стационарном компе мышь, на ноутбуке тачпад.
Могу поинтересоваться, насколько часто вы кроссплатформенные UI приложения через сеть отлаживаете вообще?
Отлаживал с ноута приложение на компе где-то полгода назад.
Но я не профессиональный разработчик кроссплатформенных приложений.
Потому что мне сама фраза о том что надо использовать 2 компа там где можно использовать один кажется каким то архаичным пережитком
Но вы же была недовольны тем что у Delphi нет IDE под мак. Если поставить IDE на мак, надо будет как-то отлаживать версию приложения под Windows. По-любому нужен будет либл второй компьютер с Windows, либо хотя бы виртуалка.
Для кроссплатформенной разработки нужна хотя бы виртуалка с другой осью. Это никакой не "архаичный подход".
Я вообще не понимаю в чём проблема отладки через сеть и почему это кого-то напрягает.
Отличия пренебрежимо малы.
Ну как пренебрежимо когда количество попеременного ввода отличается на порядки.
Самое простое: сохранять в расшаренный текстовый файл.
Вместо двух нажатий: Ctrl+C и Ctrl+V
Если поставить IDE на мак, надо будет как-то отлаживать версию приложения под Windows
Ключевая разница в том что они не нужны одновременно. Если вам нужно починить баг на винде вы его чините на винде максимально удобно и комфортно, если на маке то соответственно там, никуда не переключаясь, не жонглируя двумя мышами, текстовыми файлами и сетевыми подключениями.
Я вообще не понимаю в чём проблема отладки через сеть и почему это кого-то напрягает.
Проблема вот в костылях вроде этого: "Самое простое: сохранять в расшаренный текстовый файл." Если раз в полгода то норм, а если каждый день то еще как будет напрягать.
Вот я постоянно пользуюсь двумя компами с одной мышкой и клавиатурой - спасибо Mouse Without Borders - помимо "общего пространства" для двух компов, позволяет использовать общий буфер обмена и перекидывать файлы до 100 Мб. Насколько знаю, есть свои аналоги и для не-винды. Два компа - потому что один корпоративный без всякого лишнего, а второй персональный на котором включаю ютуб или гуглю что-нибудь.
Представьте себе, даже на одном компе бывает несколько копий репозитория с разными бранчами.
А зачем это делать, если можно компилировать один и тот же код под разные платформы, выбирая нужную платформу при помощи комбобокса? Рекомендуемый подход именно такой.
А зачем это делать
Это безотносительно платформ. Например если идет параллельная работа над двумя фичами. В нескольких рабочих копиях никакого не удобства нет, наоборот это позволяет распараллелить работу ощутимо сократив время на переключение бранчей и перекомпиляцию.
Рекомендуемый подход именно такой.
Рекомендуемый кем?
Рекомендуемый кем?
Компанией Embarcadero, разработчиком Delphi.
Она продвигает идеологию что код, работающий под Винду, должен работать и на других системах.
Параллельной разработке это никак не препятствует.
Компанией Embarcadero, разработчиком Delphi.
Ну тоесть они даже свой продукт не осилили сделать кроссплатформенным, и учат других как надо это делать?
А они осилили сделать кроссплатформенным.
Для отладки приложений Delphi IDE подключается к приложению по TCP. Поэтому для Delphi нет разницы между отладкой приложения локально или удаленно. Всё и так работает, незачем что-то придумывать.
Кроссплатформенно - это когда IDE можно запустить на требуемой платформе и отлаживать программу локально на той же машине.
На андроиде например, да?
Для андроида везде эмуляторы используются, запускаются они автоматически и вы отлаживаете локально, вам не нужно 2 устройства и куда то там по сети коннектиться.
Если нет устройства на Маке, всегда можно отлаживать на виртуальной машине. И не будет проблем ни с "двумя мышками", ни с копированием.
Какой смысл обсуждать несущественную проблему?
Я в курсе. Но товарищ выше по треду хочет, чтобы и IDE запускалась на целевой платформе, без этого он разработку под неё кросплатформенной не признаёт :)
Для отладки приложений Delphi IDE подключается к приложению по TCP.
Поэтому для Delphi нет разницы между отладкой приложения локально или
удаленно. Всё и так работает, незачем что-то придумывать.
Для delphi может и нет, для разработчика - есть. Вы непонятно зачем защищаете какие то убогие костыли. А если я вообще только под macos хочу приложение написать, нафиг мне комп с виндой для этого?
А если я вообще только под macos хочу приложение написать, нафиг мне комп с виндой для этого?
Мне кажется, или ответ очевиден, что XCode/Swift ваши лучшие друзья в таком случае.
А если я вообще только под macos хочу приложение написать, нафиг мне комп с виндой для этого?
Запустите под Wine, в чём проблема...
Запустите под Wine, в чём проблема...
Костыль на костыле и костылем погоняет, особенно прекрасно это будет работать на arm64 процессоре. Вот потому этот язык и почти мертв.
Нет никаких костылей.
Я вам расскажу как делал сам (правда, не под Macos, а под Android).
Я написал приложение под WIndows, отладил его под Windows. Затем перекомпилировал под Android, перенёс приложение на смартфон и запустил там.
Отладкой под Android я вообще не занимался т.к. ошибок не было. Вся отладка шла под Windows. Это было легко и приятно.
Поэтому мне трудно понять, зачем мы вообще спорим и о каких "проблемах" разработки на Delphi вы рассказываете мне.
У меня на ноуте десктопное приложение на Delphi, на стационарном компе DLL-ки написанные на Delphi, которые коннектятся к приложению через сокеты по локальной сети, еще есть Android-приложение написанное на Delphi. Проблем с разработкой и отладкой не возникало. IDE и приложения очень экономичны в плане потребления памяти, всё компилируется быстро и легко.
Нет ни каких костылей. Много крупных сред имеют возможность только под одной платформой работать. Тот же VS.
Почти у каждого на маке стоит Parallels и никто не жалуется. Уставишь, запускаешь среду и можешь напрямую в Маке разрабатывать без всяких проблем.
Помимо этого, как уже сказали, софт под все платформы можно создавать и отлаживать под виндой (за исключением случаев прямой работы с платформой).
Вас вот смущает, что на Андроид нет IDE? Вроде нет. Все ставят её на комп и там пишут, а через WiFi отлаживают. Вот и RAD Studio всё это позволяет. Хоть в виртуалках ставь, хоть с реальным железом по сети работай. Разработка от этого не страдает.
Много крупных сред имеют возможность только под одной платформой работать. Тот же VS.
Поэтому в VS в основном только под винду и пишут. Для кроссплатформенной разработки есть и другие крупные среды, которые не имеют идиотского ограничения "комп с виндой".
Почти у каждого на маке стоит Parallels и никто не жалуется. Уставишь,
запускаешь среду и можешь напрямую в Маке разрабатывать без всяких
проблем.
Вместо теоретических рассуждений попробуйте сами так сделать, и посмотрите насколько комфортно вам будет работать в среде скомпилированной под x86/х64 в режиме эмуляции на arm64 процессоре.
Помимо этого, как уже сказали, софт под все платформы можно создавать и отлаживать под виндой
Запустите под виндой макос бинарники которые взаимодействуют с нативным апи, и расскажите что у вас получилось и насколько успешно удалось отладить код использующий эти функции.
Вас вот смущает, что на Андроид нет IDE? Вроде нет. Все ставят её на комп и там пишут, а через WiFi отлаживают.
Отлаживают локально через эмулятор андроида. Если вы ни разу не писали приложений под андроид, то хотя бы читайте внимательнее предыдущие сообщения.
Разработка от этого не страдает.
Ну а тем кому удобнее например в линуксе работать, вы что посоветуете? Опять колхоз с виртуалками? Серьезно? Нормальный человек просто другую IDE возьмет и начнет писать на немертвом языке, это куда более очевидное решение.
Колхоз - это когда для кроссплатформенной разработки тебе нужно на каждую платформу ставить и настраивать среду и проект.
Я сдаю кроссплатформенный софт на Делфи под все доступные платформы и не испытываю абсолютно никаких проблем.
Более того. Как раз для всех платформ кроме мака и иос на Винде есть удобные средства виртуализации. WSL и WSA. Это плюсом к без проблемной возможности подключить целевую платформу по сети из любого места.
Колхоз - это когда для кроссплатформенной разработки тебе нужно на каждую платформу ставить и настраивать среду и проект.
А если для кросс-платформенной разработки мне нужна только одна определенная ОС, причем не самая удобная, и никакая другая не подходит это не колхоз?
Я сдаю кроссплатформенный софт на Делфи под все доступные платформы и не испытываю абсолютно никаких проблем.
Ваш проект вероятно относительно прост и практически никак не взаимодействует с операционной системой.
Спорить об удобстве той или иной ОС - глупо. И я также не оспариваю тот факт, что кроссплатформенная IDE - это лучше, чем не кроссплатформенная. Однако, от того, что IDE нет под твою "любимую" ОС далеко не делает эту самую IDE и тем более язык и его инструменты плохими или ненужными.
У меня проекты есть как простые, так и использующие уникальные для конкретной ОС вещи. Например, под Андроид и иос совершенной иной подход к работе с файлами. При чем сильно отличающийся друг от друга. На мобильных ОС совершенно иначе работает ввод текста. Имеются активити "поделиться" и т.д.
Так что, даже самые простые проекты могут использовать платформозависимый код.
Только ни то ни другое мне не мешает создавать как сложные так и простые проекты. От 3д приложений, до простого клиента ChatGPT.
Вы можете без проблем посетить мой гит и посмотреть на некоторые открытые кроссплатформенные проекты на делфи
https://github.com/HemulGM
ставить и настраивать среду
IDE здорового человека умеют синхронизацию настроек
Вы можете без проблем посетить мой гит
Могу, но зачем?
не делает эту самую IDE и тем более язык и его инструменты плохими или ненужными.
Если есть средства позволяющие все то же самое, только без указанных недостатков, то вполне делает. Что собственно и наблюдаем в статистике популярности языков и ide
Так что, даже самые простые проекты могут использовать платформозависимый код
Который вы предлагаете отлаживать с костылями или вообще отправляете как есть?
Спасибо за минус, я его вам обязательно верну.
Нет ни каких костылей. Много крупных сред имеют возможность только под одной платформой работать. Тот же VS.
VS официальные билды для винды, линукса и макоси.
Вы как-то странно себе кроссплатформенную разработку представляете. По-вашему, на Java или Go каком-нибудь тоже надо 3 разных компа, чтобы скомпилировать программу под разные операционки?
Есть такая штука как кросс-компиляция, благодаря которой вы просто компилируете программу под разные ОС, независимо от ОС разработчика. А что-то там супер-пупер платформоспецифичное отлаживать нужно крайне-крайне редко. Это явно не часть повседневной работы.
кросскомпиляция и кросс-ИДЕ разные вещи
А что-то там супер-пупер платформоспецифичное отлаживать нужно крайне-крайне редко. Это явно не часть повседневной работы.
Кроссплатформенную разработку я себе представляю именно так как она есть, потому что я ей и занимаюсь. Супер-пупер платформоспецифичные задачи каждую неделю есть.
Вон под .NET так же пишут все спокойно в Visual Studio под виндой, а запускают хоть на линуксе, хоть на макоси
Вашими бы устами да мед пить. Хотел бы я посмотреть как эти люди будут писать, ну например код для извлечения иконок для типов файлов, в Visual Studio под виндой чтобы запустить на макоси.
Согласен. Если по расширению файла надо иконку найти, то это вообще от ОС не зависит. Но, честно говоря, непонятно для какой десктопной приложухи это вообще надо. Разве что для альтернативного файлового менеджера или FTP-клиента. А так большинство приложух просто системный диалог для выбора файлов используют.
Я так понимаю человек хочет чтобы в его приложении автоматом использовались системные иконки для типов файлов. Причём "динамические".
Ну то есть грубо говоря вот вы привязали pdf'ки к условному Foxit и у всех pdf'ок поменялись иконки. И теперь нужно чтобы если приложение запускается на вашем компе, то в нём у pdf'ок были такие же иконки от Foxit .
Так нормально?
https://github.com/HemulGM/ChatGPT
Как насчёт xBase?
BASIC жив и, наверное, это самый распространённый язык на компьютерах, ведь он есть во всех версиях Windows в виде VBS-скриптов, и во всех офисных пакетах в виде VBA, причём, как справедливо указано, не только от Microsoft. Не говоря уже о том, что Microsoft охотно лицензировала VBA в любые другие программы, например, он присутствует во многих SCADA-системах, и только в последнее время C# стал альтернативой в этой области.
вот поддержу. Чем больше я имею дело с офисной автоматизацией, тем более убеждаюсь, что VBA практически невозможно убить. Разработка паршивого макроса для компании сторонним подрядчиком - это дело весьма дорогое в принципе, а чем менее распространенный язык (я говорю про кадавров мойофис, р7) и чем меньше информации и специалистов по разработке в нем, тем дороже. Когда один подрядчик за макрос на JS ( который я впоследствии написал за неделю, и то это вышло долго потому, что в JS на тот момент ни в зуб ногой, и долго изгалялся над весьма банальными вещами) насчитал сумму с большими нулями, я понял, что так они мелкософты не обскачут.... С такими расценками на весьма банальные вещи компании, которая ценит деньги, гораздо проще и дешевле держать если не купленные в обход, то даже ломанные офисы (и даже самостоятельно их ломать). Есть разница, когда у тебя сами сотрудники пишут макросы по своему разумению в процессе работы или ты за каждую строчку отслюниваешь и еще надо держать человека, который бы управлял этими проектами. Потому низкий порог входа, распространенность и массовость для VBA - это огромнейшее конкурентное преимущество мелкософтов, и если они кинутся от него резко отказываться, то реально выстрелят себе в ногу, и эта рана будет заживать лет 5-10.
Я на днях открыл хедхантер и написал резюме на VBA-разработчика (верней, это было старое резюме, просто обновил информацию за последние 2-3 года и оставил висеть). Блин, сегодня залез по совсем другом поводу, и вижу - его смотрят, однако, даже при том, что в статусе написано, что уже работаю, и зарплату поставил повыше рынка.
Только этот BASIC, который VB/VBA, никакого отношения к тому BASIC, что в статье (Dartmuth BASIC) не имеет. На слове BASIC в названии всё сходство и заканчивается.
Синтаксис похожий, ключевые слова идентичны... 🤔 Кстати, автор статьи с вами не согласен, он считает, что Visual Basic является продолжением Basic-ов из 80-х годов (на самом деле их десятки разных), и "проиграл JavaScript" , что очень странно, т.к. они из очень разных "весовых категорий" (VB вообще компилируемый).
проиграл JavaScript", что очень странно, т.к. они из очень разных "весовых категорий" (VB вообще компилируемый).
В 20xx годах во времена Internet Explorer 6 браузер поддерживал JavaScript и VBScript. VBScript предполагался основным языком для работы со встраиваемыми в странички ActiveX компонентами. В своё время шёл наравне с JS, а поддерживался вплоть до августа 2019. До появления Powershell тот же VBScript был основным языком управления Windows для сценариев где не справлялись простые BAT-файлы. Один язык для операционной системы, управленя Outlook-ом и для анимации в загружаемых из сети страничках — рай для архитекторов, ад для безопасников.
<html>
<body>
<script type="text/vbscript">
document.write("Hello Habr")
</script>
</body>
</html>Ну, сходств в синтаксисе и ключевых словах у императивных языков — хоть отбавляй. Только это же не повод говорить, что Go — это C, хотя там даже в создателях есть не то, что сходства, а прямые совпадения :)
Бейсики из 80-х — всякие там Quick, Turbo — соотносятся с Dartmuth BASIC точно так же, как и VB/VBA: есть слово BASIC в названии, есть одинаковые ключевые слова. И всё. В том BASIC, который умер (и про который ещё Дейкстра писал “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration”):
Обязательная сквозная нумерация строк, номера заодно служат и метками;
Однобуквенные идентификаторы;
Полное отсутствие даже жалкого подобия на модульность;
Одна глобальная область видимости;
Жалкое подобие функций (в одну строку максимум);
Недоподпрограмы без аргументов, GOSUB/RET — это завуалированные GOTO;
Много тут сходства с VB? let,if и print — они и в Rust let,if и print, но Rust что-то никто не торопится называть BASIC'ом :)
"Живость" языка определяется в бОльшей степени тем, сколько на нем начинают новых проектов, а не сколько копий интерпретатора установлено.
Это противоречит всей сути понятия «значимость в истории».
Как давно вы перестали пить коньяк по утрам?
К.м.к, Pascal пал жертвой как собственного мифа, так и низкого порога вхождения. Когда в индустрию ринулись тысячи мартышек, умеющих только набрасывать кнопочки на формы, виноватым в этом почему-то сделали доступный язык и средства разработки на нём.
А сегодня даже среди тех, кто знает, что такое Delphi, мало кто слышал о FreePascal и его возможностях. А те, кто не знает, судят о нём по TP7 для DOS.
Да тупо набрасывать формочки не один только Pascal позволял. Как минимум ещё C#. Он, как по мне, даже проще Pascal'я
> Pascal пал жертвой как собственного мифа
какого именно? скорее C++ его вытеснил, хотя и не сразу
C# появился гораздо позже, более того, в разработке C# участвовал напрямую разработчик Delphi переманенный компанией MS.
И нет, в "набрасывании формочек" Delphi до сих пор лучше и быстрее. А язык ничем не сложнее. Скорее наоборот
Pascal/Delphi стали жертвами MFC. Поскольку это был оригинальный Микрософтовский продукт, все были уверены, что для работы с Windows он надёжней. А он был на С++.
Паскаль было сложнее интегрировать с любыми конструкциями не входящими изначально в язык, код написанный на C/C++ легче интегрировался с операционкой и библиотеками тоже написанными на C/C++
Зато в Delphi в отличии от C/C++ для статичской линковки сторонней DLL не нужно генерить lib файл библиотеки . Хватает описания экспорта.
То, что вы описываете это динамическая линковка.
Статической линковки внешних библиотек, не написанных на самой Delphi, в ней нет вообще.
В Delphi есть статическая линковка внешних библиотек (в т.ч. написанных на других языках), она делается через .rc-файл (где перечисляются линкуемые ресурсы: dll, jpeg, wav и т.д.). Таким образом DLL-ки включаются в исполняемый файл.
Нет, и это тоже не статическая линковка, а просто подключение бинарных ресурсов. Так, конечно, можно делать, но этому сопутствует геморой по извлечению библиотеки как ресурса в файл с последующей подгрузкой его через LoadLibrary() и так далее.
Настоящая статическая линковка это когда линкер подключает объектный код нужной библиотеки (не машинный исполняемый) из специального библиотечного файла (не dll/exe/so) и это делается перед тем как начать генерацию машинного кода в бинарнике. Таким образом и имена импортируемых функций можно срезолвить для использования прямо в загруженном образе бинарника, и при этом не заниматься подгрузкой внешних файлов. Много чего в embedded так делается по понятным причинам.
Вы бы это, извините на добром слове, матчасть подтянули, а?
https://www.baeldung.com/cs/static-dynamic-linking-differences
На самом деле ограниченный механизм статического связывания имеется.
Нужно в коде использовать директиву
{$LINK filename}
Но, если я правильно помню, есть проблема, заключающаяся в том, что использовать можно только файлы obj, а не lib. Впрочем, проблема решалась пронрамкой, превращающей lib в один или несколько obj.
Также раньше была проблема использования Борландом другого формата obj файлов. И была програмка, эти форматы преобразующая. Сейчас вроде obj от того же MSVC вполне можно использовать без преобразования.
И еще момент. Иногда под статическим связыванием понимают не связывание при компиляции с объектным файлом, а подключение функций dll при старте программы.
В смысле динамическое связывание - это LoadLibrary/dlopen + GetProcAddress/dlsym. Т.е. явно прописано подключение в ходе выполнения программы. Соответственно, функции доступны только с момента подключения.
А статическое - это либо так называемой библиотекой импорта, либо специальными объяалениями. В том же delphi это в объявлении функции external 'dllname' name 'procname' (или index n). Тогда связывание будет осуществлено в процессе инициализации до выполнения любого кода программы (в том числе из различных секций инициализации).
Вы несёте какую-то ересь :(
Динамическое связывание называется динамическим потому, что оно использует динамически подгружаемые библиотеки -- то есть те, которые загрузчик ОС нашёл в PATH и\или текущем каталоге.
Если же он ничего не подгружает и код библиотеки присутствует прямо в образе -- статичен -- то такая ситуация называется статическим связыванием.
А LoadLibrary/GetProcAddress это вообще не связывание, так как выполнение кода до этого места может и не дойти, что не имеет значение при классических связываниях.
Есть динамическая загрузка dll и статическая. Наверно, он об этом
Более, того, есть статическая отложенная
Вы несёте какую-то ересь :(
Я не берусь судить, насколько правильно использовать термин "статическое связывание" применительно к динамически загружаемым библиотекам (просто не интересовался этим вопросом), но то, что достаточно много людей его употребляют именно в таком контексте - это сложившийся факт. Если что, я сам в таком контексте данный термин не использую, дабы не путаться.
Вы бы это, извините на добром слове, матчасть подтянули, а?
Библиотека извлекается в память.
Командой
bcc32c -c filename.c -o filename.objгенерируете объектный файл и затем подключаете его директивой
{$L 'filename.obj'}Вот теперь правильно.
То есть было неправильно говорить что статическая линковка невозможна?
А это - статическая линковка?
function DllGetDataSnapClassObject(const [REF] CLSID, [REF] IID: TGUID; var Obj): HResult; cdecl; external 'libmidas.a' dependency 'stdc++';Статическая линковка в Delphi нужна только чтобы импортировать объекты из сторонних библиотек, если у них нет COM-интерфейса. Но для этого проще написать "обертку" в C++, это тупая механическая работа. То есть нет смысла со всем этим заморачиваться.
Питон проще дельфи/паскаля, на нем сейчас начинают детей учить основам программирования. И на сегодняшний момент это один из самых популярных языков программирования в мире ;-)
Пусть ребенок попробует без бутылки разобраться что это за неведомое нечто и почему оно такое жуткое:
class Person:
def __init__(self, name, age):
self.name = name
self.age = agetxt = "Hello World"[::-1]x = lambda a: a + 10Да вроде тут всё весьма понятно. Есть мутные места в Питоне, но не это.
ООП само по себе многословно и содержит много лишнего, но это сейчас модная парадигма. А второй и третий примеры прямо-таки лаконичны и классичны.
Скорее в Паскале могло бы вызвать удивление, почему объявление функции отличается от присваивания. Ну дети так глубоко не задумываются, конечно, но тем не менее.
А второй и третий примеры прямо-таки лаконичны и классичны
Абсолютно контринтуитивно, нелогично и не так как на других языках.
Лучше уж учиться программированию на javascript чем на питоне.
Первое – абсолютная калька с Фортрана, второе – приблизительная калька с Лиспа. Два каноничных языка-прародителя. Мне лично оба примера кажутся вполне интуитивно понятными. Не всё ж в Cи-стиле барахтаться.
Детям не всё равно, с какого языка это калька?
Никакая интуиция не поможет понять смысл этих примеров.
Чего не понять-то? Первое - перебор массива в обратном (отрицательном) порядке, второе - присваивание. Присваивается лямбда-выражение, то есть тело функции. Надо объяснить детям, что лямбда - это формализм для функциональной записи, но это и так культурному человеку необходимо знать.
Уж проще понять, чем отличие трёх видов скобок.
а давайте что б детям еще веселее было, заставим их в блокноте без подсветки синтаксиса все смотреть. а в качестве первого урока сразу ооп пойдет и через неделю что б обязательно продакшн код компилили. раньше же вот когда паскаль был, то все дети обязательно вставки на асме учили. чем ж питон хуже, давайте и в нем найдем дикую дичь - пусть мучаются! На питоне ж без лямбы писать невозможно. и тем более без ооп....
Популярен он потому, что на нём можно быстро что-то запрототипировать. И то что он интерпретируемый, делает ему определённую нишу в скриптинге. Но за пределами этого, где ведётся разработка чего-то толстого и сложного -- уже всё, это не для питона.
И ещё мне сложно назвать более простым язык, у которого отступы имеют синтаксическое значение.
Это расхожая фраза - реклама Питона из любого холодильника делает своё дело.
Питон не проще. Некоторые программы на Питоне - тупо длиннее программ на Паскале по количеству символов.
Но это действительно - самый популярный язык программирования.
Питон, конечно, сложнее Паскаля, потому что семантика языка гораздо более объёмная. Но простые программы на Питоне писать проще. И нужно ли неспециалистов обучать статической типизации - большой вопрос.
А так вообще лучше Лого (и Скретча для самых маленьких) для обучения детей ничего не придумали. Это бестиповые языки.
А, вроде, Лого миры даже где то изучают как начальный базис для формирования алгоритмического мышления и есть какие то игры с элементами программирования на нём или с ним.
Ну, трудно спорить тут в комментариях. Ни с одним из ваших предложений в первом абзаце не согласен. У PascalABC.NET скажем семантика также огромная - не знаю, как количественно сравнивать семантику. Про статическую типизацию спорить не буду - это холивар. Инвертирую вопрос - нужно ли неспециалистов обучать динамической типизации. И потом неспециалисты - они же вырастут и станут специалистами )
Современные школьники сейчас сильно продвинулись. Лого практически не используется. А Scratch - это не текстовое программирование - мы его тут как будто не обсуждаем. Но дело хорошее.
По поводу того - проще ли на Питоне писать простые программы - я несколько раз публиковал эту табличку - опубликую и здесь в качестве ответа
Я думаю, что начинающим вообще незачем акцентировать внимание, что данные в компьютере имеют какое-то специфическое типизированное представление. Это просто, так сказать, аппаратный хак, низачем не нужный для изучения принципов программирования на языке высокого уровня.
Что касается вашей таблички, то питоновский код у вас - это просто буквальный перевод паскалевской семантики в питоновский синтаксис. Питоновский программист так писать не будет. Зачем, например, вы типизируете значения или задаёте определённый размер массивам. Это не нужно.
Некоторые примеры просто неверны, например, вместо матрицы на питоне построен кортеж с её элементами. Но в питоне есть мощнейший матричный пакет, ничего подобного которому нет для паскаля. Хотя это тема вообще не для школьников.
Если вы в паскале изображаете подобие лямбды, то в питоне можете написать настоящую лямбду:
Add = lambda a,b: a+bМассив 1..9 не нужно создавать в питоне, можно обойтись генератором. С такой же лёгкостью создав бесконечный генератор, чего с паскалевским массивом вы сделать не сможете, так как бесконечный массив описать невозможно.
Ну и т.д.
Если вы пойдёте в обратном направлении и заведёте, например, список, в котором часть элементов является числами, а часть строками, причём числа для интереса не будут ограничены машинной разрядностью, то вам на паскале придётся уже поизвращаться. А зачем нужен такой список, спросите вы? Например, просуммировать свои записи о расходах. Там может быть в блокнотике записано число, а может быть какой-нибудь комментарий. Вы же понимаете, что на массив int'ов мы в реальной жизни рассчитывать не можем.
Не буду спорить в деталях. Мы погружаемся в сравнение языков программирования, причем, не для начинающих.
Питон - хороший язык программирования. Я лишь реагировал на вашу фразу, что Питон проще. Не проще. В силу динамической природы на нем можно сделать вещи, которые нельзя сделать просто на статически типизированном языке. Ну там полиморфный список создать или матрицу. Иногда это выигрышно для начинающих. И мыслить надо по-другому. Оборотная сторона - ошибки на этапе выполнения - Питон перечеркивает многое, для чего создавались компиляторы. Ну - такая идеология. Хороший преподаватель эти ошибки будет сглаживать. Но школьники всё равно пишут код с массой ошибок, не все из которых проявляются даже на этапе выполнения.
Полностью согласен, что начинающим на начальном этапе незачем акцентировать, как там всё устроено в компьютере. На статически типизированных всё равно возникает своя культура - целые это целые, и вещественное туда не присвоишь.
Про пакеты не буду спорить - пакеты - сильная сторона Питона - фактически на каждую задачу есть пакет.
Несколько замечаний по вашим замечаниям :)
Вроде у меня в коде список списков. Нету там кортежей. И этот код часто пишут школьники для ЕГЭ и родственных задач - так что в табличку он попал из за этого.
Не очень понимаю, почему в Питоне настоящие лямбды, а в Паскале - нет. Вот ваша лямбда тут: (a,b) -> a + b. Самая настоящая. И - проще. И используются лямбды в Паскале чаще - они имеют более краткий синтаксис. Собственно, это придумка технологии LINQ - вместе с цепочками методов - на Питоне цепочки методов можно встретить редко.
Arr(1..9) - это как раз функция - генератор массива. Диапазон (1..9) выступает в качестве генератора последовательности - это как раз то, что в Питоне достигается синтаксисом, аналогичным списковому включению. Если мы говорим не о массивах, а о генераторах последовательностей, то в Паскале также есть генераторы бесконечных последовательностей. Они делаются либо с помощью оператора yield как в C#, либо с помощью встроенных стандартных функций. Ну например, бесконечный натуральный ряд:
1.Step.Print;Ну и т.д.
Все современные языки это обеспечивают.
Еще раз - я только реагировал на фразу, что Питон проще :)
Но в питоне есть мощнейший матричный пакет, ничего подобного которому нет для паскаля
Это не так. System.Math.Vectors - вектора, матрицы, кватернионы. Всё в основном для работы с графикой
Вот общая библиотека https://github.com/mikerabat/mrmath
Массив 1..9 не нужно создавать в питоне, можно обойтись генератором
Кто мешает использовать генераторы в Паскале?
for var i in range(1, 21, 1,
function(n: Integer): Boolean
begin
Result := n mod 2 = 0;
end)
do
WriteLn('enum = ', i);
WriteLn;
for var i in range(-2, 6, 2) do
WriteLn('enum = ', i);
WriteLn;
for var i in rangeRandom(0, 1000, 10) do
WriteLn('enum = ', i);Вот пример с генераторами (именно генераторами, а не создание массива)
заведёте, например, список, в котором часть элементов является числами, а часть строками
Во-первых есть тип Variant, который позволяет хранить данные любого типа.
var Arr: TArray<Variant> := [1, 2, '2', 434, 2.3, 'fsdsdf'];Во вторых, в для Паскаля тоже есть тип BigNumbers
В-третьих, ...
А зачем нужен такой список, спросите вы? Например, просуммировать свои записи о расходах. Там может быть в блокнотике записано число, а может быть какой-нибудь комментарий. Вы же понимаете, что на массив int'ов мы в реальной жизни рассчитывать не можем.
... это глупо. Любой здравомыслящий будет помещать в массив именно числа при парсинге "блокнотика".
Посмотрите на питоновский пакет NumPy. Который является частью стандартной библиотеки. Это очень серьёзная вещь.
Про генераторы - интересно, не был в курсе этого достижения.
Любой класс, в котором есть есть метод GetEnumerator может стать генератором и использоваться напрямую в циклах или где угодно где нужно генератор.
NumPy - библиотека серьезная, но всё в ней - это простая математика, которая есть в Паскале вообще на уровне компилятора. Остальное в RTL, а чего не хватает в сторонних библиотеках. При чем нативно, а не через NumPy, которая на самом деле библиотека на С.
Basic в недрах https://en.wikipedia.org/wiki/Dartmouth_Time_Sharing_System это само совершенство. Это совсем не интерпретатор! Это по сути многопользовательская IDE работающая на одной машине для сопровождения исходного кода и передающая его на компиляцию и выполнение на другую более мощную. Всё это ещё и территориально могло быть разнесено на приличное расстояние.
ИМХО появление персонального компьютера вызвало откат технологий в программировании на четверть века. Я уже не раз тут писал, что при появлении "новых" статей на тему асинхронности и многозадачности часто с улыбкой вспоминаю, как меня "фигурально" били в курилке за асинхронную и многозадачную работу с двумя лентами на ЕС-1045 в разгар рабочего дня. Я тем самым наглым поведением забирал себе столько ресурсов сколько мог. И было это в середине 80хх и использовался ПЛ/1.
> ИМХО появление персонального компьютера вызвало откат технологий в программировании на четверть века.
скорее freeze, но т.к. масса мало грамотных людей начала программировать, средний уровень качества конечно понизился, также DTSS вполне заслуживает отдельной статьи
Причина не в появлении ПК.
Причина в том, что нужен программист, который (1) не занимает отдельной ставки, (2) не требует отдельной зарплаты, (3) работает очень быстро, (4) решает конкретные разовые задачи.
А программист, который сидит на отдельной ставке и медленно, разумно работает, чтобы решать задачи в общем случае — это будет слишком дорого. Для него же ещё и компьютер покупать надо.
В этом году языку COBOL исполнилось 64 года, и он остаётся одним из старейших из активно применяемых языков программирования, а также одним из лидеров по объёму написанного кода.
Кто и как оценивал объёмы написанного кода? Так то на Fortran тоже дофига чего написано, плюс он ещё и старше.
Так пишет IBM, которая сама и похоронила COBOL, заперев компилятор в мейнфреймах. Статистически объем кода может быть огромным, если умножить число старых банкоматов на число строк кода их приложений. Добавлю, что OpenMainframe Project, начатый с пандемией, закончился каталогом в пару тысяч невостребованных вакансий. Open не совместима с жадностью.
Кстати, COBOL реализует десятичную математику и декларативную валидацию полей записи из коробки. Это все его киллер-фичи. Развитие компиляторов остановилось лет 30 назад. Самая популярная спека - COBOL85.
Где он, этот кобол? Кто на нём что пишет? Где этот объём написанного кода? На оставшихся музейных экспонатах, которые ещё не успели списать? Учитывая количество питонистов сегодня и число коболистов в период расцвета Кобола, думаю, сейчас за месяц на питоне пишется больше, чем всё, что написано на Коболе.
Это не подколка, мне правда любопытно. За 30 лет своей карьеры в ИТ я никакого кобола на горизонте не видел, но периодически слышу, что Кобол невероятно востребован.
Видите ли, я работал и работаю в крупнейших мировых компаниях из Fortune 500, в штатовских в том числе. Мало того, я даже в IBM работал. Которая этот самый Кобол на этих самых мейнфреймах вроде как продаёт. Так что встретить его я бы теоретически мог. Но не встретил. Я, конечно, знаю, что Кобол в природе есть. Но говорить о том, что он какой-то лидер - это из области городских легенд.
Вроде пытались применять.
Во всяком случае есть книжка "КОБОЛ ЭВМ Минск-32", однако встретить (или вспомнить) Минск-32 сложнее, вероятно, чем Кобол где-то ещё.
В мире мейнфремов он цветёт и пахнет.
Просто это отдельный, довольно изолированный мир. То, что Вы его не видите - это как то, что я никогда не видел живого мангуста, живого бурундука.
В мире мейнфреймов. Это сразу ограничивает ареал этого кобола до очень узкой области. Сколько программистов что-то пишут на мейнфреймах по сравнению со всей остальной массой программистов? Это не мир, а мирок. Кто его изучает? Где? Когда выходили последние обновления? Сколько сейчас в природе коболистов? Судя по всему, это ничтожная доля.
То есть вы хотите сказать, что коболисты по сравнению с остальными программистами это как Рокфеллеры по сравнению с какими-то туземцами. Ну так, не буду комментировать.
Я бы скорее привёл аналогию с гужевым транспортом. Он ведь тоже не исчез в мире. И даже в развитых странах всё ещё имеет свою нишу. И те кто с ним связан вполне себе зарабатывают неплохие деньги.
Мейнфрем это нечто такое, с чем если связались, то очень трудно потом от него избавиться. Да и не хотят особо, потому что есть вещи, для которых лучше него ничего до сих пор не придумали, при сопоставимой стоимости. Сколько лет ему скорую смерть предрекают, а он живёт назло врагам.
И, кстати, у меня есть несколько знакомых, которые работают на Cobole. Может, мне просто повезло. И они говорят, что Cobol, при всех своих недостатках, очень хорош для той специфической области, в которой он используется.
Вы не понимаете (с). Мейнфреймы это специальный вендурлокнутый мирок от IBM. Он такой не потому, что они тупые. Ребята почти полвека тому назад придумали бизнес, где можно десятками лет сидеть на контрактах по всей вертикали: начиная с железа и обучения специалистов, до рынка инструментов разработки, софта и консалтинга - с которых невозможно слезть. Что-то похожее сотворила Apple со своими iPhone для масмаркета - специфичным железом, языками, инструментами, системой распространения программ и оплаты, и т.п. - но у этих хотя бы не нужно проходить дорогущие обучения и сертификции, где специалистов готовят почти как космонавтов.
Сразу после распада СССР я работал во внешнеторговой организации, где половина автоматизации делалась на Коболе для совместимости с зарубежными системами.
Я там работал в другой половине автоматизации (MS-DOS, Паскаль+SQL) и особенно в коболовский вопрос не погружался, но у меня осталось впечатление, что они при этом писали на немецком диалекте Кобола, так как машины у них были немецкие. По тем временам многие из старшего поколения изучали немецкий язык в школе, и это выглядело не так чудовищно, как звучит сейчас.
Хотелось бы больше деталей. Или там NDA?
Именно. Восстановление утраченной бизнес логики - это то, что сейчас актуально на рынке труда для тех стека. Джуны и амбассадоры не нужны, проверено на 20 компаниях.
Концептуально COBOL это что-то среднее между языком в 1С, Gherkin из мира TDD и shell скриптами.
COBOL разрабатывали как язык-клей для бизнес применений, поэтому программа больше напоминает литературный английский, нежели лаконичную математику как в хаскелях. Отсюда многословность и безумное количество длиннющих ключевых слов. Например наряду с "x > y" можно писать "x IS GREATER THAN y". Но зато если придерживаться определенной дисциплины, то можно писать код, который будет понятен не только программистам, но и тем кто хорошо разбирается в бизнесе домене. Это актуально например для банковской сферы, где сложность идёт не столько из алгоритмов, сколько из законодательства и специфики предметной области. Из плюшек - поддержка SQL (как first-class citizen), работы со структурированными данными, вызовы нативного кода и т.п.
Поэтому идея переписывания на хаскель выглядит неожиданной. Ну может быть там была какая-то специфика и на коболе накодили что-то из теорката.
Нет никаких проблем с тем, чтобы писать хоть даже микросервисы по перекладыванию жсонов на хаскеле
Проблема не в этом. Мейнфрейм это по сути общая унифицированная среда исполнения, где вместе крутятся и программы, и базы данных, и все остальное. Смотрите, когда программа на коболе говорит: дорогой DB2, дай мне данных из той вон таблицы, то в ответ получает практически кусок адресного пространства, где эти самые данные лежат. Все происходит за микросекунды, не зависимо от объема. Представляете? Вот это 1С-подобное поделие, может ворочать террабайтами данных, и тысячами транзакций, вообще не напрягаясь. Все потому, что ему не нужно приседаний с сервисами, микросервисами, сетями, энкрипшеном, драйверами, файлами и файловыми системами, сокетами, джейсонами, приведением типов, маппингом данных, конфигурациями и тому подобной ерундой. Все же находится локально, в одном понятном физическом месте, всегда доступно, везде однотипно, унифицировано и сертифицировано.
Попытки переписать с кобола, на языки общего назначения, а особенно те, которые всю историю развивались на писишках с абсолютно другими вводными и ограничениями, сразу упираются в то, что размер и сложность кода растут на порядки. Хаскель или джава - принципиальной роли не играет. Переписывать приходится не только инфраструктурный код, но и логику приложений, поскольку ограниченность ресурсов и распределенность принципиально меняют правила игры. Ну то есть автоматическая трансляция с одного на другое в общем случае это фантастика. При этом жизненный цикл такого кода начинает измеряться считанными годами (вот прямо в штуках), когда потом чисто экологически ломается обратная совместимость, - а не десятилетиями как на мейнфреймах.
пока данные не начинают модифицироваться кем-то ещё, или пока кто-то не решает работать с этим куском АП как, собственно, с памятью,
Кто ж ему разрешит? Я говорил про отсутствие лишних абстракций, а не разграничения доступа.
вот проблемы с тем, чтобы понимать, что там наворотил предыдущий кобол-ковбой — есть, и эти проблемы от железа не зависят, потому что ограничены нашей черепной коробкой, увы.
Где гарантии, что хаскель-мэны не нагородят ещё хуже? Тем более раз речь зашла об автоматической генерации кода. Если цель уйти в микросервисы, то они наверняка ее достигнут. Но что будут делать с таким кодом люди, которые придут лет через пять? А десять? Ну понятно, что - переписывать. Если разберутся конечно в том, что нагородил кодогенератор по мотивам произведений тех доисторических ковбоев.
нет никаких причин их не писать на хаскеле
Горизонтальное масштабирование и вообще любая взрослая параллельность при отсутствии полной изоляции (один процесс может зависеть от другого, в общем случае выполняемого на соседней ноде в кластере).
Написать-то можно и на ассемблере, но барьеров перепрыгнуть придется в разы больше, в сравнении с любым языком, в котором акторная модель и distributed execution не прикостылены спустя десятилетия, а заложены в архитектуру языка.
Где он, этот кобол? Кто на нём что пишет?
Не знаю, как в вашей стране, а у нас в Голландии COBOL до сих пор используется достаточно широко.
Что я видел сам:
1999 - Авиакомпания KLM. К счастью, мне самому не пришлось там сталкиваться с COBOL-ом - я писал на другом устаревшем языке - PL-1. Там же использовалась и СУБД IMS, разработка IBM родом из 1960-х годов.
Кстати, в конце 1990х годов KLM рассматривала возможность использования системы планирования полетов других авиакомпаний вместо своей. Одна из кандидаток - система одной из американских авиакомпаний родом из 1960-х, написанная на FORTRAN вообще без использования СУБД (все данных хранились в файлах).
2010 - Центробанк. Прямо-таки заповедник COBOL.
2017 - Металлургический комбинат Tata Steel. Основная программа, собственная ERP-cистема для управления всем производством (на первом уровне согласно 5-уровневой архитектуре управления индустриальными процессами), написана на COBOL. (Там, правда, еще использовались Java и Python, но основная часть реализована на COBOL). Там же использовалась и СУБД IMS.
Сейчас COBOL все еще широко используется в банках, страховых компаниях, крупных предприятиях типа Gasuine (местный "Газпром").
Сейчас заглянул в LinkedId - в Голландии 64 открытых вакансий по COBOL. Довольно много для такого устаревшего языка.
Кстати, в Голландии в 2000-х годах увеличились продажи мейнфреймов.
Сейчас заглянул в LinkedId — в Голландии 64 открытых вакансий по COBOL.
Вероятно им видется не с руки тратится/разрабатывать и внедрять какой то сторонний софт в свои бизнес процессы привязанный к текущим реалиям.
P.S. Много это или мало 64-е вакансии в сравнении с другими предложениями в рамках отдельной страны?
А вот скажите, язык AWK, он уже мёртв или ещё нет?
Например, я вот на нём пишу.
Попробую накинуть свои пять копеек на вентилятор. Про Pascal vs. C:
Это был один из двух вариантов доступных нам на ЕС-ках в ВУЗе (ака IBM 360) в лихие 90-е. Паскаль и PL/1. C ни в каком виде туда нам не завезли.
Паскаль был обязательным курсом по программированию на 1-2 курсе (хз что там изучать было два года, я туда ни разу не ходил, только на экзамен пришёл).
После появления ПК турбо-паскаль появился гораздо раньше Турбо-С. То же самое было с библиотекой Turbo Vision.
С появлением Turbo Vision на C, появился ещё один нюанс: Компиляция проекта на Turbo Vision & С шла в несколько раз дольше, чем того же проекта на Pascal. То что у меня собиралось за десятки секунд (проект уровня курсового), на C можно было не спеша сходить покурить, вернуться и ещё немного подождать. А поскольку "машинное время" было весьма ограниченным, то это также решало. По крайней мере, до того, как ПК стал доступен среднему классу в нашей стране.
Delphi появился гораздо раньше своего аналога на C и потому комьюнити его также было больше в начале нулевых. На Object Pascal есть всё, что в C++, указатели, классы и т.п. А уж библиотек VCL наверное в разы больше. Но синтаксис эклектичен, это да.
хз что там изучать было два года
Видите ли, товарищ, распечатка мелом на доске идёт очень медленно. Даже объяснение простой процедуры требует сначала вывести её мелом на доску, потом отладить её тряпкой и мелом, а только потом компилировать, записывая значения переменных в окне отладки на второй доске.
Безмашинное программирование — штука медленная!
Forth ещё был популярен.
Только совсем уж в слабых железках и в виде обучения. Покажите какой-то софт, реально написанный на Форте.
Всем 2 2 + .
))
Загрузчик FreeBSD до 12 версии - а больше и не припомню.
Банально nncron, eserv
OpenBios (был/есть и в ПК OLPC)
ForthCAD
…
XFmap
…
Forth Application (на сайте Forth. Inc)
P.S. Просто Форт (Forth) по слухам был популярен некоторе время в начале/сeредине 80-х годов на Западе, а в СССР в период его распада отметился изданием некоторого количества книг, в том числе и оригинальны от рускоязычных авторов. :)
Язык Форт в СССР и России
Сейчас, конечно, Форт чаще всего можно встретить в нише разработки встраиваемых систем, хотя для него создано много интересных и самих Форт систем.
Для написания каких программ лучше всего подходит Forth (Форт) язык?
насколько я знаю. то форт очень популярен на всякого рода контроллерах/встройках с очень маленьким ресурсом. В 1-2кб можно запихнуть большой объем логики работы контроллера. Но это тема не моя, только слышал.
Да, его ещё вычислительную архитектуру аппаратно реализуют и в рамках FPGA.
P.S. Для интересующихся Форт есть
и русскоязычный действующий форум по нему
и Телеграм канал
Насколько я помню, Starflight, предок Star Control, на Forth написан.
Да, на Форт (86, 89 год первой и второй игры) в сети сохранились и некоторые её исходники.
Проект Starflight-Reverse по реверсу бинарного кода игры в Си вариант (с использованием и SDL) для компиляции Си компилятором и запуска под Linux, Windows.
Странные взаимоисключающие утверждения содержит статья. Про кобол:
Сегодня мы считаем его заурядным, но когда-то он был самым популярным языком в мире.
И одновременно:
На COBOL разрабатывали очень немногие.
Про алгол тоже странное:
В спецификации не было указано ни одного инструмента для ввода-вывода, из-за чего, по сути, его невозможно использовать в реальности.
Ну, полная ерунда. Ввод-вывод практически во всех тогдашних языках, да и современных тоже, используют функции ввода-вывода. Точно так же и в алголе эти функции были. Стандарта на них не было, а функции были. И алгол прекрасно использовался на практике.
Мы называем C «подобным ALGOL»,
Это тоже странно. Си по синтаксису был антогонистом алголу. Языки-последователи были либо си-подобными, либо алголо-подобными (позже названные паскале-подобными).
Ну, и сам паскаль был упрошённой синтаксически (и немного семантически) версией алгола-60 (а, про это и написано, да).
Процедуры ввода-вывода были не в Алголе, а в библиотеках программ в конкретных реализациях. Концептуально точно также как, например, функция рисования окна не является частью языка Си, но количественно гораздо хуже, так как тогда несовместимых операционных окружений были сотни (до появления System/360 – вообще буквально на каждой машине своё) и никаких кроссплатформенных библиотек не было. В то же время Кобол и Фортран имели жёстко стандартизированный ввод-вывод, что было крайне важно для практического написания программ в то время, так как по описанной причине требовалась кроссплатформенность.
Синтаксис и семантика языка Си в наиболее фундаментальном смысле происходят от Алгола: описание переменных, статическая типизация, составные операторы с блочной структурой, передача параметров по значению и ряд других моментов, воспринимающихся сейчас, как само собой разумеющееся. Если сравнивать с четвёркой первоязыков Фортран_I – Лисп – Кобол – Алгол-60, то большинство современных языков алголоподобны. И даже современный Фортран в ряде аспектов более подобен Алголу-60, чем Фортрану_I.
Ну и Паскаль от Си семантически почти не отличается, это вообще языки-близнецы, хотя у них разные лексические элементы и, как следствие, визуально разный синтаксис. Именно поэтому они долгое время конкурировали между собой.
Процедуры ввода-вывода были не в Алголе, а в библиотеках программ в конкретных реализациях
Сейчас бы сказали - в рантайме.
количественно гораздо хуже, так как тогда несовместимых операционных окружений были сотни
Операционные окружения не имели отношения к названям функций. А названия этих функций зависели не от окружений, а от реализации алгола, а их было вполне считанное количество. Да и в разных реализациях вариантов было не сильно разнообразно. В конце-концов не составляло особого труда обернуть одну функцию в другую.
Если сравнивать с четвёркой первоязыков Фортран_I – Лисп – Кобол – Алгол-60, то большинство современных языков алголоподобны
Ну, среди именно этой четвёрки, таки да :).
Ну и Паскаль от Си семантически почти не отличается, это вообще языки-близнецы, хотя у них разные лексические элементы и, как следствие, визуально разный синтаксис.
Нуууу! Я бы так не сказал! Как раз семантически они изрядно разные, а вот с синтаксисом мы забавлялись, меняя бинарным редактором в копии компилятора на пидипоидных машинках begin-end'ы на скобочки и получая визуально "почти си" ;)
Я имею в виду виртовский паскаль. В борландовском варианте паскаль к си, конечно, приблизился.
В конце-концов не составляло особого труда обернуть одну функцию в другую.
Обернуть составляло труд, так как многие реализации не позволяли в точности управлять форматом ввода-вывода. И могло, как я понимаю, получиться даже так, что данные, выведенные на какие-нибудь перфокарты алголовской программой на одной машине, могли оказаться непригодными к вводу в алголовскую программу на другой машине. Тогда ж не было всяких XML и JSON, и совместимый ввод-вывод тех времён – это точное указание форматов.
Кстати, и исходные тексты программ были несовместимы между реализациями по той же самой причине. Например, в типографской печати в алголовских программах ключевые слова выделялись, по замыслу разработчиков, жирным шрифтом. Что это означало при вводе в компьютер, они не побеспокоились уточнить, потому что вообще-то Алгол разрабатывался как язык формальной записи алгоритмов, а не как язык практического программирования компьютеров. И вот, в частности, в реализации IBM жирные слова ставились в апострофы. А многие другие фирмы так не делали. Поэтому там, где на какой-нибудь условной машине Burroughs в программе набивалось BEGIN, в IBM надо было писать 'BEGIN'. (Не имею понятия, как в компиляторах первого вида отличали при этом ключевые слова от идентификаторов, так как запрета на их совпадение в Алголе нет, а контекстная зависимость не задумывалась).
К слову, складывается впечатление, что IBM сделала компилятор Алгола для S/360 "на отвали" специально, чтобы затруднить использование языка. Хотя компилятор входил в стандартный дистрибутив OS/360 и OS/370 десятки лет.
как в компиляторах первого вида отличали при этом ключевые слова от идентификаторов
Извращались лексически, например, писали _BEGIN
могло, как я понимаю, получиться даже так, что данные, выведенные на какие-нибудь перфокарты алголовской программой на одной машине, могли оказаться непригодными к вводу в алголовскую программу на другой машине.
Я, вот, межмашинный обмен перфокартами не застал (да и вообще застал только ввод программ с перфокарт, вывод был на распечатки, но это НИИ и вузы, не промышленность, там может иначе было). Неужели, такой перфокарточный поток данных был сильно актуален и широко распространён? Ну тут не знаю, системные программеры могли библиотечный формат вывода и подхачить под нужды. Там компиляторы были полусамодельные, вообще не проблема была сделать совместимым.
Кстати, и исходные тексты программ были несовместимы между реализациями по той же самой причине.
при перфокарточном вводе это не составляло большой проблемы, тк колода перфоркарт имела ограниченный срок службы и их всё-равно приходилось перебивать. :)
в реализации IBM жирные слова ставились в апострофы
О, да, это боль :)
там, где на какой-нибудь условной машине Burroughs в программе набивалось BEGIN, в IBM надо было писать 'BEGIN'. (Не имею понятия, как в компиляторах первого вида отличали при этом ключевые слова от идентификаторов, так как запрета на их совпадение в Алголе нет, а контекстная зависимость не задумывалась).
то, что не задумывалась не значит, что не могла быть реализована :).
Хотя компилятор входил в стандартный дистрибутив OS/360 и OS/370 десятки лет.
Не только входил, но и активно использовался. И он и ещё пара десятков реализаций. Значит, не было особых проблем это использовать.
Неужели, такой перфокарточный поток данных был сильно актуален и широко распространён?
Насколько я понимаю, в 1960-х годах основным средством переноса данных с одной машины на другую были перфокарты. Просто не было других совместимых носителей, ну и никаких сетей, естественно, тоже не было.
9-дорожечную магнитную ленту придумали в S/360 в 1966 году, и ещё лет 10 она распространялась, прежде чем стать фактическим стандартом.
Не только входил, но и активно использовался. И он и ещё пара десятков реализаций. Значит, не было особых проблем это использовать.
Я лично не встречал среди программистов OS/370 ни одного человека, который бы им пользовался. Сам я в своей жизни откомпилировал одну программу на Алголе – просто набрал из справочника алгоритмов. Потом переписал на PL/I, потому что уж больно неэстетично выглядели эти листинги с апострофами.
Насколько я понимаю, в 1960-х годах основным средством переноса данных с одной машины на другую были перфокарты. Просто не было других совместимых носителей, ну и никаких сетей, естественно, тоже не было.
Вопрос в переносе данных с машин одной системы на машины другой. Зоопарки несовместимых машин в одном месте - не очень понятная история. А если это передача между организациями, то там проблема в потенциальной несовместимости формата данных на перфокарте - не самая большая проблема :)
Я лично не встречал среди программистов OS/370 ни одного человека, который бы им пользовался.
А у нас таких половина дружественного НИИ была. Вторая половина жила на БЭСМ-6 и использовала паскаль :)
До 1990-х годов зоопарки несовместимых машин были обычной историей, практически единственно возможной. А в первой половине 1960-х вообще каждая новая машина была несовместимой с предыдущими.
и насколько часто требовалось переносить данные на перфокартах с одного типа машины на другую? Я, вот, честно, не застал такой юзкейс и не особо понимаю зачем это могло понадобится. Микросервисы тогда ещё не придумали :)
Разумеется, говоря Pascal мы подразумеваем DELPHI, а говоря Basic - мы подразумеваем VB.
Конечно же, нет. Вернее, если рассматривать именно дельфи и вб, то всё как вы сказали, но тут речь именно о паскале и бейсике. У паскаля более долгая история и гораздо бОльшее влияние на индустрию и языки, чем короткая вспышка популярности дельфей.
Вот бейсик, тот, кажется, язык в себе - повлиял только на самого себя в реинкарнации вб и вбс. Дальше никуда не пошёл (и слава тебе господи!) ;)
Зато повлиял на популярность программирования персоналок.
Эволюция програмного обеспечения более чем наполовину (и, возможно, на 90% но это не точно) определяется "битвой бульдогов под ковром", а лучше - "дружным коллективом пауков в банке", - т.е. в области коммерции, конкуренции, картельных соглашений и лоббирования. Тесная связь бизнеса и политики. По-моему, так.
Неа. Тогда бы не было феноменов руби, пхп, скалы и, даже питона (да, и пёрла). Ну, и многострадальный паскаль, задуманный как язык для обучения, внезапно стал популярным задооолго до того, как борланд выпустил свои турбокомпиляторы. Собственно, и си тоже хороший пример. Вообще корпоративных языков не так и много. По сравнению с сониищем остальных.
КМК, именно отсутствие подобного инструмента визуальной разработки на Basic, и привело к стагнации экосистемы OS/2, а потом к её проигрышу в конкурентной борьбе.
Существовал конкурент MS VB 3.0 от IBM для OS/2 и Windows под названием VisualAge for Basic (кстати, VisualAge for Smaltalk тоже существовал, и даже были попытки его использования в России в банковской сфере именно под OS/2). Так что инструментарий был. Видимо, не в этом дело.
Так что инструмент, «немножко» опоздал, на лет пять после выхода OS/2 2.0, и соответственно ни как не мог повлиять на развитие и расширение экосистемы OS/2. Так что проблема с инструментарием массовой разработки была, точнее с его отсутствием инструмента как такового, а тут как говориться «дорога ложка к обеду».
IBM скорее свой REXX продвигал, и Visual REXX тоже был - но не помню, было ли там удобное рисование формочек как в VB.
эхх, надеюсь, когда-нибудь вспомнят про аппаратные языки на которых написаны почти все цифровые чипы от процессоров до чипсетов и даже простых цифровых адаптеров интерфейсов типа усб хаба. Я про такие как Verilog и SystemVerilog, VHDL например. Ведь почти всё что юзают ITшники написано на них (сейчас разве что совсем мелочь типа шинного драйвера SN74HC244, или lvlshifter-ы возможно сразу рисуют в схематике). Даже тест бенчи, симуляции и тд написаны на этих языках. Ну и про TCL можно вспомнить.
'>' У BASIC есть еще одно интересное применение:
'>' инструменты Office. В конечном итоге Microsoft
'>' превратила BASIC в Visual Basic, который
'>' использовался как язык макросов Office.
...
'>' Недавно он уступил позиции JavaScript и теперь
'>' считается устаревшим языком написания макросов.
А в каком смысле Бейсик уступил позиции JavaScript, если они применяются в разных средах и для разных дел:
Бейсик, о котором тут прошла речь, применяется в среде офиса для написания макросов.
JavaScript применяется в среде браузера для написани скриптов.
Бейсик, о котором тут прошла речь, применяется в среде офиса для написания макросов.
JavaScript применяется в среде браузера для написани скриптов.
макросы в офисе уже давно можно писать на жаваскрипте. Понятия не имею насколько широко это распространено в мире, возможно, автор статьи больше владеет информацией.
Когда-то и бейсик пытались впихнуть в браузеры, вот чуть выше коммент по теме
https://habr.com/ru/companies/ncloudtech/articles/753562/#comment_25842746
я бы добавил apt
Мой коллега программирует ПЛК на языке ST. По синтаксису очень похож на Паскаль. Видимо этот диалект будет ещё долго жить.
Ради интереса посмотрел проект и был крайне удивлен непривычным подходом. Я привык к файлам программы, а их нет. В одном окне код на Паскале, в другом описание переменных в третьем - дерево компонентов. На вопросы как хранится код, какая система контроля версий толкового ответа не получил.
Это в семействе IBMовских компиляторов VisualAge такое было. Просто классы во внутреннем представлении в единой базе данных со внутренней системой контроля версий. Причём база могла храниться на многопользовательском сервере. Круто на самом деле.
VisualAge for Java был очень классной средой разработки, но не выстрелил, потому что был заточен под разработку standalone программ, а Java пошла в основном развиваться в сторону веба.
Готов поспорить что он вам ответил следующие: код хранится внутри ПЛК, система контроля версий присутствует в виде сравнения проекта на ПК и коде что был загружен в ПЛК.
Контроль версий зависит уже от конкретной реализации. У Сименса в TIA Portal вполне себе прикручивается внешняя система контроля версий.
Несправедливо обойдён вниманием язык B. А ведь он не только непосредственный предшественник C (разница между B и C такова: один интерпретатор, другой компилятор, первый безтиповый, второй вместо одного типа данных, машинного слова, предложил чуть больше). Именно из B идёт синтаксис всех так называемых C-подобных языков.
Прикольно было бы дожить до подобной статьи где неха первом месте из 10 будет яваскрипт
Я даже знаю одну контору в Москве, которая сейчас, в 2023 году, пишет и развивает очень специфический софт на PL/1. 15 лет назад еще было на еле дышащих ЕС-1066, потом я ушел оттуда. Сейчас вроде обновились на что-то, но прикладной код поменять - это десятилетия работы. Говорят, оставили как есть.
BASIC стал первым языком с интерпретатором в режиме реального времени
Да вы что! А как же lisp?
Я бы не сказал, что BASIC мертв, есть примеры современных проектов, где его используют в локальных целях, например стартап Rumble
Не понимаю, почему в списке нет LISP? Он не такой уж влиятельный? Или пока ещё не мёртвый?
Ну, так то живой вполне себе: SBCL 2.3.7 вышел 29 июля этого года.
Clojure 1.12 через пару месяцев выйдет, уже 4-я альфа версия есть.
LFE 2.1.2 вышел 3 августа: https://lfe.io/
Читаю статью и мысленно возвращаюсь в 80-е годы прошлого столетия.
Мне довелось тогда не только программировать на многих из упомянутых языках, но и даже написать и издать в "Финансах и статистики" несколько книг и эти книги, как и многие другие по программированию были нарасхват. Про Фортран и ПЛ/1 писалось в "Комплексирование программ в ОС ЕС":
Про Паскаль и Аду было написано в "От Паскаля к Аде":
Что удивительно (?), мне часто пишут энтузиасты ПЛ/1, которые программируют на нём до сих пор. Сам я сегодня ни на одном из этих языков не программирую.
P.S. Когда учился в академии нам преподавали практически все упомянутые в статье языки.
10 самых влиятельных (и почти мёртвых) языков программирования