Мозголомающие средства разработки.
После недельного писания на F# появилась идея, отчего использование дельфи так часто вырывает мозг программистам.
Суть в том, что дельфи это законченный продукт с замкнутым комьюнити. Собственно говоря, для работы на нем ничего кроме самого дельфи и нескольких сторонних компонентов (которые никуда больше и не пригодны) не нужно. Соответственно, у программистов тупо не было стимула выглядывать за пределы своей песочницы. В дельфи было все, необходимое и достаточное, чтобы писать всякого рода опердень в то время. Причем в силу простоты - это еще и стимулировало индивидуальное вкалывание, нахрен нужна какая-то командная разработка, какие-то процессы и прочие атрибуты, если один человек мог спокойно сделать достаточно немалую софтину.
Сишные и С++ либы, опять же, не подключались без извращений типа "завернуть в dll с plain C интерфейсом".
Сколько я не смотрю на другие средства разработки - там обязательно есть какая-то шиза на тему того, что невозможно пользоваться, не вкурив штук пять смежных областей. Тот же дотнет - это просто страшная сборная солянка из XML, веба, рефлекшена с кодогенерацией, хитрожопого ООП, причем некоторые вещами оттуда до сих пор проще переписать чем использовать готовые.
Послушаешь
zabivator и прочих про ocaml - это просто гамон, какие-то сишные компиляторы, какие-то либы, портирование между виндами и линуксами и прочий мрак.
Жаба энтепрайзная тоже страх какой-то, судя по количеству фреймворков, методик взаимодействия с внешним миром и прочего.
Т.е. все другие платформы ориентированы или на работу в команде с разделением труда или на знание множества смежных шизов, что в любом случае не дает окопаться в песочнице и 20 лет самостоятельно пилить одну и ту же опердень.
Суть в том, что дельфи это законченный продукт с замкнутым комьюнити. Собственно говоря, для работы на нем ничего кроме самого дельфи и нескольких сторонних компонентов (которые никуда больше и не пригодны) не нужно. Соответственно, у программистов тупо не было стимула выглядывать за пределы своей песочницы. В дельфи было все, необходимое и достаточное, чтобы писать всякого рода опердень в то время. Причем в силу простоты - это еще и стимулировало индивидуальное вкалывание, нахрен нужна какая-то командная разработка, какие-то процессы и прочие атрибуты, если один человек мог спокойно сделать достаточно немалую софтину.
Сишные и С++ либы, опять же, не подключались без извращений типа "завернуть в dll с plain C интерфейсом".
Сколько я не смотрю на другие средства разработки - там обязательно есть какая-то шиза на тему того, что невозможно пользоваться, не вкурив штук пять смежных областей. Тот же дотнет - это просто страшная сборная солянка из XML, веба, рефлекшена с кодогенерацией, хитрожопого ООП, причем некоторые вещами оттуда до сих пор проще переписать чем использовать готовые.
Послушаешь
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Жаба энтепрайзная тоже страх какой-то, судя по количеству фреймворков, методик взаимодействия с внешним миром и прочего.
Т.е. все другие платформы ориентированы или на работу в команде с разделением труда или на знание множества смежных шизов, что в любом случае не дает окопаться в песочнице и 20 лет самостоятельно пилить одну и ту же опердень.
no subject
студия - это делала одна фирма
билдер - это делала другая фирма.
Почему у тебя глаза не оранжевые? Как ты можешь быть без оранжевых глаз?
а как нехер делать - другая архитектура.
Так и тут.
нету стандартного enviroment - /usr/lib, /lib, /usr/include/, /usr/bin, /bin\
нету, потому что другая архитектура, перпендикулярно. И нахер они не нужны в этой архитектуре, потому что мне только решать где размещать мои файлы.
Это уже обсуждалось. Если бы не пакетные менеджеры в никсах = там был бы такой ад, что крышей бы двинулись с первой секунды. Ибо никто никогда не знает что какая софтина ставит, какие вносит зависимости и куда какие файлы пихает.
В винде это отдано на откуп либо инсталятору, который суть аналог пакетного менеджера, либо если stand-alone софт (аналога в никсах нет), тогда мы работаем только в контексте текущей относительной папке, а в систему не гадим вообще.
А то, что проблемы со сборкой окамлов под виндой - это проблемы того, что тебе сейчас захотят сделать пересадку негретянского уха. Вместо того, чтоб разработать нормально продукт под архитектуру целевой системы начинают снова и снова боб с горохом, какое-то портирование, эмуляция никсовых папок и т.п.
Нахер-нахер такое.
no subject
no subject
Ага, то-то я смотрю заебёшься собирать программы под вендой =)
Да ладно! Для того пути и стандартизированы, чтобы не плодить сущности без меры.
Пиздато делать пакетный менеджер в каждой новой программе, безусловно!
Ставь всё в /opt. С точностью до glibc работать будет.
Скажите, а кто оплатит портирование приложений с модной сейчас enterprise на модную через пару лет?
Вот был avalon - где он сейчас?
XAML та же участь ждёт =)
no subject
Ты пойми, что портировать какую-нибудь опердень в случае когда микрософт совместимость поддерживает от 95 винды до семерки, при том, что обычно такой софт во избежание проблем делается по максимуму независящим от системы - это гораздо проще, чем разгребать срач линуксовых папок, пакетных менеджеров, разных версий glibc и gcc.
Под виндой программы собираются спокойно, если автор хотя бы немного уделил этому внимания. Но вместо этого начинаются пляски с цигвинами, мингвами и прочей чужеродной хренью.
no subject
Ты меня с кем-то путаешь. У меня нет времени на вуду, потому с инструментами, которые работают через жопу стараюсь не связываться принципиально :)
Эта стандартизация - из другой песочницы. Которая от рынка десктопов занимает, не забывай, 1%.
Это было имя бета-версии WPF/Silverlight/XAML, которые в продакшыне назвали по-другому :)
no subject
Сейчас ковыряем энтерпрайз. Являет собой распределенную файловую систему.
Сборка сервера метаданных представляет собой готовые бинарники для Linux_x64.
Так вот.. в сборке для исключения вуду(по задумке создателей хорошо, но в итоге вылазит хрени столько, что мама не горюй) собранные перл,апач, скрипты на переле, etc. Потому что указана работоспособность всего этого барахла только на RH И SLES, Только на определенных ядрах и версиях.
Млять..вы где видели чтобы для винды софт просил номер сборки ядра ????
Ебж вашу мать то....
no subject
no subject
Почему-то вспоминается stable_api_nonsense.txt (c) гражданин Торвальдс
no subject
У меня просто вопрос чаще всего возникает..что если все так хорошо и стандартизованно в линуксе, какого хрена весь энтерпрайз поставляется в блобах с привязкой к конкретному ядру и дистру. И даже после этого мы как хомячки прыгаем с бубнами. Чаще всего надо просто "ЗНАТЬ" где же косяк, просто логически это не доходит.
no subject
Вот и тут тоже самое.
Веток-то в linux по сути всего три: 2.4.last(устарела), 2.6.8-last, 2.6.18-last.
Чем не production
no subject
Только давай тогда не будем говорить про "стандарты"/"совместимость" линукса.
Потому что это определяется в большей степени разработчиком и его вменяемостью. Если ты умный и толковый и мух у тебя поменьше, это не означает что все такие же.
Просто знания и умения под определенную платформу нельзя за неделю перенести под другую перпендикулярную идеологию. И каждый со своей колокольни начинает поливать говном и рассказывать про свои реалии.
+1