Мозголомающие средства разработки.

[metaclass]

После недельного писания на F# появилась идея, отчего использование дельфи так часто вырывает мозг программистам.

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

Сколько я не смотрю на другие средства разработки - там обязательно есть какая-то шиза на тему того, что невозможно пользоваться, не вкурив штук пять смежных областей. Тот же дотнет - это просто страшная сборная солянка из XML, веба, рефлекшена с кодогенерацией, хитрожопого ООП, причем некоторые вещами оттуда до сих пор проще переписать чем использовать готовые.
Послушаешь zabivator и прочих про ocaml - это просто гамон, какие-то сишные компиляторы, какие-то либы, портирование между виндами и линуксами и прочий мрак.
Жаба энтепрайзная тоже страх какой-то, судя по количеству фреймворков, методик взаимодействия с внешним миром и прочего.

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

Comments

[zamotivator.livejournal.com]

С mfc работал, message map и vptr понимаю, layoting менялся.
Значит, только сокращение?
Ничему не противоречит.
Флажок для сборки с ATL тоже просто сокращение?

[npocmu.livejournal.com]

Про ATL ничего скажу, практически не использовал.
Но думаю что да. Ибо
cl /? | grep mfc
cl /? | grep atl
ничего не дали.

Итак, предположим что у компилятора есть ключ меняющий расположение vptr в объекте. Ничего криминального в этом нет. НО! Будете ли вы спорить с тем фактом (имхо аксиомой), что все исходные тексты программы и используемых статических библиотек должны быть:

- или скомпилированы с одинаковой установкой этого ключа компилятора
- или каждое объявление класса должно предваряться некой специфической #pragma, указывающей компилятору, где именно хранится vptr в объектах этого класса

?

[zamotivator.livejournal.com]

Итак, предположим что у компилятора есть ключ меняющий расположение vptr в объекте. Ничего криминального в этом нет
Да

НО! Будете ли вы спорить с тем фактом (имхо аксиомой), что все исходные тексты программы и используемых статических библиотек должны быть:

- или скомпилированы с одинаковой установкой этого ключа компилятора
- или каждое объявление класса должно предваряться некой специфической #pragma, указывающей компилятору, где именно хранится vptr в объектах этого класса

?
Аксиома верная, но спорить буду (не с ней).
Если ты включил MFC || ATL, то ты получил:
1) Ровно 1 (одну) реализацию компилятора
2) Жутчайший гемморой со сборкой и использованием сторонних библиотек.