![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Мозголомающие средства разработки.
После недельного писания на F# появилась идея, отчего использование дельфи так часто вырывает мозг программистам.
Суть в том, что дельфи это законченный продукт с замкнутым комьюнити. Собственно говоря, для работы на нем ничего кроме самого дельфи и нескольких сторонних компонентов (которые никуда больше и не пригодны) не нужно. Соответственно, у программистов тупо не было стимула выглядывать за пределы своей песочницы. В дельфи было все, необходимое и достаточное, чтобы писать всякого рода опердень в то время. Причем в силу простоты - это еще и стимулировало индивидуальное вкалывание, нахрен нужна какая-то командная разработка, какие-то процессы и прочие атрибуты, если один человек мог спокойно сделать достаточно немалую софтину.
Сишные и С++ либы, опять же, не подключались без извращений типа "завернуть в dll с plain C интерфейсом".
Сколько я не смотрю на другие средства разработки - там обязательно есть какая-то шиза на тему того, что невозможно пользоваться, не вкурив штук пять смежных областей. Тот же дотнет - это просто страшная сборная солянка из XML, веба, рефлекшена с кодогенерацией, хитрожопого ООП, причем некоторые вещами оттуда до сих пор проще переписать чем использовать готовые.
Послушаешь![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
zabivator и прочих про ocaml - это просто гамон, какие-то сишные компиляторы, какие-то либы, портирование между виндами и линуксами и прочий мрак.
Жаба энтепрайзная тоже страх какой-то, судя по количеству фреймворков, методик взаимодействия с внешним миром и прочего.
Т.е. все другие платформы ориентированы или на работу в команде с разделением труда или на знание множества смежных шизов, что в любом случае не дает окопаться в песочнице и 20 лет самостоятельно пилить одну и ту же опердень.
Суть в том, что дельфи это законченный продукт с замкнутым комьюнити. Собственно говоря, для работы на нем ничего кроме самого дельфи и нескольких сторонних компонентов (которые никуда больше и не пригодны) не нужно. Соответственно, у программистов тупо не было стимула выглядывать за пределы своей песочницы. В дельфи было все, необходимое и достаточное, чтобы писать всякого рода опердень в то время. Причем в силу простоты - это еще и стимулировало индивидуальное вкалывание, нахрен нужна какая-то командная разработка, какие-то процессы и прочие атрибуты, если один человек мог спокойно сделать достаточно немалую софтину.
Сишные и С++ либы, опять же, не подключались без извращений типа "завернуть в dll с plain C интерфейсом".
Сколько я не смотрю на другие средства разработки - там обязательно есть какая-то шиза на тему того, что невозможно пользоваться, не вкурив штук пять смежных областей. Тот же дотнет - это просто страшная сборная солянка из XML, веба, рефлекшена с кодогенерацией, хитрожопого ООП, причем некоторые вещами оттуда до сих пор проще переписать чем использовать готовые.
Послушаешь
zabivator и прочих про ocaml - это просто гамон, какие-то сишные компиляторы, какие-то либы, портирование между виндами и линуксами и прочий мрак.Жаба энтепрайзная тоже страх какой-то, судя по количеству фреймворков, методик взаимодействия с внешним миром и прочего.
Т.е. все другие платформы ориентированы или на работу в команде с разделением труда или на знание множества смежных шизов, что в любом случае не дает окопаться в песочнице и 20 лет самостоятельно пилить одну и ту же опердень.
no subject
Линукс далеко не закончен.
> Зачем куча систем сборки если есть make?
Если есть make, то почему существует autoconf?
> Зачем несовместимые компиляторы - для студии свой, для билдера свой?
Дык и под линуксами компиляторы Си совместимы плоховато.
> Зачем куча говна - MFC, ATL - которые поддерживает нормально лишь студия?
"Зачем куча говна -- KDE, Gnome -- которые поддерживает нормально лишь под Линуксом?"
Демагогия.
У Маков вообще свой язык программирования ОбжективСи, своё всё, и ничего. На Юниксах традиции партизанщины намного сильнее -- сотни шеллов, тысячи языков, даже утилиты отличаются.
> Зачем ASP и .NET (конкретно - WPF, и что там было модным до? Window Forms&), с которыми за пределами студии невозможно нормально работать?
Вот уж пук в лужу. Как раз с .Net лучший инструмент ReShaper.
> И при этом нету СТАНДАРТА ДЕ-ФАКТОР и ДЕ-ЮРО - POSIX ... Нету стандартных каталогов для заголовочных файлов и библиотек.
Всё это конечно интересная теория, но что-то я очень много кода видел вида
#ifndef FreeBSD
#ifdef _AIX
#include
Линукс далеко не закончен.
> Зачем куча систем сборки если есть make?
Если есть make, то почему существует autoconf?
> Зачем несовместимые компиляторы - для студии свой, для билдера свой?
Дык и под линуксами компиляторы Си совместимы плоховато.
> Зачем куча говна - MFC, ATL - которые поддерживает нормально лишь студия?
"Зачем куча говна -- KDE, Gnome -- которые поддерживает нормально лишь под Линуксом?"
Демагогия.
У Маков вообще свой язык программирования ОбжективСи, своё всё, и ничего. На Юниксах традиции партизанщины намного сильнее -- сотни шеллов, тысячи языков, даже утилиты отличаются.
> Зачем ASP и .NET (конкретно - WPF, и что там было модным до? Window Forms&), с которыми за пределами студии невозможно нормально работать?
Вот уж пук в лужу. Как раз с .Net лучший инструмент ReShaper.
> И при этом нету СТАНДАРТА ДЕ-ФАКТОР и ДЕ-ЮРО - POSIX ... Нету стандартных каталогов для заголовочных файлов и библиотек.
Всё это конечно интересная теория, но что-то я очень много кода видел вида
#ifndef FreeBSD
#ifdef _AIX
#include <inet.h>
#ifdef LINUX
#include <net/net.h>
#endif
Видимо это "стандарт".
Собственно почитайте классические книги по современному Юникс-программированию, Робачевского скажем, там рассказывается, что даже у банального open()/write() разные ERRNO и поведение под разными системами. "Стандарт POSIX." Переносим, ага.
> Ну так соберите мне gcc под вендой без напильника.
Интересно, как же это cygwin умудряются его собирать. Видимо, с напильником.
> Да и собрать deb пакет (один из самых сложных пакетов среди линуксов!) В РАЗЫ ПРОЩЕ ЧЕМ СОБРАТЬ ИНСТАЛЛЯТОР ПОД ВЕНДОЙ
Ну едрить твою в кочерыжку бабушку, это ж сравнить негров с мотоциклами!
Вообще-то инсталляторов "под Виндой" тыщи, как и "под Юниксом".
Ознакомьтесь: http://en.wikipedia.org/wiki/List_of_installation_software -- особенно с секцией "кроссплатформенные".
Если некоторые из тысяч лично у Вас вызвали такие вот ощущения, это не доказывает универсальности опыта. Наивно Вы считаете, что писать и отлаживать скажем скрипты с chmod муфиле+х как-то легче, чем бейсик с аналогичными командами.
А скажем, типовой инсталлер под Виндой для Дельфи был InstallShield Express, там вообще не было окна скриптования.
Так что
Да и собрать инсталлятор под виндой В РАЗЫ ПРОЩЕ ЧЕМ СОБРАТЬ DEB ПАКЕТ!!!111 пыщпыщ!
no subject
Вот инструкция, всё просто и понятно.
http://www.debian.org/doc/maint-guide/
Жду встречной ссылки на описание процесса сборки инсталлятора
С остальным значит согласны.
Хотя для идиотов и юристов описывают:
http://documentation.installshield.com/Robo/BIN/Robo.dll?tpc=%2Frobo%2Fprojects%2Finstallshieldlivinghelp%2FISLivingHelpMain2.htm%3FRINoLog28301%3DT&mgr=agm&wnd=InstallShieldLivingHelp%7CMain&agt=wsm&ctxid=
А вообще конечно deb/rpm это убогие по возможностям костыли для программеров. Скажем, типовой виндоинсталлер предлагает Всё/минимум/кастомизируй, может править конфигурацию для стандартных компонентов, ставить спец.дрова, проверять систему нетривиальным образом. Как это решается в дебиане? "Напишите скрипт". Во сервис, а.
Re: С остальным значит согласны.
В генте ещё нужно прописать патчинг всякий.
no subject
Примеры можно? Желательно, сравнимые с MFC - где vptr смещен на 4 байта относительно начала класса.
no subject
Просвещайтесь:
http://en.wikipedia.org/wiki/Category:C_compilers
http://en.wikipedia.org/wiki/Category:C%2B%2B_compilers
(и это далеко не полный список)
Как раз на Юниксах десяток разных компиляторов -- начиная от Sun Studio и IBM Visual Age.
> Желательно, сравнимые с MFC - где vptr смещен на 4 байта относительно начала класса.
Обычно проблемы с компиляторами начинаются задолго до исполнения.
> sh, bash, dash (light bash), zsh... 5 (пять) штук. Где сотни?
Начинаются отмазки в стиле "не всё так плохо, всего 19"
http://en.wikipedia.org/wiki/Category:Unix_shells
"Стандарт", ага.
> Без cygwin'а было бы совсем грустно. Он делает из windows подобие нормальной системы.
Что для гомосексуалиста норма, то для нормального человека гомосексуализм. Вообще-то винда НТ POSIX-сертифицирована с 1994 года. Официально, комитетом POSIX, за деньги.
Вы стандарт позикса сначала изучите, матчасть почитайте, а потом рассуждайте про "норму".
> и под unix системами могут существовать РАСШИРЕНИЯ (а не замещения!) errno
Херню какую-то городите. Скажем, известная проблема с блокирующим IO в определённой ситуации -- одна система тупо возвращает одну ошибку, вторая другую. Усё, приплыли.
А как там в POSIX со "стандартом" на ioctl()?
И не соизволите тыкнуть на стандарт по заголовочным файлам? Меня интересует сетевая подсистема. Клятые виндузятники клевещут, что разные API в разных Юниксах...
no subject
Тролль? Понемаю.
Я про несовместимости вообще-то, про которые были упомянуты.
А Си - он один, ANSI C.
Стандарт де-факто - sh и bash.
Остальное - для end-user'ов, которые хотят тонкого тюнинга консоли, либо light-версии "заместителей" - dash.
То-то там имена вызовов с двумя подчёркиваниями идут.
Помнится мне, пробовал я там собрать утилиту... Там и не получилось.
Под cygwin собралось сразу.
no subject
> Я про несовместимости вообще-то, про которые были упомянуты.
> А Си - он один, ANSI C.
пипец, такой большой, а в Гугле забанен
ну вот сходу специфика, которая может поломать совместимость
http://groups.google.com/group/fido7.su.c-cpp/browse_thread/thread/4579db8a7d183d87
https://www.suntrainingcatalogue.com/eduserv/client/loadCourse.do;jsessionid=D773548BC98D2C77F9721EA76E5B1F42.tomcat2?coId=ru_RU_WDO-2800&coCourseCode=WDO-2800&l=ru_RU
а как там с линковкой между компиляторами?
а как там с заголовочными файлами?
а зачем, если "Си - он один", кошмарное число #ifdef МОЙКОМПИЛЯТОР1?
А вот "Си он один" для любимого GCC: http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
> Стандарт де-факто - sh и bash.
Честно говоря, мне хотелось бы уйти от тупого тролления.
Нет, ну вот с точки зрения профи, чем отличается "bash стандарт de-facto" и "gcc стандарт de-facto" от "cmd.exe стандарт de-facto" и "msvc стандарт de-facto"?
Разве что меньшей обоснованностью: cmd.exe есть на минимум 90% компьютеров мира, а bash пусть на 4%.
> То-то там имена вызовов с двумя подчёркиваниями идут.
Помнится мне, пробовал я там собрать утилиту... Там и не получилось.
Никаких двойных подчёркиваний в стандарте и в его реализации нету. Если какая-то утилита что-то нехорошее делала, то это как бы её проблема.
> http://en.wikipedia.org/wiki/Berkeley_sockets
Спасибо. Я вот тоже попытался одну утилиту (rdesktop) скомпилировать, с cygwin сразу не заработало, а вот с MSVC после 2 часов секса заработало. Причина в том, что этот "стандарт" сильно разный на linux, BSD & windows. И вообще они СВОЙ netdb/in.h включили на случай "ну если не поможет, то вот наш".
no subject
В какой именно ситуации, какие именно системы?
Нету =(
http://en.wikipedia.org/wiki/Berkeley_sockets
The "de jure" standard definition of the Sockets interface is contained in the POSIX standard, known as:
IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX).
Open Group Technical Standard: Base Specifications, Issue 6, December 2001.
ISO/IEC 9945:2002
no subject
Феерический бред. Библиотека классов перепутана с языком, классы перепутаны с объектами...
no subject
no subject
Другой вопрос что лэйоут объектов вроде как различался в отладочном и релиз режимах. Ну так MFC тут абсолютно не причем.
no subject
no subject
no subject
Точнее, мне это показывали мои тогдашние коллеги - запускаем проект, выбираем опцию сборки - в часности, указываем "use mfc" or "not use mfc".
Пруфлинк я попытался найти, но нигде никто не пишет, как именно выглядит layouting в памяти, за исключением рассылок по конкретным компиляторам.
Витус прав, слушайте Витуса. Он дурного не посоветует.
no subject
Хинт: опции сборки "use mfc", "not use mfc" на самом деле шорткат для кучки опций компилятора и линкера.
no subject
Значит, только сокращение?
Ничему не противоречит.
Флажок для сборки с ATL тоже просто сокращение?
no subject
Но думаю что да. Ибо
cl /? | grep mfc
cl /? | grep atl
ничего не дали.
Итак, предположим что у компилятора есть ключ меняющий расположение vptr в объекте. Ничего криминального в этом нет. НО! Будете ли вы спорить с тем фактом (имхо аксиомой), что все исходные тексты программы и используемых статических библиотек должны быть:
- или скомпилированы с одинаковой установкой этого ключа компилятора
- или каждое объявление класса должно предваряться некой специфической #pragma, указывающей компилятору, где именно хранится vptr в объектах этого класса
?
no subject
Да
Аксиома верная, но спорить буду (не с ней).
Если ты включил MFC || ATL, то ты получил:
1) Ровно 1 (одну) реализацию компилятора
2) Жутчайший гемморой со сборкой и использованием сторонних библиотек.
no subject
Как ни странно, Робачевский писал про другое.
Он писал, что ERRNO не ограничивается СТАНДАРТНЫМИ ошибками, и под unix системами могут существовать РАСШИРЕНИЯ (а не замещения!) errno.
no subject
Исключительно как доноры менеджера keyboard layout.
>>Интересно, как же это cygwin умудряются его собирать. Видимо, с напильником.
в cygwin он доработан напильником под цигвиновские правила жизни + autoconf. win32-версия, емнип, славна тараканами. Ну и отсутствие /usr/lib сильно сказывается