Хорошие слова. Полностью с Вами согласен. Именно их буду говорить своим студентам, когда будем проходить темы — техническое строение и функционирование микропроцессоров и основы ассемблера. Голосовать не могу. Поэтому только так — Большое спасибо.
Думаю, не только ко мне этот вопрос. Кстати интересный. Потому что в принципе описание процессов только из одной перспективы, как в вашем пиимере - отдела кадров - не самое оптимальное. Всевозможные темы имеют много чего общего, хотя и кое какие специфические вещи. И вот это общее - универсально настолько, что может почти без изменений кочевать из одной темы в другую. Пример с approval workflow ( процессы утверждения). В процессах, которые описывают проекты, есть цепочки для последующего разрешения или изменения статуса. Точно такие же процессы есть и в отделах кадров, в документо-обороте, в процессах при работе с внешними фирмами, экспертами итд. Похожие процессы протекают и в "кишках" любого микропроцессора, или например описание для Tasks, process или job у операционных симтем. Поэтому изобретать велосипед в каждой новой теме не стоит. Стоит видеть похожести. Это облегчает усилия сокращает время и проще для понимания или видоизменения потом. Думаю интернет полон всякими примерами. Есть ли у вас более конкретные вопросы? Потому что разговаривая о BPMN мы разговариваем меньше об этом, и больше о том, как работают или должны работать фирма, отдел, программа, какая-то функция или операция итд. Те. по большей частью о том, что нас окружает. И только маленькая часть - это нотации и описание. С удовольствием поделюсь, если будут вопросы.
полностью с Вами согласен. Приведу свой пример, хоть он немного из другой, нешкольной области. Работаю в Германии доцентом. Как раз по разным темам из it — начиная от железяк до софта и bigdata. Как по школам, так и по университетам — все детали образования — это задача отдельных земель, городов и школ. Нет 100% программы, которая везде одинаковая — общий контроль есть. Но он по-большей части например у меня — от студентов. Т.е. по окончании семестра у них есть возможность оценить моё преподавание по разным кретериям. При наличии дефицитов — будут разговоры с руководителями института. Но. Хоть и темы для обучения оговорены, как это будет преподнесено — моё личное право. И лекцци похожих доцентов из разных городов — различаются по оформлению, качеству, глубины преподнесения вевозможных тем итд. Т.е. имеется наличие своего рода свобод. Но нет никакой анархии в виде безконтрольности. Я, например в своём семестре имею практические занатия с платами Arduino. У других доцентов такого не слышал. А мне это помогает соеденить смежные темы — ассемблер, сотваляющие и работа микроконтроллера, алгоритмы, работа со всевозможными структурами, как например стек, регистры итд. И без этих плат можно обойтись, но с ними многие вещи становятся понятнее. И студенты об этом сообщают в своих рекомендациях к семестрам.
И ещё один момент но его задам с осторожностью. Могу ошибиться , тк. уже более 20 лет не живу в среде русского языка, но мне кажется, что ваше выражение
Помните, что операторы if — это далеко не все зло.
...должно подниматься так, что if операторы - уже зло. Но они не одни есть зло, есть и другие злые вещи. А я вам скажу своё мнение, что сам оператор не есть зло. Злом может быть необдуманное его использование, которое сильно усложняет читаемость кода, а также возведение этого оператора в своего рода ранг табу и после - "борьба" против его использования. Так называемая охота на ведьм.
Дорогой автор, даже, если вам не нравятся другие мнения, всё равно стоит к ним прислушаться. Объясню почему.
В первом случае вы привели тривиальный случай, который 1:1 повторяет if оператор - те. вы заменили этот if оператор на две функции. А что делать, если внутри функции три и более if оператора? Заменять их на n! количество функций? У меня названий не хватит, если я вместо 4-х if(ов) 24 функции напишу, каждая из которых отдельную ситуацию воспроизведёт.
Это первое. Второе. Как бы вы не упрощали, вам всё равно выше по хирархии вызовов надо будет де-то принимать решение, какую из реализаций вызывать. Поэтому видение в if чего-то, чем надо пренебрегать - есть нежелание согласится с чем-то обычным. Таким-же как, если из одного города до другого надо доехать, то это потребует времени. Да, вместо велосипеда одно взять быструю машину но всё равно- какое-то время это потребуется. Очевидно.
В последнем примере опять-же тривиальный случай с типом string. А что делать, если функция возвращает другие типы данных? Например тот-же самый созданный файл, который не смог быть открытым, тк. места на плате нет или нет прав на создание. Что вы там за default value возьмёте?
Не понимаю. весь ассемблер набит функциями по переходу в зависимости от значения или состояния в аккумуляторе. Под это и создаётся оператор if, ну те. он потом с лёгкостью переводится в набор ассемблер команд.
Если вы не видите похожести, что при описании, даже BPM-системы, нужны принципы описания, которые вы и пытаетесь создать. И идея правильная, но уже существуют реализации. И, не плохие. Я вам про грамматику, вы мне — но я-же книгу пишу.
Мы видим это в разных плоскостях. А жаль.
Я думаю под этим словом глючит не стоит ничего. Просто ярлык. Есть процессоры с их микрокодом, ассемблер. ОС, язык. Когда процессор глючил, например от Intel, то на софт-уровне эту проблему на какое-то время исправили.
Если кто-то говорит, что язык глючит, то единственное, что может в этом случае иметь место - компилятор языка сырой и требует доработки. Если язык сам по себе имеет логические или синтаксические ошибки, то он никогда не выйдет на большую сцену. Не знаю таких.
А кто вам лично мешает создавать ОС, браузеры или прикладные программы на неглючных языках писать, как вы выражается? Смешивается всё в кучу. Программирую на многих языках, вплоть до ассемблера. Ни один из них не могу назвать глючным. Один для одного типа задач, другой - для другого. Но фигни на них написать всегда можно. Но это как и с человеческим языком. Можно 50-ю словами всю жизнь обходиться и после каждого второго слова мат для связки слов использовать. А можно и так, что и 50 тысяч слов не будет хватать. Ваша абстракция с суперменом больше говорит о вас, чем о теме, которую вы затрагиваете. Зачем так сложно?
Ада-Эльбрус проецирует адскую синтаксическую инкапсуляцию памяти на аппаратную защиту советского Эльбруса, и это круто.
По мне - какой-то набор слов. Вроде умных, но вместе - ничего не значащих.
А всё вместе вами сказанное- даже и не знаю, что с этим делать. Не нравится/не удовлетворяет youtube, переходите на российский аналог. Вы думаете чересчур сложно. Но желаю вам успеха на вашем поприще.
Какие фашисты, какие вектора на самоуничтожение, какое советское кино, которое никуда нельзя вставить, какие шедевры в застенках? Дяденька, может быть два раза подумать, перед тем, как такое писать.
Если почитать, то многое, что выдавалось за своё- было хорошое, но часто всё же не наше. Не уменьшаю вклад отдельных людей, но тренд был такой - в моде, с атомными бомбами, электронными устройствами, быт. техникой и не исключение - программным обеспечением. Когда Стив Вознияк создавал прототипы Apple, то у нас об этом и духом не пахло. А видеть какое то особенное стремление, что то "настоящее наше" спрятать от общества- какая то теория заговора, не больше..
Вы так точно описали эти признаки, что спрошу вас — вы что, следите за мной и компанией в которой я работаю? (#ирония). Не могу голосовать, но подписываюсь под каждым вашим словом.
… самостоятельная сборка своего вычислительного устройства
дети/подростки/взрослые сегодня лампочку не все могут поменять дома/в машине, понятия не имеют, как без ютуба морковь почистить, а вы самостоятельная сборка. Я-бы этого тоже хотел. Но посмотришь по сторонам и сразу в обратном убеждаешься. Но как говорится — надежда умирает последней. Но ваши слова улыбнули.
апплодирую стоя (не имея возможности голосовать).
И да, страна-то развалилась, но от этого академиков меньше не стало. Как говорят, что история нас учит, что мы у истории ничему не учимся.
Ну все не могут быть такими умными как вы #ирония.
А серьёзно- ведь как раз таки и была дискуссия о интерполяции этих примеров. И именно 'проблема' с этим. Но об этом уже были пару комментариев выше.
Думаю, не только ко мне этот вопрос. Кстати интересный. Потому что в принципе описание процессов только из одной перспективы, как в вашем пиимере - отдела кадров - не самое оптимальное. Всевозможные темы имеют много чего общего, хотя и кое какие специфические вещи. И вот это общее - универсально настолько, что может почти без изменений кочевать из одной темы в другую. Пример с approval workflow ( процессы утверждения). В процессах, которые описывают проекты, есть цепочки для последующего разрешения или изменения статуса. Точно такие же процессы есть и в отделах кадров, в документо-обороте, в процессах при работе с внешними фирмами, экспертами итд. Похожие процессы протекают и в "кишках" любого микропроцессора, или например описание для Tasks, process или job у операционных симтем. Поэтому изобретать велосипед в каждой новой теме не стоит. Стоит видеть похожести. Это облегчает усилия сокращает время и проще для понимания или видоизменения потом. Думаю интернет полон всякими примерами. Есть ли у вас более конкретные вопросы? Потому что разговаривая о BPMN мы разговариваем меньше об этом, и больше о том, как работают или должны работать фирма, отдел, программа, какая-то функция или операция итд. Те. по большей частью о том, что нас окружает. И только маленькая часть - это нотации и описание. С удовольствием поделюсь, если будут вопросы.
И ещё один момент но его задам с осторожностью. Могу ошибиться , тк. уже более 20 лет не живу в среде русского языка, но мне кажется, что ваше выражение
...должно подниматься так, что if операторы - уже зло. Но они не одни есть зло, есть и другие злые вещи. А я вам скажу своё мнение, что сам оператор не есть зло. Злом может быть необдуманное его использование, которое сильно усложняет читаемость кода, а также возведение этого оператора в своего рода ранг табу и после - "борьба" против его использования. Так называемая охота на ведьм.
Дорогой автор, даже, если вам не нравятся другие мнения, всё равно стоит к ним прислушаться. Объясню почему.
В первом случае вы привели тривиальный случай, который 1:1 повторяет if оператор - те. вы заменили этот if оператор на две функции. А что делать, если внутри функции три и более if оператора? Заменять их на n! количество функций? У меня названий не хватит, если я вместо 4-х if(ов) 24 функции напишу, каждая из которых отдельную ситуацию воспроизведёт.
Это первое. Второе. Как бы вы не упрощали, вам всё равно выше по хирархии вызовов надо будет де-то принимать решение, какую из реализаций вызывать. Поэтому видение в if чего-то, чем надо пренебрегать - есть нежелание согласится с чем-то обычным. Таким-же как, если из одного города до другого надо доехать, то это потребует времени. Да, вместо велосипеда одно взять быструю машину но всё равно- какое-то время это потребуется. Очевидно.
В последнем примере опять-же тривиальный случай с типом string. А что делать, если функция возвращает другие типы данных? Например тот-же самый созданный файл, который не смог быть открытым, тк. места на плате нет или нет прав на создание. Что вы там за default value возьмёте?
Не понимаю. весь ассемблер набит функциями по переходу в зависимости от значения или состояния в аккумуляторе. Под это и создаётся оператор if, ну те. он потом с лёгкостью переводится в набор ассемблер команд.
в параметрах иногда true/false незначительно изменяют кое-какие например флаги. Т.е. убрав if, мне придётся дублировать полностью намного сложнее код.
Какое-то искуственное придумывание проблемы на пустом месте.
… правильный, но вызывает вопрос — а как быть и что делать, если этого не произойдёт? Ведь скорее всего ситуация не изменится.
Мы видим это в разных плоскостях. А жаль.
Я думаю под этим словом глючит не стоит ничего. Просто ярлык. Есть процессоры с их микрокодом, ассемблер. ОС, язык. Когда процессор глючил, например от Intel, то на софт-уровне эту проблему на какое-то время исправили.
Если кто-то говорит, что язык глючит, то единственное, что может в этом случае иметь место - компилятор языка сырой и требует доработки. Если язык сам по себе имеет логические или синтаксические ошибки, то он никогда не выйдет на большую сцену. Не знаю таких.
А кто вам лично мешает создавать ОС, браузеры или прикладные программы на неглючных языках писать, как вы выражается? Смешивается всё в кучу. Программирую на многих языках, вплоть до ассемблера. Ни один из них не могу назвать глючным. Один для одного типа задач, другой - для другого. Но фигни на них написать всегда можно. Но это как и с человеческим языком. Можно 50-ю словами всю жизнь обходиться и после каждого второго слова мат для связки слов использовать. А можно и так, что и 50 тысяч слов не будет хватать. Ваша абстракция с суперменом больше говорит о вас, чем о теме, которую вы затрагиваете. Зачем так сложно?
По мне - какой-то набор слов. Вроде умных, но вместе - ничего не значащих.
А всё вместе вами сказанное- даже и не знаю, что с этим делать. Не нравится/не удовлетворяет youtube, переходите на российский аналог. Вы думаете чересчур сложно. Но желаю вам успеха на вашем поприще.
Как же люди до сих пор могли понять и наличие библиотек и функций итд.? Вам не кажется что вы навеваете сложность там где её нет?
Вы ещё уверены, что вы на правильном портале?
Какие фашисты, какие вектора на самоуничтожение, какое советское кино, которое никуда нельзя вставить, какие шедевры в застенках? Дяденька, может быть два раза подумать, перед тем, как такое писать.
Если почитать, то многое, что выдавалось за своё- было хорошое, но часто всё же не наше. Не уменьшаю вклад отдельных людей, но тренд был такой - в моде, с атомными бомбами, электронными устройствами, быт. техникой и не исключение - программным обеспечением. Когда Стив Вознияк создавал прототипы Apple, то у нас об этом и духом не пахло. А видеть какое то особенное стремление, что то "настоящее наше" спрятать от общества- какая то теория заговора, не больше..
дети/подростки/взрослые сегодня лампочку не все могут поменять дома/в машине, понятия не имеют, как без ютуба морковь почистить, а вы самостоятельная сборка. Я-бы этого тоже хотел. Но посмотришь по сторонам и сразу в обратном убеждаешься. Но как говорится — надежда умирает последней. Но ваши слова улыбнули.
И да, страна-то развалилась, но от этого академиков меньше не стало. Как говорят, что история нас учит, что мы у истории ничему не учимся.
Дорогой автор, ну добавьте к BPM ещё одну букву N и вы получите
велосипедBPMN, который пытаетесь изобрести.