История Photoshop

Этому посту 12 лет уже :)

я только наткнулся, прикольно, не знал, что оно на паскале было когда-то

Фотошоп уже не тот: версии для телефонов, нейросети добавили
Срамота

Неужели они сделали нейросеть на паскале? Или на ассемблере?

А вот еще такой вопрос интересный. Раньше действительно была мода на паскаль. Хотя Си уже существовал. С++ наверно тоже, но это неточно. И все же, большие ожидания были именно от паскаля, как от более высокоуровневого языка. Поэтому наверное выбор паскаля в то время для первой версии фотошопа был очевиден.

И почему же все-таки проиграл паскаль на фоне Си и С++?

Begin-End – думаю, не проблема для сегодня. Тем более современные студии сами дополняют код по первым буквам. И если взглянуть на Си, любой исходник с ГТК+, там ведь названия функций – трех- четырех- этажный мат. Читаешь такое и думаешь, это ты выругался или демона призвал? Короче, много-букв не проблема.

Блоки объявления переменных. В паскале переменные должны быть объявлены в специальном блоке var. В ранних сях образца 89 года, тоже переменные объявлялись только в начале функции. Компилятор жестко ругался, если это не так. Современные компиляторы просто выдают предупреждение, что мы то такое уже осилим, но ты либо стандарт смени, либо подвинь там все.

Я думаю, это требование у ранних компиляторов было из-за прохода по тексту. И ограничениям памяти. Что он сначала должен знать с чем работаем, а потом уже работать. Ведь представь у тебя все дети уже сыты, рассажены по местам, регистрам, памяти… и тут бац картина Репина «не ждали». Тебе придется разместить нового ребенка. А у тебя все уже подобрано. Еще раз все переделывать.

Помнится такие еще одно- и двух- проходовые ассемблеры. Помните такое?

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

не знал, что оно на паскале было когда-то

Оно было на Pascal’е, потому что Pascal был first-class citizen в MacOS Classic, на нём было всё UI и системные API. А C, C++ на MacOS были second-class citizen, и в них там даже есть Pascal расшерения, типа строк вида `«\pString» – Pascal-строка.

А, ещё Adobe очень долго тянул внутри виндового Photoshop порт всеобъемлющей GUI-либы MacOS Classic которая называлась Macintosh Toolbox на Windows, WinAPI.

Видимо портировать эту либу на WinAPI/GDI им показалось легче, чем сделать нативный порт Photoshop на WinAPI.

И почему же все-таки проиграл паскаль на фоне Си и С++?

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

Кроме того, виртовский паскаль был все-таки учебным языком, для реального прикладного программирования использовались сильно несовместимые между собой реализаци от Borland, Microsoft и некоторых других. Причем Microsoft потом в районе 89-го года с Borland можно сказать, что поделили сферы влияния: Borland прекратил развивать Turbo Basic, а Microsoft - Quick Pascal. От Си оба не отказываются.

Но при этом паскаль от Borland был уже не столько паскаль, сколько Модула-2 к которой добавили ООП. Если почитать книгу про Модула-2 можно увидеть, что почти все ее фичи были реализованы в Borland/Turbo Pascal.

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

И хотя тогда разные реализации Си тоже имели несовместимости, но куда меньшие, а в 1989-м году вообще появился стандарт C89/Ansi.

Так что я думаю, победа Си была обусловлена:

1) Стандартизированностью Си и лучшей переносимостью, по сравнению с паскалем. Меньшим вендорлоком.

2) Все же бОльшим распространением Си вообще и бОльшей универсальностью.

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

Сишные хидеры - это вообще не модули. Нет, тут однозначно паскалевские (а точнее Модула-2-шные) модули удобнее си-шных хидеров. Причем при желании в паскале (как минимум борландовском) тоже можно было вставлять хидеры и/или код через директиву {$include «имя файла»}

А вот еще такой вопрос интересный. Раньше действительно была мода на паскаль.

Некоторые первые прикладные операционные системы, родословная которых берёт своё начало с года создания языка программирования C и даже раньше, действительно использовали Pascal в качестве языка программирования высокого уровня, поскольку C был младше и не так распространён.

Кроме упомянутой Mac OS Classic, которая древнее Windows и тем более Linux, ещё Pascal использовали в GRiD-OS (первые в мире ноуты): https://deltacxx.insomnia247.nl/projects/gridcompass/large_files/Yahoo%20group%20backup/RuGRiD-Laptop/files/6_GRiD-OS-Programming/5_Common-Code-Reference.pdf

А вот, например, в Xerox PARC Alto использовался предок C – BCPL, аналогично именно на BCPL были написаны первые версии AmigaOS (AmigaDOS).

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

Еще интересно из истории языков программирования. Заметили? По-сути исчезли функциональные языки, декларативные. Императивные победили. Всякие ерланги, реакты вспыхнули и канули в лету. Даже модное одно время реактивное программирование на С++ сдохло. Тоже не взлетел подход.

С++ наверно тоже

Нет. Кроме реализаций на большие машины, паскаль был базовым языком на Apple’ах и очень очень популярен для IBM PC в 80-ые годы. По нему было море литературы. Первые компиляторы на крестах стали доступны где-то после 1990-ого года.

Видимо портировать эту либу на WinAPI/GDI им показалось легче, чем сделать нативный порт Photoshop на WinAPI.

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

на Си можно было написать ядро ОС, а вот на паскале не очень

На паскале был написал Apple DOS. Операционку такого уровня на паскале вполне можно сделать.

И почему же все-таки проиграл паскаль на фоне Си и С++?

Переносимость на разное оборудование. Оно (оборудование) было очень разным и ожидалось, что будет ещё разнообразнее. Например, процы Itanium могут работать как в big-, так и little-endian режимах - эту фичу сознательно запилили прямо в проц, так как хотели сесть на оба стула сразу.

Грамотно написанный сишный код достаточно перекомпилировать, и, что важнее, есть (сейчас уже утерянная) культура написания аппаратно-независимого кода. Паскль же практически всегда для больших проектов с непростой работой с оборудованием надо сочетать с ассемблером. Итого, если пишешь на паскале - то пишешь под конкретную комбинацию аппаратура + ассемблер + реализация паскаля. Сишный код можно успешно сконпелять, заменив компилятор и часть исходников - включаемые файлы.

Возможно, они оказались менее удобны, сишных хидеров.

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

Это, внезапно, много где играло роль. Скажем, первый DOOM разрабатывался на NeXT’ах под NeXTSTEP’ом, хотя имел как целевую платформу более слабый IBM PC.

Победила практически реализованная кроссплафторменность, пусть даже реализованная в таком всратом виде, как на си.

И почему же все-таки проиграл паскаль на фоне Си и С++?

Потому что юниксы и оффтопик написаны на Си, их нативные интерфейсы сишные, и только на Си не нужно делать дополнительных прокладок совместимости между ОС и прогой. Так что вопрос сводится к: 1) почему юникс в 70-е годы написан на Си, 2) почему линукс а начале 90-х написан на Си, 3) почему вин9х написан на Си. Всё остальное - строго следствия этих трёх событий, мнение прикладных программистов про удобство/неудобство синтаксисов этих двух языков тут уже роли не играло.

А компилировать чем? А то руки чешутся.

почему юникс в 70-е годы написан на Си

Эм... Потому что Си был написан для юникса. Это же очевидно. Но в начале был ассемблер.

Потому что юниксы и оффтопик написаны на Си

Это все понятно и имеет место быть. Но больше интересует вопрос о том, почему Паскаль не выстрелил в качестве языка написания ОСей? Только лишь портируемость кода на разные архитектуры была главной причиной или есть что-то еще?

Раньше действительно была мода на паскаль.

Вернее, Borland VCL

И почему же все-таки проиграл паскаль на фоне Си и С++?

MSVC++ пришёл.

Еще интересно из истории

Open Source Pascal Operating System Kernels ©.

И почему же все-таки проиграл паскаль на фоне Си и С++?

Мое личное понимание (местами могу путаться в показаниях):

Паскаль пришёл из европейского университета, а Сишку пиарила могущественная коммерческая AT&T (Bell Labs), которой надо было UNIX продавать. Там даже Ричи чернуху всякую лабал заказную про то, как плох Паскаль. Разумеется, UNIX разошёлся по учебным заведениям в США - оттуда, внезапно, получаются будущие сотрудники коммерческих компаний, который написали все остальное.

Паскаль, к слову, далеко не только Виртовский бывает, с которым любят сравнивать Сишку и С++. А ещё были и всякие Модула, etc. Из всей этой ветви языков теперь только обрубок Golang.

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

В те времена очень много было на Паскале. Даже первые версии Windows. Отличный язык без тонн UB. До сих пор в C нет ряда возможностей, которые были даже в первых вариантах Паскалей.

Begin-End – думаю, не проблема для сегодня.

Глаза режет.

Тем более современные студии сами дополняют код по первым буквам.

и призывают демонов.

только на Си не нужно делать дополнительных прокладок совместимости между ОС и прогой

Дурацкая идея. Не только в плане выбора языка, но и с точки зрения совместимости. Разные версии C тоже имеют различия, которые приходится обходить ifdef-костылями. Еще одно свидетельство незрелости линукса в качестве ОС общего назначения.

Взрослая ОС должна быть индифферентна к прикладным ЯП-ам, как, например, винда. Но для этого же стабилизировать ABI надо, а джастфорфанщики на это пойтить никак не могут.

Глаза режет

Глаза как раз режет клинопись из нечитаемых символов, характерных для C-подобных языков. Можно подумать, у современного говнокодера мысля прет с такой скоростью, что написать «begin» вместо фигурной скобки – уже проблема. А еще в Паскале нет UB, вообще нет.

Можно подумать, у современного говнокодера мысля прет с такой скоростью, что написать «begin» вместо фигурной скобки – уже проблема.

Нажать «shift + [ ]» быстрее чем выписывать begin-end, и сам код не выглядит кучей ненужных однотипных «словов».

Еще одно свидетельство незрелости линукса в качестве ОС общего назначения.

В голос... А мужики-то и не в курсе.

Взрослая ОС должна быть индифферентна к прикладным ЯП-ам, как, например, винда.

Ну да, конечно...

А мужики-то и не в курсе

Система общего назначения без стабильных программных интерфейсов – это система трех процентов маргиналов. Можете попробовать опровергнуть сей тезис.

это система трех процентов маргиналов.

Жгите дальше.

стабилизировать ABI надо

https://lkml.org/lkml/2012/12/23/75:

«WE DO NOT BREAK USERSPACE!»

Нажать «shift + [ ]» быстрее чем выписывать begin-end,

Это для программистов в классическом понимании слова - забивать код. Чем вы занимаетесь, что у вас вколачивание исходного кода - bottleneck продуктивности?

Очень слабый аргумент.

Чем вы занимаетесь, что у вас вколачивание исходного кода - bottleneck продуктивности?
Последнее исправление: vsnb 12.04.25 06:15:50 MSK (всего исправлений: 2)
исправлений: 2

Все что надо знать о продуктивности говорящих о продуктивности.

WE DO NOT BREAK USERSPACE!

Молодцы (хоть и вранье). Но операционная система – это не только юзерспейс.

Самая большая проблема линукса – хреновые или очень хреновые драйвера. Постоянно линуксоиды ноют, что вендоры не хотят писать драйвера под их маня-систему. А как их, мать, вашу, писать, если у вас каждый третий апдейт ядра все ломает к чертям? Нафига тратить кучу ресурсов ради 3% красноглазых задротов?

В те времена очень много было на Паскале. Даже первые версии Windows.

Такого никогда не было.

думаешь […] демона призвал […] не проблема.

Ну не знаю…

Молодцы (хоть и вранье).

Почему враньё-то? Абсолютная правда. Если пишешь userspace’ную программу, то она у тебя годами будет и компилироваться и работать, если уж и не скомпилируется, то очень маловероятно что из-за изменений в ядре, скорее из-за изменений в компиляторе, но ещё более вероятно - из-за изменений используемых библиотек.

А вот попробуйте написать драйвер работающий на уровне ядра и он уже через полгода наверняка под новое ядро не скомпилируется.

А почему денежный вопрос никто не рассматривает? Почём продавалась Сишка и почём - Паскаль?

Заметили? По-сути исчезли функциональные языки, декларативные. Императивные победили. Всякие ерланги, реакты вспыхнули и канули в лету.

LINQ в C# активно используется.

А оно продавалось? Не втюхивалось как зонд?

Ещё как продавалось. Для IBM PC-то.

Причем на Си можно было написать ядро ОС, а вот на паскале не очень, если не прибегать к хакам

Разверни мысль

Разверни мысль

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

В паскале ряд стандартных функций и процедур поддержаны на уровне «магии компилятора», например, Write/Writeln - мало того, эти процедуры принимают переменное число параметров, что невозможно для написанных пользователем. Впрочем, может быть, сейчас Delphi и FreePascal уже научились и для пользовательских это делать, я не следил.

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

Но жаль, если бы паскаль/модула-2 стали бы тем, чем сейчас является Си и потом C++, может не пришлось бы изобретать такие вещи как Rust. В отличие от Си, в Паскале есть развитая система типов и он существенно более безопаснее, при этом не настолько сильно бьет по рукам. В целом, получается так, что паскаль не дает случайно выстрелить себе в ногу, но если хочется, то и не мешает.

Ядро-то это как всё мешает написать

В Паскале тоже можно устраивать шизоидые свистопляски со ссылками и указателями во славу Сатане, например

Ядро не является обычным исполняемым файлом, оно по-особому грузится и получает управление. Еще и переход между режимами работы процессора: в случае x86 от реального к защищеннному и 64-битному. Для Си есть штатные способы все это компилировать.

P.S. Хотя сейчас задумался, что не знаю как в gcc компилируется код перехода от 16-ти битного режима к защищенному. LOL.

почему Паскаль не выстрелил в качестве языка написания ОСей? Только лишь портируемость кода на разные архитектуры была главной причиной или есть что-то еще

ЧатГПТ говорит, что когда Томпсон и ко разрабатывали B, они взяли BCPL за основу. Последний был создан раньше Паскаля, он уже использовался в системном программировании и для него было проще написать компилятор. Дальше просто улучшили В.

gcc не умеет 16-и битный код.

Паскалевские модули. Возможно, они оказались менее удобны, сишных хидеров

ЩИТО

Модули – вероятно, лучшее, что есть в объектном Паскале (TP, Delphi, FPC). Сишные «хидеры» это только верхушка хтонического ужаса, используемого в плюсах и сишке вместо модулей. Сюда ещё плюсуем стражи компиляции и усилия бедного линкера, которых каждый раз вынужден метаться с объединением объектных файлов, в которых непонятно что ссылается непонятно куда. Сами «хидеры» не являются языковой единицей, это всего лишь команда препроцессора по включению одной простыни текста в другую простыню текста.

Моя любимая страшилка для вечера субботы

Про транзитивность #include

А сейчас в современный С++ тоже вкорячивают модули.

Именно поэтому. Одобряю. Наконец-то.

Паскаль как язык прикладного программирования мне жалко. Вероятно, причина его увядания кроется в том, что долгое время им, кроме Borland, никто не занимался. Вот как бы Croco ни наезжал на «комитетские» языки, плюсам этот комитет гарантирует практическую неубиваемость. Там много игроков, и если завтра условный интел перестанет поддерживать свой компилятор – Вселенная этого просто не заметит. А "некомитетский " Паскаль в руках одного игрока зачах.

Модный ныне Rust, кстати, тоже в руках одного игрока. Поэтому я, не являясь растоненавистником, всё же несколько опасаюсь его глубокого внедрения в ядро и системные компоненты…

Чё? А как тогда для реального режима писать? Без ОС. Загрузчик например.