Сколько зарабатывает Pascal программист?

Вот только от новичка, как сказано выше, их заботливо прячут. А у нас речь шла про ПЕРВЫЙ язык для ПРОГРАММИСТА.

ИМХО, тут в людях проблема: просто это – не их.

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

Изменение требований приветствуется даже на поздних стадиях разработки

А ты работал когда-нибудь по водопаду или спиральке? Вот где ад и израиль.

для safety critical тоже

Выпускать в любом случае надо было еще вчера, даже у нас. Тут некоторые манагеры врут начальству, что мы сделаем за 2 года, когда команда сказала 4 года минимум. Се ля ви. Мы выпускаем «релизы», естественно они проходят кучу проверок и в прод попадают через года только. Спецификации, кстати, тоже меняются и дописываются по-агильному, от этого не уйти, опять же се ля ви.

К этим инструментам

Так это инструменты аджайла.

В миллионом городе за 10 лет, ни разу не встречал открытую вакансию на Pascal. Данный язык, как язык коммерческого программирования, скончался в начале 2000-x, или того раньше. На сколько я знаю, он еще остался, как примитивный устаревший язык обучения в различных недовузах.

Раньше его преподавали, как базовую вещъ, чтобы объяснить ученикам основные логические конструкции, такие как if else do. И тогда, подобный подход, выглядет крайне убого. Человек получал массу знаний, мог писать самые элементарные программы на основе готовых шаблоном и лабораторных работ, но свободным программистои не становился. Любая нетривиальная проблема - туши свет...

Еще я считаю, что Pascal, стал умирать тогда, когда среда разработки, поддерживаемая одной фирмы, стало мало по мало уведать, особенно после краха рынка доткомов в 2001 году.

Тут некоторые манагеры врут начальству, что мы сделаем за 2 года, когда команда сказала 4 года

Не удержался. Что же там за проекты на несколько лет?

А ты работал когда-нибудь по водопаду или спиральке? Вот где ад и израиль.

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

Аджайл позволяет делать дешевле, но без гарантии завершения.

если заказчик точно знает, чего хочет

Поржал, спасибо.

Все эти доисторические техники уже и не найти нигде. За последние лет 10+ ниодного места не видел, где не аджайл/скрам. Хотя не, видел, в Германии, в захолустье, в семейной логистической компании, но этим чертям б-г судья.

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

К сожалению с момента появления паскаля никакого другого языка так же хорошо подходящего для обучения программированию так и не придумали.

SML же ну.

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

Впрочем уже это все без разницы. Этот язык мертв. Этот язык стоит вычеркнуть из школьной программы.

Грамотно спроектированный язык это оксюморон. Невозможно грамотно проектировать язык, который будет удобен на протяжении более чем полувека. Со времен его «грамотного проектирования» в программировании очень много чего изменилось и очень много чего изменилось в «компах». Стандарт С++ отражает эти изменения, именно поэтому он такой большой, местами весьма противоречивый, с кривыми конструкциями и пр.пр.пр., это следствие эволюции языка, которая является следствием эволюции отрасли разработки ПО, все как с естественным языком…

Поэтому я и говорю, если человек хочет специализироваться в железе или системном программировании, то ему нужно учить С/С++, на горизонте полувека эти языки никуда не денутся. Собственно, язык С это просто макроассемблер, поэтому в каком-то виде он будет всегда. А С++ учить нужно не с т.з. стандарта (он не для этого), а с т.з. умения писать аккуратный и понятный код, для чего нужно показывать как и когда уместно использовать все эти методики, ООП, паттерны, лямбды и пр.пр.пр. Если же цель иметь просто инструмент для автоматизации работы, то лучше осваивать python. Если цель веб, то JS+Python+HTML/CSS. Соотв. в школах в физмат классах, имхо, стоит учить С/C++, а в не физмат классах знакомить с python.

У вас какой-то неправильный аджайл.

В моём понимании его главная идея в декомпозиции задачи и наблюдения прогресса по каждому кусочку. Чтобы при постройке дома было не так, что ты приходишь и видишь пустой котлован, а строители тебя убеждают, что возвращайся через год и всё будет готово. А вместо этого задача по постройке дома декомпозируется на мелкие и при этом достаточно осязаемые. Чтобы вначале спринта у тебя был список «за эти 2 недели мы построим северную стену первого этажа, западную стену первого этажа, восточную стену первого этажа, южную стену первого этажа» и т. д. И ты приходишь через 2 недели и если стены не построены, то сразу видно, что у вас проблемы. Более того, ты можешь оценить насколько именно серьёзны проблемы - если две стены из 4 всё же построили и строители дали им всем одинаковую оценку сложности, то их перенесут на следующий спринт и удвоят оценку сложности.

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

В системе появляется больше обратных связей.

А ещё continuous delivery, что проект сдаётся самодостаточными кусочками. Если у тебя по проекту рядом с домом ещё и гараж, то его построят быстрее и ты сможешь парковать там свою машину ещё до полной сдачи проекта. С одной стороны быстрее получишь выгоду и будешь радостнее, с другой быстрее накидаешь багрепортов, что там крыша течёт и нужно переделать.

В действительно крупных командах я не работал.

А там, где работал (заказная разработка ПО) по водопаду работал дважды: один раз разрабатывал сайт, в котором до начала разработки дизайнер заказчика нарисовал как должно выглядеть и заказчик расписал текстом всё поведение сайта. Единственный минус — пришлось делать слишком много вручную, а не через фреймворки. И пришлось делать фиксированную ширину в пикселах.

Второй раз делал разработку учётной системы. Там вообще всё гладко было: расписали все блоки, поля, документы, печатные формы. На последнем этапе навтыкали снимки экранов интерфейсов. Получили точный календарный план разработки, тестирования и запуска.

Но всё это проекты на реальных полтора разработчика.

За последние лет 10+ ниодного места не видел, где не аджайл/ скрам.

Потому такую фигню и пишут. Выбор языка/фреймворка/структуры данных даже в аджайле приходится делать на раннем этапе. Но аджайл заставляет вместо того, чтобы писать MVP для создания проекта, а затем уже нормального продукта, прямо из MVP делать рабочую версию. Как C++ из C.

Я так влетел, когда заказчик зарплатной системы последним уточнением требования указал, что расчётный период зарплаты у них с 27 числа предыдущего месяца по 27 число текущего. Такого количества костылей в такой короткий срок я никогда больше не делал.

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

И из-за этого вместо того, чтобы начертить чертёж дома, с заказчиком согласовывается, что дом «какой-то панельный». А количество подъездов он видит, когда смотрит на стены первого этажа. Зато может в этот момент потребовать переделать.

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

Фундамент на сколько этажей закладывать? И нагрузку на первые этажи.

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

Но при этом придётся коммуникации для гаража и дома сделать раздельные.

То есть в итоге получается дороже.

Я с заказчиками практиковал «экспресс-внедрение». По сути это тот же водопад, но с прототипом вместо документации. Пишется быстро-грязно прототип с интерфейсом. На нём согласовывается интерфейс и к нему идёт текст, что именно в полной версии должно быть настраиваемым и каким образом. Дальше разработка строго по согласованному. Любые доработки за отдельные деньги.

То есть вместо первого этажа дома как в аджайл тебе строится его макет в масштабе 1:100 и макет комнаты в масштабе 1:10 и к ним идёт бумажка с описанием, какие коммуникации будут в итоге. Но потом никакие изменения не принимаются до сдачи дома.

Человек получал массу знаний, мог писать самые элементарные программы на основе готовых шаблоном и лабораторных работ, но свободным программистои не становился. Любая нетривиальная проблема - туши свет…

Непонятно, как это вытекает из предыдущего. Паскаль даёт базовое понимание: типы, структуры данных, программные конструкции. Дальше можно шлифоваться бесконечно.

Большое же количество дельфибыдлокодеров (это реальный факт, да) же появилось не потому, что их учили на паскале, а как это ни смешно, по почти противоположной причине. Это люди, который ничему как следует не учились, даже паскаль толком не осилили, но им дали в зубы среду, которая позволяет при очень малом объёме кодирования лихо клепать формочки и приделывать к ним несложную логику. При этом сами язык и среда позволяют делать сколь угодно сложную логику, но тут уже надо уметь кодировать по-настоящему. Как минимум для начала тащить никакой сложный код в обработчики кнопочек, что так любят быдлокодеры.

К сожалению, эта публика очень поспособствовала отпугиванию от паскаля действительно серьёзных разработчиков. Sad but true.

Фундамент на сколько этажей закладывать? И нагрузку на первые этажи.

Очевидно, сколько исходно было в проекте. Тогда выйдет, что фундамент сделали прочнее, чем нужно, но стоять будет. Вот в случае если справились раньше срока и заказчик решит увеличить количество этажей, тогда проблема.

Но при этом придётся коммуникации для гаража и дома сделать раздельные.

То есть в итоге получается дороже.

Да, но если заказчик не частное лицо, а планирует извлекать выгоду из этого проекта, то он раньше начнёт получать доход от сдачи гаража в аренду, например, и этот доход может перекрыть увеличение стоимости строительства.

А количество подъездов он видит, когда смотрит на стены первого этажа.

Важные параметры типа количества жильцов нормальный заказчик укажет заранее.

Ещё раз, в аджайле заказчик быстрее узнает о факапах и может принимать решения чем жертвовать (временем, деньгами, функционалом - и каким именно). А не просто обнаружить в конце срока разработки, что проект не сделан или сделан криво. Он, конечно, сможет требовать неустойку и исправления по гарантии, но пока он этого всего дождётся, он может обанкротиться или просто потерять своё место на рынке.

Рассматривай аджайл как метод минимизации рисков, а не «как сделать идеальный продукт с идеальным заказчиком и идеальным исполнителем в идеальных условиях». Там аджайл неэффективен.

И из-за этого вместо того, чтобы начертить чертёж дома, с заказчиком согласовывается, что дом «какой-то панельный». А количество подъездов он видит, когда смотрит на стены первого этажа. Зато может в этот момент потребовать переделать.

При разработке софта это одна из главных проблем, заказчик хочет чтобы круто, кнопочка и блям-блям-блям.

Я видел такой дом!

снаружи и внутри

В нём живут, он строится, по нему водят туристов. Всё одновременно.

В миллионом городе за 10 лет, ни разу не встречал открытую вакансию на Pascal.

А вакансии, связанные с мейнфреймами в этом городе есть?

паскаль толком не осилили, но им дали в зубы среду, которая позволяет при очень малом объёме кодирования лихо клепать формочки и приделывать к ним несложную логику. При этом сами язык и среда позволяют делать сколь угодно сложную

А могли бы ещё более лихо клепать на VBA.

паскаль толком не осилили, но им дали в зубы среду, которая позволяет при очень малом объёме кодирования лихо клепать формочки и приделывать к ним несложную логику. При этом сами язык и среда позволяют делать сколь угодно сложную

А могли бы ещё более лихо клепать на VBA.

паскаль толком не осилили, но им дали в зубы среду, которая позволяет при очень малом объёме кодирования лихо клепать формочки и приделывать к ним несложную логику. При этом сами язык и среда позволяют делать сколь угодно сложную

А могли бы ещё более лихо клепать на VBA.

Интересная штука, этот ваш Ада. Немного почитал.

Смотря какой обработки: если тебе пробелы на подчеркушки позаменять – ничего проще и быстрее не придумать.

Ты не совсем понял мой пост или просто симулируешь? Давай дуэль) Есть фраза, скажем, «Всё смешалось в доме Облонских.». Нужно рандомизировать порядок слов в предложении и порядок символов в слове, при этом приложив ключ. Например: «свЁ» -> [3, 2, 1] -> «Всё». Целевая аудитория начинающая, индексации с 0 не понимает, если что. Фразы для теста в корректном UTF-8.

Сравним, что там умеет твой Поскакаль супротив скриптятины?) Бонусом я тебе и на Раст это сделаю быстрее в разы этой твоей некромантии.

чтобы зарабатывать, зная паскаль, надо иметь вторую специальность, которая и будет определять ваши доходы. и тут выбор удивительно широк - шофер, массажист, грумер декоративных собак, доставщик еды и так далее.

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

Что значит «первой»? В самом оптимистичном варианте интерпретации это «одна из трех», в самом пессимистичном — одна из многочисленных целей, и далеко не самая значащая.

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

Ты хочешь мне сказать, что Python, JavaScript, C++ были грамотно спроектированными языками для своего времени? Паскаль хорош до сих пор, но у него ПОЧТИ НЕТ НИШ.

Со времен его «грамотного проектирования» в программировании очень много чего изменилось и очень много чего изменилось в «компах»

С 90-х годов изменения в технология программирования ничтожны. Я создавал тред
Какие вы можете назвать революционные технологии ПО, созданные в последние 20 лет?
где с огромным трудом посетителям удалось выдавить из себя несколько пунктов. Изменения есть, но они ничтожны.

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

Это не эволюция языка, а деградация индустрии, которая не способна создать ничего нового. Но да, можно этот же процесс назвать и «эволюция языка», «эволюция разложения трупа», и так далее.

Поэтому я и говорю, если человек хочет специализироваться в железе или системном программировании, то ему нужно учить С/С++, на горизонте полувека эти языки никуда не денутся

Я сотрю, ты в моих тредах не сидел. Потому что я давно и упорно повторяю, что причинно-следственные связи здесь поменены местами: не C/C++ позволяют писать быстрый код, а железо оптимизировано под C/C++, и потому выбора нет. Оптимизировано под сплошные массивы, под однозадачность с синхронным вводом-выводом или многозадачность shared-nothing, под глобальные переменные как единственный механизм дальней передачи контекста, под неперемещаемые объекты в памяти, идентифицируемые цифрой указателя.

Я уверен, что многие читающие думают «ну это же как трава зеленая и небо голубое» — но нет, другие компы были, и даже если бы их не было — их все равно можно было создать по другой модели. Блин, у 8086 была даже специальная инструкция, которая считала байты в нуль-терминированной строке! Хотя, что значит «была»? До сих пор есть. В той самой ублюдочной медленной нуль-терминированной строке ассемблеров 60-х годов, где на каждый чих приходится делать полный проход по строке, чтобы узнать ее длину, в той строке, которая является причиной эдак четверти всех уязвимостей в сишном софте, когда нуль оказываетя потерян и запись-чтение происходит по случайным ячейкам, нередко стэку. К слову, класть небезопасные пользовательские данные в одно место со стэком вызовов — это тоже сишное изобретение, а x86 оптимизировало этот подход в push/pop инструкции.

Но я настаиваю на том, что все это каменный век, и рынок труда медленно, но уверенно отправляет всё это на свалку истории, потому что это софтожелезо крайне неэффективно расходует энергию-транзисторы и не имеет никаких перспектив в развитии (на самом деле уже 20 лет назад не имело). Именно потому индустрия так яростно набросилась на нейронки, и на GPGPU в общем.

Если задачу можно свести к типовой из LAPACK, то почти всегда именно этот вариант даст наилучший результат

Если реализации некой функции из LAPACK нет в cuSolver/magma, то не даст. А если даже к LAPACK нельзя свести, но кому-то очень хочется натянуть сову на глобус? И натягивают. Потому что делать что-то свое страшно, да и разучились все.

Я за использование готовых решений, если они подходят для задачи, но очень часто готовых решений для задачи нет, а есть только чел с молотком, который повсюду видит гвозди, из-за чего намного чаще выдает ненадежные медленные продукты.

Давайте нашу структуру данных делать массивом. А если она не массив, а список, то использовать другую библиотечную сортировку (mergesort)

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

«Распространенность» это попса

Дышать воздухом тоже попса?

Алсо, ты же не против что твои органы не «обновляются» бесконечно, с точки зрения функций? :) В биологических системах это обычно означает поломку

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

и на GPGPU в общем.

Емнип нормальное гпгпу никто так и не осилил, все так же надо писать отдельные ядра и руками их загружать в видяху, а для 90% бытового софта это делать никто не станет. Попытки запились автоматическое выделение ядер компилятором были, например выделять тело цикла в ядро и генерить служебный код вокруг него, но на моей памяти успехом это не увенчалось.

Емнип нормальное гпгпу никто так и не осилил

Массовая индустрия испытывает трудности с ними, но не более того. Есть немало систем (да хотя бы игровые консоли), где память GPU и CPU совмещены, потому для передачи достаточно кинуть видюхе ссыль на кусок данных. Между прочим, nvidia тоже развивает что-то подобное. Тут вся проблема главным образом вызвана плохой расширяемостью традиционных процессоров, главным образом x86, в меньшей степени ARM — в остальном каких-то фундаментальных препятствий нету.

Да, я считаю, что JavaScript и C++ были грамотно спроектированы для своего времени. Они позволили быстро решать задачи, которые было необходимо решать тогда. Переход от С к С++ позволил писать существенно более сложные проекты: gtk вот написан на С, и по факту там на С реализовано ООП через препроцессор и свободу разыменования указателя в произвольный тип данных. Ты пробовал использовать gtk? Это же адский ад, очень тяжело отлаживать, да и писать ясный код тоже не просто. Соотв. с таким подходом очень быстро достигается потолок по сложности проекта, который можно реализовать. С++ этот потолок немного отодвинул, и в частности, это привело быстрому созданию оконных интерфейсов и компы стали гораздо более удобными для массового пользователя.

Какие вы можете назвать революционные технологии ПО, созданные в последние 20 лет?

Не особо понял вопрос, но достаточно посмотреть как изменилось написание кода. В итоге за 20 лет смогли разрабатывать и поддерживать гораздо более сложные проекты, в т.ч. и те, для которых первоначальных авторов уже нет в живых. Браузер 2000 года и браузер 2022 года это несопоставимые по сложности и по объему кода проекты, аналогично можно сказать и про офисы, и про операционки, и про много другое. Если попробовать писать код так, как массово писали код в 80е или даже в 90е, то такие проекты просто никогда не увидят релиз. Вся эволюция ЯП это решение одной единственной задачи: как писать больше кода, совершая то же количество ошибок? Поэтому вводят ограничения на свободу работы с данными и вызовами функций, которые мы относим к концепциям ООП и Функционального программирования, поэтому появляются всякие конвенции о стилистике, поэтому важными становятся всякие паттерны (клише), поэтому синтаксис языка расширяется, чтобы можно было легко использовать все эти новшества…

В GPU все рванули потому, что они стали достаточно мощными для решения задач моделирования и численной оптимизации грубыми методами. И там всем плевать на архитектуру, просто теперь есть инструмент, который позволяет решать новый пласт практических задач. И архитектура GPU тоже будет следовать за языком, а язык за архитектурой.

Да, но если заказчик не частное лицо, а планирует извлекать выгоду из этого проекта, то он раньше начнёт получать доход от сдачи гаража в аренду, например, и этот доход может перекрыть увеличение стоимости строительства.

Не в аджайле тогда гараж выделяется в отдельный проект. И может делаться вообще другой командой, часто дешевле.

Рассматривай аджайл как метод минимизации рисков, а не «как сделать идеальный продукт с идеальным заказчиком и идеальным исполнителем в идеальных условиях». Там аджайл неэффективен.

Скорее перекладывание рисков на заказчика. Как ремонт квартиры без проекта.

потому для передачи достаточно кинуть видюхе ссыль на кусок данных

в остальном каких-то фундаментальных препятствий нету

Ты вот только что назвал фундаментальное препятствие. Суть - надо писать кастомный код, и это больно, даже если надо «просто кинуть адрес видяхе». Взять какую крайне «цикличную» и жручую софтину, например идею/пичарм - я прям очень сомневаюсь что кто-то будет выносить все эти километры циклов на ГПУ, тем более сквозь jvm. А там распараллелить можно очень много всего.

Тогда и ядро Linux написано на мёртвых языках, получается.

Сишка вне системщины уже вполне себе мёртвая, по крайней мере маргинальная уж точно. Да и в ведро не просто так всякий хренораст пытаются впихнуть

Я за использование готовых решений, если они подходят для задачи, но очень часто готовых решений для задачи нет, а есть только чел с молотком, который повсюду видит гвозди, из-за чего намного чаще выдает ненадежные медленные продукты.

Так всё современное программное проектирование — это выбор между костылями (которыми прикручиваем к готовому решению) и велосипедами (которыми заменяем готовое решение). Причём строгого критерия выбора костыля или велосипеда нет.

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

Блокировка диапазона на массив нормально прикручивается.

С++ этот потолок немного отодвинул, и в частности, это привело быстрому созданию оконных интерфейсов и компы стали гораздо более удобными

Как в Apple справились с классическим «Маком» в 1984 без C++? А это разве первый оконный интерфейс?

Как в Apple справились с классическим «Маком» в 1984 без C++? А это разве первый оконный интерфейс?

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

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

То есть что-то сподвигло тебя начать догадываться, что ни у кого никогда и не было цели получить на выходе программистов, а обучение состояло лишь в том, чтобы дать самые основы алгоритмов и структуры программы?

Фортран - можно даже типы явно не объявлять, если очень хочется.

Зы: работаю с мишн-критикал, у нас аджайл.

Можно поинтересоваться, что есть «мишн-критикал» в Вашем понимании? Ну и «аджайл» уж заодно тоже.

Эй, я же не говорю, что невозможно, я говорю, что это очень тяжело сделать на С.

Что там тяжёлого может быть? Наследование структур с Си есть с рождения (и используется в структуре FILE*). X Window System создана в 1982.

C++ позволяет описывать ООП конструкции меньшим количеством кода. И действительная революция C++ — это RAII. Всё остальное вполне реализуется на C.

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

У Вас какие-то странные мировоззрения. Утверждение: с любой структурой можно иметь дело в многопотоке, зачастую без синхронизации, да.

Ну попробуй написать какую-нибудь фигню с кнопками, скажем крестики нолики 3х3, на gtk, а потом на qt, и сравни потраченные усилия. Или попроси начинающего программиста это сделать и посмотри что получится.

C++ позволяет описывать ООП конструкции меньшим количеством кода.

Не просто меньшим, а еще и хорошо анализируемым компилятором, что упрощает отладку. Т.е. по факту мы имеем: а) меньше кода, б) код более выразительный и ясный, в) ошибки ловит компилятор там, где они есть, а не там, где препроцессор поработал. ИМХО, это очень хороший виток эволюции языка.

Наследование структур с Си есть с рождения (и используется в структуре FILE*).

Вот с этого места - можно поподробнее?

Ну попробуй написать какую-нибудь фигню с кнопками, скажем крестики нолики 3х3, на gtk, а потом на qt, и сравни потраченные усилия.

Примерно одинаково. Построчно почти один к одному перевод.

Не просто меньшим, а еще и хорошо анализируемым компилятором, что упрощает отладку.

Ну не знаю. gdb и прочие отладчики с Си++ работают значительно хуже, чем с Си.

Похоже, что нельзя. Не могу найти, где я это видел…

Ладно, оставим часть, что наследование есть.

Паскаль - простой и хорошо продуманный язык. Сделан людьми, понимающими что такое дизайн ЯП (привет хакерам Bell). Ставит мозги - закладывает аккуратность и структурированное мышление, потому идеален как первый язык. Среди хоть немного распространенных ЯП ничего лучше по этим критериям не сделали.

Закладывать цель работать на нем не надо. И пытаться учиться и работать на одном и том же языке тем более не надо, дубовый будешь.

Питон как первый - хз, неплохо вроде, MIT не даст соврать. Аккуратности поменьше, зато абстрактности больше, и код проще (если взять простое подмножество питона).

«Менее популярное» != «мёртвое». «Мёртвое» - это когда больше не используется вообще никем.

Наследование структур с Си есть с рождения

… и до 99-го, когда его запретили.

Всё остальное вполне реализуется на C

Как насчет наследования в системе типов?

Всмысле saahriktu?

https://i.ytimg.com/vi/7gNqoNgdktA/maxresdefault.jpg

С 90-х годов изменения в технология программирования ничтожны. Я создавал тред Какие вы можете назвать революционные технологии ПО, созданные в последние 20 лет? где с огромным трудом посетителям удалось выдавить из себя несколько пунктов. Изменения есть, но они ничтожны.

Просмотрел этот твой тред, только на первой странице куча революционных технологий представлена. Другое дело, что ты их можешь не считать революционными. Ну так а что вообще принципиально нового тогда со времён фон Неймана было создано? Так, новые абстракции городили поверх машинных кодов и устройства ввода-вывода полировали.