LINUX.ORG.RU

О XML-программистах

 , ,


7

7

Всем более-менее опытным программистам, работавшим с энтерпрайзом, четко известен следующий эмпирический закон:

Девятое Правило Гринспуна, о котором он сознательно предпочел умолчать

Любая более-менее крупная программа на Java или C# является программой на XML

Вобщем, в один прекрасный день, работая на C#, я написал на XML-конфиг некоторых приблуд для UI. Это смотрелось настолько элегантно и красиво, и кастомизировалось настолько проще, по сравнению с обычным хардкодом, что я долго лелеял идею о том чтобы воткнуть подобное еще куда-либо в проект.

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

Получилось опять же крайне неплохо, но потом я посидел и подумал.

А что если эти два конфига объединить в один XML?

Ой, стойте, но тогда ведь получается, что туда же можно перенести и разнообразные простые валидаторы и предикаты действий по бизнес-логике? Описание геттеров/сеттеров и простой арифметики - не такое уж сложное занятие, тем более проект и так в System.Reflection по уши.

Черт! Но вообще-то ведь и сложные тоже не проблема - ведь они явлются в 99% случаев не более чем SQL/HQL-запросами, которые никто не мешает хранить в конфигах.

Ух, а ведь если подумать еще - то туда же можно перенести и сами действия по бизнес-логике, не так ли?

Но ведь можно пойти и дальше. Из XML можно вообще-то говоря даже и генерировать модель данных для всей логики системы! И ведь это не просто бредовая идея - такое отчасти давно уже делается стандартными средствами .Net-платформы, например тем же Entity Framework.

И тут я задался вопросом - а зачем нам тогда вообще большая часть кода на C#? Сторонние библиотеки мы ведь точно так же можем вызывать из интерпретатора XML.

Вон оно как все отлично то выходит.

Хм, правда что-то эта модель несколько, скажем так, раздулась.

Вот бы, конечно, написать более высокоуровневый интерпретатор XML чтобы он нам генирировал наш XML из декларативного описания другим XML?

И тут меня осенило. Где-то я это уже видел. Может быть в одной книжке, давно забытой на полке? Или в старой статье семьдесят мохнатого года?

Вспомнив окончательно, я просто расплакался.

Итак:

Вторая Теорема Лавсана

Каждый XML-программист (то есть любой продвинутый java/c#-программист) в конечном итоге доходит до лиспа, просветляется и плачет.

Дискач.

★★★

Последнее исправление: cetjs2 (всего исправлений: 1)
Ответ на: комментарий от Deleted

Я активно пишу на 4 языках и мне не сложнее читать и писать s-expressions чем код на Java. Это тебе аргумент. А то, что ты коверкаешь слова с целью оскорбить человека, характеризует тебя как недалёкого человека. Это тебе на будущее.

pseudo-cat ★★★
()
Ответ на: комментарий от pseudo-cat

Да господи, Рома, зачем метать бисер перед свиньями? Я сюда захожу по большей части исключительно из желания развлечься, посмотреть на цирк и клоунов.

lovesan ★★★
() автор топика
Ответ на: комментарий от pseudo-cat

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

lovesan ★★★
() автор топика
Ответ на: комментарий от Deleted

ליסף — древний магический оберег от недопрограммистов, которые прочитали книгу «PHP за 112 часов» и пошли гулять по собеседованиям.

PolarFox ★★★★★
()
Ответ на: комментарий от lovesan

Возьмешь в секту? Тоже хочу веровать.

Deleted
()
Ответ на: комментарий от lovesan

Дело в том, что тебе не нужен язык. Тебе нужно задачу решать, в кратчайшие сроки, с наименьшими бюджетами.

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

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

SV0L0CH
()
Ответ на: комментарий от SV0L0CH

Поведение фрагмента кода должно быть очевидным не зависимо от его окружения.

Тогда тебе стоит отказаться от функций. Потому что поведение функции - зависит от ее определения, то есть от контекста.

Что-то решение задачи в кратчайшие сроки совсем не вяжется с подменой синтаксиса.

почему же? Вполне вяжется.

anonymous
()
Ответ на: комментарий от anonymous

Тогда тебе стоит отказаться от функций.

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

loz ★★★★★
()
Ответ на: комментарий от anonymous

Функции ведут себя совершенно одинаково: принимают аргументы и выдают результат в отличии от макросов.

SV0L0CH
()
Ответ на: комментарий от SV0L0CH

вершенно одинаково: принимают аргументы и выдают результат в отличии от макросов.

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

anonymous
()
Ответ на: комментарий от loz

Можно передавать в ф-ю лямбды и коллить их внутри, будешь управлять порядком.

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

anonymous
()
Ответ на: комментарий от SV0L0CH

Так ты можешь привести хоть один аргумент в пользу того, что поддержка макросов сложнее поддержки функций?

anonymous
()
Ответ на: комментарий от anonymous

Что он может привести, он же про них только на лоре читал.

loz ★★★★★
()
Ответ на: комментарий от anonymous

макросы не особо нужны, они для других вещей.

Например?

loz ★★★★★
()
Ответ на: комментарий от loz

Вопервых, зачем это может понадобиться?

Вовторых, я видел много версий flip в виде функции и не понимаю почему это надо делать именно макросом.

Более того само по себе изменение порядка вычислений аргументов делает код неочевидным и за такое надо бить кувалдой по рукам. Тем более что сам по себе этот порядок может быть рандомным и должен считаться рандомным.

SV0L0CH
()
Ответ на: комментарий от SV0L0CH

Так каким образом макросы усложняют отладку? Желательно на примере - вот у нас макрос Х, делаем ошибку Y и очень трудно найти и исправить, а вот если то же самое сделать функциями...

anonymous
()
Ответ на: комментарий от anonymous

При чём тут поддержка макросов и поддержка функций? Я про поддержку кода в котором вызовы макросов выглядят идентично вызовам функций.

Я ведь не жалуюсь на Template Haskell где вызов шаблона обозначен специальным символом и разработчик сразу знает что это именно шаблон а не что иное.

SV0L0CH
()
Ответ на: комментарий от anonymous

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

SV0L0CH
()
Ответ на: комментарий от SV0L0CH

Вопервых, зачем это может понадобиться?

Вводить синтаксическии конструкции которые упрощают тебе написание кода.

Вовторых, я видел много версий flip

А версию flip которая не вычисляет аргументы видел?

Более того само по себе изменение порядка вычислений аргументов делает код неочевидным

Абстрактные фабрики шаблонов интерфейсов тоже не очень очевидны.

loz ★★★★★
()
Ответ на: комментарий от loz

А версию flip которая не вычисляет аргументы видел?

видел:

module T where

test = flip (+)
==================== Tidy Core ====================
Result size of Tidy Core = {terms: 6, types: 5, coercions: 0}

T.test
  :: GHC.Integer.Type.Integer
     -> GHC.Integer.Type.Integer -> GHC.Integer.Type.Integer
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType <S,1*U><S,1*U>,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True,
         ConLike=True, WorkFree=True, Expandable=True,
         Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}]
T.test =
  \ (x_aNV :: GHC.Integer.Type.Integer)
    (y_aNW :: GHC.Integer.Type.Integer) ->
    GHC.Integer.Type.plusInteger y_aNW x_aNV
qnikst ★★★★★
()
Ответ на: комментарий от loz

эм.. таким, что она вообще исчезает?

T.test =
  \ (x_aNV :: GHC.Integer.Type.Integer)
    (y_aNW :: GHC.Integer.Type.Integer) ->
    GHC.Integer.Type.plusInteger y_aNW x_aNV

В прочем даже без этой оптимизации в силу ленивости аргументы не были бы вычеслены.

qnikst ★★★★★
()
Ответ на: комментарий от loz

Если выражение не вычисляется, то это должно быть указано явно, а не как в уродствах типа C/C++ где перегруженые operqator&& и operator|| работают не так как встроеные.

SV0L0CH
()
Ответ на: комментарий от qnikst

Нет, ты про аргументы функции-аргумента flip, а я про аргументы flip - то есть функцию. В кратце если ты вызовешь flip (\x y -> [x,y]) то у тебя не должна создасться лямбда, а внутри flip должно быть в каком-то виде доступно выражение (\x f -> [x, y]) которое flip может вычислить, может не вычислить, может изменить или сделать что угодно, что может язык делать с данными.

loz ★★★★★
()
Ответ на: комментарий от loz

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

qnikst ★★★★★
()

Ага, а потом проекты еле шевелятся, не влазят ни в одну память, никакого тайп сефети и читаемости, но это просто джава и сисярп говно, а не гениальный программист, решивший все описать языком разметки :)

f1xmAn ★★★★★
()
Ответ на: комментарий от qnikst

нет, \x y -> [x,y] вычисляется в функцию перед вызовом flip, поэтому flip ничего не может сделать с выражением, оно получает готовый объект, в данном случае - функцию.

loz ★★★★★
()
Ответ на: комментарий от SV0L0CH

При чём тут поддержка макросов и поддержка функций? Я про поддержку кода в котором вызовы макросов выглядят идентично вызовам функций.

Ну так чем поддержка в этом случае сложнее? Можешь привести аргументы?

Я ведь не жалуюсь на Template Haskell где вызов шаблона обозначен специальным символом

Вот как раз в TH поддержка будет сложнее, т.к. макросы выделены.

anonymous
()
Ответ на: комментарий от SV0L0CH

Не хватало мне есчё анализировать ошибки в самих макросах и отлаживать их.

А чем это отличается от анализа ошибок в функциях и отладки функций?

Но если в сообщениях о ошибке выводится код после препроцессинга

Почему после? До.

Всяко выходит дольше чем без макросов.

Почему дольше-то? Наоборот - макросы поще отлаживаются.

anonymous
()
Ответ на: комментарий от SV0L0CH

Более того само по себе изменение порядка вычислений аргументов делает код неочевидным и за такое надо бить кувалдой по рукам.

То есть ленивые функции и лямбды - это зло и за них надо бить по рукам, я все верно понял?

anonymous
()
Ответ на: комментарий от SV0L0CH

Если выражение не вычисляется, то это должно быть указано явно

А зачем, собственно? что это тебе даст?

anonymous
()
Ответ на: комментарий от anonymous

Ну вот тебе кусок кода на C++:

a = b + c[d];

Вопрос: что этот код делает?

Если бы это был Си, ответ был бы тривиальным.

anonymous
()
Ответ на: комментарий от anonymous

ленивые функции и лямбды - это зло и за них надо бить по рукам

Ну вот, сам же все понимаешь. Зачем спрашиваешь тогда?

anonymous
()
Ответ на: комментарий от anonymous

Вопрос: что этот код делает?

Тот же вопрос можно задать для любого полиморфного кода. Значит следует отменить полиморфизм, я верно понял?

anonymous
()
Ответ на: комментарий от anonymous

Ну и непонятно, какое это имеет отношение к макросам.

anonymous
()
Ответ на: комментарий от anonymous

Ну замечательно. Лямбды уберем, полиморфизм уберем, вообще все уберем - и будет долбиться в жопу с гото. Только гото, только хардкор.

anonymous
()
Ответ на: комментарий от anonymous

Значит следует отменить полиморфизм, я верно понял?

Все правильно понял. Любые средства языка, которые позволяют запутать контекст, не имеют ни малейшего права на существование. Макросы, полиморфизм, изменяемый синтаксис, любые виды препроцессоров - все это зло и должно быть искоренено.

anonymous
()

/me тоже расплакался.

derlafff ★★★★★
()
Ответ на: комментарий от anonymous

Все правильно понял. Любые средства языка, которые позволяют запутать контекст, не имеют ни малейшего права на существование. Макросы, полиморфизм, изменяемый синтаксис, любые виды препроцессоров - все это зло и должно быть искоренено.

Ну то есть я был прав - все убираем и пишем через гото. Будет простой и поддерживаемый код - без этих ваших полиморфизмов, функций и других, зависимых от контекста, штук. Переменные, кстати, тоже лучше отменить, и присваивание. А то эдак, выходит, какие-то штуки даже _в одном и том же контексте_ разную семантику имеют. Непорядок! Вот лежит у нас в EAX 0 - пусть он там и лежит.

anonymous
()
Ответ на: комментарий от loz

А тебе часто дают куски какого-то кода без контекста и спрашивают что он делает?

Всегда. Человек читает код строчку за строчкой, и держать в голове весь контекст и все мегатонны используемых библиотек он не должен.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.