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

[metaclass]

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

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

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

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

Comments

[vp.livejournal.com]

Многопользовательскость винды в текущем варианте - начиная с NT4.
даже в 98й винде была многопользовательскость, свои папки и т.п. Но иначе, тупиковая ветвь.
Так что лет 15 уже как.

[aamonster.livejournal.com]

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

И отклонения от этой схемы больно бьют. Появляется второй аккаунт - пользователь грузится и недоумевает: "а где мои программы?". Или даже если программы есть - у них сбиваются настройки. Желающие могут дрочить реестр и переносить данные из одной ветки в другую, копировать домашние каталоги и т.п., рискуя привести систему в неработоспособное состояние. Или настраивать всё по два раза.

Т.е. со стороны системы поддержка многопользовательского режима есть, а со стороны жизни - уже нету. Поздно сделали.

[w00dy.livejournal.com]

Со стороны жизни всё тоже есть. Поддержка многопользовательского окружения один из критериев на получение designed for windows или как там то лого называется.

[metaclass.livejournal.com]

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

А, еще ж есть терминальные сервера, там вообще ад и ханука в этом плане.

[volodymir-k.livejournal.com]

Спасибо, Вы еще раз подтвердили, что бывают некачественные программы. Уведомляю, что такие бывают и под другими ОС.

> Или даже если программы есть - у них сбиваются настройки.

Интересно, а как настройки одного пользователя появляются у другого в линуксе -- видимо, телепатически переносятся.

[zamotivator.livejournal.com]

cp -R /home/first/.programName ~/.programName

[volodymir-k.livejournal.com]

Научитесь читать: мой собеседник стонет, что некошерными являются действия "Желающие могут дрочить реестр и переносить данные из одной ветки в другую, копировать домашние каталоги и т.п., рискуя.."

Понимаете, копировать -- РИСКУЯ!!! РИСКУЯ!!!

[aamonster.livejournal.com]

В линуксе как-то проще с юзерами - видимо, из-за отсутствия реестра и тенденции хранить всё, что касается пользователя, в одном месте.

[volodymir-k.livejournal.com]

Я конечно не доктор и не в курсе последних советов по конфигурации иксов. Но в 2002 году помнится был жутчайший зоопарк, что настройки софта хранились:
* в хоме
* в самой программе
* в оконном менеджере
* в иск сервере
и наследовались, позваоляя использованием шаблонов для имен классов.

Насчёт реестра Ваши беспредметные философские рассуждения любопытны, но не убедительны. Конкретно где трудность? Что, использовать реестр для настроек винда как-то прям вынуждает, файлы запрещает?

Если нет, то в чём разница между экспортом куска реестра с настройками и копированием файла настроек?

[aamonster.livejournal.com]

Винда - не особо вынуждает, а вот guidelines по написанию под нее указывают (или, во всяком случае, указывали раньше) использовать реестр. И до фига прог, соответственно, этим страдает.

При этом, если вы не в курсе, у реестра есть три основных ветки. И как минимум настройки проги есть в HKLM и/или HKCU - тогда достаточно их найти. А как максимум - в HKCR, и вот тогда начинается зоопарк со взбесившимися червями, ибо guid'ы одной проги, естественно, никто группировать не будет.

Насчёт линукса я могу заблуждаться в силу недостаточного знакомства. Но насчёт винды - по граблям набегался. Наиболее адекватны Portable-версии.

[volodymir-k.livejournal.com]

> При этом, если вы не в курсе, у реестра есть три основных ветки.

4. HKEY_CURRENT_CONFIG

> А как максимум - в HKCR

HKCR это подветка HKLM
HKEY_LOCAL_MACHINE\SOFTWARE\Classes

> Но насчёт винды - по граблям набегался.

А у меня наоборот, никаких проблем с переносом настроек не было.


Подход реестра и кучи конфиг файлов технически абсолютно идентичны. Есть и юникс проги, которые хранят настройки... см выше -- в 5 местах; в реестре максимум в 2. Если программа хранит настройки глобально -- значит она так написана, и проблема с переносом настроек решается 1:1 как с файлами.