Так вот, с моей точки зрения, Линукс — уебищное говно, кривое и неюзабельное, с уебищной архитектурой(кривой и непродуманной), с уебищными API(малофункциональными и неудобными), с уебищной инфраструктурой(глючной, кривой, неудобной, и слепленной на коленке), и так далее.
Поэтому меня искренне удивляло, до некоторого времени, нахуя люди этим уебищным говном пользуются(если отбросить варианты вроде отсутствия денег и/или желания приобщиться к мнимой технологической элите). Но что меня еще более удивляло — так это то, что когда людям говоришь об уебищности вот этого говна, они начинают агрессивно доказывать обратное, но доказывать практически не пользуясь никакими логическими доводами, доказывать эмоционально(чуть ли не как пособия по этологии), как будто бы им нанесли личное оскорбление, а иногда и не доказывать, а явно воспринимать это как личное оскорбление.
Нет, ну вы подумайте! Человек воспринимает указание на технологические недостатки некоторых конкретных реализаций некоторых абстрактных концепций как личное оскорбление. Оскорбление кучи байтов! Я думал, вот это вот пиздец, если это не шизофрения, то я даже не знаю, какой она бывает.
…
Когда дело доходит до разработки ПО, эмоции только мешают, причем очень сильно мешают. "Чувствование"(вместо продумывания) ведет к дерьмовому коду, и, как следствие, к дерьмовым программам.
via http://love5an.livejournal.com/360953.ht...
@cirnofag: БЕЗЭМОЦNАНАЛЬНЫМ
17 comments
recommend
bookmark
subscribe
Все доводы взяты откудато с потолка, лол.
>Чтобы объяснять детали в подробностях, надо, во-первых, иметь дохуя свободного времени и желания печатания на клавиатуре, а во-вторых, общаться с соответствующим собеседником. Какой смысл объяснять анонимусу, речь которого изобилует тухлыми мемами с Lurkmore.ru("хуита" etc.) о нутре, да или хотя бы интерфейсе линукса в сравнении с нутром/интерфейсами других ОС?
Что касается нефункционального апи, то это очень-очень толстый наброс, предназначенный для нихера не шарящих жопоголовых убунтоидов.
ШТО?
"Поэтому меня искренне удивляло, нахуя люди этим уебищным говном пользуются?"
Любопытно. Пойти-бы, что-ли, у хостера или провайдера поинтересоваться?
древняя же паста.
http://love5an.livejournal.com/360953.ht... У меня в голове около этого комментария нарисовалось +150 зелёным цветом.
Интенсивность: 100%
Жирность: 100%
Fat Opaque Particles: 9000, later 100500 (не уверен, что меня поймут, но похуй)
>POSIX — говно, объективно.
>макосьными интерфейсами ни в какое сравнение не идет
вот это мне шаблон порвало, кстати.
Хуевый вброс хуев.
Жалко его, так быстро слился на банальщине. Видно, что даже не ковырял и близко линупсы. Я вот могу обоснованно показать, почему вынь-апи бычий кал, это просто! Отсутствуют высокоуровневые абстракции (не дотнет, а именно для цпп), те, что есть (MFC) дико перегружены и переусложнены как архитектурно, так и чисто в прикладном смысле — необходимо писать массу кода для выполнения простых вещей. Я писал на WTL, знаете ли, установка свойств окна через шаблонные параметры — это индусная жемчужина. Чисто сишные интерфейсы везде, а у функций, порой, параметров раза в 2 больше, чем используется на деле, т.е. 50-80% ставятся в NULL и 0. Разного рода security descriptors и прочее. Казалось бы, неужели сложно было сделать вараинт функций без этого кала? Посмотрите на линуксовые сишные функции, 1-4 параметра, ничего лишнего.
Далее. Часть реально нужных компонентов просто отсутствует, например, плавающие панели, сплиттеры (тягаемые разделители, да), они есть только в WTL, и реализованы как костыль над стандартными окнами вручную, т.е. в каждой библиотеке их надо делать заново. Хвалёные компоненты из MSO также есть только в MSO, а в программах они отрисовываются руками поверх менюшек и кнопок. Сколько в этом велосипедизма — одному болмеру известно. Создание тулбаров — адовый чад кутежа, сначала набить список изображений и подписей к ним через какой-то анал типа OLE, потом прилепить его к тулбару, причём, часть операций делается через посылку сообщений контролу, а часть — через вызов функций (которые оборачивают эти сообщения, но это есть не для всего, насколько я помню). Причём, часть контролов вынесена в commctl32.dll, а часть можно сразу так создавать. Когда мне пришлось работать с GTK+, я буквально РЫДАЛ, насколько там всё просто и логично и насколько хорошо сделана документация. Пусть это был PyGTK, там прослойка тонкая. И всё равно, в одной библиотеке логично и интуитивно понятно сложено всё, что размазано костылями по WinAPI, Common Controls, GDI+ и прочим убожествам, вдобавок, с ним удобно работать и по функционалу оно превосходит виндовые поделия.
Пробовали загружать JPG/PNG/GIF в GDI+? А сохранять? Там надо сначала создать объект-компрессор, выставить у него параметры, потом проделать ещё десяток магических манипуляций, подать на вход битмап, а на выходе он должен высрать жепегешку. И с декодированием так же, потому что основные контролы cannot into нормальные графические форматы, а умеют лишь RGB BMP, так что потом к этому прикручиваются адовой степени ООПшности костыли в виде GDI+ (логика там и не ночевала, как и в OLE с его гуидами, проксями и маршаллингом). К счастью, GTK появился позже, а также stable api is nonsense, слава тем людям, кто это понимает, и поэтому от подобного говна достаточно быстро избавляются, тогда как в M$ поддержка легаси есть линия партии, и пусть девелоперы страдают. И проектировка интерфейса в glade3 в линупсах имеется, причём, полноценная, со сплиттерами и табами, а не как в ресурсах диалогов (вдобавок, редактор ресурсов доступен только в платной студии, хотя есть ещё корявенькие сторонние поделки, но у меня, помнится, были с ними проблемы).
И это я только гуя коснулся, а про создание драйверов вам могут лучше рассказать матом те, кто их писал. А также пояснить за всю хуйню, почему под винду практически не создаются драйверы виртуальных файловых систем, тогда как под линукс их жопой жуй, да и то подавишься. Хинт: потому что виндовая модель драйверов писалась под индусным впечатлением от сетевого стека, а в линуксе — для живых людей.
Довершу простыню. Говёность виндового API не только в том, что оно вот так размазано. И не только в том, что оно необоснованно переусложнено. И даже не в том, что то, что мы видим в приложениях даже от самого MS на деле отсутствует в стандартных библиотеках.
Это всё хуйня. С этим можно жить и бороться.
Говно в том, что все эти вещи разных уровней абстракций надо использовать ОДНОВРЕМЕННО. В одной программе мы и посылаем сообщения окнам контролов (да, там каждый контрол — это самостоятельное окно, вы не знали? В иксах же окно — это окно, а контролы рисуются приложением через его библиотеки как оно того хочет, что, кстати, защищает от посылки разных кликов кнопкам одного приложения из трояна-другого), и создаём объекты GDI+ для работы с картинками, и ебём гуиды, скажем, DirectSound со своими ебаническими пиздецами, и всё это перемешивается в объектно-процедурный код. Дотнет, конечно, нависает над подобным кошмаром своей 200-метровой тушей, но всё же даже если отбросить его неповоротливость, он имеется далеко не у всех. Хотя с этим ситуация понемногу выправляется, но мы будем настырными и напомним, что для успешной работы с любым приложением надо держать ВСЕ версии фреймворка от 1 до 3 (или уже 4-я вышла?). Я и сам сталкивался, что ставил 3-й, а нужен был 2-й. Видимо, в M$ тоже попытались следовать линуксовым тенденциям поломки API, но почему-то забыли, что на их платформочке превалирует закрытый код, который влёгкую забрасывается девелоперами без надежд на реинкарнацию на новой версии их фреймворка. В итоге, имеем парк программ, которые не работают на 2 и 3-м, и всем на это похуй автоматически (по безысходности), потому что похуй девелоперу.
Тра-ля-ля, энжой ёр проприетари шыт.
Ощущаю Силу и многолетнюю мудрость в словах твоих, брат. Схоронил пасту.
Теперь ты вооружён мощным оружием против спермобыдлокодеров!
Я не могу направить его против себя.
Уверен, что не все так гладко с тем же GTK и qtlib.
Да, и что вы собственно видите плохого в "чисто сишных интерфейсах"?
В своей статье вы высказали мысль о том, что нужно было сделать версию функций АПИ без параметров для security descriptors и "зарезервированных" параметров. Тогда, получается, для той же CreateFile и OpenFile будет 2-3 версий функций, правильно я вас понял? Если это так, то это приведет к "перегруженности" и "архитектурной переусложненности", не так ли?
В чисто сишных интерфейсах я вижу как минимум устарелость с т.з. современных парадигм программирования. Толковых оболочек для этого нет (если не считать упомянутых Qt/GTK и GTKmm), мелкософт их не предоставляет. MFC страшен, .NET монструозен. Нет, я не считаю, что выделение функций без параметров в отдельную сущность что-либо перегрузит, ведь их можно было б вынести в отдельный .h, и если программист не собирается связываться с этим делом, он просто не инклудит этот файл и использует короткие версии. Получилось бы компактно и красиво, но M$ не умеет такое делать, увы. Вообще, зарезервированные параметры — это бред, серьёзно. И проистекает он из двух фундаментальных вещей Windows: закрытость платформы (идеологическая, которая распространяется на весь её софт) и бинарная совместимость с любым древним говном, хотя и это уже похерено давно. Говорят, на семёрке много старого софта не идёт, но в EXE файлах мы по-прежнему видим CANNOT BE RUN IN DOS MODE. Легаси, деградация, рабство, безыдейность.
Так как винда — платформа очень коммерческая, и с её пользователей стремятся драть три шкуры, впаривая исправитель ошибки №100500 за $19.99 (серьёзно, есть такие программы с одной кнопкой за бабло), то ожидать подвижек в этой области не стоит. Тогда как на линуксе даже если что-то в API ломают, делается это не с потолка, обычно есть серьёзные причины (хотя и бредовые бывают, что уж тут). И если это вызовет отказ работы некоторых программ, автор или любой другой программист может взять исходники, исправить их для работы с новыми интерфейсами и всё снова будет чудесно. Да, это создаст некоторый промежуток, пока программа не будет работать с новым API, но:
1) в стабильных дистрибутивах никогда не обновляют библиотеки, пока остальные программы не переделают под новые или изменённые функции, так что юзер ничего не заметит;
2) если обновление уже должно произойти, а автор так и не удосужился починить свою поделку, её выкидывают из дистрибутива;
3) а если эта программа сильно важна вам, просто не обновляйте библиотеки, обычно патчи безопасности бэкпортируются.
Эти механизмы отработаны годами, и, как правило, юзер сам виноват, что решил пообновлять библиотеки, назначения которых он не знает, «а потом рабочий стол пропал и мышки нет, чёрный экран и буквы».