Разработчики прикладных решений и библиотек

[metaclass]

http://www.scala-lang.org/node/8610
"I distinguish between Scala application programmers and Scala library designers, because the required skill sets are really quite different."

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

Comments

[metaclass.livejournal.com]

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

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

[teewoon.livejournal.com]

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

[theaspect.livejournal.com]

Если в жаба-коде происходит магия, то можно одной кнопкой скачать исходники из мавена и пробиться в самые глубины. В пыхе это заканчивается "Ошибка: фак ю!"

[bydlorus.livejournal.com]

Ещё раз подчеркну, что в C/C++ (особенно в gcc) всё то же самое. Реализация STL это вынос мозга, оптимизации, основанные на фишках gcc зашкаливают, и т.п.

[justy-tylor.livejournal.com]

Это верно в части знаний предметной области. Для отображения картинко.jpg не обязательно знать DCT и Huffman, библиотеки и фреймворки в помощь.

А вот инструменты прикладникам освоить надо, иначе будут попадать молотком по пальцам, писать "как деды на Фортране" и впадать в ахуй при виде правильно забитого гвоздя.

[metaclass.livejournal.com]

По крайней мере я это могу сделать, когда понадобится, или модифицировать стандартный, посмотрев на исходники :)

[justy-tylor.livejournal.com]

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

Различия между системным, библиотечным и прикладным кодом чисто эксплуатационные.

Если утверждается bullshit, что для нормального использования языка системщикам нужно знать "матан", а прикладникам нет, то это одна из двух ситуаций:
1) Данный "матан" не нужен и системщикам, а используется только для чесания ЧСВ.
2) Такой "матан" в реальности нужен всем программистам на этом языке, но количества говнокода "как на Фортране" со стороны прикладников оправдывается светлыми маркетинговыми целями.

[justy-tylor.livejournal.com]

Более того, делал кроссплатформенный GUI-фреймворк (персоналки, мобильники, телевизоры, ...).

Железо и API платформы тоже представляют собой предметные области, а не языковые инструменты.

[justy-tylor.livejournal.com]

Нужные, как только требуется customized UI - САПРы, игры и множество других ниш. Повторяю, различия между системным, библиотечным и прикладным кодом чисто эксплуатационные.

А вот вы что именно пытаетесь доказать, что "системные программисты" шибко умные, или что "прикладные программисты" имеют право быть тупыми?

[justy-tylor.livejournal.com]

Нет "системных" и "прикладных" программистов. Всё зависит от упаковки продукта. Можете мне верить.

[justy-tylor.livejournal.com]

И специализации "системность" тоже нет. Для реализации GUI-подсистемы операционки опыт создания GUI для САПР намного более релевантен, чем опыт написания драйвера USB.