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

[metaclass]

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

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

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

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

Comments

[zamotivator.livejournal.com]

Кстати, в тему "законченного продукта".
Вот линукс и юникс - законченный продукт для разработки, ему сто лет в обед.
Откуда же полезли все эти студии, билдеры, дельфи?
Зачем куча систем сборки если есть make?
Зачем несовместимые компиляторы - для студии свой, для билдера свой?
Зачем куча говна - MFC, ATL - которые поддерживает нормально лишь студия?
Зачем ASP и .NET (конкретно - WPF, и что там было модным до? Window Forms&), с которыми за пределами студии невозможно нормально работать?
И при этом нету СТАНДАРТА ДЕ-ФАКТОР и ДЕ-ЮРО - POSIX (в windows есть POSIX? Ну так соберите мне gcc под вендой без напильника. Соберите мне psi какой-нибудь). Нету (без напильника среды-адаптера - cygwinэа) make. Нету стандартных каталогов для заголовочных файлов и библиотек.
Есть БАРДАК.

Так что ребята - не надо ляля про "Гамон". Гамон у венды с её бардаком, и поддержать кроссплатформенность linux <-> windows, или unix <-> windows в разы сложнее, чем учесть отдельные ньюансы между линуксами, юниксами.
В линуксах и юниксах единственный зоопарк, что имеет место быть - это пакетные менеджеры.
Но есть OpenSUSE build service, который эту проблему нивилирует.
Да и собрать deb пакет (один из самых сложных пакетов среди линуксов!) В РАЗЫ ПРОЩЕ ЧЕМ СОБРАТЬ ИНСТАЛЛЯТОР ПОД ВЕНДОЙ

[http://users.livejournal.com/_valerka_/]

а какие проблемы в кроссплатформенности между версиями windows? Ну да, бывают специфические вещи, но если их не использовать, то всё, написанное для 95й винды работает на 7ке. У юниксов разве тоже так? Там вон с гномом и кде разобраться невозможно, что стоит.

[zamotivator.livejournal.com]

Если забыть, что "WinAPI устарел, и писать нужно на .NET" то windows stable в плане API.
Но POSIX-у лет поболе таки будет.

[http://users.livejournal.com/_valerka_/]

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

[w00dy.livejournal.com]

Ребе не понимает что такое posix? posix всяко победнее winapi будет.

[nealar.livejournal.com]

Агащаз. Подсказать, что конкретно отвалится или сами знаете?

[vp.livejournal.com]

затем, что
студия - это делала одна фирма
билдер - это делала другая фирма.
Почему у тебя глаза не оранжевые? Как ты можешь быть без оранжевых глаз?
а как нехер делать - другая архитектура.
Так и тут.
нету стандартного enviroment - /usr/lib, /lib, /usr/include/, /usr/bin, /bin\
нету, потому что другая архитектура, перпендикулярно. И нахер они не нужны в этой архитектуре, потому что мне только решать где размещать мои файлы.
Это уже обсуждалось. Если бы не пакетные менеджеры в никсах = там был бы такой ад, что крышей бы двинулись с первой секунды. Ибо никто никогда не знает что какая софтина ставит, какие вносит зависимости и куда какие файлы пихает.
В винде это отдано на откуп либо инсталятору, который суть аналог пакетного менеджера, либо если stand-alone софт (аналога в никсах нет), тогда мы работаем только в контексте текущей относительной папке, а в систему не гадим вообще.
А то, что проблемы со сборкой окамлов под виндой - это проблемы того, что тебе сейчас захотят сделать пересадку негретянского уха. Вместо того, чтоб разработать нормально продукт под архитектуру целевой системы начинают снова и снова боб с горохом, какое-то портирование, эмуляция никсовых папок и т.п.
Нахер-нахер такое.

[kong-en-ge.livejournal.com]

Ребе, еще ведь не пятница? :)

[zamotivator.livejournal.com]

нету, потому что другая архитектура, перпендикулярно. И нахер они не нужны в этой архитектуре, потому что мне только решать где размещать мои файлы.
Ага, то-то я смотрю заебёшься собирать программы под вендой =)

Ибо никто никогда не знает что какая софтина ставит, какие вносит зависимости и куда какие файлы пихает.
Да ладно! Для того пути и стандартизированы, чтобы не плодить сущности без меры.

В винде это отдано на откуп либо инсталятору, который суть аналог пакетного менеджера
Пиздато делать пакетный менеджер в каждой новой программе, безусловно!

либо если stand-alone софт (аналога в никсах нет), тогда мы работаем только в контексте текущей относительной папке, а в систему не гадим вообще.
Ставь всё в /opt. С точностью до glibc работать будет.

А то, что проблемы со сборкой окамлов под виндой - это проблемы того, что тебе сейчас захотят сделать пересадку негретянского уха. Вместо того, чтоб разработать нормально продукт под архитектуру целевой системы начинают снова и снова боб с горохом, какое-то портирование, эмуляция никсовых папок и т.п.
Нахер-нахер такое.
Скажите, а кто оплатит портирование приложений с модной сейчас enterprise на модную через пару лет?
Вот был avalon - где он сейчас?
XAML та же участь ждёт =)

[metaclass.livejournal.com]

avalon==wpf - использует xaml в качестве языка разметки. Ты хотя бы изучил матчасть, прежде чем спорить :)

Ты пойми, что портировать какую-нибудь опердень в случае когда микрософт совместимость поддерживает от 95 винды до семерки, при том, что обычно такой софт во избежание проблем делается по максимуму независящим от системы - это гораздо проще, чем разгребать срач линуксовых папок, пакетных менеджеров, разных версий glibc и gcc.

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

[vp.livejournal.com]

Ага, то-то я смотрю заебёшься собирать программы под вендой

Ты меня с кем-то путаешь. У меня нет времени на вуду, потому с инструментами, которые работают через жопу стараюсь не связываться принципиально :)

Для того пути и стандартизированы, чтобы не плодить сущности без меры.

Эта стандартизация - из другой песочницы. Которая от рынка десктопов занимает, не забывай, 1%.

Вот был avalon - где он сейчас?

Это было имя бета-версии WPF/Silverlight/XAML, которые в продакшыне назвали по-другому :)

[fas-tm.livejournal.com]

+1
Сейчас ковыряем энтерпрайз. Являет собой распределенную файловую систему.
Сборка сервера метаданных представляет собой готовые бинарники для Linux_x64.
Так вот.. в сборке для исключения вуду(по задумке создателей хорошо, но в итоге вылазит хрени столько, что мама не горюй) собранные перл,апач, скрипты на переле, etc. Потому что указана работоспособность всего этого барахла только на RH И SLES, Только на определенных ядрах и версиях.

Млять..вы где видели чтобы для винды софт просил номер сборки ядра ????
Ебж вашу мать то....

[crazy-daemon.livejournal.com]

Легко. Драйвера вполне могут сказать "чувак, у тебя винда не того релиза, отвали".

[metaclass.livejournal.com]

А, так насчет линукса и юникса как законченного продукта. Ты бредишь. В 95 году насчет программинга было такое вуду, что тебе и не снилось, линукса не было вообще, коммерческих юниксов я не видел, но предполагаю, что там был страшнейший боб с горохом, т.к. все было относительно просто и все можно было делать вручную.
Винда была 3.11. Был дос. Была куча разнообразных вуду компиляторов разнообразных вуду языков.
Т.е. монолитный продукт типа дельфей, позволяющий в одной среде сделать все на тот момент был натурально шагом вперед.
Т.е. "полезло", как ты говоришь, это все из очевидной потребности работать с нормальными инструментами вместо вудуистских. Другое дело, что в итоге вудуистские победили, т.к. микрософт одно вуду заменил другим, а борланд, сделав нормальный инструмент, не осилила навязать его всем и не интегрировала его во все что только можно.

[lionet.livejournal.com]

В 95 году я был лектором на семинаре по Линуксу в НИИАР, и там же видел, как они используют SGI Crimson, Indigo. Это было круто, потому то Win 3.1[1] не тявкала, а разговоры о чикаге не впечатляли.

[lionet.livejournal.com]

Это я про то, что там линукса где-то не было, и про коммерческие юниксы. На SGI был Irix, так у него был векторный GUI интерфейс! Иконки в папках можно было растянуть и ужать, чтобы оно лучше на экране помещалось. Как-то это программировалось, наверное.

[vromanov.livejournal.com]

Уже была MSVS. Программировалось легко и свободно..
Я в 96 написал первую версию ReGet. Это была моя первая программа на С++. Все заняло месяца два..

[volodymir-k.livejournal.com]

> Вот линукс и юникс - законченный продукт для разработки

Линукс далеко не закончен.

> Зачем куча систем сборки если есть make?

Если есть make, то почему существует autoconf?

> Зачем несовместимые компиляторы - для студии свой, для билдера свой?

Дык и под линуксами компиляторы Си совместимы плоховато.

> Зачем куча говна - MFC, ATL - которые поддерживает нормально лишь студия?

"Зачем куча говна -- KDE, Gnome -- которые поддерживает нормально лишь под Линуксом?"
Демагогия.
У Маков вообще свой язык программирования ОбжективСи, своё всё, и ничего. На Юниксах традиции партизанщины намного сильнее -- сотни шеллов, тысячи языков, даже утилиты отличаются.

> Зачем ASP и .NET (конкретно - WPF, и что там было модным до? Window Forms&), с которыми за пределами студии невозможно нормально работать?

Вот уж пук в лужу. Как раз с .Net лучший инструмент ReShaper.

> И при этом нету СТАНДАРТА ДЕ-ФАКТОР и ДЕ-ЮРО - POSIX ... Нету стандартных каталогов для заголовочных файлов и библиотек.

Всё это конечно интересная теория, но что-то я очень много кода видел вида
#ifndef FreeBSD
#ifdef _AIX
#include

[Error: Irreparable invalid markup ('<inet.h>') in entry. Owner must fix manually. Raw contents below.]

> Вот линукс и юникс - законченный продукт для разработки

Линукс далеко не закончен.

> Зачем куча систем сборки если есть 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 пыщпыщ!

[zamotivator.livejournal.com]

Да и собрать инсталлятор под виндой В РАЗЫ ПРОЩЕ ЧЕМ СОБРАТЬ DEB ПАКЕТ!!!111 пыщпыщ!
Вот инструкция, всё просто и понятно.
http://www.debian.org/doc/maint-guide/
Жду встречной ссылки на описание процесса сборки инсталлятора

[zamotivator.livejournal.com]

Дык и под линуксами компиляторы Си совместимы плоховато.
Примеры можно? Желательно, сравнимые с MFC - где vptr смещен на 4 байта относительно начала класса.

Демагогия.
У Маков вообще свой язык программирования ОбжективСи, своё всё, и ничего. На Юниксах традиции партизанщины намного сильнее -- сотни шеллов, тысячи языков, даже утилиты отличаются.
*загибает пальца*
sh, bash, dash (light bash), zsh... 5 (пять) штук.
Где сотни? ksh, etc - есть, маргинальщина на текущий момент.
С, C++. Erlang? написан на Си. Python? Си. И так далее. Но их не тысячи, их пара десятков от силы, а популярных и используемых - десяток.

Интересно, как же это cygwin умудряются его собирать. Видимо, с напильником.
Без cygwin'а было бы совсем грустно. Он делает из windows подобие нормальной системы.
Без cygwin, mingw, msys - соберёте?

[zamotivator.livejournal.com]

Собственно почитайте классические книги по современному Юникс-программированию, Робачевского скажем, там рассказывается, что даже у банального open()/write() разные ERRNO и поведение под разными системами. "Стандарт POSIX." Переносим, ага.
Как ни странно, Робачевский писал про другое.
Он писал, что ERRNO не ограничивается СТАНДАРТНЫМИ ошибками, и под unix системами могут существовать РАСШИРЕНИЯ (а не замещения!) errno.

[permea-kra.livejournal.com]

>>"Зачем куча говна -- KDE, Gnome -- которые поддерживает нормально лишь под Линуксом?"
Исключительно как доноры менеджера keyboard layout.

>>Интересно, как же это cygwin умудряются его собирать. Видимо, с напильником.
в cygwin он доработан напильником под цигвиновские правила жизни + autoconf. win32-версия, емнип, славна тараканами. Ну и отсутствие /usr/lib сильно сказывается

[npocmu.livejournal.com]

>>Зачем куча систем сборки если есть make?

А make уже поддерживает имена файлов с пробелами?

[zamotivator.livejournal.com]

Откуда у вас исходные файлы с пробелами в именах? Есть? Выпилите нафиг.
Вот потому и не поддерживается - никому не нужно такие извращение, My Cool Name.c ага, щас.

[kiryl.livejournal.com]

А какие там проблемы с пробелама?

$ cat Makefile
all: a\ file\ with\ spaces

a\ file\ with\ spaces:
echo test > "$@"
$ make
echo test > "a file with spaces"
$ cat "a file with spaces"
test