Гиллель Уэйн*, разработчик и консультант по формальной верификации, обратил внимание на статью «20 наиболее значимых языков программирования в истории», которую сам автор называет «нелепой, только что придуманной таблицей». По мнению Уэйна, эта характеристика вполне справедлива: автор таблицы называет Go «наиболее значимым», но не включает в список ALGOL, Smalltalk или ML. И не учитывает Pascal, потому что тот «почти мёртв». Абсурд! Это противоречит всей сути понятия «значимость в истории».
Так давайте обсудим некоторые «почти мёртвые» языки и причины их важности.
Дисклеймер: Да, не все из этих языков мертвы и забыты. Ведь большинство людей слышали о Smalltalk, правда? Также, скорее всего, в этой статье полно ошибок, ведь их легко допустить, когда вы анализируете 60-летнюю историю компьютерных вычислений. Не стесняйтесь возражать, если что-то заметите!
Дисклеймер 2: Да, некоторые из упомянутых здесь языков были «первыми изобретёнными», а другие — «первыми популярными». История — это сложно!
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
Определение влияния
Небольшое предисловие о том, что стоит понимать под «влиянием». Простой факт того, что X был первым языком с функцией Z, не означает, что X действительно оказал влияние на Z. Несмотря на то что Absys, возможно, стал первым языком логического программирования, его большая часть строится на разработанном независимо Prolog. В конечном итоге есть только один точный показатель того, повлиял ли X на Y: цитирование. Что означает один из следующих вариантов:
Y ссылается на X в своем справочном руководстве
Y ссылается на статью, которая цитирует X
Автор Y заявляет: «На нас повлиял X»
Цитирование происходит по цепочке. Иногда в руководстве по языку Q упоминается документ R, который в свою очередь называет источником вдохновения статью S, где говорится о заимствовании идей из языка T. Таким образом, мы понимаем, что T оказал влияние на Q, даже если цепочка довольно длинная. Следовательно, для поиска нужной информации требуется изучить большое количество источников. Чтобы ускорить процесс, мы определяем область поиска с помощью эвристики.
Одним из эффективных методов является изучение сходств языков программирования. Крайне редко языки самостоятельно приходят к одинаковому синтаксису. Так что если два языка имеют схожий синтаксис, вероятно, один из них повлиял на другой. Например: даже не зная о проектных решениях Матца, мы понимаем, что на Ruby оказал влияние Smalltalk, так как оба языка используют метод select для фильтрации списка. Это не решающее доказательство. Возможно, разработка Матца независима, или же и на Ruby, и на Smalltalk повлиял один и тот же предшественник. Но оно дает нам точку отсчёта для начала поиска.
Языки
COBOL
Происхождение: CODASYL, 1960. COBOL сформировался в результате разделения разработки для бизнеса и науки. Тогда промышленные языки высокого уровня применялись либо для инженерных расчетов, либо для работы с данными. Все инженеры выбрали FORTRAN, в то время как в бизнес-сфере царил хаос из COMTRAN, FLOW-MATIC и других, поэтому Министерство обороны собрало комитет для создания единого универсального бизнес-языка. И им стал COBOL.
Он был одним из четырёх «родительских» языков, вместе с ALGOL, FORTRAN и LISP. Сегодня мы считаем его заурядным, но когда-то он был самым популярным языком в мире. На нём до сих пор работают многие из поддерживаемых бизнес-систем.
Значение: Синтаксис и семантика COBOL редко встречаются в современных вычислениях. Самым значительным нововведением COBOL является концепция структуры данных. В FORTRAN и ALGOL единственной доступной структурой данных был статический массив. Однако в COBOL можно было загружать структурированные файлы с иерархическими данными, которые автоматически преобразовывались в соответствующие переменные. Это стало предвестником современных структур данных.
Причина упадка: Сыграли два основных фактора. Первый: COBOL не перекликался с другими проектами PLT. На COBOL разрабатывали очень немногие. А значит, что вторые и третьи поколения языков, основанные на уроках своих предшественников, его почти не использовали. Это связано не столько с проблемами самого COBOL, сколько с результатом пренебрежительного отношения академического сообщества к процессу его создания. Организация CODASYL была коммерческой и, очевидно, не заслуживала внимания. К тому же, COBOL чрезвычайно сложен даже по меркам современных языков. Компиляторы COBOL отставали от своих современников на микро- и миникомпьютерах, что позволило другим языкам развиться и в конечном итоге выйти вперёд.
ALGOL
Происхождение: Комитет ALGOL, 1960 год. ALGOL-58 был выпущен на два года ранее, но быстро устарел, поэтому здесь я их объединяю. Комитет стремился создать хороший язык для исследования алгоритмов. Иными словами, ALGOL представлял собой формализованный «псевдокод».
Среди четырёх основных языков наиболее «мёртвым» является ALGOL; все ещё знают о LISP, COBOL до сих пор поддерживает множество старых систем, а большинство научных пакетов используют FORTRAN. Но я знаю множество программистов, которые даже не слышали об ALGOL. Может показаться, что это наименее важный из основных языков, но на самом деле наоборот. Из четырёх языков только LISP близок к ALGOL по своей всепроникающей значимости.
Значение: Итак, лексическая область действия, структурное программирование, вложенные функции, формальные спецификации языка, семантика вызова по имени, грамматики БНФ, блочные комментарии... ALGOL глубоко затронул каждый современный язык.
Причина упадка: ALGOL был языком для исследований, а не коммерческим инструментом. Он создавался для анализа алгоритмов. В спецификации не было указано ни одного инструмента для ввода-вывода, из-за чего, по сути, его невозможно использовать в реальности. Разумеется, можно было создать расширение для компилятора, но с тем же успехом можно было бы добавлять и прочую функциональность.
Именно так люди и поступили. В 1960-70-х годах было разработано множество языков, похожих на ALGOL, которые расширяли его возможности за счёт ввода-вывода и дополнительных структур данных. Сюда входят JOVIAL, SIMULA, CLU и CPL. Созданные позднее языки основывались на этих расширениях, а не на самом ALGOL. Мы называем C «подобным ALGOL», но на самом деле он подобен BCPL, который подобен CPL, который подобен ALGOL. ALGOL похоронили его потомки.
Впоследствии авторы попытались модернизировать его до ALGOL-68, который кардинально отличался от ALGOL-60 и не имел такого же влияния. Развивать направление ALGOL-60 продолжил Паскаль Никлауса Вирта.
APL
Происхождение: Кен Айверсон, 1962 год. Сначала это была рукописная нотация для записи математических действий с массивами, но затем IBM использовала её как язык программирования. В качестве языка APL сосредоточился на обработке массивов, предоставляя возможность сжато управлять большими блоками чисел.
Если вы уже слышали о APL, то, вероятно, помните его как «тот странный язык с символами». Одним из самых знаменитых фрагментов кода является реализация игры «Жизнь»:
Для его написания требовалась вот такая специализированная клавиатура:
Тем не менее, APL стал популярен на мейнфреймах, так как для работы требовал очень мало оперативной памяти.
Значение: Обработка массивов. В эпоху, когда сложение двух списков чисел подразумевало использование map или цикла, APL предложил идею оперирования над всем массивом одновременно. Вот пример:
Это стало настоящим прорывом в научном сообществе. Большая часть прикладной математики сводится к операциям над большими матрицами. Получение внешних произведений становится невероятно простым, когда можно просто взять внешнее произведение с помощью ∘.f!
Нововведение APL привело к созданию R, numpy, pandas, Matlab и т.д. Также есть прямые наследники APL: J, Dyalog, K, Q. Они не столь успешны, но активно используются в финансовом секторе.
Причина упадка: очевидно, проблема в клавиатурах. Если нет возможности писать код на ASCII, много написать и не получится. Иверсон решил эту проблему в J, где вместо различных символов используются диграфы. Вместо ≠ используется ~:. Но это случилось в 1990 году, довольно поздно для популяризации радикально нового стиля программирования.
Менее заметная проблема заключается в том, что APL и J работали только с однородными данными. Нельзя хранить строки и числа в одной структуре данных (если не использовать ячейки, что уже совсем другая история), а работа со строками обычно превращается в кошмар. Так что никаких датафреймов, что исключает большую часть современной науки о данных.
Дополнительная информация: Notation as a Tool of Thought
BASIC
Происхождение: Джон Кемени, 1964 г. Изначально это был упрощённый аналог FORTRAN, созданный для помощи в использовании компьютеров людям, не связанным с инженерией.
BASIC по-настоящему расцвёл в эпоху микрокомпьютеров. Первые из них не обладали достаточным объёмом памяти для компиляции программ на «полноценных» языках программирования, в то время как упрощённый компилятор BASIC можно было уместить примерно в 2 килобайта. Он стал общепринятым языком начинающих программистов. Если вы занимались программированием дома в 1970-х, то, вероятнее всего, писали на BASIC на микрокомпьютере.
Значение: BASIC стал первым языком с интерпретатором в режиме реального времени (Dartmouth Time Sharing System), опередив APL на год. А поскольку система APL была доступна только для клиентов IBM, долгое время выбор стоял между BASIC и ничем.
BASIC привнёс программирование в быт, особенно среди детей. Многие программисты 80-х и 90-х годов, в будущем ставшие влиятельными специалистами, впервые освоили программирование именно на BASIC. Множество корпоративных систем также были написаны на BASIC, что, вероятно, поспособствовало скорому упадку Cobol.
У BASIC есть еще одно интересное применение: инструменты Office. В конечном итоге Microsoft превратила BASIC в Visual Basic, который использовался как язык макросов Office. Затем это распространилось на OpenOffice и LibreOffice, укрепив позиции BASIC в конкретной области. Недавно он уступил позиции JavaScript и теперь считается устаревшим языком написания макросов.
Причина упадка: BASIC воспринимали как «второстепенный» язык. Его могли использовать дети или владельцы малого бизнеса, но настоящие программисты предпочитали настоящие языки. Когда производители смогли производить недорогие микрокомпьютеры с более чем 16 Кбайт оперативной памяти, то разработчики стали отказываться от BASIC в пользу языков типа Pascal и C.
BASIC некоторое время продолжал существовать как язык для обучения детей, но, кажется, затем освободил и эту нишу.
PL/I
Происхождение: IBM, 1966 год. В работе IBM применялись два языка: FORTRAN для ученых и COMTRAN для бизнесменов. Столкнувшись с конкуренцией COBOL и стремясь упростить системы, компания попыталась создать язык, который был бы полезен как для инженерных, так и для бизнес-целей. В результате получился своего рода суперсет двух языков с множеством дополнительных функций сверху. Теперь все могли использовать один и тот же язык, а IBM зарабатывала гораздо больше денег! Урааааааа
Значение: Авторы ALGOL-68 иронически называли PL/I устаревшим языком. Но все достижения ALGOL-68 в PL/I были реализованы раньше и лучше. Хотя COBOL первым получил структурированные данные, PL/I впервые реализовал их как тип данных. В COBOL чтение пользователя с именем приводило к появлению двух глобальных переменных — user и name. В PL/I это была бы одна переменная с полем user.name. PL/I стал первым языком высокого уровня, в котором появились указатели для прямого управления памятью, константы и перегрузка функций.
Многие из этих концепций были внедрены в современное программирование через язык C, являющийся сочетанием BCPL и PL/I. Синтаксис комментариев в C также взят из PL/I.
Причина упадка: программисты FORTRAN считали его слишком похожим на COBOL, а программисты COBOL — на FORTRAN. IBM попыталась предложить в качестве альтернативы двум распространённым языкам один, значительно более сложный. Также успеху не способствовало то, что они были единственными разработчиками компилятора — это вызывало недоверие из-за зависимости от одного производителя. Когда IBM наконец преуспела в решении этих проблем, мир компьютерных технологий уже перешёл к эре микрокомпьютеров, где PL/I уступил BASIC.
Дополнительная информация: The Choice of PL/I
SIMULA 67
Происхождение: Оле Даль и Кристен Нюгаард, 1967 год. Они модифицировали ALGOL для моделирования симуляций. Сначала разработали SIMULA I, имевший специализированный синтаксис для моделирования и выполнения задач. SIMULA I нашел применение на ранних этапах, но оба автора были недовольны «специализированностью» языка и большим количеством дублирующего кода в моделях. Они стремились создать более универсальную систему для описания объектов в целом, а не только для моделирования.
Концепция заключалась в том, что пользователи могли задавать новые типы, называемые «классами», с полиморфным разрешением функций. А затем — создавать функции моделирования как частный случай объектной системы, что упрощало бы настройку того, как все это работает, в соответствии с их конкретными потребностями.
Значение: Несмотря на то, что SIMULA не был первым «истинным» языком ООП, он стал первым языком с полноценными объектами и заложил основу, на которой строились последующие языки. В том числе разделение на классы и объекты, подклассы, виртуальные методы и защищённые атрибуты. Он стал источником вдохновения для большинства академических исследований в области объектов после 1967 года. Как CLU, так и ML указывали SIMULA в качестве источника основного влияния. Бьёрн Страуструп написал докторскую диссертацию по SIMULA, в конечном итоге многие идеи SIMULA были внедрены в язык C++.
Причина упадка: В докторской диссертации Страуструп заявил, что SIMULA слишком медленный для использования в больших масштабах. Медленный в духе «Удачи с выполнением задач, если не используете мейнфрейм». Стоит отметить, что Smalltalk-80, который развил эти идеи дальше, имел преимущество в виде дополнительных 13 лет действия закона Мура. И даже Smalltalk часто критиковали за излишнюю медлительность. Идеи, которые были в SIMULA, начали внедрять в более простые быстрые языки.
Pascal
Происхождение: Никлаус Вирт, 1970 год. Создан, чтобы сохранить суть ALGOL-60 после того, как ALGOL-68 показался Вирту слишком сложным. Сперва стал известен как язык «введения в computer science», и к началу 80-х годов стал вторым по популярности языком на досках объявлений о работе Usenet. Вирт рассматривал всё семейство — Pascal, Modula и Oberon — как единую концепцию языка.
Значение: Pascal не представил ни одной совершенно новой идеи. Это был намеренно консервативный язык, который стремился собрать и объединить в своих рамках лучшее из прошедшего десятилетия. Pascal вынес синтаксис ALGOL за пределы академического мира, и синтаксис присваивания ALGOL, :=, стал известен как «стиль Pascal». С этого момента большинство языковых особенностей, напоминающих ALGOL, скорее всего, были вдохновлены не им, а Pascal.
Хотя сам Pascal не был особенно инновационным, его разновидности такими были. Вирт также стал пионером концепции «пошагового улучшения» как метода написания совершенного программного обеспечения. В конечном итоге это привело к созданию Modula, который популяризовал модули первого класса, и Euclid — первого формального языка верификации, используемого на практике.
Причина упадка: В отличие от большинства других языков в списке, у Pascal не было серьезных структурных препятствий или сильного конкурента. Да, он конкурировал с C, но всё равно успешно существовал долгое время. Обычно говорят об эссе Why Pascal is not my favorite language («Почему Pascal не мой любимый язык»), но это слишком простой ответ, а история гораздо сложнее. Также довольно высокие места в рейтингах TIOBE и PYPA до сих пор занимает Delphi, так что Pascal не настолько мёртв, как тот же SIMULA. Точный же анализ упадка Pascal занял бы больше места, чем остальная часть данного эссе.
Дополнительная информация: Pascal and its Successors
CLU
Происхождение: Барбара Лисков, 1975 г. Лисков хотела поэкспериментировать с абстрактными типами данных. Вот и всё. Вот в чем суть CLU.
Значение: CLU, возможно, самый влиятельный язык, о котором никто не слышал. Итераторы? CLU. Абстрактные типы данных? CLU. Дженерики? CLU. Проверяемые исключения? CLU.
Существуют расхождения в терминологии, и может быть не совсем очевидно, что все это исходит именно от CLU, и тем не менее. Каждая языковая спецификация следующего десятилетия будет ссылаться на CLU. CLU сделал многое.
Причина упадка: CLU был демонстрационным языком; Лисков хотела, чтобы люди приняли ее идеи, а не конкретный язык. Так и случилось: почти каждый современный язык чем-то обязан CLU. Завершив работу над CLU, Лисков перешла к Argus, который должен был продемонстрировать идеи о параллелизме. Он не получил такого же признания, и в нём еще много нераскрытого.
Дополнительная информация: A History of CLU
ML
Происхождение: Робин Милнер, 1976 г. Милнер разрабатывал LCF Prover, одну из первых систем автоматического доказательства теорем. Если вы составили доказательство в правильном формате, LCF мог проверить его корректность. Чтобы помочь в написании доказательств, Милнер создал метаязык, основанный на надежных математических формализмах, что в то время означало строгие статические типы и функции высшего порядка. В конце концов ML был стандартизирован как Standard ML.
Значение: ML можно считать самым старым «алгебраическим языком программирования». С ML связывают очень многое: алгебраические типы данных, модули, типизированное функциональное программирование. Удивительно, но он не был первым во всех этих аспектах! Первый ML разрабатывался только для LCF и не являлся языком общего назначения, поэтому не обладал многими из этих функций. Когда люди начали делать его более универсальным, то стали внедрять идеи из других исследовательских языков. Однако, одна очень важная идея зародилась именно в ML: вывод типов. ML стал первым статически-типизированным языком, где не требовалось указывать типы, поскольку компилятор определял их самостоятельно. Это проложило путь типизированного функционального программирования за пределы академической среды и в производство.
ML также существенно повлиял на современные системы доказательства теорем. Языки программирования для Isabelle, CVC3 и Coq основаны на ML. Многие аспекты теории типов были основаны на ML, хотя в последние годы в области функционального программирования все больше признания получает Haskell.
Smalltalk
Происхождение: Алан Кэй, 1972, 1976 и 1980 гг. Smalltalk-72 стал первым, Smalltalk-76 представил миру концепцию «объектно-ориентированного программирования», а Smalltalk-80 получил широкое распространение.
Smalltalk не был первым языком с объектами, но стал первым «объектно-ориентированным». Разница в том, что в Simula объекты дополняли примитивы, такие как числа и булевые значения, в то время как в Smalltalk даже булевые значения были объектами. Если хотите узнать больше, я кое-что написал здесь.
Значение: Иногда кажется, что Smalltalk — это «истинный» язык ООП, а такие языки как Java и Python — нет, но это не верно. ООП, как и любая другая парадигма, является продуктом множества различных влияний. Но язык определенно популяризовал саму идею. Если вы откроете любую книгу по общей теории ООП из середины 80-х или начала 90-х, она будет на Smalltalk. Кто-то переведёт свои примеры на C++, некоторые — на другие языки, но все будут использовать Smalltalk.
Smalltalk также популяризовал идею о объектах как о передаваемых данных, что привело к появлению CORBA, и вдохновил создание модели Actor.
Причина упадка: Общепринято считать, что Smalltalk проиграл из-за распространения C++. Но это не правда. У Smalltalk действительно были некоторые проблемы, в частности, сложность взаимодействия с другими инструментами и низкая производительность. Но даже в 1990-е годы Smalltalk использовался активно, и многие предполагали, что он станет доминирующим языком в бизнесе.
А потом появился Java.
Smalltalk не стал единственной жертвой «Java-покалипсиса»: Java также отодвинул на задний план Eiffel, Ada95 и почти все остальное в мире ООП. Интересный вопрос не в том, почему Smalltalk умер, а почему C++ остался в живых. Я полагаю, потому что C++ был лучше совместим с C, что облегчало его интеграцию в существующие системы.
***
Это лишь малая часть важных и почти умерших языков. Я не затрагивал ALPHARD, ALTRAN, Argus, Automath, BCPL, COMTRAN, CPL, Eiffel, FLOW-MATIC, HOPE, Hypercard, ISWIM, JOVIAL, MacSyma, Mesa, Miranda, Multics Shell, PLANNER, SMP, Sketchpad или SNOBOL. Каждый из них внёс свой уникальный вклад в современное программирование. История — это сложно.
Большинство влиятельных языков так и не стали популярными. Немногие использовали хотя бы один из них. Но каждый из них вдохновил людей, которые в свою очередь вдохновили других; так ДНК забытых языков появляется спустя десятилетия после их забвения. Существует также бесчисленное количество языков, идеи которых так и не были реализованы. «Энциклопедия языков программирования» насчитывает более 8000 языков. Многие из них содержали идеи, которые в дальнейшем не нашли развития. Представьте, сколько бы мы упустили, если бы никто не узнал о SIMULA или Лисков не представила бы CLU!
Вот почему мне так нравится изучать историю. Понимать, что мы потеряли, и находить это снова.
Благодарю Миикку Коскинена, Кевлина Хенни, Эрика Фишера и Леви Пирсона за их корректировки и отзывы.
Комментарии (346)
vadimr
09.08.2023 13:24+8Много ссылок на Фортран, а сам Фортран не перечислен в десятке. Хотя это источник императивного программирования, как такового.
Source
09.08.2023 13:24+9Автор в статье упомянул, что Fortran и Lisp вполне живы и хорошо себя чувствуют.
Хотя в этом контексте не очень понятно почему он решил похоронить Delphi (он же Object Pascal) и Pharo (он же Smalltalk)
vadimr
09.08.2023 13:24+2Тут, действительно, много неясного с определением современного статуса языка. Я, например, никогда не слышал о Pharo, зато три разных обновлявшихся в текущем году компилятора PL/I знаю. Хотя не считаю PL/I особо актуальным языком (к сожалению).
Source
09.08.2023 13:24На мой взгляд, современный язык должен иметь кросс-платформенный компилятор/интерпретатор. Вокруг него должны устраивать конференции или ещё какие-либо мероприятия. Ну и для позиционирования у него должен быть сайт в современном дизайне. Плюс удобный тулинг и поддержка со стороны 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/vadimr
09.08.2023 13:24-1Delphi удовлетворяет критерию кроссплатформенности???
Ну напишите на Delphi программу для macOS или на Pharo для z/OS.
Einherjar
09.08.2023 13:24На delphi можно писать для macos, это вполне официальная фича, насколько оно адекватно в итоге получится не в курсе, но точно знаю что отлаживать написанное через одно место придется потому что их ide есть только для windows (2023 год на дворе). В общем мне очень жаль тех кому приходится легаси на дельфи еще и под макось тащить.
ilriv
09.08.2023 13:24-2Отлаживать очень просто. IDE запускается на компьютере с WIndows, приложение запускается на компе с MacOS. Далее IDE подключается к порту на Маке и приложение отлаживается через сеть.
Einherjar
09.08.2023 13:24+4Очень просто это я в IDE на маке пишу код, там же нажимаю F5 и программа просто запускается под дебаггером. Кунг-фу с двумя компьютерами или виртуалками это не "очень просто", это клоунада.
ilriv
09.08.2023 13:24У вас весь код на одном компьютере, и вы можете с этого компьютера отладить этот код под Windows, Android, iOS, MacOS и Linux. Выглядит отнюдь не как клоунада.
Или лучше ставить 3 отдельных IDE под Windows, MacOS и Linux и копировать код на 3 компа? Это не клоунада?
Einherjar
09.08.2023 13:24+2Выглядит
Именно что только выглядит, на бумаге в маркетинговых методичках. Ровно до тех пор пока вы не попробуете. Потому что по факту с GUI приложением вам придется постоянно переключаться между двумя компами, потому что IDE на одном, а приложение на втором, да еще и в самой операционке что то постоянно потыкать надо - где то файлы почистить, где то настройки поменять, где то текст скопировать.
Или лучше ставить 3 отдельных IDE под Windows, MacOS и Linux и копировать код на 3 компа? Это не клоунада?
Представьте себе, даже на одном компе бывает несколько копий репозитория с разными бранчами.
ilriv
09.08.2023 13:24Я и так постоянно переключаюсь между тремя экранами, которые подключены к двум компам. Вообще не проблема.
Einherjar
09.08.2023 13:24+2Переключаться на второй комп чтобы там например в фоне ютуб запустить и переключаться чтобы отлаживать приложение это заметно отличающиеся сценарии. Ну вот допустим понадобилось скопировать текст из отладчика в текстбокс отлаживамого приложения, ну или наоборот из приложения в отладчик чтобы условие для брейкпоинта назначить. Что вы будете делать? Набирать руками? Да что там текст, вы с двумя мышами предлагаете работать что ли? Могу поинтересоваться, насколько часто вы кроссплатформенные UI приложения через сеть отлаживаете вообще? Потому что мне сама фраза о том что надо использовать 2 компа там где можно использовать один кажется каким то архаичным пережитком.
ilriv
09.08.2023 13:24Переключаться на второй комп чтобы там например в фоне ютуб запустить и переключаться чтобы отлаживать приложение это заметно отличающиеся сценарии
Отличия пренебрежимо малы.
Ну вот допустим понадобилось скопировать текст из отладчика в текстбокс отлаживамого приложения, ну или наоборот из приложения в отладчик чтобы условие для брейкпоинта назначить. Что вы будете делать?
Делал по-разному. Самое простое: сохранять в расшаренный текстовый файл.
Да что там текст, вы с двумя мышами предлагаете работать что ли?
На стационарном компе мышь, на ноутбуке тачпад.
Могу поинтересоваться, насколько часто вы кроссплатформенные UI приложения через сеть отлаживаете вообще?
Отлаживал с ноута приложение на компе где-то полгода назад.
Но я не профессиональный разработчик кроссплатформенных приложений.
Потому что мне сама фраза о том что надо использовать 2 компа там где можно использовать один кажется каким то архаичным пережитком
Но вы же была недовольны тем что у Delphi нет IDE под мак. Если поставить IDE на мак, надо будет как-то отлаживать версию приложения под Windows. По-любому нужен будет либл второй компьютер с Windows, либо хотя бы виртуалка.
Для кроссплатформенной разработки нужна хотя бы виртуалка с другой осью. Это никакой не "архаичный подход".
Я вообще не понимаю в чём проблема отладки через сеть и почему это кого-то напрягает.
Einherjar
09.08.2023 13:24+1Отличия пренебрежимо малы.
Ну как пренебрежимо когда количество попеременного ввода отличается на порядки.
Самое простое: сохранять в расшаренный текстовый файл.
Вместо двух нажатий: Ctrl+C и Ctrl+V
Если поставить IDE на мак, надо будет как-то отлаживать версию приложения под Windows
Ключевая разница в том что они не нужны одновременно. Если вам нужно починить баг на винде вы его чините на винде максимально удобно и комфортно, если на маке то соответственно там, никуда не переключаясь, не жонглируя двумя мышами, текстовыми файлами и сетевыми подключениями.
Я вообще не понимаю в чём проблема отладки через сеть и почему это кого-то напрягает.
Проблема вот в костылях вроде этого: "Самое простое: сохранять в расшаренный текстовый файл." Если раз в полгода то норм, а если каждый день то еще как будет напрягать.
ilriv
09.08.2023 13:24Если вам нужно починить баг на винде вы его чините на винде максимально удобно и комфортно
Да и так удобно и комфортно.
Ничем не сложнее чем администрировать удаленный сервер при помощи Putty. Это ведь не "ужас-ужас"?
Einherjar
09.08.2023 13:24Ничем не сложнее чем администрировать удаленный сервер при помощи Putty. Это ведь не "ужас-ужас"?
Когда вы администрируете сервер через putty вы не запускаете GUI приложение там
deitry
09.08.2023 13:24+1Вот я постоянно пользуюсь двумя компами с одной мышкой и клавиатурой - спасибо Mouse Without Borders - помимо "общего пространства" для двух компов, позволяет использовать общий буфер обмена и перекидывать файлы до 100 Мб. Насколько знаю, есть свои аналоги и для не-винды. Два компа - потому что один корпоративный без всякого лишнего, а второй персональный на котором включаю ютуб или гуглю что-нибудь.
ilriv
09.08.2023 13:24Представьте себе, даже на одном компе бывает несколько копий репозитория с разными бранчами.
А зачем это делать, если можно компилировать один и тот же код под разные платформы, выбирая нужную платформу при помощи комбобокса? Рекомендуемый подход именно такой.
Einherjar
09.08.2023 13:24А зачем это делать
Это безотносительно платформ. Например если идет параллельная работа над двумя фичами. В нескольких рабочих копиях никакого не удобства нет, наоборот это позволяет распараллелить работу ощутимо сократив время на переключение бранчей и перекомпиляцию.
Рекомендуемый подход именно такой.
Рекомендуемый кем?
ilriv
09.08.2023 13:24Рекомендуемый кем?
Компанией Embarcadero, разработчиком Delphi.
Она продвигает идеологию что код, работающий под Винду, должен работать и на других системах.
Параллельной разработке это никак не препятствует.
Einherjar
09.08.2023 13:24+3Компанией Embarcadero, разработчиком Delphi.
Ну тоесть они даже свой продукт не осилили сделать кроссплатформенным, и учат других как надо это делать?
ilriv
09.08.2023 13:24-2А они осилили сделать кроссплатформенным.
Для отладки приложений Delphi IDE подключается к приложению по TCP. Поэтому для Delphi нет разницы между отладкой приложения локально или удаленно. Всё и так работает, незачем что-то придумывать.
MiraclePtr
09.08.2023 13:24+1А они осилили сделать кроссплатформенным.
Нет, ниасилили. Кроссплатформенно - это когда IDE можно запустить на требуемой платформе и отлаживать программу локально на той же машине.
А то что вы описали - это именно что костыли.
DreamingKitten
09.08.2023 13:24Кроссплатформенно - это когда IDE можно запустить на требуемой платформе и отлаживать программу локально на той же машине.
На андроиде например, да?
Einherjar
09.08.2023 13:24+1Для андроида везде эмуляторы используются, запускаются они автоматически и вы отлаживаете локально, вам не нужно 2 устройства и куда то там по сети коннектиться.
ilriv
09.08.2023 13:24Если нет устройства на Маке, всегда можно отлаживать на виртуальной машине. И не будет проблем ни с "двумя мышками", ни с копированием.
Какой смысл обсуждать несущественную проблему?
Einherjar
09.08.2023 13:24+1Вы давно устанавливали макос на виртуальную машину под виндой? Там костылей еще больше чем с отладкой по сети. Я уже молчу про легальную сторону такого действия. Ну и в довесок мы еще получим х2 требования к размеру оперативки, но это уже ладно.
ilriv
09.08.2023 13:24Ну по вопросу установки макос на виртуальную машину мне нечего сказать, не пробовал.
DreamingKitten
09.08.2023 13:24Я в курсе. Но товарищ выше по треду хочет, чтобы и IDE запускалась на целевой платформе, без этого он разработку под неё кросплатформенной не признаёт :)
Einherjar
09.08.2023 13:24+1Для отладки приложений Delphi IDE подключается к приложению по TCP.
Поэтому для Delphi нет разницы между отладкой приложения локально или
удаленно. Всё и так работает, незачем что-то придумывать.Для delphi может и нет, для разработчика - есть. Вы непонятно зачем защищаете какие то убогие костыли. А если я вообще только под macos хочу приложение написать, нафиг мне комп с виндой для этого?
Areso
09.08.2023 13:24А если я вообще только под macos хочу приложение написать, нафиг мне комп с виндой для этого?
Мне кажется, или ответ очевиден, что XCode/Swift ваши лучшие друзья в таком случае.
ilriv
09.08.2023 13:24А если я вообще только под macos хочу приложение написать, нафиг мне комп с виндой для этого?
Запустите под Wine, в чём проблема...
Einherjar
09.08.2023 13:24+1Запустите под Wine, в чём проблема...
Костыль на костыле и костылем погоняет, особенно прекрасно это будет работать на arm64 процессоре. Вот потому этот язык и почти мертв.
ilriv
09.08.2023 13:24Нет никаких костылей.
Я вам расскажу как делал сам (правда, не под Macos, а под Android).
Я написал приложение под WIndows, отладил его под Windows. Затем перекомпилировал под Android, перенёс приложение на смартфон и запустил там.
Отладкой под Android я вообще не занимался т.к. ошибок не было. Вся отладка шла под Windows. Это было легко и приятно.
Поэтому мне трудно понять, зачем мы вообще спорим и о каких "проблемах" разработки на Delphi вы рассказываете мне.
У меня на ноуте десктопное приложение на Delphi, на стационарном компе DLL-ки написанные на Delphi, которые коннектятся к приложению через сокеты по локальной сети, еще есть Android-приложение написанное на Delphi. Проблем с разработкой и отладкой не возникало. IDE и приложения очень экономичны в плане потребления памяти, всё компилируется быстро и легко.
Source
09.08.2023 13:24+2Вы как-то странно себе кроссплатформенную разработку представляете. По-вашему, на Java или Go каком-нибудь тоже надо 3 разных компа, чтобы скомпилировать программу под разные операционки?
Есть такая штука как кросс-компиляция, благодаря которой вы просто компилируете программу под разные ОС, независимо от ОС разработчика. А что-то там супер-пупер платформоспецифичное отлаживать нужно крайне-крайне редко. Это явно не часть повседневной работы.
Siemargl
09.08.2023 13:24кросскомпиляция и кросс-ИДЕ разные вещи
Source
09.08.2023 13:24Ну так о том и речь, что кросс-IDE особо и не нужны. Вон под .NET так же пишут все спокойно в Visual Studio под виндой, а запускают хоть на линуксе, хоть на макоси.
Свои нюансы при кроссплатформенной разработке безусловно есть, но это не то, что можно решить переносом IDE под другие ОС.
Einherjar
09.08.2023 13:24+1А что-то там супер-пупер платформоспецифичное отлаживать нужно крайне-крайне редко. Это явно не часть повседневной работы.
Кроссплатформенную разработку я себе представляю именно так как она есть, потому что я ей и занимаюсь. Супер-пупер платформоспецифичные задачи каждую неделю есть.
Вон под .NET так же пишут все спокойно в Visual Studio под виндой, а запускают хоть на линуксе, хоть на макоси
Вашими бы устами да мед пить. Хотел бы я посмотреть как эти люди будут писать, ну например код для извлечения иконок для типов файлов, в Visual Studio под виндой чтобы запустить на макоси.
0xd34df00d
09.08.2023 13:24+2Про дотнет не знаю, а в плюсах и кутях это просто
QMimeDatabase+QMimeType.
Source
09.08.2023 13:24Согласен. Если по расширению файла надо иконку найти, то это вообще от ОС не зависит. Но, честно говоря, непонятно для какой десктопной приложухи это вообще надо. Разве что для альтернативного файлового менеджера или FTP-клиента. А так большинство приложух просто системный диалог для выбора файлов используют.
Kanut
09.08.2023 13:24+1Я так понимаю человек хочет чтобы в его приложении автоматом использовались системные иконки для типов файлов. Причём "динамические".
Ну то есть грубо говоря вот вы привязали pdf'ки к условному Foxit и у всех pdf'ок поменялись иконки. И теперь нужно чтобы если приложение запускается на вашем компе, то в нём у pdf'ок были такие же иконки от Foxit .
ryo_oh_ki
09.08.2023 13:24+13BASIC жив и, наверное, это самый распространённый язык на компьютерах, ведь он есть во всех версиях Windows в виде VBS-скриптов, и во всех офисных пакетах в виде VBA, причём, как справедливо указано, не только от Microsoft. Не говоря уже о том, что Microsoft охотно лицензировала VBA в любые другие программы, например, он присутствует во многих SCADA-системах, и только в последнее время C# стал альтернативой в этой области.
IvanSTV
09.08.2023 13:24+6вот поддержу. Чем больше я имею дело с офисной автоматизацией, тем более убеждаюсь, что VBA практически невозможно убить. Разработка паршивого макроса для компании сторонним подрядчиком - это дело весьма дорогое в принципе, а чем менее распространенный язык (я говорю про кадавров мойофис, р7) и чем меньше информации и специалистов по разработке в нем, тем дороже. Когда один подрядчик за макрос на JS ( который я впоследствии написал за неделю, и то это вышло долго потому, что в JS на тот момент ни в зуб ногой, и долго изгалялся над весьма банальными вещами) насчитал сумму с большими нулями, я понял, что так они мелкософты не обскачут.... С такими расценками на весьма банальные вещи компании, которая ценит деньги, гораздо проще и дешевле держать если не купленные в обход, то даже ломанные офисы (и даже самостоятельно их ломать). Есть разница, когда у тебя сами сотрудники пишут макросы по своему разумению в процессе работы или ты за каждую строчку отслюниваешь и еще надо держать человека, который бы управлял этими проектами. Потому низкий порог входа, распространенность и массовость для VBA - это огромнейшее конкурентное преимущество мелкософтов, и если они кинутся от него резко отказываться, то реально выстрелят себе в ногу, и эта рана будет заживать лет 5-10.
Я на днях открыл хедхантер и написал резюме на VBA-разработчика (верней, это было старое резюме, просто обновил информацию за последние 2-3 года и оставил висеть). Блин, сегодня залез по совсем другом поводу, и вижу - его смотрят, однако, даже при том, что в статусе написано, что уже работаю, и зарплату поставил повыше рынка.
kekoz
09.08.2023 13:24+5Только этот BASIC, который VB/VBA, никакого отношения к тому BASIC, что в статье (Dartmuth BASIC) не имеет. На слове BASIC в названии всё сходство и заканчивается.
ryo_oh_ki
09.08.2023 13:24+3Синтаксис похожий, ключевые слова идентичны... ???? Кстати, автор статьи с вами не согласен, он считает, что Visual Basic является продолжением Basic-ов из 80-х годов (на самом деле их десятки разных), и "проиграл JavaScript" , что очень странно, т.к. они из очень разных "весовых категорий" (VB вообще компилируемый).
commanderxo
09.08.2023 13:24+3проиграл 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>
kekoz
09.08.2023 13:24+2Ну, сходств в синтаксисе и ключевых словах у императивных языков — хоть отбавляй. Только это же не повод говорить, что 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;
Пример программы на Dartmuth BASIC Много тут сходства с VB?
let,ifиprint— они и в Rustlet,ifиprint, но Rust что-то никто не торопится называть BASIC'ом :)
commanderxo
09.08.2023 13:24+4Ещё живы устройства где классический BASIC - основной язык программирования
impwx
09.08.2023 13:24+3"Живость" языка определяется в бОльшей степени тем, сколько на нем начинают новых проектов, а не сколько копий интерпретатора установлено.
Zenitchik
09.08.2023 13:24А как быть, если язык в принципе предназначен для мелкой автоматизации рабочего места, а не для разработки приложений?
PereslavlFoto
09.08.2023 13:24+3Всё в порядке. Живость языка VB определяется тем, сколько на нём начинают новых функций и процедур в MS Office, то есть он живее всех языков программирования.
klopp_spb
09.08.2023 13:24-5Это противоречит всей сути понятия «значимость в истории».
Как давно вы перестали пить коньяк по утрам?
DreamingKitten
09.08.2023 13:24К.м.к, Pascal пал жертвой как собственного мифа, так и низкого порога вхождения. Когда в индустрию ринулись тысячи мартышек, умеющих только набрасывать кнопочки на формы, виноватым в этом почему-то сделали доступный язык и средства разработки на нём.
А сегодня даже среди тех, кто знает, что такое Delphi, мало кто слышал о FreePascal и его возможностях. А те, кто не знает, судят о нём по TP7 для DOS.
zergon321
09.08.2023 13:24Да тупо набрасывать формочки не один только Pascal позволял. Как минимум ещё C#. Он, как по мне, даже проще Pascal'я
victor_1212
09.08.2023 13:24> Pascal пал жертвой как собственного мифа
какого именно? скорее C++ его вытеснил, хотя и не сразу
GBR-613
09.08.2023 13:24+2Pascal/Delphi стали жертвами MFC. Поскольку это был оригинальный Микрософтовский продукт, все были уверены, что для работы с Windows он надёжней. А он был на С++.
0serg
09.08.2023 13:24Паскаль было сложнее интегрировать с любыми конструкциями не входящими изначально в язык, код написанный на C/C++ легче интегрировался с операционкой и библиотеками тоже написанными на C/C++
LAutour
09.08.2023 13:24Зато в Delphi в отличии от C/C++ для статичской линковки сторонней DLL не нужно генерить lib файл библиотеки . Хватает описания экспорта.
0xd34df00d
09.08.2023 13:24+2Это вопрос платформы, а не языка. Мне под линуксом для «C/C++» тоже никакие lib-файлы не надо генерить.
DreamingKitten
09.08.2023 13:24Это только потому, что они уже за вас кем-то ранее сгенерированы и установлены в вашу систему туда, где об этом знает ваш линкер.
Без этого попытка собрать что-то со -static обречена на фиаско.
DreamingKitten
09.08.2023 13:24+2То, что вы описываете это динамическая линковка.
Статической линковки внешних библиотек, не написанных на самой Delphi, в ней нет вообще.
ilriv
09.08.2023 13:24В Delphi есть статическая линковка внешних библиотек (в т.ч. написанных на других языках), она делается через .rc-файл (где перечисляются линкуемые ресурсы: dll, jpeg, wav и т.д.). Таким образом DLL-ки включаются в исполняемый файл.
DreamingKitten
09.08.2023 13:24Нет, и это тоже не статическая линковка, а просто подключение бинарных ресурсов. Так, конечно, можно делать, но этому сопутствует геморой по извлечению библиотеки как ресурса в файл с последующей подгрузкой его через LoadLibrary() и так далее.
Настоящая статическая линковка это когда линкер подключает объектный код нужной библиотеки (не машинный исполняемый) из специального библиотечного файла (не dll/exe/so) и это делается перед тем как начать генерацию машинного кода в бинарнике. Таким образом и имена импортируемых функций можно срезолвить для использования прямо в загруженном образе бинарника, и при этом не заниматься подгрузкой внешних файлов. Много чего в embedded так делается по понятным причинам.
Вы бы это, извините на добром слове, матчасть подтянули, а?
https://www.baeldung.com/cs/static-dynamic-linking-differences
geher
09.08.2023 13:24На самом деле ограниченный механизм статического связывания имеется.
Нужно в коде использовать директиву
{$LINK filename}
Но, если я правильно помню, есть проблема, заключающаяся в том, что использовать можно только файлы obj, а не lib. Впрочем, проблема решалась пронрамкой, превращающей lib в один или несколько obj.
Также раньше была проблема использования Борландом другого формата obj файлов. И была програмка, эти форматы преобразующая. Сейчас вроде obj от того же MSVC вполне можно использовать без преобразования.
ilriv
09.08.2023 13:24Вы бы это, извините на добром слове, матчасть подтянули, а?
Библиотека извлекается в память.
Командой
bcc32c -c filename.c -o filename.objгенерируете объектный файл и затем подключаете его директивой
{$L 'filename.obj'}DreamingKitten
09.08.2023 13:24Вот теперь правильно.
ilriv
09.08.2023 13:24То есть было неправильно говорить что статическая линковка невозможна?
А это - статическая линковка?
function DllGetDataSnapClassObject(const [REF] CLSID, [REF] IID: TGUID; var Obj): HResult; cdecl; external 'libmidas.a' dependency 'stdc++';Статическая линковка в Delphi нужна только чтобы импортировать объекты из сторонних библиотек, если у них нет COM-интерфейса. Но для этого проще написать "обертку" в C++, это тупая механическая работа. То есть нет смысла со всем этим заморачиваться.
fillrate
09.08.2023 13:24Питон проще дельфи/паскаля, на нем сейчас начинают детей учить основам программирования. И на сегодняшний момент это один из самых популярных языков программирования в мире ;-)
ilriv
09.08.2023 13:24+2Пусть ребенок попробует без бутылки разобраться что это за неведомое нечто и почему оно такое жуткое:
class Person: def __init__(self, name, age): self.name = name self.age = agetxt = "Hello World"[::-1]x = lambda a: a + 10vadimr
09.08.2023 13:24Да вроде тут всё весьма понятно. Есть мутные места в Питоне, но не это.
ООП само по себе многословно и содержит много лишнего, но это сейчас модная парадигма. А второй и третий примеры прямо-таки лаконичны и классичны.
Скорее в Паскале могло бы вызвать удивление, почему объявление функции отличается от присваивания. Ну дети так глубоко не задумываются, конечно, но тем не менее.
ilriv
09.08.2023 13:24А второй и третий примеры прямо-таки лаконичны и классичны
Абсолютно контринтуитивно, нелогично и не так как на других языках.
Лучше уж учиться программированию на javascript чем на питоне.
vadimr
09.08.2023 13:24Первое – абсолютная калька с Фортрана, второе – приблизительная калька с Лиспа. Два каноничных языка-прародителя. Мне лично оба примера кажутся вполне интуитивно понятными. Не всё ж в Cи-стиле барахтаться.
ilriv
09.08.2023 13:24Детям не всё равно, с какого языка это калька?
Никакая интуиция не поможет понять смысл этих примеров.
vadimr
09.08.2023 13:24Чего не понять-то? Первое - перебор массива в обратном (отрицательном) порядке, второе - присваивание. Присваивается лямбда-выражение, то есть тело функции. Надо объяснить детям, что лямбда - это формализм для функциональной записи, но это и так культурному человеку необходимо знать.
Уж проще понять, чем отличие трёх видов скобок.
fillrate
09.08.2023 13:24-1а давайте что б детям еще веселее было, заставим их в блокноте без подсветки синтаксиса все смотреть. а в качестве первого урока сразу ооп пойдет и через неделю что б обязательно продакшн код компилили. раньше же вот когда паскаль был, то все дети обязательно вставки на асме учили. чем ж питон хуже, давайте и в нем найдем дикую дичь - пусть мучаются! На питоне ж без лямбы писать невозможно. и тем более без ооп....
DreamingKitten
09.08.2023 13:24Популярен он потому, что на нём можно быстро что-то запрототипировать. И то что он интерпретируемый, делает ему определённую нишу в скриптинге. Но за пределами этого, где ведётся разработка чего-то толстого и сложного -- уже всё, это не для питона.
И ещё мне сложно назвать более простым язык, у которого отступы имеют синтаксическое значение.
jobless
09.08.2023 13:24+2Basic в недрах https://en.wikipedia.org/wiki/Dartmouth_Time_Sharing_System это само совершенство. Это совсем не интерпретатор! Это по сути многопользовательская IDE работающая на одной машине для сопровождения исходного кода и передающая его на компиляцию и выполнение на другую более мощную. Всё это ещё и территориально могло быть разнесено на приличное расстояние.
ИМХО появление персонального компьютера вызвало откат технологий в программировании на четверть века. Я уже не раз тут писал, что при появлении "новых" статей на тему асинхронности и многозадачности часто с улыбкой вспоминаю, как меня "фигурально" били в курилке за асинхронную и многозадачную работу с двумя лентами на ЕС-1045 в разгар рабочего дня. Я тем самым наглым поведением забирал себе столько ресурсов сколько мог. И было это в середине 80хх и использовался ПЛ/1.
victor_1212
09.08.2023 13:24> ИМХО появление персонального компьютера вызвало откат технологий в программировании на четверть века.
скорее freeze, но т.к. масса мало грамотных людей начала программировать, средний уровень качества конечно понизился, также DTSS вполне заслуживает отдельной статьи
PereslavlFoto
09.08.2023 13:24Причина не в появлении ПК.
Причина в том, что нужен программист, который (1) не занимает отдельной ставки, (2) не требует отдельной зарплаты, (3) работает очень быстро, (4) решает конкретные разовые задачи.
А программист, который сидит на отдельной ставке и медленно, разумно работает, чтобы решать задачи в общем случае — это будет слишком дорого. Для него же ещё и компьютер покупать надо.
denis-19
09.08.2023 13:24+3В этом году языку COBOL исполнилось 64 года, и он остаётся одним из старейших из активно применяемых языков программирования, а также одним из лидеров по объёму написанного кода.
olku
09.08.2023 13:24Так пишет IBM, которая сама и похоронила COBOL, заперев компилятор в мейнфреймах. Статистически объем кода может быть огромным, если умножить число старых банкоматов на число строк кода их приложений. Добавлю, что OpenMainframe Project, начатый с пандемией, закончился каталогом в пару тысяч невостребованных вакансий. Open не совместима с жадностью.
Кстати, COBOL реализует десятичную математику и декларативную валидацию полей записи из коробки. Это все его киллер-фичи. Развитие компиляторов остановилось лет 30 назад. Самая популярная спека - COBOL85.
vadimr
09.08.2023 13:24+1IBM с самого начала не любила Кобол. Язык PL/I был придуман в IBM в числе основных задач для замены Кобол (1966 год).
Кобол продвигало американское государство в лице Пентагона, а дальше к нему оказались привязаны финансовые организации, где он распространялся вирусным путём.
Dynasaur
09.08.2023 13:24+1Где он, этот кобол? Кто на нём что пишет? Где этот объём написанного кода? На оставшихся музейных экспонатах, которые ещё не успели списать? Учитывая количество питонистов сегодня и число коболистов в период расцвета Кобола, думаю, сейчас за месяц на питоне пишется больше, чем всё, что написано на Коболе.
Это не подколка, мне правда любопытно. За 30 лет своей карьеры в ИТ я никакого кобола на горизонте не видел, но периодически слышу, что Кобол невероятно востребован.
K_Chicago
09.08.2023 13:24+4как я понимаю, на Cobol в капиталистических странах написано очень большое количество кода для обслуживания коммерческих транзакций, и в государственных структурах - в области налоговой, пенсионного, медицинских счетов и пр. В СССР и далее в России это по-моему не применялось поэтому вы никакого кобола нигде и видеть не могли, если вы в России.
Dynasaur
09.08.2023 13:24+2Видите ли, я работал и работаю в крупнейших мировых компаниях из Fortune 500, в штатовских в том числе. Мало того, я даже в IBM работал. Которая этот самый Кобол на этих самых мейнфреймах вроде как продаёт. Так что встретить его я бы теоретически мог. Но не встретил. Я, конечно, знаю, что Кобол в природе есть. Но говорить о том, что он какой-то лидер - это из области городских легенд.
K_Chicago
09.08.2023 13:24+4хм, а в банках вам работать доводилось? Скажем, в BofA, Chase, 5/3rd, U.S.bank? Я подозреваю, там-то и вся мякотка. Или, скажем, в IRS? А то что IBM продает Cobol - ну ведь они же у себя-то его держать не обязаны, или вы хотите сказать что вы работали в IBM Sales Department и ни разу не видели чтобы они Cobol продавали? Вполне может быть, я не думаю что сейчас много новых кастомеров кобол покупают...
Dynasaur
09.08.2023 13:24+1Ну так и я о том. Есть узкая ниша, в которой он, конечно есть. Я ж не говорю, что его нет. Я говорю о том, что ниша узкая.
artemisia_borealis
09.08.2023 13:24Вроде пытались применять.
Во всяком случае есть книжка "КОБОЛ ЭВМ Минск-32", однако встретить (или вспомнить) Минск-32 сложнее, вероятно, чем Кобол где-то ещё.
GBR-613
09.08.2023 13:24+2В мире мейнфремов он цветёт и пахнет.
Просто это отдельный, довольно изолированный мир. То, что Вы его не видите - это как то, что я никогда не видел живого мангуста, живого бурундука.
Dynasaur
09.08.2023 13:24+3В мире мейнфреймов. Это сразу ограничивает ареал этого кобола до очень узкой области. Сколько программистов что-то пишут на мейнфреймах по сравнению со всей остальной массой программистов? Это не мир, а мирок. Кто его изучает? Где? Когда выходили последние обновления? Сколько сейчас в природе коболистов? Судя по всему, это ничтожная доля.
K_Chicago
09.08.2023 13:24мейнфремы это "мирок"??
Ну да, ну да. Если считать по головам, то точно так и есть. Или вот скажем, какие-нибудь занюханые Ротшильды, или Барухи, или там Рокфеллеры - да сколько их всего-то? И полусотни голов на круг не наберется, ничтожная кучка жалких людишек, никакого значения они иметь не могут.
Dynasaur
09.08.2023 13:24+2То есть вы хотите сказать, что коболисты по сравнению с остальными программистами это как Рокфеллеры по сравнению с какими-то туземцами. Ну так, не буду комментировать.
Kanut
09.08.2023 13:24Я бы скорее привёл аналогию с гужевым транспортом. Он ведь тоже не исчез в мире. И даже в развитых странах всё ещё имеет свою нишу. И те кто с ним связан вполне себе зарабатывают неплохие деньги.
GBR-613
09.08.2023 13:24+1Мейнфрем это нечто такое, с чем если связались, то очень трудно потом от него избавиться. Да и не хотят особо, потому что есть вещи, для которых лучше него ничего до сих пор не придумали, при сопоставимой стоимости. Сколько лет ему скорую смерть предрекают, а он живёт назло врагам.
И, кстати, у меня есть несколько знакомых, которые работают на Cobole. Может, мне просто повезло. И они говорят, что Cobol, при всех своих недостатках, очень хорош для той специфической области, в которой он используется.
funca
09.08.2023 13:24+3Вы не понимаете (с). Мейнфреймы это специальный вендурлокнутый мирок от IBM. Он такой не потому, что они тупые. Ребята почти полвека тому назад придумали бизнес, где можно десятками лет сидеть на контрактах по всей вертикали: начиная с железа и обучения специалистов, до рынка инструментов разработки, софта и консалтинга - с которых невозможно слезть. Что-то похожее сотворила Apple со своими iPhone для масмаркета - специфичным железом, языками, инструментами, системой распространения программ и оплаты, и т.п. - но у этих хотя бы не нужно проходить дорогущие обучения и сертификции, где специалистов готовят почти как космонавтов.
vadimr
09.08.2023 13:24+1Сразу после распада СССР я работал во внешнеторговой организации, где половина автоматизации делалась на Коболе для совместимости с зарубежными системами.
Я там работал в другой половине автоматизации (MS-DOS, Паскаль+SQL) и особенно в коболовский вопрос не погружался, но у меня осталось впечатление, что они при этом писали на немецком диалекте Кобола, так как машины у них были немецкие. По тем временам многие из старшего поколения изучали немецкий язык в школе, и это выглядело не так чудовищно, как звучит сейчас.
0xd34df00d
09.08.2023 13:24+4Довольно иронично, но за последние полгода я общался с двумя командами хаскелистов, которые переписывали (или собирались переписывать) неподдерживаемое легаси-кобольство. В одном случае они это уже успешно и продуктивно делают несколько лет (вместе с развитием и добавлением фич), в другом — там с коболом настолько всё плохо, что собирались использовать всякие средства статического анализа, формальных доказательств и прочего, чтобы просто понять, что делает написанное легаси.
AnthonyMikh
09.08.2023 13:24+1Хотелось бы больше деталей. Или там NDA?
0xd34df00d
09.08.2023 13:24+1В первом случае — ну, чуваки из местного рителейра с едой вполне успешно что-то там делают. Кстати, удивительно, сколько людей оттуда я, оказывается, знал и раньше по всяким там IRC, и они делают довольно прикольные вещи.
Во втором — ну там никто не знал даже, какой код вообще используется, а какой — лежит мёртвым грузом, и что на входе, а что — на выходе, поэтому были мысли присобачить всякое там символьное выполнение с выводом типов, чтобы понять, что вообще происходит, но возникли некоторые трудности организационного характера. У людей с коболом были деньги, условно, на год работы команды из трёх человек, а люди с формальными методами оценили работу в три года команды из пяти человек.
olku
09.08.2023 13:24+3Именно. Восстановление утраченной бизнес логики - это то, что сейчас актуально на рынке труда для тех стека. Джуны и амбассадоры не нужны, проверено на 20 компаниях.
funca
09.08.2023 13:24+2Концептуально COBOL это что-то среднее между языком в 1С, Gherkin из мира TDD и shell скриптами.
COBOL разрабатывали как язык-клей для бизнес применений, поэтому программа больше напоминает литературный английский, нежели лаконичную математику как в хаскелях. Отсюда многословность и безумное количество длиннющих ключевых слов. Например наряду с "x > y" можно писать "x IS GREATER THAN y". Но зато если придерживаться определенной дисциплины, то можно писать код, который будет понятен не только программистам, но и тем кто хорошо разбирается в бизнесе домене. Это актуально например для банковской сферы, где сложность идёт не столько из алгоритмов, сколько из законодательства и специфики предметной области. Из плюшек - поддержка SQL (как first-class citizen), работы со структурированными данными, вызовы нативного кода и т.п.
Поэтому идея переписывания на хаскель выглядит неожиданной. Ну может быть там была какая-то специфика и на коболе накодили что-то из теорката.
0xd34df00d
09.08.2023 13:24+1Хаскель как язык для лаконичной математики — это несколько миф. Он просто лаконичный язык с неплохой системой типов, о коде на котором можно неплохо рассуждать без обкладывания его тоннами тестов (что довольно полезно для всяких там бизнес-приложений, где даже простои — убытки). Нет никаких проблем с тем, чтобы писать хоть даже микросервисы по перекладыванию жсонов на хаскеле без всякого теорката, и нет никаких причин их не писать на хаскеле.
funca
09.08.2023 13:24+1Нет никаких проблем с тем, чтобы писать хоть даже микросервисы по перекладыванию жсонов на хаскеле
Проблема не в этом. Мейнфрейм это по сути общая унифицированная среда исполнения, где вместе крутятся и программы, и базы данных, и все остальное. Смотрите, когда программа на коболе говорит: дорогой DB2, дай мне данных из той вон таблицы, то в ответ получает практически кусок адресного пространства, где эти самые данные лежат. Все происходит за микросекунды, не зависимо от объема. Представляете? Вот это 1С-подобное поделие, может ворочать террабайтами данных, и тысячами транзакций, вообще не напрягаясь. Все потому, что ему не нужно приседаний с сервисами, микросервисами, сетями, энкрипшеном, драйверами, файлами и файловыми системами, сокетами, джейсонами, приведением типов, маппингом данных, конфигурациями и тому подобной ерундой. Все же находится локально, в одном понятном физическом месте, всегда доступно, везде однотипно, унифицировано и сертифицировано.
Попытки переписать с кобола, на языки общего назначения, а особенно те, которые всю историю развивались на писишках с абсолютно другими вводными и ограничениями, сразу упираются в то, что размер и сложность кода растут на порядки. Хаскель или джава - принципиальной роли не играет. Переписывать приходится не только инфраструктурный код, но и логику приложений, поскольку ограниченность ресурсов и распределенность принципиально меняют правила игры. Ну то есть автоматическая трансляция с одного на другое в общем случае это фантастика. При этом жизненный цикл такого кода начинает измеряться считанными годами (вот прямо в штуках), когда потом чисто экологически ломается обратная совместимость, - а не десятилетиями как на мейнфреймах.
0xd34df00d
09.08.2023 13:24+1дай мне данных из той вон таблицы, то в ответ получает практически кусок адресного пространства, где эти самые данные лежат. Все происходит за микросекунды, не зависимо от объема.
Это всё очень круто, пока данные не начинают модифицироваться кем-то ещё, или пока кто-то не решает работать с этим куском АП как, собственно, с памятью, начитавшись hacker's delight и ковыряя отдельные байтики и битики (точно так же, как с другой стороны баррикад начитавшиеся Мартина и GoF начинают развешивать гроздья ненужных абстракций).
На современном железе нет никаких проблем обрабатывать тысячи транзакций в секунду, даже копируя данные в драйвере БД. А вот проблемы с тем, чтобы понимать, что там наворотил предыдущий кобол-ковбой — есть, и эти проблемы от железа не зависят, потому что ограничены нашей черепной коробкой, увы. Поэтому сегодня (а не в 70-х) люди как-то на всех уровнях предпочитают решать задачи, возможно, даже чуть менее оптимально в теории, если это им даст возможность быстрее вносить изменения и больше думать о смысле кода и о, так сказать, сложности самой задачи, а не её реализации на конкретной технологии.
И поэтому attention span распыляется на ковыряние выдачи БД как сырых данных в памяти вместо того, чтобы подумать над алгоритмической сложностью. И именно поэтому в соседнем треде один мейнфрейм-программист на RPG долго и красиво рассказывал, как он там избегает STL и хеши перехеширует, чтобы потом очень быстро сравнивать попарно элементы множеств из миллионов и сотен тысяч элементов, а когда у него спрашиваешь — нафига попарно, когда можно отсортировать и сделать бинарный поиск на порядки быстрее (ну это если есть ресурсы на подумать после ковыряния мейнфреймов), он ничего не отвечает и куда-то пропадает.
funca
09.08.2023 13:24+1пока данные не начинают модифицироваться кем-то ещё, или пока кто-то не решает работать с этим куском АП как, собственно, с памятью,
Кто ж ему разрешит? Я говорил про отсутствие лишних абстракций, а не разграничения доступа.
вот проблемы с тем, чтобы понимать, что там наворотил предыдущий кобол-ковбой — есть, и эти проблемы от железа не зависят, потому что ограничены нашей черепной коробкой, увы.
Где гарантии, что хаскель-мэны не нагородят ещё хуже? Тем более раз речь зашла об автоматической генерации кода. Если цель уйти в микросервисы, то они наверняка ее достигнут. Но что будут делать с таким кодом люди, которые придут лет через пять? А десять? Ну понятно, что - переписывать. Если разберутся конечно в том, что нагородил кодогенератор по мотивам произведений тех доисторических ковбоев.
PereslavlFoto
09.08.2023 13:24+1А вот скажите, язык AWK, он уже мёртв или ещё нет?
Например, я вот на нём пишу.
flygrounder
09.08.2023 13:24+2Его интерпретатор есть почти в любом Linux дистрибутиве - пациент скорее жив, чем мёртв)
safari2012
09.08.2023 13:24+7Попробую накинуть свои пять копеек на вентилятор. Про 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 наверное в разы больше. Но синтаксис эклектичен, это да.
PereslavlFoto
09.08.2023 13:24хз что там изучать было два года
Видите ли, товарищ, распечатка мелом на доске идёт очень медленно. Даже объяснение простой процедуры требует сначала вывести её мелом на доску, потом отладить её тряпкой и мелом, а только потом компилировать, записывая значения переменных в окне отладки на второй доске.
Безмашинное программирование — штука медленная!safari2012
09.08.2023 13:24я вспомнил, на том курсе был еще ассемблер (IBM 360) и даже машинные коды. в том смысле, что надо было уметь компилировать на бумажке ассемблер в машинные коды (не сложно, на самом деле).
FakeOctopus
09.08.2023 13:24+3Forth ещё был популярен.
n0isy
09.08.2023 13:24+1Только совсем уж в слабых железках и в виде обучения. Покажите какой-то софт, реально написанный на Форте.
Всем 2 2 + .
))
forthuse
09.08.2023 13:24+3Банально nncron, eserv
OpenBios (был/есть и в ПК OLPC)
ForthCAD
…
XFmap
…
Forth Application (на сайте Forth. Inc)P.S. Просто Форт (Forth) по слухам был популярен некоторе время в начале/сeредине 80-х годов на Западе, а в СССР в период его распада отметился изданием некоторого количества книг, в том числе и оригинальны от рускоязычных авторов. :)
Язык Форт в СССР и РоссииСейчас, конечно, Форт чаще всего можно встретить в нише разработки встраиваемых систем, хотя для него создано много интересных и самих Форт систем.
Для написания каких программ лучше всего подходит Forth (Форт) язык?
AlexeyK77
09.08.2023 13:24+1насколько я знаю. то форт очень популярен на всякого рода контроллерах/встройках с очень маленьким ресурсом. В 1-2кб можно запихнуть большой объем логики работы контроллера. Но это тема не моя, только слышал.
forthuse
09.08.2023 13:24Да, его ещё вычислительную архитектуру аппаратно реализуют и в рамках FPGA.
P.S. Для интересующихся Форт есть
и русскоязычный действующий форум по нему
и Телеграм канал
Dimsml
09.08.2023 13:24+2Насколько я помню, Starflight, предок Star Control, на Forth написан.
forthuse
09.08.2023 13:24+2Да, на Форт (86, 89 год первой и второй игры) в сети сохранились и некоторые её исходники.
Проект Starflight-Reverse по реверсу бинарного кода игры в Си вариант (с использованием и SDL) для компиляции Си компилятором и запуска под Linux, Windows.
avost
09.08.2023 13:24Странные взаимоисключающие утверждения содержит статья. Про кобол:
Сегодня мы считаем его заурядным, но когда-то он был самым популярным языком в мире.
И одновременно:
На COBOL разрабатывали очень немногие.
Про алгол тоже странное:
В спецификации не было указано ни одного инструмента для ввода-вывода, из-за чего, по сути, его невозможно использовать в реальности.
Ну, полная ерунда. Ввод-вывод практически во всех тогдашних языках, да и современных тоже, используют функции ввода-вывода. Точно так же и в алголе эти функции были. Стандарта на них не было, а функции были. И алгол прекрасно использовался на практике.
Мы называем C «подобным ALGOL»,
Это тоже странно. Си по синтаксису был антогонистом алголу. Языки-последователи были либо си-подобными, либо алголо-подобными (позже названные паскале-подобными).
Ну, и сам паскаль был упрошённой синтаксически (и немного семантически) версией алгола-60 (а, про это и написано, да).vadimr
09.08.2023 13:24Процедуры ввода-вывода были не в Алголе, а в библиотеках программ в конкретных реализациях. Концептуально точно также как, например, функция рисования окна не является частью языка Си, но количественно гораздо хуже, так как тогда несовместимых операционных окружений были сотни (до появления System/360 – вообще буквально на каждой машине своё) и никаких кроссплатформенных библиотек не было. В то же время Кобол и Фортран имели жёстко стандартизированный ввод-вывод, что было крайне важно для практического написания программ в то время, так как по описанной причине требовалась кроссплатформенность.
Синтаксис и семантика языка Си в наиболее фундаментальном смысле происходят от Алгола: описание переменных, статическая типизация, составные операторы с блочной структурой, передача параметров по значению и ряд других моментов, воспринимающихся сейчас, как само собой разумеющееся. Если сравнивать с четвёркой первоязыков Фортран_I – Лисп – Кобол – Алгол-60, то большинство современных языков алголоподобны. И даже современный Фортран в ряде аспектов более подобен Алголу-60, чем Фортрану_I.
Ну и Паскаль от Си семантически почти не отличается, это вообще языки-близнецы, хотя у них разные лексические элементы и, как следствие, визуально разный синтаксис. Именно поэтому они долгое время конкурировали между собой.
avost
09.08.2023 13:24Процедуры ввода-вывода были не в Алголе, а в библиотеках программ в конкретных реализациях
Сейчас бы сказали - в рантайме.
количественно гораздо хуже, так как тогда несовместимых операционных окружений были сотни
Операционные окружения не имели отношения к названям функций. А названия этих функций зависели не от окружений, а от реализации алгола, а их было вполне считанное количество. Да и в разных реализациях вариантов было не сильно разнообразно. В конце-концов не составляло особого труда обернуть одну функцию в другую.
Если сравнивать с четвёркой первоязыков Фортран_I – Лисп – Кобол – Алгол-60, то большинство современных языков алголоподобны
Ну, среди именно этой четвёрки, таки да :).
Ну и Паскаль от Си семантически почти не отличается, это вообще языки-близнецы, хотя у них разные лексические элементы и, как следствие, визуально разный синтаксис.
Нуууу! Я бы так не сказал! Как раз семантически они изрядно разные, а вот с синтаксисом мы забавлялись, меняя бинарным редактором в копии компилятора на пидипоидных машинках begin-end'ы на скобочки и получая визуально "почти си" ;)
Я имею в виду виртовский паскаль. В борландовском варианте паскаль к си, конечно, приблизился.vadimr
09.08.2023 13:24В конце-концов не составляло особого труда обернуть одну функцию в другую.
Обернуть составляло труд, так как многие реализации не позволяли в точности управлять форматом ввода-вывода. И могло, как я понимаю, получиться даже так, что данные, выведенные на какие-нибудь перфокарты алголовской программой на одной машине, могли оказаться непригодными к вводу в алголовскую программу на другой машине. Тогда ж не было всяких XML и JSON, и совместимый ввод-вывод тех времён – это точное указание форматов.
Кстати, и исходные тексты программ были несовместимы между реализациями по той же самой причине. Например, в типографской печати в алголовских программах ключевые слова выделялись, по замыслу разработчиков, жирным шрифтом. Что это означало при вводе в компьютер, они не побеспокоились уточнить, потому что вообще-то Алгол разрабатывался как язык формальной записи алгоритмов, а не как язык практического программирования компьютеров. И вот, в частности, в реализации IBM жирные слова ставились в апострофы. А многие другие фирмы так не делали. Поэтому там, где на какой-нибудь условной машине Burroughs в программе набивалось
BEGIN, в IBM надо было писать'BEGIN'. (Не имею понятия, как в компиляторах первого вида отличали при этом ключевые слова от идентификаторов, так как запрета на их совпадение в Алголе нет, а контекстная зависимость не задумывалась).К слову, складывается впечатление, что IBM сделала компилятор Алгола для S/360 "на отвали" специально, чтобы затруднить использование языка. Хотя компилятор входил в стандартный дистрибутив OS/360 и OS/370 десятки лет.
gatoazul
09.08.2023 13:24+1как в компиляторах первого вида отличали при этом ключевые слова от идентификаторов
Извращались лексически, например, писали _BEGIN
avost
09.08.2023 13:24могло, как я понимаю, получиться даже так, что данные, выведенные на какие-нибудь перфокарты алголовской программой на одной машине, могли оказаться непригодными к вводу в алголовскую программу на другой машине.
Я, вот, межмашинный обмен перфокартами не застал (да и вообще застал только ввод программ с перфокарт, вывод был на распечатки, но это НИИ и вузы, не промышленность, там может иначе было). Неужели, такой перфокарточный поток данных был сильно актуален и широко распространён? Ну тут не знаю, системные программеры могли библиотечный формат вывода и подхачить под нужды. Там компиляторы были полусамодельные, вообще не проблема была сделать совместимым.
Кстати, и исходные тексты программ были несовместимы между реализациями по той же самой причине.
при перфокарточном вводе это не составляло большой проблемы, тк колода перфоркарт имела ограниченный срок службы и их всё-равно приходилось перебивать. :)
в реализации IBM жирные слова ставились в апострофы
О, да, это боль :)
там, где на какой-нибудь условной машине Burroughs в программе набивалось BEGIN, в IBM надо было писать 'BEGIN'. (Не имею понятия, как в компиляторах первого вида отличали при этом ключевые слова от идентификаторов, так как запрета на их совпадение в Алголе нет, а контекстная зависимость не задумывалась).
то, что не задумывалась не значит, что не могла быть реализована :).
Хотя компилятор входил в стандартный дистрибутив OS/360 и OS/370 десятки лет.
Не только входил, но и активно использовался. И он и ещё пара десятков реализаций. Значит, не было особых проблем это использовать.
vadimr
09.08.2023 13:24Неужели, такой перфокарточный поток данных был сильно актуален и широко распространён?
Насколько я понимаю, в 1960-х годах основным средством переноса данных с одной машины на другую были перфокарты. Просто не было других совместимых носителей, ну и никаких сетей, естественно, тоже не было.
9-дорожечную магнитную ленту придумали в S/360 в 1966 году, и ещё лет 10 она распространялась, прежде чем стать фактическим стандартом.
Не только входил, но и активно использовался. И он и ещё пара десятков реализаций. Значит, не было особых проблем это использовать.
Я лично не встречал среди программистов OS/370 ни одного человека, который бы им пользовался. Сам я в своей жизни откомпилировал одну программу на Алголе – просто набрал из справочника алгоритмов. Потом переписал на PL/I, потому что уж больно неэстетично выглядели эти листинги с апострофами.
avost
09.08.2023 13:24+1Насколько я понимаю, в 1960-х годах основным средством переноса данных с одной машины на другую были перфокарты. Просто не было других совместимых носителей, ну и никаких сетей, естественно, тоже не было.
Вопрос в переносе данных с машин одной системы на машины другой. Зоопарки несовместимых машин в одном месте - не очень понятная история. А если это передача между организациями, то там проблема в потенциальной несовместимости формата данных на перфокарте - не самая большая проблема :)
Я лично не встречал среди программистов OS/370 ни одного человека, который бы им пользовался.
А у нас таких половина дружественного НИИ была. Вторая половина жила на БЭСМ-6 и использовала паскаль :)
vadimr
09.08.2023 13:24+1До 1990-х годов зоопарки несовместимых машин были обычной историей, практически единственно возможной. А в первой половине 1960-х вообще каждая новая машина была несовместимой с предыдущими.
avost
09.08.2023 13:24и насколько часто требовалось переносить данные на перфокартах с одного типа машины на другую? Я, вот, честно, не застал такой юзкейс и не особо понимаю зачем это могло понадобится. Микросервисы тогда ещё не придумали :)
vadimr
09.08.2023 13:24Микросервисы, конечно, не придумали, но вообще передача результатов одной программы на вход другой – нередкая вещь.
avost
09.08.2023 13:24сейчас нередкая. А в 60-е? А на машину другого типа?
Кажется, и актуальность задачи переоценена и трудность адаптации функции ввода-вывода. Что подтверждается десятилетиями успешной работы с Алголом-60 :)
K_Chicago
09.08.2023 13:24+2"смешались в кучу кони-люди".
наличие в этом странном списке Basic и Pascal это то что в англоязычной среде называется wishful thinking. Примерно "выдавать желаемое за действительное", только сказано проще и яснее.
Разумеется, говоря Pascal мы подразумеваем DELPHI, а говоря Basic - мы подразумеваем VB.
причина "упадка" DELPHI как я понимаю исключительно в области коммерческих войн. "упадок DELPHI" я полагаю это то же самое что "упадок Borland".
VBA как вариант VB вполне себе имеет свою нишу и будет иметь пока злобный микрософт/макрохард не решит его убить. Ну, примерно также как Oracle решил убить Forms&Reports. Причина тут одна - опять же англоязычный термин job security, т.е. стремление сохранить бизнес(работу) любой ценой, в первую очередь - жертвовать полезностью продукта ради непрерывного выпуска новых несовместимых "версий" и поддержания высокого порога вхождения. Никому не нужны курицы несущие золотые яйца, идеальная среда программирования нанесет смертельный ущерб очень серьезным коммерческим империям.
Вообще это однобокий и неверный подход - рассматривать эволюцию языков словно это эволюция научных теорий - объективная, и определяемая лишь критерием истинности. Эволюция програмного обеспечения более чем наполовину (и, возможно, на 90% но это не точно) определяется "битвой бульдогов под ковром", а лучше - "дружным коллективом пауков в банке", - т.е. в области коммерции, конкуренции, картельных соглашений и лоббирования. Тесная связь бизнеса и политики. По-моему, так.
avost
09.08.2023 13:24+1Разумеется, говоря Pascal мы подразумеваем DELPHI, а говоря Basic - мы подразумеваем VB.
Конечно же, нет. Вернее, если рассматривать именно дельфи и вб, то всё как вы сказали, но тут речь именно о паскале и бейсике. У паскаля более долгая история и гораздо бОльшее влияние на индустрию и языки, чем короткая вспышка популярности дельфей.
Вот бейсик, тот, кажется, язык в себе - повлиял только на самого себя в реинкарнации вб и вбс. Дальше никуда не пошёл (и слава тебе господи!) ;)
Зато повлиял на популярность программирования персоналок.Эволюция програмного обеспечения более чем наполовину (и, возможно, на 90% но это не точно) определяется "битвой бульдогов под ковром", а лучше - "дружным коллективом пауков в банке", - т.е. в области коммерции, конкуренции, картельных соглашений и лоббирования. Тесная связь бизнеса и политики. По-моему, так.
Неа. Тогда бы не было феноменов руби, пхп, скалы и, даже питона (да, и пёрла). Ну, и многострадальный паскаль, задуманный как язык для обучения, внезапно стал популярным задооолго до того, как борланд выпустил свои турбокомпиляторы. Собственно, и си тоже хороший пример. Вообще корпоративных языков не так и много. По сравнению с сониищем остальных.
axe_chita
09.08.2023 13:24+4Кстати, Visual Basic был той самой «волшебной палочкой», которая создала массовую экосистему Windows. Ведь благодаря ему, несмотря на все его недостатки, на Windows лавинообразно и быстро появилось огромное программных продуктов, а писать под Windows смогли не только гуру, но и простые смертные.
КМК, именно отсутствие подобного инструмента визуальной разработки на Basic, и привело к стагнации экосистемы OS/2, а потом к её проигрышу в конкурентной борьбе.
B13nerd
09.08.2023 13:24Существовал конкурент MS VB 3.0 от IBM для OS/2 и Windows под названием VisualAge for Basic (кстати, VisualAge for Smaltalk тоже существовал, и даже были попытки его использования в России в банковской сфере именно под OS/2). Так что инструментарий был. Видимо, не в этом дело.
axe_chita
09.08.2023 13:24Ну как существовал конкурент VB… Скажем так, этот конкурент опоздал к моменту битвы OS/2 vs Windows. Первая версия Visual Basic вышла в мае 1991 года, а VisualAge for Basic же вышел в 1997 году, когда Microsoft уже выпустила Visual Basic 5.
Так что инструмент, «немножко» опоздал, на лет пять после выхода OS/2 2.0, и соответственно ни как не мог повлиять на развитие и расширение экосистемы OS/2. Так что проблема с инструментарием массовой разработки была, точнее с его отсутствием инструмента как такового, а тут как говориться «дорога ложка к обеду».
unreal_undead2
09.08.2023 13:24+1IBM скорее свой REXX продвигал, и Visual REXX тоже был - но не помню, было ли там удобное рисование формочек как в VB.
vadimr
09.08.2023 13:24Visual REXX был изделием Watcom. Рисование формочек там, конечно, было, на то он и Visual. Но это не IBM.
Для простых случаев (в том числе и формочек для работы с DB2) Visual REXX был очень удобен.
Mirn
09.08.2023 13:24+4эхх, надеюсь, когда-нибудь вспомнят про аппаратные языки на которых написаны почти все цифровые чипы от процессоров до чипсетов и даже простых цифровых адаптеров интерфейсов типа усб хаба. Я про такие как Verilog и SystemVerilog, VHDL например. Ведь почти всё что юзают ITшники написано на них (сейчас разве что совсем мелочь типа шинного драйвера SN74HC244, или lvlshifter-ы возможно сразу рисуют в схематике). Даже тест бенчи, симуляции и тд написаны на этих языках. Ну и про TCL можно вспомнить.
rvs2016
09.08.2023 13:24+1'>' У BASIC есть еще одно интересное применение:
'>' инструменты Office. В конечном итоге Microsoft
'>' превратила BASIC в Visual Basic, который
'>' использовался как язык макросов Office.
...
'>' Недавно он уступил позиции JavaScript и теперь
'>' считается устаревшим языком написания макросов.А в каком смысле Бейсик уступил позиции JavaScript, если они применяются в разных средах и для разных дел:
Бейсик, о котором тут прошла речь, применяется в среде офиса для написания макросов.
JavaScript применяется в среде браузера для написани скриптов.avost
09.08.2023 13:24Бейсик, о котором тут прошла речь, применяется в среде офиса для написания макросов.
JavaScript применяется в среде браузера для написани скриптов.макросы в офисе уже давно можно писать на жаваскрипте. Понятия не имею насколько широко это распространено в мире, возможно, автор статьи больше владеет информацией.
funca
09.08.2023 13:24Технически можно, но код на JS получается гораздо более многословным и нестыковки с семантикой VB лезут из всех щелей.
deitry
09.08.2023 13:24+1Когда-то и бейсик пытались впихнуть в браузеры, вот чуть выше коммент по теме
https://habr.com/ru/companies/ncloudtech/articles/753562/#comment_25842746
vk6677
09.08.2023 13:24+1Мой коллега программирует ПЛК на языке ST. По синтаксису очень похож на Паскаль. Видимо этот диалект будет ещё долго жить.
Ради интереса посмотрел проект и был крайне удивлен непривычным подходом. Я привык к файлам программы, а их нет. В одном окне код на Паскале, в другом описание переменных в третьем - дерево компонентов. На вопросы как хранится код, какая система контроля версий толкового ответа не получил.
vadimr
09.08.2023 13:24+1Это в семействе IBMовских компиляторов VisualAge такое было. Просто классы во внутреннем представлении в единой базе данных со внутренней системой контроля версий. Причём база могла храниться на многопользовательском сервере. Круто на самом деле.
VisualAge for Java был очень классной средой разработки, но не выстрелил, потому что был заточен под разработку standalone программ, а Java пошла в основном развиваться в сторону веба.
Scaeurgus
09.08.2023 13:24Готов поспорить что он вам ответил следующие: код хранится внутри ПЛК, система контроля версий присутствует в виде сравнения проекта на ПК и коде что был загружен в ПЛК.
MiraclePtr
09.08.2023 13:24+1код хранится внутри ПЛК, система контроля версий присутствует в виде сравнения проекта на ПК и коде что был загружен в ПЛК.
это не система контроля версий, а дно какое-то.
контроль версий - это про возможность diff'ов между любыми разными версиями (а не только двумя), откат на любую из предыдущих промежуточных версий, ветвления, слияния,revert'ы, bisect и т.д.
Ailuropoda_M
09.08.2023 13:24Контроль версий зависит уже от конкретной реализации. У Сименса в TIA Portal вполне себе прикручивается внешняя система контроля версий.
easimonenko
09.08.2023 13:24+1Несправедливо обойдён вниманием язык B. А ведь он не только непосредственный предшественник C (разница между B и C такова: один интерпретатор, другой компилятор, первый безтиповый, второй вместо одного типа данных, машинного слова, предложил чуть больше). Именно из B идёт синтаксис всех так называемых C-подобных языков.
caballero
09.08.2023 13:24Прикольно было бы дожить до подобной статьи где неха первом месте из 10 будет яваскрипт
FanzilAlRawi
09.08.2023 13:24+1Я даже знаю одну контору в Москве, которая сейчас, в 2023 году, пишет и развивает очень специфический софт на PL/1. 15 лет назад еще было на еле дышащих ЕС-1066, потом я ушел оттуда. Сейчас вроде обновились на что-то, но прикладной код поменять - это десятилетия работы. Говорят, оставили как есть.
ss-nopol
09.08.2023 13:24BASIC стал первым языком с интерпретатором в режиме реального времени
Да вы что! А как же lisp?
Gera94
09.08.2023 13:24Я бы не сказал, что BASIC мертв, есть примеры современных проектов, где его используют в локальных целях, например стартап Rumble
bodyawm
Паскаль тяжело назвать мертвым. Он все еще частенько юзается в энтерпрайзе (Delphi) и энтузиасты продолжают на нем пилить всякие штуки
programmerjava
да скорее всего для чего-то нового и серьезного уже практически никогда не будут выбраны эти технологии. легаси не в счет как и старые привычки ) либо я упустил что-то еще
Nichls
Зря Вы так.
Под WIndows быстрее, чем на Delphi, не знаю на чём можно написать ПО для работы с специфическими данными заказчика под Windows XP/7/8/10/11.
Ключевое тут - быстро. А ещё лучше - очень быстро. И про кроссплатформенность речь не идёт, как правило. Главное, чтобы под WIndows работало. С флэшки. Заказчику нет никакого дела до того, на чём программист реализовал его хотелку. И в качестве аргумента "На хххх программировать я учился ххх лет и в связи с этим ПО будет стоить ххх денег" приниматься заказчиком не будет. Тут больше сработает принцип "Посмотреть на дом, как жена одета и дети, на чем приехал и назвать цену "Вам не дорого и мне не дёшево"". Речь правда о небольших заказчиках.
На Delphi (10.3) до сих пор пишу.
PsihXMak
Ещё можно добавить, имхо, Delphi - лучший язык программирования, как первый. В плане синтаксиса достаточно простой и очень приятный, при этом все современные концепции присутствуют.
a-tk
Ещё бы не был он столь многословным - цены б ему не было.
Hlad
То же самое хотел написать: в какой-то момент люди выбирают Си-подобные языки потому, что там есть сокращённый синтаксис, да и в целом меньше букв надо нажимать.
Gapon65
С моей точки зрения, проблема в обратном - в "читабельности" программ программ написанных на Паскале (и его "родственниках"). Современные IDE хорошо помогают с печатанием кода. Код с большим количеством зарезервированных слов наподобие BEGIN ... END нашему мозгу труднее парсить нежели { .. }. Хотя, персонально, моим самый любимый языком является ADA и подобные строго типизированные языки.
ilriv
Мало какой язык может соревноваться в плане читаемости с Паскаль.
{}, int[], Arr[::c] и подобные конструкции вообще не предназначены для человеческого мозга.
Hlad
Тут ситуация, как со стенографией: если не знать, что значат все эти значки, нифига не понятно, но если её освоить, можно писать заметно быстрее.
LAutour
А так же помнить кучу нюанов из-за компромисных решений разработчиков С\С++: например в зависимости от контекста *имя может быть как именем указателя, так и значением под указателем, разнофункциональность слова static и т.д.
ilriv
"Стерпится - слюбится".
Если синтаксис
"SELECT * FROM A LEFT JOIN B"заменить на"# * @ A < ? B", SQL-щики будут довольны?dimykus
С таким утрированием можно в другую сторону пойти и заменить = на EQUALS := на ASSIGN 1 на ONE и т.п.
И будет у нас
if (a LESS then b) then
begin
a ASSIGN b PLUS FOUR TWO OP_END
end OP_END
Стало лучше?
atshaman
Получился примерно COBOL если что :).
Но вообще - если вспомнить какое количество ошибок возникло из-за '=' и '==' в разных языках - то ASSIGN уже не кажется хтоническим злом )))
ilriv
Я не утрирую.
Человеку всегда легче работать с интуитивно понятными вещами. Интуитивно понятно что "=" и "equals" это одно и то же.
Вот у нас есть две крайности: многословный SQL и лаконичный Regex. На чём пишется быстрее и какой код получается более читаемым?
Kanut
Не надо говорить за всех. Мне вот это не было интуитивно понятно. Меня так научили, это да. Но интуиция тут вообще не при чём.
Iwanowsky
Это точно, Pascal — самый лучший ЯП для начального обучения основам программирования и ООП, кто бы что ни говорил. Хорошая читаемость текста программы, четко выраженная модульность, явная типизация переменных, наглядное представление объектов при ООП (в отличие от др. ЯП) и т.д. Далеко не все школьники и студенты могут начать изучение программирования с ООП на C++ или Python; а вот на Pascal — значительно легче.
ЯП Pascal — живее всех живых (как бы кто его ни хоронил) и до сих пор используется во мн. серьезных проектах (хотя с годами почему-то все реже), выходят новые версии (в т.ч. в этом году) ЯП (Free Pascal, GNU Pascal и др.) и сред разработки (Embarcadero Delphi, Lazarus, PascalABC.NET и др.)
miksmiks
Небольшое уточнение. PascalABC.NET - это не только среда разработки, но и прежде всего диалект языка программирования Паскаль с весьма большими расширениями.
Про восприятие школьниками Паскаля - полностью поддерживаю - наш опыт говорит, что его синтаксис воспринимается и читается начинающими легко.
yatanai
Как прошедший этот путь школьник скажу - в других языках многие понятия довольно абстрактны, та же функция это некий "объект который можно вызвать". У объекта можно взять ссылку, манипулировать им... А что в паскале? Есть ПРОЦЕДУРА которая ничего не возвращает, а есть ФУНКЦИЯ которая возвращает результат.
Во многих языках переменная такой же абстрактный тип, она может быть статической, глобальной, множественно-определяемой, константной лалала... В паскале же у тебя все переменные одного типа хранятся в одном месте, а если надо создать переменную на стеке то ты явно пишешь var n : integer; и этот "var" сразу в глаза бросается и сразу всё становится понятно.
И неподготовленным мозгам паскальные "абстракции" воспринимаются легче, а к многословности привыкаешь.
UPD Хотя я в итоге слез с него, ибо его конструкции с условиями и циклами довольно ограниченные. Я помню что не смог найти как итерироваться по какой-то формуле, надо было либо использовать математику либо while циклы с каким-то лишним кодом.
miksmiks
Деление на процедуры и функции как говорит наш опыт хорошо воспринимается начинающими.
А про переменные - современных школьников мы учим вначале в стиле с автовыведением типа:
Явные типы вводятся потом и в ограниченном числе задач. Это позволяет понизить сложность.
Кстати именно для цикла с шагом, о котором Вы наверное говорили, мы вводили конструкцию
Начинающие её также отлично воспринимают
vadimr
По-моему, автовыведение типа – это весьма сложная для новичков концепция, которую ваши ученики вряд ли полностью понимают. Рад, если я ошибаюсь.
Я иногда занимаюсь репетиторскими занятиями по программированию со студентами, далеко не новичками, и я просто открывал им глаза, объясняя различие в семантике оператора присваивания в языках со статической и с динамической типизацией. Вообще это проходит на институтских занятиях мимо многих. А тут ещё более хитрый случай.
miksmiks
Ошибаетесь. Школьники, даже младшие (6-7 класс у нас), отлично понимают, что в записи
в ячейку памяти n записывается целое, а в ячейку памяти a - вещественное.
В языках с динамической типизацией конечно имя связывается со значением, и это может вызывать удивление. Но здесь никаких проблем с усвоением нет. Приучаешь вс время задавать вопрос, какого типа данная переменная. Система intellisense кстати позволяет это подглядеть, просто наведя в редакторе курсор мыши на имя. Поэтому у нас тут никогда не возникает проблем с объяснением. А когда объясняем школьникам постарше, какого типа скажем
то тут говорим сакральное "здесь сложно - это знать необязательно, надо знать лишь, что можно сделать с результатом".
vadimr
Это-то (поверхностно) понять несложно, это прямо буквально на экране написано. Сложно понять, что происходит при дальнейших присваиваниях.
Вы задайте им мой вопрос ниже, вот и посмотрим, отлично понимают или не очень.
lgorSL
Так и в других языках циклы вполне себе красиво записываются, например Python:
Или например Scala
Или Kotlin:
miksmiks
Да. Во всех современных языках это есть. Просто обсуждалось, что в старом Паскале или даже Delphi приходилось огород городить для реализации цикла с шагом.
vadimr
Попробуйте попросить своих учеников интерпретировать следующий код:
Если у вас хотя бы половина учеников при таком подходе сможет правильно назвать результат, я удивлюсь. Зато не удивлюсь, если вообще никто.
FoxWMulder
а в чëм тут может быть сложность?
vadimr
В том, что в последнем присваивании не совпадают типы справа и слева, оба из которых вводятся неявно и вдобавок не вполне очевидным образом. Результатом в данном случае будет ошибка компиляции.
Конечно, профессиональный программист это легко поймёт, но для новичка, который не акцентируется на типизации, это сложный вопрос.
Хотя тут ещё какой профессиональный программист. Двое из трёх джунов отвечают, что в операторе языка Си
в результате получится 0.3333333
miksmiks
Попробую. В сентябре уже :)
Но мы учим, что в Паскале при делении целого на целое результат вещественный. Учим, что целому нельзя присвоить вещественное. Просим посмотреть тип y в среде при наведении курсора мыши - он будет real.
И здесь - центральный вопрос - "так почему же этот код не компилируется?"
Я вас уверяю, найдётся школьник который ответит точно.
Просто это вопрос методики - как учить. Если учим на статически типизированных языках, то вопрос о типах - важнейший. И дети быстро это хватают.
Методически кстати можно попросить написать типы явно в первых двух строках:
vadimr
Центральный вопрос здесь вообще понять, что код не скомпилируется. А почему – уже легче разобраться.
В других языках ещё могло бы и неожиданно округлиться, но на Паскале мне сложно сейчас придумать такой пример за долгим отсутствием практики.
miksmiks
Ну, код не скомпилируется потому что мы запустим компилятор, и он выдаст: "Нельзя преобразовать тип real к integer". И тут начнут догадываться, что что-то не так с типами :)
Вот ошибка, которую школьники допускают чаще:
И здесь эту характерную ошибку приходится объяснять. Но после двух-трех раз они научаются такие ошибки исправлять.
Конечно Вы правы: новые возможности влекут за собой новые проблемы - и где найти баланс...
vadimr
Ну с компилятором-то несложно ответить. Это вопрос для ответа в уме :)
В вашем примере по сути то же самое, что в моём.
a-tk
Зато много вопросов к локальности переменных и вообще градаций локальности данных
a-tk
Почитал дальнейшее обсуждение, оказывается появились более локальные переменные чем в те годы, когда я его последний раз видел.
Радует, что эволюционирует язык и самые больные места уходят в прошлое.
geher
Может быть, мой мозг какой-то нестандартный, но ему как раз код с большим количеством слов вместо мелких значков разбирать проще. Смотришь - и все сразу видишь. И в глаазах не рябит.
KivApple
Мозг понимает картинки быстрее, чем слова. Письменность с многобуквенными словами появилась позднее, чем 1 картинка = 1 слово. Используется более древний и значит более отточенный эволюцией механизм сличения картинок.
Так что мозгу действительно проще разбирать несколько видов скобок, чем begin end. Если он знает их смысл.
Не случайно люди любят эмоджи и всякие стикеры в переписках. 1 картинка считывается быстрее, чем слово или несколько.
ilriv
Я воспринимаю begin..end по цвету, цвет воспринимается ещё быстрее чем картинки. Где больше синенького, там служебные слова. Там где черненькое, там операции над переменными.
Есть ещё такой аспект. Если у человека не идеальное зрение, ему трудно быстро сосчитать скобки. Четыре скобки или пять? Попробуйте определить на глазок.
geher
Фокус в том, что часто используемые слова в программе (те же begin и end) воспринимаются как картинки, а не как последовательность символов, которую нужно еще прочитать. Причем как большие, хорошо различаемые между собой картинки. А от скобок этих в глазах рябит, поскольку они просто теряются на экране. Одиночную скобку в строке могу и не заметить с первого взгляда. Да еще не очень хорошо отличаются друг от друга при быстром взгляде на экран: круглые, фигурные, квадратные - слишком мелкие и похожие друг на друга.
miksmiks
Действительно, большое количество begin-end нагружает программу, но обычно их много не бывает. К тому же, эквивалентная программа на C с большим количеством }}}} в конце тоже не очень читабельно. А все современные IDE подсвечивают парность операторных скобок, что конечно улучшает восприятие
FoxWMulder
тут и дело привычки конечно многое значит. я всегда с ужасом смотрел на C и Java после Delphi. В Delphi всë структурировано и читабельно, в C/Java всë намешано в кучу. Всегда была ассоцияция как будто код запихнули в миксер, хорошо перемещали и сказав вот читайте. скобки вместо begin end это мелочи.
ilriv
Велика ли разница:
gwplnicker
Меня больше всего напрягали в паскале именно эти begin end, когда учился в универе. С++ нравился именно из-за {}, вместо паскалевской конструкции.
ilriv
begin end ставятся при помощи хоткеев, вручную набирать не обязательно.
begin...end гораздо нагляднее разделяет код на смысловые блоки, чем {}. Код становится более читабельным.
Например:
Начало смыслового блока while i < j do begin визуально уравновешивается end в конце. Всё что между ними - это операции над переменными. Таким образом код получается структурированным и читаемым.
Когда пишете
вы видите начало конструкции, но приходится всматриваться где она заканчивается.
gwplnicker
рисую отчеты в фастрепорте и вот там меня подбешивают эти бегиненды, да можно перейти на c-подобный синтаксис, но паскль привычней.
Удобство побеждает ленность.
ilriv
Для любителей C-синтаксиса есть C++Builder. Причем можно написать программу частично на Паскале, частично на C++Builder.
AnthonyMikh
… Или можно просто вызвать
arr.reverse()и не думать об индексах вообще /silriv
В обоих языках это можно просто вызвать reverse. Это же просто пример элементарной процедуры.
0xd34df00d
Не приходится — скобочки подсвечиваются, да и отступы помогают.
Ну и если приходится всматриваться, то это, возможно, знак, что надо разбить функцию на кусочки.
atshaman
Интересно, есть ли какие-то исследования на этот предмет? Что лучше с т.з. когнитивной нагрузки - большее количество native text или меньшее количество спецсимволов - в идеале еще и с разбивкой по "уровню подготовленности"?
Т.е. мы-то понятно - 30 лет за компом, кто к чему привык, то и "удобно\лучше", а вот без этого "стокгольмского синдрома"? Для диспетчеров\операторов точно знаю, достаточно масштабные исследования проводились - а вот для программистов я хз... было бы интересно.
0xd34df00d
Думаю, тут будет сильно мультимодальное распределение. Кому-то то удобнее, кому-то наоборот.
Мне вот очень быстро стало сильно удобнее в агде с её уникодными закорючками, чем в идрисе с нормальными словами, хотя агду я толком не знал на момент начала, а с идрисом у меня уже был опыт в пару лет.
KivApple
Я думаю, что лучше спецсимволы. Они сильнее выделяются по начертанию.
Парсинг картинок более древний механизм мозга (а значит более развитый). Письменность с многобуквенными словами появилась позднее.
Не случайно у людей популярны всякие эмоджи в переписках. Скорость восприятия одной выделяющейся картинки выше, чем скорость восприятия слова (которое по факту есть последовательность из нескольких картинок).
Спецсимволы выделяются сильнее на фоне всяких имён переменных и т. п.
Я думаю, что begin end хорошо воспринимается именно из-за подсвечивания. То есть человек может ориентироваться не только на начертание, но и на цвет. И это ускоряет восприятие, а не "нативность".
atshaman
Но при этом иероглифическая письменность проиграла фонетической - именно по причине большей когнитивной нагрузки.
Тут еще такой момент, что native text в программировании использует те же нейронные связи, что и обычный текст в жизни, а спецсимволы за пределами кодинга не используются примерно нигде - т.е. даже если "абстрактно-вакуумно '{' воспринимается лучше 'begin' (А это мы еще про шрифты и различия между '{([' на письме не говорим!) - то наша нейросеточка тупо лучше обучена на распознавание этого самого begin'а".
В общем, выглядит как тема для ха-аарошего такого исследования ).
unreal_undead2
认真的 ?
KivApple
Во-первых, иероглифы использует больше миллиарда человек. Так что проиграла условно.
Во-вторых, сравните количество иероглифов и количество спецсимволов в С-подобных языках. Кстати, в Pascal тоже есть спецсимволы, просто чуть меньше. Всего лишь на 2-3 (begin, end, array of).
В-третьих, иероглифическую письменность дольше учат, зато быстрее читают. Буквы выигрывают именно по порогу входа. Однако, столь высокий порог входа обусловлен количеством и сложностью начертания от руки (компьютеры стали массовыми совсем недавно и, внезапно, сейчас бум эмоджи, которые чем-то похожи на иероглифы - 1 символ = много смысла). Спецсимволов в С немного и они простой формы.
atshaman
Да-да, тут я должен сказать, что корпус написанных на фонетических языках текстов порядково превосходит записанный иероглифическим письмом бла-бла-бла - но не буду. - совсем уж в сторону уйдем, при том что всем в общем-то все понятно и ратующих за всеобщий переход на иероглифическую письменность разве что 1,5 депутата на всю Россию найдется.
По поводу "много\не много" - гляньте на плюсы и добавьте перегрузку операторов чтоб совсем хорошо стало.
Кстати, а эмодзи - вообще дикий костыль, порожденный отсутствием сколько-нибудь вменяемых средств ввода в современных телефонах.
KivApple
Так всё совпадает с высоким порогом входа. Выше порог входа, меньше писателей. Плюс от руки писать иероглифы дольше, чем буквы.
atshaman
Да-да, на клавиатуре разумеется нет НИКАКОЙ разницы
UncleSam27
Прекращайте подкидывать идеи наши депутатам. Не хочется читать Пушкина в кандзи.
atshaman
В нонешнее время - славянские резы актуальней, и тут уже долбославов(ТМ) может найтись поболе
yatanai
Было, я плохо помню, но делали исследования типо "количество ошибок на программу" или что-то такое. Многословные языки выигрывали всегда, за них топили многие крупные игроки в "те" времена, но... Юниксоиды поверили в С и все кто мечтал о свободном ПО писали именно на нём. В итоге, как писали выше, "эмодзи победили".
И единственное что мне приходит на ум в виде "промежуточной версии в эволюции" это Java. Где и символьный синтаксис и миллиарды спецслов.
atshaman
Ну вот внутреннее ощущение у меня именно такое - а Сишечка это такие "Грехи отцов", что пали на детей...
ilriv
Приходится тыкать на скобочки, чтобы они подсвечивались. Иначе в сложных конструкциях не понять,какая скобка к чему относится.
miksmiks
В редакторе PascalABC.NET при помощи хоткея wb <Shift-пробел> набирается вся конструкция
atshaman
Извиняюсь, но сниппеты есть у всех, кому они нужны - от intellij до vim'а - у кого нет, тому видимо и не надо...
miksmiks
<повтор - удалено>
lgorSL
Смотрите на отступы, и тогда скобки или begin\end не будут играть разницы.
Вдобавок можно добавлять пустые строки в код, и строка с
}выглядит практически как пустая.На мой взгляд, begin и end выглядят как шум.
ilriv
У меня свои личные требования к синтаксису:
- служебные слова (if, then, while, begin), операторы (+, <, =, ==), переменные (a, b, temp, socket, canvas) и классы (TSocket, TCanvas) должны быть визуально легко различимы друг от друга.
- поэтому это плохая практика, когда специальный символ "{" используется в качестве служебного слова. Специальные символы надо зарезервировать для операторов.
- это нехорошо когда начало блока while { легко различимо на странице, но приходится искать конец блока }.
- критические важные элементы кода должны занимать достаточно много места на экране. Неправильно, когда критически важный элемент кода выглядит как малозаметная точечка. Если это правило нарушается, то при чтении кода (а особенно при редактировании чужого кода) приходится вглядываться в каждую точечку.
- односимвольные элементы кода должны иметь защиту от дурака. Точка, двоеточие, скобка, фигурная скобка должны иметь однозначный смысл. Они не должны менять своё значение в зависимости от контекста.
- синтаксис должен быть интуитивно понятен. Почему-то иконки стараются делать интуитивно понятными, а элементы синтаксиса делают контринтуитивными и предлагают просто это запомнить и смириться. Но ваше подсознание всё равно продолжит протестовать против контринтуитивных символов.
atshaman
Причем с современным autocomplition'ом\сниппетами\live templates\контролем операторных скобок и пр на большую часть этого примерно пофиг.
Kanut
Когда int и var и на таком маленьком куске, то не велика. Вопрос всегда ли у вас только int или бывают и названия классов подлиннее?
bratuha
Теперь так в Delphi можно делать? В классическом Pascal и в (старых?) Delphi был отдельно блок var в начале каждой функции, процедуры или юнита/программы.
ilriv
Да. Но есть нюанс:
При таком объявлении переменная будет видна только внутри своей синтаксической конструкции.
bratuha
Супер. Спасибо! Нашел в доках этот раздел, фича языка называется inline variable declaration. Действительно получается, что и среда разработки, и язык, живее всех живых и активно поддерживаются.
Все верно, так и должно быть. В других языках именно таким образом и происходит.
ilriv
Дельфийский код сейчас выглядит так:
https://github.com/Pigrecos/TensorFlow.Delphi/blob/main/src/Tensorflow.Utils.pas
miksmiks
В PascalABC.NET так можно было делать с 2007 года. В Delphi 11 с 2021 года такая возможность тоже появилась (подсмотрели :), как и возможность писать
miksmiks
В паскалевском ReverseArray var перед параметром - лишняя - там массив и так передается по ссылке во всех известных диалектах Паскаля.
И для лучшей читаемости рекомендуют писать begin с новой строчки и end под begin. Как и { } во многих правилах написания кода. Но дело вкуса - я понимаю.
a-tk
Велика
ilriv
Выше я приводил код без оптимизации.
В оптимизированном коде Delphi нет никаких лишних телодвижений:
Einherjar
На c# + wpf/winforms можно сделать как минимум не медленнее, с меньшим количеством багов и плюс людей умеющих писать код найти куда проще, ибо их больше. Да и можно использовать лучшие IDE для разработки.
На Delphi сам писал. Лет 15 назад... Практический смысл делать что то новое на этом примерно тогда и закончился.
playnet
"на c# + wpf/winforms" - сделать можно не медленнее, имея заметно больше опыта. У дельфи (был) уровень входа у плинтуса, а с шарпом я работал и простым назвать вообще не могу..
Конечно, у шарпа перспектив больше, включая кроссплатформенность.
Einherjar
Чем он сложнее? Для входа не обязательно сразу знать все фичи языка, формошлепство там точно такое же - рисуешь в редакторе форму дважды кликаешь на кнопку и пишешь обработчик. И что то начнет работать. А дальше stackoverflow driven development (инфы по шарпу и винформам там вангую побольше будет). Плюс куча готового кода в nuget вообще для любых хотелок, на дельфи придется велосипеды изобретать.
Короче то же самое все, только IDE продвинутые за вас половину багов найдут и код читаемее получается.
werymag
Как человек который делал проги на Делфи и сейчас делаю на c# (wpf), скажу что написать простую мелкую прогу, с нормальным интерфейсом, логикой, работой с БД на Делфи в разы быстрее, там формошлепство в разы удобнее (чем в Вин Форм) - одно привязка с вытягиванием по сторонам чего стоит, и в целом обработка событий интуитивней.
А уж WPF (особенно с MVVM) это вообще не про простоту и быстроту - это про ручную разметку, команду, ООП, патерны и прочее.
Естественно при большом опыте и набором готовых решений где угодно можно быстро что-то наклепать, но в делфи уровень требований к опыту в разы ниже. Очень жаль, что язык "умер".
tester12
Если нужно быстро сделать пару формочек, связанных с каким-то железом (принтеры, сканеры штрих-кода, кассовые аппараты, дисковые массивы, разные мониторы, промышленные станки), то Delphi/Lazarus - неплохой выбор.
a-tk
... а потом молиться, чтобы это не надо было развивать и поддерживать хотя бы лет 5...
zuek
...я недавно икнул, когда меня попросили обновить корпоративную софтину, а у неё дефолтный значёк от Delphi... но когда я в архиве нашёл исходники с таким же именем от 96-го года, я был реально озадачен... а рядом нашёл ещё более ранние исходники с похожим названием, на Pascal, под DOS. Так что кто-то вполне может "это" не только поддерживать хотя бы лет 5, но даже и портировать на "родственные" языки (правда, не завидую той команде, которая интерфейсы перерисовывала, даже если и TurboVision использовался - всё равно много править)...
tester12
Развивать и поддерживать софт нужно при любом языке программирования. А умение разбираться в старом коде (своём и чужом) - одно из обязательных умений хорошего программиста.
PuerteMuerte
Ну как бы и да, и нет. Если речь идёт о создании чего-то простого, то без разницы. Если нужно приложение со сложным развитым GUI, библиотека Delphi намного богаче чем то, что доступно на WinForms или тем более мертворождённом WFP. Плюс, на Delphi приложение всё-таки будет нативным, без прослойки в виде дотнета. С другой стороны, на дотнете есть из коробки EF, и я не в курсе, есть ли сейчас что-то подобное в современной Delphi. Старые приблуды вроде Bold, это не то.
MiraclePtr
Дотнет уже давным-давно умеет компилироваться в нативный код
PuerteMuerte
JIT-компиляция не считается. Проблемы с производительностью остаются всё те же, по крайней мере, для десктопных приложений, а не для серверных, которые раз "прогрелись" и после этого продолжают работать.
Einherjar
Поясните пожалуйста, о каких проблемах с производительностью идет речь? Какие то стереотипы времен .net framework 2.0
PuerteMuerte
Я про банально отзывчивость UI приложения. Разница на не слишком шустрых машинах видна невооружённым взглядом, даже без тестов.
Einherjar
Разница между чем и чем конкретно?
atshaman
Это ж какой археотех должен быть, чтоб на нем WPF'ный UI тормозил - не СУБД, не сетевка, не ФС - а вот прям сам UI? Причем если мы за сравнение с delphi - то это какое-то бизнес-приложение должно быть, а они свистопердельными анимациями, мягко говоря, не прегружены...
Пример можно?
a-tk
Да без проблем. DataGrid на 100 столбцов и 5000 строк, находящийся в DataTemplate для TabControl-а.
При переключении вкладок можно отойти чай заварить. Несмотря на ухищрения с виртуализацией (которые, к слову, сводят с ума прокрутку)
atshaman
"Локи, а НАХРЕНА?!" (Безотносительно "тормозит или нет" - у меня вот сейчас проверил - html'ка на 500к ячеек минуту грузилась) - зачем так делать? Что полезного можно получить с такого, гм, интерфейса? Оно ж даже на диспетчерскую видеостену - неадекватно будет...
0xd34df00d
Ну у меня в RSS-читалке, например, заголовки сразу всех новостей в канале показываются, и их может быть хоть 5, хоть 50 тыщ. И по ним всем можно искать, фильтровать, и так далее.
Kanut
А на экране одновременно сколько видно? Все 50 тыщ?
0xd34df00d
Во вьюшку все 50 тыщ грузится, видно — десяток-другой, доступно для быстрой навигации (скажем, по первой букве текста) — все 50 тыщ, оптимизация этого процесса — на вьюшке.
Kanut
Ну так "во вьюшку" и в WPF можно кучу чего запихать. Проблемы начнутся только если это всё одновременно отрисовывать надо будет.
0xd34df00d
Если вы не заметили, я отвечал на вопрос «Локи, А НАХРЕНА [5 тыщ строк]?!»
Kanut
Ну так вопрос то в том нахрена их одновременно все видеть.
0xd34df00d
Про «одновременно видеть» я не, гм, увидел ни в одном из комментариев выше до моего.
Kanut
Бывает.
0xd34df00d
Поможете исправить ошибку и укажете, где это написано?
Kanut
Я бы сказал что это понятно из контекста и формулировок.
Но можете попросить людей уточнить что они имели в виду.
0xd34df00d
Ясно.
Siemargl
Проблема в дефолтном ВПФ гриде очевидно.
Переписывайте, штош
У меня, кстати, он из 32-бит процесса вылетал по памяти. Пляски с бубном вокруг виртуализации с этим помогли, но с торможением - нет. Надо его менять.
0xd34df00d
У меня-то нет проблем (и рсс-читалка вообще на кутях), я просто отвечал на вопрос о том, зачем вьюшка с пятью тыщами строк.
atshaman
Ну, так можно сказать, что "мне миллиард строк в БД нужен чтобы по ним искать\фильтровать" - в контексте GUI-приложения дофига релевантно будет - пусть и чистая правда.
vcKomm
Искать-фильтровать — это одно, а показывать — совсем другое
Einherjar
Либо виртуализация настроена неправильно либо грид удаляется из дерева и пересоздается либо хз что еще, тут не к фреймворку вопросы а к тому кто код писал. Профилятор в помощь.
Siemargl
Да тормозит в сравнении, как ни печально. И WPF и драйверы к СУБД тоже (ODAC например).
Цена прогресса, чтобы археотех вытеснять.
Чтобы не жаловаться на криворуких, можно банально сравнить работу VS6.0 или Delphi c современной VS >2015
Einherjar
VS6.0 это уже просто блокнот по сравнению с 2022. VS Code и то функциональнее. К скорости работы непосредственно интерфейса обоих у меня претензий нет никаких. Проблема с VS в другом - там из за кривой архитектуры (тянущейся я так понимаю собственно с 6.0) очень много выполняется на UI-потоке того что по уму должно делаться в фоне. От этого и лаги все, и это было и до перехода интерфейса на WPF, на 700 проектах в солюшне любая VS умирает. В последних версиях вроде понемногу решают это, плюс процесс наконец то стал 64-битный.
Ну и VS 6.0 не на дельфи написана.
isadora-6th
Лично у меня лагал VS 2021 на ввод символа до 0.7 секунд на i7-8750H (который так-то дум этернал в 120фпс может), на дефолтном шаблоне "Hello World" в консольном приложении.
При том, что "тормозной электрон" VSCode от тех же майков, проблемы инпут лага не имеет вовсе.
Мне кажется, что 64 бита позволят вижле и дальше просто обновляться, без перелопачивания, т.к. крашей на больших проектах не будет, а разработка то дорожает, нужно купить капутер помощней.
a-tk
Хотели пруф - я предложил пруф.
Вопрос "зачем" немного в другой плоскости лежит.
Einherjar
Не совсем понятно пруфом чего именно это подразумевалось. 5000 строк одновременно ни на один экран не влезает, отображение длинных списков всегда эффективно решается виртуализацией, без нее тормозить будет независимо от того как и на чем вы делаете UI, а влезающее на экран количество строк отрисует без тормозов любой UI-фреймворк. Я лично с нуля делал древовидный грид на avalonia ui (не wpf но суть та же, и это .net), и ничего не тормозит ни на 5 строках ни на 5 тысячах ни на 5 миллионах, и с прокруткой порядок. Потому что на экране отображается от силы 100, а это не требует большого количества вычислительных ресурсов, элементы переиспользуются, а доступ к списку по индексу это операция O(1). С виртуализацией строк хоть 5 миллиардов может быть, лишь бы данные в память влезли.
a-tk
Да в сообщении выше вопрос был:
Я привёл пример торможения.
Предлагаю не развивать эту тему вопросами целесообразности, она действительно невелика.
Einherjar
Так такое и на дельфи тромозить будет и на чистом С с ассемблерными вставками, если не предпринять меры оптимизации. Все же изначально речь шла про проблемы с производительностью в .net, но данная задача решается на .net без проблем с производительностью.
atshaman
Прояснения позиции для - я не утверждаю, что "UI на .net не тормозит НИКОГДА" - у меня ощущение что в той области, где delphi является условным конкурентом C# (Корпоративная бизнесуха под Windows) разницы в производительности примерно "нет" - что конечно не исключает возможности написания тормозючего глюкалова вот прям на чем угодно.
MiraclePtr
Какой JIT? Там честный AOT.
Cregennan
Он про другое: https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
atshaman
Предполагаю, что там, где эта разница на самом деле критична - ни шарпу, ни delphi делать особо нечего, а в типовой gui'шной бизнесухе задержки возникают нихрена не из-за рантайма или там gc...
Siemargl
Лаги из-за GC прекрасно заметны во всяких играх, особенно на мобилках на Юнити
atshaman
Ну, я примерно это и сказал, не? :)
Einherjar
Если зацикливаться только на том что из коробки, то все равно упретесь в написание велосипедов. При этом сторонних библиотек для дотнета доступно куда больше.
Почему мертворожденном? На нем создано очень много приложений. Да и XAML весьма удобен если хочется сделать более менее продвинутые и архитектурно корректные вещи в UI, пытаясь делать которые что на винформах что на дельфи у вас будут в основном файлы по 3000 строк, велосипеды и говнокод.
Kanut
Под .Net в целом и WPF в частности сейчас столько опенсорса что ситуация скорее обратная.
max_dark
Qt- современныйDelphialexey_public
Только не в плане написания интерфейса, по сравнению с Delphi это просто кошмар.
А если к Delphi докупить DeveloperExpress - то до сих пор ничего радом стоящего нет ни у кого. Это просто совсем другой уровень возможностей и интерфейса.
Но да - за Qt в общем случае платить не надо. Ну пока не потребуется что-то хотя бы уровня вывода графиков.
0serg
Qt Designer имхо примерно столь же удобен сколь и визуальный редактор Delphi
alexey_public
К этому вопросов нет. И на этом всё заканчивается.
Но достаточно взглянуть на список компонентов даже тех, что идут в комплекте с Delphi чтобы понять насколько глубока пропасть между Qt и Delphi.
Если бы кто-то повторил компоненты даже из классической 7 версии - то тогда да, это был бы прорыв в Qt. Но пока Qt сделала платным даже простенький компонент для вывода графиков.
P.S. Под интерфейсом я имел в виду интерфейс приложения, а не среды разработки.
0serg
Мне кажется что рисование графиков это не очень распространенный use-case и для него (как и вообще для дата-аналитики) сегодня лучше подходит Python + PyQt чем плюсы или дельфи.
alexey_public
Ну вот я написал на Qt приложение для работы с железом.
Мне сразу потребовалась графика на OpenGL. В Qt в принципе не проблема. Хотя под Delhi можно найти готовые решения и пользоваться, а не вспоминать написание шейдеров даже для простейшего приложения.
И мне потребовался вывод графиков кучи параметров. И вот тут приехали, я попробовал их компонент, работает, неплохо, не TСhart конечно, но неплохо. Благо что распространять и продавать приложение не нужно.
А для чего ещё нужно desktop приложение ? :-)
А так я только за Qt. Потому что когда в железе все на Си или С++,
то писать интерфейс обмена предпочтительнее с приложением на том же С++.
0serg
Ну тут you got me :D я бы свой велосипед сделал для подобного графика, вряд ли там нужно что-то хитрое. Или взял бы одну из thirdparty если нужно было бы что-то более сложное.
В Qt с OpenGL намного проще чем в Delphi, а если не хочется возиться с шейдерами то есть QGraphicsScene и Qt3D.
alexey_public
Вот кто бы написал статью на хабре как правильно пользоваться QGraphicsScene и Qt3D :-)
А на велосипед не было времени, надо было быстро что-то работающее собрать. Просто странно что в той же Delphi это уже лет 20 как норма. А тут всё никак.
KivApple
Для Qt есть бесплатный QCustomPlot.
alexey_public
Да, вроде пробовал, но возможности сильно порезаны :-(
0serg
Из того что быстро гуглится есть еще JKQTPlotter и QWT. Последний вроде как специально для кейсов подобных описанному Вами предназначается
alexey_public
Благодарю, надо попробовать.
geher
Еще Qwt
LuchS-lynx
Lazarus кросплатформенный живее всех живых
PsihXMak
Lazarus спасал в этом плане долгие годы. Но теперь FMX компилируется под линукс, по этому, можно писать прямо на Delphi.
alan008
Справедливости ради, под линукс компилируется только невизуальная часть FMX, а для компиляции визуальных формочек нужно отдельно "докупать" FMXLinux от разработчиков FMX, либо, возможно, он включен в Architect редакции RAD Studio, не уточнял.
Zhuikoff
На lazarus можно писать прямо на Linux'е.
regs
А можно и на Винде. И там же скомпилировать под другие системы. Кросс-компиляции из коробки нет, но можно настроить если не со всего, то со многого на многое. Не говоря о графической части - полный агностицизм. При компиляции уже указываешь на что - Win32, GTK, qt итд итп.
MiraclePtr
Это не так. Если заказчик не совсем дурак и он заказывает не поделку-однодневку, а что-то для долгосрочного использования, то его волнует, насколько легко ему будет найти потом кого-нибудь, кто будет поддерживать и развивать этот написанный на заказ софт, например, в случае если этот программист умрет/пропадет/уедет/заломит огромную цену. Иначе есть риск оказаться в ситуации как некоторые американские банки, у которых тысячи строк кода на мертвом COBOL, с которым никто сегодня особо не хочет работать, и они вынуждены выманивать старых дедов с пенсии.
Вот кстати характерный пример: мужик начал писать на заказ ERP-систему, но в итоге получилось так, что мало кто бы согласился потом разбираться в этом и поддерживать этот код. Заказчик офигел, и, понятное дело, отказался от дальнейшего сотрудничества (обосновав, в том числе, выбором крайне непопулярного я/п). Комментарии там тоже прекрасные.
entze
С ковбоями на Коболе скорее проблема в том, что на момент разработки было актуально, но прошло 30-40(?) лет за которые банки так и не смогли поменять.
atshaman
Тут ключевой момент - в наличии людей, готовых это писать и потом сопровождать - а их на рынке примерно... нет. Т.е. вообще конечно есть - и даже пишут\сопровождают что-то - но вот "на рынке" нёма. Соответственно нет новых проектов -> нет джунов, которые будут на них набивать руку, нет... да ничего примерно нет - "отрицательная обратная связь".
А сам по себе delphi да, все еще если не "хорош", то вполне неплох для ряда применений даже адекватен... в отрыве от рыночной ситуации.
Areso
Вот выйду на пенсию, буду сопровождать проекты на Дельфи =)
atshaman
Есть вероятность не дождаться :). Был у меня не так давно кейс с заменой внутрицеховой автоматизации на delphi на современную вебню - просто по тому, что главный автоматизатор на пенсию собрался.
Оно даже работало и работало адекватно, и под задачи модернизировалось - но влезать в legacy-проект с 10+ летней историей, связанный с непрерывным производством желающих не нашлось. Вот уже второй год в процессе замены, если я не ошибаюсь :).
voltag
Из моего опыта, проблема обычно в "цене". Нет проблем разобраться в легаси, если есть время, оплата и доступ. И с 20+ можно нормально работать и переносить.
atshaman
Как говорил один из моих начальников - "Можно ракету в космос запустить! Да можно одним напильником! Да один человек справится! Если этот человек - не ты." :)
На определенном уровне примерно ВСЕ становится "вопросом цены", дело не в том, что "сопровождать это невозможно", а в том что бизнес заранее посчитал и решил что с т.з. "цены" дешевле будет периписать с нуля, чем тащить мертвую лошадь.
geher
А сейчас и кроссплатформенность не вопрос. Современный Delphi поддерживает разработку под большое количество платформ, в том числе и мобильных.
Еще есть Lazarus со своим LCL (аналог vcl).
atshaman
Кстати, забавно - но когда я последний раз в эту тему лез - наиболее "безболезненным" кроссплатформенным GUI был как раз таки FreePascal\LCL - на мой хелловрот его хватило с запасом ).
Shklo
подтверждаю: два дня назад все-таки замахался делать работу ручками т.к. ее периодичность и объемность со временем тали лишь расти. За вечер на коленке на делфях собрал софтину, раздал причастным коллегам, показал куда нажимать.
И, все.
Теперь можно страдать над чем-то другим))
select26
Да и с кроссплатформенностью не все так плохо. Есть FPC. Есть Lazarus - он прямо Delphi проекты понимает. Я видел проекты, которые им собираются под разные платформы.
Я согласен и с оценкой Delphi, и с тем что Pascal хоронить рано.
auresio
С кроссплатформенностью все как раз таки отлично у Делфи. Винда, мак, линукс, андроид и айос, если упороться можно сторонними компонентами в веб интрефейс трансформировать.
w0lf
Мне пару месяцев назад была нужна специфичная софтина которая читает данные с последовательного порта и особым образом их визуализирует. Взял Lazarus под Ubuntu, скормил ему свои библиотеки рисования графиков, которые писал ещё будучи студентом под Delphi в далёких 97-98 годах (25!!!! лет назад), добавил простую логику обмена с последовательным портом, фигак фигак и заработало. Мало того, при желании можно скомпилировать и под Windows. Так что говорить и смерти Паскаля, imho, преждевременно.
atshaman
С такой логикой и perl живее всех живых - а то, что лежит тихо и пахнет, так это ерунда, зато смотри-как-я-могу!
w0lf
Да. У меня кстати до их пор один сайт с движком на Perl работает - владельцев всё устраивает, зачем что то менять?
atshaman
Так я и не призываю, если что )
remzalp
Kylix (=Delphi for Linux) я увидел еще во времена, когда основным кроссплатформенным инструментом были Java и Perl
А сейчас есть как платное кроссплатформенное, так и вполне себе бесплатный Lazarus.
cat_chi
Хорошее мнение :) Но очень узкий кейс. Настолько узкий, что можно поспорить, какой из языков более живой – Delphi или COBOL, который так же ограничен узкой специализацией, но в куда более широких масштабах.
К тому же... Аргумент "не знаю на чём можно быстрее" – он про уникальные преимущества Delphi, или всё-таки про ваши навыки? Потому что язык, который живёт за счёт навыков и привычек отдельных энтузиастов – сложно назвать в полной мере живым.
Из аналогов мне навскидку в голову приходят C#, Qt и даже, прости господи, Electron. Я не готов спорить, что из этого действительно будет быстрее – я всё-таки серверный разработчик и не имею релевантного опыта.
Но было бы интересно узнать мнение того, кто собаку съел и на дельфях, и на том же электроне, что реально быстрее. И насколько разница в скорости (если дельфи однозначно быстрее) важнее, чем простота поиска разработчиков.
И ещё аргумент – а если всем вашим заказчикам сказать "а давайте вы теперь будете не с флешки запускать софтину, а из браузера вот отсюда? И там уж как хотите, хоть с компа под виндой, хоть с телефона, хоть с утюга" – какой процент согласится? :)
PsihXMak
В плане производительности разницы практически нет.
Как по мне, единственная проблема Delphi - это ценовая политика Embarcadero. Что бы поставить его на предприятии, придётся отвалить немаленькую сумму за Delphi, DexExpress и ещё пачку полезных пакетов.
А вот кадры - вообще не проблема. Язык на столько прост, что можно спокойно сажать вчерашнего студента и он сможет писать достаточно сложный продукт почти с ходу.
Я встречал полноценное микросервисное веб приложение, написанное полностью на Delphi. И я даже не знаю, что меня пугало больше - само существование этого приложения или то, на сколько просто оно было написано.
Siemargl
Вообще то нет.
На сегодняшний день безопасность языка Дельфи осталась на уровне С++93.
Весьма дисгармонирует с понижением средней квалификации корпоратив-кодера.
cat_chi
Ну тогда получается, что и смысла в Delphi нет.
PsihXMak
Я бы скорее сказал, получается, нет смысла в других языках. Какой смысл писать на чём то ещё, если есть универсальный Delphi?
cat_chi
Тогда, боюсь, вы промахнулись с предыдущим комментарием и ответили не тому :)
fillrate
С ностальгией вспоминаю Дельфи, долгое время использовал его как основной язык программирования. Но на сегодняшний момент он безнадежно устарел. Насчет быстроты я с вами согласен. Можно быстро и качественно накидать простенькую утилитку на VCL. Язык вполне может и сейчас использоваться для небольших десктопных проектов с GUI. Но написать серьезное приложение на дельфи - это боль и страдание.
DreamingKitten
Ну такое. Я на нём писал почтовый сервер. И ещё кое что раз и два.
Т.е. при наличии определённой усидчивости и мотивации, системно программировать можно и на Delphi. А уж FPC...
fillrate
Конечно можно, но зачем? Ссылки, которые вы дали, опубликованы 15+ лет назад. Мотивацию можно легко проверить, открыв любой сайт с предложениями о работе. Все сразу станет ясно.
Вообще не понимаю, почему многие программисты так упорно цепляются за устаревшие технологии. Переход с дельфи на какой-нибудь .NET/C# для хорошего инженера вопрос нескольких месяцев. Изучение парочки нужных фрейморков полгода-год. Эти инвестиции с лихвой окупятся при первом же поиске работы.
P.S. Раньше думал, что оставлю дельфи написать что-то для души. Не вышло. Тот же питон оказался банально проще для написания консольных мелких утилит и различной автоматизации. Ну а C# с бесплатной VS на голову удобнее и стабильнее RAD Delphi студио. Единственное, что там осталось действительно на высоте - это быстрое создание GUI на VCL, особенно для работы с данными. Ах, компоненты DevExpress - любовь всей жизни :-)
KivApple
Qt с Qt Creator тоже позволяет накидать формочку за несколько минут, а потом городить логику в onClick listener.
Ещё есть C# c WPF. Который наверное даже популярнее Qt под Windows.
Surrogate
Например команда энтузиастов пишет на нем ZCAD (хабро-статья с упоминанием о нем, в YouTube)!
Так что не спешите Pascal хоронить)
whoisking
Ещё есть популярная DAW Fl Studio от Image-Line.
kekoz
Delphi — это не Pascal. И даже Object Pascal — не Pascal, просто Apple получили благословение Вирта на переименование своего Clascal.
А Pascal как язык для практического применения — мёртвый от рождения. Как сказал сам Вирт, “Главная проблема Pascal в том, что слишком многие восприняли его слишком серьёзно”. Это язык для обучения. А для работы Вирт сделал Modula (2).
omxela
Консольное приложение Дельфи - чистый Паскаль, и, поверьте, бодренько так используется, например, мной. Вот помру - станет мёртвый.
UGivi
Если используете тип string (не строковые литералы), то уже не классический Паскаль, а расширения типа "Турбо Паскакаль от фирмы Борман"(Ц), а с некоторыми конструкциями - уже Object Pascal/Delphi (начиная версии с 7й язык тоже так назвали, чтобы всех запутать, OP остался во всяких FreePascal и VirtualPascal). Консоль - это окружение исполнения и интерфейс, ограничение на использование языковых возможностей в остальных аспектах не накладывается, консольные приложения вполне могут быть и сложными и очень даже привязанными к конкретному компилятору из-за особенностей реализации.
Быстрее.. в некоторых случаях на Перле быстрее сделать программу, чем запускать среду.
kekoz
“Чистый Pascal” — это тот, который описан в документе ISO/IEC 7185:1990. Delphi не соответствует этому документу. И никогда не соответствовал. И дело не в том, что в Delphi есть значительно больше, а ровно наоборот — в Delphi нет того, что должно быть в реализации, чтобы называться “чистым Pascal”. Для успокоения всех ценителей могу лишь сообщить — я вообще не встречал ни одной реализации Pascal, которая соответствовала бы упомянутому документу. Таким образом, “чистый Pascal” — это несуществующий сферический конь в вакууме. Мёртвый от рождения язык.
Siemargl
Gnu Pascal соответствует и существует.
Возможно, и FreePascal в ISO режиме.
Areso
Сделал язык для работы, которым никто не пользуется?)
LAutour
Идеи из Modula повлияли на развитие Pascal.
kekoz
С точностью до наоборот :) Modula появился после Pascal.
LAutour
Я не про историю появления языков. Я про то как идеи от одного языка программирования переходят в другие (даже в более ранние).
kekoz
Россиянский GPS под названием ГЛОНАСС подойдёт как пример, что никто не пользуется? :)
Zenitchik
Нет. Я пользуюсь.
А для науки и вовсе, чем больше навигационных сетей одновременно доступно - тем лучше.
kekoz
А я что-то сказал против ГЛОНАСС? Ты не заметил, что речь идёт не о навигационной сети, а об использовании Modula-2, на котором ПО ГЛОНАСС и написано, которое я и привёл как опровержение мнению@Areso, что Modula-2 никто не использует?
Давай читать внимательно, осознавая прочитанное прежде чем писать комментарии в духе ущёмлённого патриотизма и размахивать минусодубинкой.
Zenitchik
Извини, погорячился. Перечитай пожалуйста, свой предыдущий пост. Как его поймёт человек, который не в теме?
Areso
Окей, кто-то пользуется.
Но число видимых проектов не очень велико. Потому что работы для embedded C программистов я вижу много, а вот то, что где-то в дебрях Роскосмоса использовали Modula-2 для спутников ГЛОНАСС я не знал.
Ailuropoda_M
В конце концов есть SCL/ ST (IEC 61131-3), который живее всех живых и смерти его в обозримом будущем не предвидится.