Да, о программировании

[metaclass]

теперь очень часто всё вообще не на программистах держится

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

Правильно спроектированная архитектура в кодировании не нуждается. :)

Comments

[guamoka.livejournal.com]

а как жо ж. правильно поставленный вопрос- половина ответа:)

[lupus-lupusum.livejournal.com]

В 70х говорили то ж самое. Все уже написано до нас.

[molnij.livejournal.com]

ну-ну, и это говорит человек, пишущий для бухгалтеров
там во-первых "правильной" постановки попросту не существует, ибо меняется все со страшной скоростью и описано в устрашающем объему томов
а во-вторых, конечно не нуждается! она нуждается только в настройке! Чем и занимается любой программист 1С (SAP, oracle forms и т.п.)
При этом, принципиальная разница между кодированием на языках уровня си\паскаль\ява и настройкой системы в самописных диалектах я не вижу. По сути разница громадна, а принципиальной - никакой

[metaclass.livejournal.com]

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

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

[molnij.livejournal.com]

По первому.
Конечно, бывает и так как ты сказал. Но например в системе которой я занимаюсь(не один разумеется) уже сотни печатных форм требуемых для бух.отчетности, причем действительно нужных - все они прописаны в гостах, ту и прочей ереси. При этом существует по нескольку версий для каждой формы.
И это мы обсуждаем только "внешнюю" сторону - т.е. вывод информации на бумаге. А я говорил немного не о том. Я говорил о способах организации и обработки информации. У нас у постановщиков которые работают в бухучете\HR несколько шкафов забито разными кодексами, дополнениями, разъяснениями и прочими примечаниями. Это не считая периодических изданий, где в каждом номере на полста страницах подробно разжевывается один подпункт отдельного параграфа какого-нибудь налогового кодекса. При этом, например, ЦБ выпуская уникальное распоряжение по организации чего-нибудь иногда ставит под удар уже отработанную систему... Но кого ж это волнует. Вон у меня товарищ в районе нового года сидел авралом переписывал какую-то кредитную систему, потому что умным дядьком в ЦБ взбрела какая-то фигня в голову. Самое плохое, что на этапе разработки ты не можешь запихнуть все в архитектуру. Как ни старайся. Точнее конечно можешь, но при этом мы получаем на выходе то, о чем разговор шел дальше - систему у которой настройка равнозначна программированию.
О чем ты написал во втором абзаце.
Но! Я ведь не говорил что разницы между этими языками нет. Она есть, она большая, временами громадная... Но в принципе, ничего не решающая. Все равно для организации настройки требуется программист. И никакой бухгалтер, юрист, кадровик не в состоянии выполнить её самостоятельно (если у него, разумеется нет соответствующего склада мышления). Всё равно требуется человек, который понимает архитектуру системы, а не архитектуру предметной области. И вот это различие - существенно.
А тьюринг-полнота... Да кому она нужна-то? SQL в чистом виде, вроде бы, если задуматься - тоже будет тьюринг-полным. Теоретически. А на практике это кому-то нужно?

[metaclass.livejournal.com]

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

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

[molnij.livejournal.com]

инкремент: select a+1 from dual;
суперпозиция: select a+1 from (select 2 as a from dual)
минимум: select min(a) from (select 1 as a from dual union all selct 2 as a from dual)

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

А про настройку. Ну а какая разница-то? Все равно это программирование. Я не вижу (еще раз) принципиальной(!) разницы. Кто-то пишет в яве - которая выполняется в вирт.машинах. Кто-то пишет на 1с, который выполняется на выделенном сервере в своей среде. Где принципиальная разница? Это я, напомню, к первому тезису: "Правильно спроектированная архитектура в кодировании не нуждается." Не нуждается, для неё кодирование называется настройкой.