дневник заведен 02-06-2002
постоянные читатели [303]
цитатник:
- • лента
17-09-2009 21:46 Программное заявление
Когда в результате бессмысленной и беспощадной оранжевой революции мы придём к власти, я намерен принять закон, который будет автоматически причислять к сексуальным меньшинствам всех, пытающихся писать многопоточный код под windows без предварительного детального прочтения соответствующей литературы. А так как принадлежность к оным меньшинствам в нашем справедливом государстве будет караться неукоснительной смертной казнью, то средний профессиональный уровень программистов будет значительно повышен.
Так же я намерен воспользоваться законом о защите наших интересов за рубежом для того, чтобы убедиться в исполнении вышеописанного не только в России, но и в Китае и Индии. Даже, пожалуй, с них начнём.
И будет всем счастье.
Так же я намерен воспользоваться законом о защите наших интересов за рубежом для того, чтобы убедиться в исполнении вышеописанного не только в России, но и в Китае и Индии. Даже, пожалуй, с них начнём.
И будет всем счастье.
Группы: [ програмазмы ]
[ Рабочее ]
Комментарии:
во как наболело у человека 
Мне интересно, как ты будешь отслеживать сей факт. А если он прочел, но нифига не понял?
Много может быть неточностей, надо будет поработать над этим законом
Много может быть неточностей, надо будет поработать над этим законом
Программиста вообще не должно парить "много" поточный у него код или нет.
Все проблемы от морально устаревших средств разработки. Если всему прогрессивному человечеству понятно "как" организовывать потоки и их согласование, то решение считается тривиальным и подлежит вынесению за скобки ручной имплементации.
Все проблемы от морально устаревших средств разработки. Если всему прогрессивному человечеству понятно "как" организовывать потоки и их согласование, то решение считается тривиальным и подлежит вынесению за скобки ручной имплементации.
Pacifik Ну тогда уж речь не о средствах разработки, а о парадигме программирования. Декларативный код еще как-то справляется с этой задачей, но "вынести за скобки" управление потоками при императивной модели как-то пока ни у кого не получилось - вне зависимости от средств разработки. И вряд ли получится.
А декларитивный код пока всё равно менее эффективен по сравнению с.
А декларитивный код пока всё равно менее эффективен по сравнению с.
Ой. Ой, сколько слов, значение которых я представляю себе смутно ...
Я хочу просто привести пример программы, которая не требует от программиста ничего кроме протягивания стрелочки от одного кубика к другому. Это Tibco BusinessWorks, который умеет все, разве что варить суп.
Я хочу просто привести пример программы, которая не требует от программиста ничего кроме протягивания стрелочки от одного кубика к другому. Это Tibco BusinessWorks, который умеет все, разве что варить суп.
Pacifik я могу ошибаться, но мне кажется, что это скорее оркестратор бизнеспроцессов, а-ля BizTalk. Это, как бы, принципиально иной архитектурный уровень, всё же. К собственно программированию данный вопрос отношение имеет чуть более чем никакое.
Tibco не конкурирует с бизтоком. Скорее с WebSphere или оракловыми решениями.
Это не оркестратор "бизнес-процессов", для этого есть более мудреный продукт.
То что приведено на скриншоте - это код некоторой функциональности приложения (интеграционного адаптера если называть вещи своими именами).
Если называть вещи еще более своими именами - то это сервис кеширования неких данных (бизнес-объектов). Как косвенно видно по дисижен три в начале в сервисе реализовано несколько методов (начальная загрузка данных при старте приложения, обновление кеша, гет из кеша и т.п).
Как видно есть циклы (группы с закругленной стрелочкой в шапке), есть критические секции (их нужно просто заключить в группу и они никогда не пересекутся), есть полная абстракция от понятий "переменная", память. Есть серия операций, у каждой из которых есть вход и выход. Все что нужно программисту - придумать в какой последовательности выполнить операции, какие условия поставить на стрелочки, и как оформить XSLT преобразования.
Ах, да. Самое важное! Придумать толковые названия для кубиков.
Все преобразования выполняются через XSLT. Поддерживается XPath. Как они обсчитываются я никогда даже не задумывался. Я просто знаю что в определенной точке мне нужно закончить определенные вычисления чтобы двигаться дальше, поэтому я собираю стрелочки в этой точке и рисую следующую.
Я не ограничен в каналах коммуникаций - можно по JDBC подключиться к базе данных, можно сандалить и слушать TCP (ну и следовательно HTTP), EBS, FTP да хоть просто графический интерфейс с пользователем можно вставить.
И хотя у этой платформы достаточно прикладное назначение - создавать интеграционные адаптеры (посредников между шиной данных и приложением), количество практических задач которые можно решить с ее помощью превращает ее в, практически, полноценную среду разработки.
Например, я написал на ней морской бой. ПРостая веб-страничка с расчерченным полем и картинками. Можно стрелять по клеткам, открывая их, и топить корабли если они за ними скрываются. Очень убедительно получилось. Главное что я не написал ни строчки кода. Даже шаблон HTML страницы я рисовал а не прописывал.
Я за 3 часа реализовал игру, которую кодом описывал бы пару дней.
Конечно под этим всем, где-то там далеко внизу лежит ява. Но, мне это не интересно. Мне интересно быстро создавать работающие решения. И, да, я не знаю как реализовывать многопоточный код. Зато я знаю что могу пустить из одной точки две стрелочки и они будут просчитываться независимо.
Ну и, конечно же, я не программист. Но я, получается, создаю программы. Ведь в конце концов все эти схемы превращаются в код на яве. Точно так же как инструкции превращаются компилятором в машинный код.
Или это все-таки программирование ? )) Разве это не алгоритмическая реализация поставленной задачи ?
Мне, почему-то, кажется, что это все то же программирование. Либо я не выпускник кафедры кибернетики.
Это не оркестратор "бизнес-процессов", для этого есть более мудреный продукт.
То что приведено на скриншоте - это код некоторой функциональности приложения (интеграционного адаптера если называть вещи своими именами).
Если называть вещи еще более своими именами - то это сервис кеширования неких данных (бизнес-объектов). Как косвенно видно по дисижен три в начале в сервисе реализовано несколько методов (начальная загрузка данных при старте приложения, обновление кеша, гет из кеша и т.п).
Как видно есть циклы (группы с закругленной стрелочкой в шапке), есть критические секции (их нужно просто заключить в группу и они никогда не пересекутся), есть полная абстракция от понятий "переменная", память. Есть серия операций, у каждой из которых есть вход и выход. Все что нужно программисту - придумать в какой последовательности выполнить операции, какие условия поставить на стрелочки, и как оформить XSLT преобразования.
Ах, да. Самое важное! Придумать толковые названия для кубиков.
Все преобразования выполняются через XSLT. Поддерживается XPath. Как они обсчитываются я никогда даже не задумывался. Я просто знаю что в определенной точке мне нужно закончить определенные вычисления чтобы двигаться дальше, поэтому я собираю стрелочки в этой точке и рисую следующую.
Я не ограничен в каналах коммуникаций - можно по JDBC подключиться к базе данных, можно сандалить и слушать TCP (ну и следовательно HTTP), EBS, FTP да хоть просто графический интерфейс с пользователем можно вставить.
И хотя у этой платформы достаточно прикладное назначение - создавать интеграционные адаптеры (посредников между шиной данных и приложением), количество практических задач которые можно решить с ее помощью превращает ее в, практически, полноценную среду разработки.
Например, я написал на ней морской бой. ПРостая веб-страничка с расчерченным полем и картинками. Можно стрелять по клеткам, открывая их, и топить корабли если они за ними скрываются. Очень убедительно получилось. Главное что я не написал ни строчки кода. Даже шаблон HTML страницы я рисовал а не прописывал.
Я за 3 часа реализовал игру, которую кодом описывал бы пару дней.
Конечно под этим всем, где-то там далеко внизу лежит ява. Но, мне это не интересно. Мне интересно быстро создавать работающие решения. И, да, я не знаю как реализовывать многопоточный код. Зато я знаю что могу пустить из одной точки две стрелочки и они будут просчитываться независимо.
Ну и, конечно же, я не программист. Но я, получается, создаю программы. Ведь в конце концов все эти схемы превращаются в код на яве. Точно так же как инструкции превращаются компилятором в машинный код.
Или это все-таки программирование ? )) Разве это не алгоритмическая реализация поставленной задачи ?
Мне, почему-то, кажется, что это все то же программирование. Либо я не выпускник кафедры кибернетики.
Pacifik понятно. Очень интересно, спасибо.
Но это всё-таки значительно более высокий уровень кода. Конструктор лего из кубиков. И таки да, это программирование, но как раз то, что я писал изначально - другая парадигма, декларативный стиль написания описания программы. Для совсем других задач. Для архитектуры сервисов - идеально. Для более специфических задач - навряд ли. Написать-то можно что угодно на чем угодно, но как только речь зайдет о том, как сделать эффективно - никуда ты от старого доброго императивного стиля не денешься.
Но мы об очень разном круге задач говорим. То, что может так легко писаться - оно и параллелиться легко. До той поры пока ты не начинаешь писать код самих "кубиков". А там ты все равно рано или поздно столкнешься с необходимостью писать вручную, и писать правильно.
То, на что матерюсь я - недетская такая физическая задача, считаемая в реальном времени на кластере из полутора сотен ядер. Ни о каком декларативном подходе тут и речи не может быть. И подавляющее большинство "общих" задач таково же.
Хотя да, мечта о языке программирования уровня "Хочу базу данных, хочу чтоб работала" - она всем присуща. Только вряд ли это когда-нибудь придет в нашу область.
Но это всё-таки значительно более высокий уровень кода. Конструктор лего из кубиков. И таки да, это программирование, но как раз то, что я писал изначально - другая парадигма, декларативный стиль написания описания программы. Для совсем других задач. Для архитектуры сервисов - идеально. Для более специфических задач - навряд ли. Написать-то можно что угодно на чем угодно, но как только речь зайдет о том, как сделать эффективно - никуда ты от старого доброго императивного стиля не денешься.
Но мы об очень разном круге задач говорим. То, что может так легко писаться - оно и параллелиться легко. До той поры пока ты не начинаешь писать код самих "кубиков". А там ты все равно рано или поздно столкнешься с необходимостью писать вручную, и писать правильно.
То, на что матерюсь я - недетская такая физическая задача, считаемая в реальном времени на кластере из полутора сотен ядер. Ни о каком декларативном подходе тут и речи не может быть. И подавляющее большинство "общих" задач таково же.
Хотя да, мечта о языке программирования уровня "Хочу базу данных, хочу чтоб работала" - она всем присуща. Только вряд ли это когда-нибудь придет в нашу область.
Капитан Очевидность, взываю к тебе! 
Алекс Лочер офтоп
http://hh.ru/vacancy/2281710
кто-то из твоих интереовался ремеди http://hh.ru/vacancy/2281710
http://hh.ru/vacancy/2281710
кто-то из твоих интереовался ремеди http://hh.ru/vacancy/2281710
Tammi Спасибо. Насколько я понимаю, интересовавшаяся там даже была на собеседовании, и чего то там ей не понравилось.
Камрад
Tammi Спасибо, мы уже беседовали в июне. Видимо с тех пор они так никого и не нашли.
Алекс Лочер Freeda ну тут мое дело - посигналить. Жаль что не тое...
мои пять копеек
[Print] 1 2
William Wolos