Себя поучи.
V>В переводе на русский — начальство не уверено в том, что это им вообще надо, но выделить немного денег на эксперименты не проч. V>Когда что-то действительно надо — там сценарии всегда другие.
Еще раз, тебе из первых рук говорят — была куча контор, которым было действительно надо. Кто-то ниасилил заплатить нормлальным разрабам, кого-то развели ушлые говоруны ртом, кому-то разработчиков просто не хватило.
L>>и ожидаемо пролетела, ушлые дельцы загнали аналог Rational Rose как вундерфавлю. V>Так "за обеды" или задорого?
Учу читать. Дорого.
V>Т.е., если бы эти утилиты позволяли, например, связать метод статической диаграммы с блок-схемой алгоритма или с параметризируемым шаблоном проектирования (из GoF или кучи еще библиотечных), позволял бы запускать это всё на симуляцию, задавая/играя параметрами алгоритмов — это был бы полноценный САПР. V>А так нет.
Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП, а реализация изначально автоматизирована компиляторами. То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы.
Короче, для кода САПР — это IDE со всеми плюшками.
V>В этом смысле программистские недо-САПР типа Rational Rose и Together позволяли строить разве что, скажем, "проволочную модель", которая прозрачна и статична, не обладает параметрами или свойствами, не допускает симуляции работы, т.е. примерно бесполезна.
Не примерно, а не просто бесполезна, но еще и вредна.
L>>А что, дотком — это только веб? У меня для тебя новости. V>Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но.
Иногда нужно и дальше википедии читать.
Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем.
L>>Не надо всех по себе судить, ладно? V>Я сужу не по себе, а по всем окружающим ровесникам, при том, что я был из "молодой" обоймы во второй половине 90-х — тот самый вчерашний студент. V>ООП включили в программы ВУЗ-ов для 3-го курса моей специальности в год, когда я ВУЗ заканчивал.
Да, а еще в вузах преподавали иностранные языки. С известно каким результатом.
V>Если джава, плюсы, дельфи — то да. V>И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг...
Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил
V>>>А что, сложно потратить пол-часа и запомнить, что означают символы UML? )) L>>Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей. V>Это называет "эрудиция".
Некоторые и умение "ботать по фене" эрудицией называют.
Нет смысла запоминать изначально ущербную вымученную нотацию. Ее и читать-то порой с экрана или распечатки невозможно — поди разбери это открытая стелочка, или закрытая, но не заштрихованная.
V>Она "выстреливает" не на конкретной "бессмысленной сущности", а на большом комплексе их, экономя специалисту время в каждой мелочи, встречающейся по работе.
L>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram. V>Разве ты не проходил их в ВУЗ-е?
Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?
V>Кружочков, ромбиков, трапеций, стрелок и т.д. V>Твой пренебрежительный тон должен означать некое превосходство над этим всем? ))
Не некое, а подавляющее.
Диаргамма должна быть понятна всем без исключения участникам процесса. Поэтому ты либо учишься делать визуализацию, которая понятна и заказчикам, и твоей команде, либо всю жизнь "учишь UML нотацию".
Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".
Re[10]: Опять поднимают про low-code и помоечку для средняко
Здравствуйте, landerhigh, Вы писали:
V>>Т.е., если бы эти утилиты позволяли, например, связать метод статической диаграммы с блок-схемой алгоритма или с параметризируемым шаблоном проектирования (из GoF или кучи еще библиотечных), позволял бы запускать это всё на симуляцию, задавая/играя параметрами алгоритмов — это был бы полноценный САПР. V>>А так нет. L>Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП а реализация изначально автоматизирована компиляторами.
Забавная ахинея в стиле Шарикова. ))
Изачально ведь был автокод.
Это и был "технический проект"?
А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.
В общем, коллега, еще не изобрели смайлика, чтобы выразить реакцию на подобные "окровения". ))
L>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы.
Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое.
Тут речь, скорее, о глубине иерархий сущностей проектирования, без проблем воспринимаемых человеком.
По моим наблюдениям, до глубины иерархии слоёв проектирования примерно 3 человек более-менее справляется.
Относительно алгоритмов — примерно до 7 шагов воспринимается на ура, а если больше — уже не помешает "подсказка" в том или ином виде.
Т.е., когда больше/глубже — начинаются сложности с восприятием.
Поэтому, графические представления никогда из программирования не уйдут.
И не важно, по какой нотации они выполнены.
Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде.
Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось.
Туда же псевдокод для обяснения сущности применённых "трюков".
Всё вместе резко помогло.
Реальная практика.
L>Короче, для кода САПР — это IDE со всеми плюшками.
Современные IDE не отвечают определению САПР.
Это, скорее, продвинутые текстовые редакторы исходного кода вкупе с органайзером проектов.
Я как раз рядом в обсуждениях упоминал неоднократно, что современные софтовые САПР растут из пресловутых "конструкторов сайтов".
Просто м/у простейшими конструкторами сайтов а-ля нулевые и некоторыми нынешними уже пропасть, уже ближе к берегу САПР.
V>>В этом смысле программистские недо-САПР типа Rational Rose и Together позволяли строить разве что, скажем, "проволочную модель", которая прозрачна и статична, не обладает параметрами или свойствами, не допускает симуляции работы, т.е. примерно бесполезна. L>Не примерно, а не просто бесполезна, но еще и вредна.
В нашем деле вредна лишь категоричность и прочие проявления узости ума.
L>>>А что, дотком — это только веб? У меня для тебя новости. V>>Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но. L>Иногда нужно и дальше википедии читать. L>Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем.
Увы для тебя, бум автоматизации не совпал с бумом доткомов — он начался примерно на 7 лет раньше.
И не был надутым пузырём — развитие ср-в автоматизации было поступательным.
Наверно ты имеешь ввиду, что во время бума доткомов многие участники слишком много надежд возложили на ср-ва автоматизации?
Но только это никак не повлияло на скорость развития этих ср-в.
Во времена бума доткомов много на что возложили надежд, не только на UML.
Основные надежды были:
— на быстрое продолжение развитие всемирной сети;
— на продолжение развития быстродействия компьютеров в духе 90-х;
— на продолжение развития интереса к интернету у населения со скоростью, показанной в период 95-2000-й год.
Все три пункта вошли в насыщение в начале 2000-х.
— cетка оказалась для населения дорогой и медленной.
— компьютеры резко замедлили рост быстродействия;
— даже чудовищные инвестиции в доткомы оказались не способны удовлетворить любопытство населения относительно новой технологии — т.е. развитие информационного и операционного наполнения Сети отставало от роста любопытства людей, что в итоге любопытство случилось, считай, однократным.
Но инвестиции в технологии донета не пропали даже с кризисом доткомов.
Пропали инвестиции в некоторые конкретные проекты — ну это такое...
Тут по класике надо понимать во что инвестируешь — в технологию, или в обезъянок, способных лишь использовать технологии, разработанные другими людьми.
Ну и, кризис не отменил доткомов и даже не замедлил развитие сети, но заставил более разборчиво подходить к инвестированию в этой области.
V>>Если джава, плюсы, дельфи — то да. V>>И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг... L>Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил
Но без махровых ООП-иерархий наследования — читай внимательней.
Если ты про таблицу ф-ий драйверов ОС или плагинов в некоторой прикладной системе — это тот самый компонентный подход, т.е. абстракция одного уровня.
Туда же OLE/ActiveX.
V>>>>А что, сложно потратить пол-часа и запомнить, что означают символы UML? )) L>>>Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей. V>>Это называет "эрудиция". L>Некоторые и умение "ботать по фене" эрудицией называют.
Угу, тоже порой помогает понять собеседника.
L>Нет смысла запоминать изначально ущербную вымученную нотацию.
"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так.
Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного.
И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.
Я для случая писательства не помню всех тонкостей UML, ес-но, но когда пришлось пару раз поупражняться — открыл описание нотации, открыл примеры, нарисовал за 15 мин.
Всё, вопрос исчерпан.
L>>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram. V>>Разве ты не проходил их в ВУЗ-е? L>Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?
Резьба по цитатам — это способ юления такой или как понимать?
Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности.
Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости.
V>>Кружочков, ромбиков, трапеций, стрелок и т.д. V>>Твой пренебрежительный тон должен означать некое превосходство над этим всем? L>Не некое, а подавляющее.
Пока что ты подзалетел в обсуждении несколько раз, так шта, назовём это как оно и называется — самомнением.
L>Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".
Да ладно, многие коллеги прекрасно читают без словаря.
Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. ))
В UML примерно так же, как и в любой другой области.
Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их.
Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п.
Здравствуйте, vdimas, Вы писали:
L>>Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП а реализация изначально автоматизирована компиляторами. V>Забавная ахинея в стиле Шарикова. ))
От Швондера слышу!
V>Изачально ведь был автокод. V>Это и был "технический проект"? V>А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.
И? Они до сих пор оба используются. Кое-где.
Только какое они имеют отношение к осбуждаемой теме?
L>>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы. V>Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое.
Совершенно верно. И в большинстве случаев — совершенно бессмысленно.
V>Тут речь, скорее, о глубине иерархий сущностей проектирования, без проблем воспринимаемых человеком. V>По моим наблюдениям, до глубины иерархии слоёв проектирования примерно 3 человек более-менее справляется. V>Относительно алгоритмов — примерно до 7 шагов воспринимается на ура, а если больше — уже не помешает "подсказка" в том или ином виде. V>Т.е., когда больше/глубже — начинаются сложности с восприятием.
Если разработчику при работе над конкретным модулем нужно держать в голове 7 уровенй иерархий проектирования, то вы проектируете что-то не то. Или не так. Или все вместе.
V>Поэтому, графические представления никогда из программирования не уйдут. V>И не важно, по какой нотации они выполнены.
Натравливаешь на код doxygen, он рисует достаточное графическое представление.
V>Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде. V>Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось.
Так согласно одной довольно известной догме программирования, это означает, что код — говно-с
А если серьезно, то никаких проблем в комментариях описать диаграмму поведения модуля на языке plantuml, и доксиген тебе ее интегрирует прямо в документашку.
V>Туда же псевдокод для обяснения сущности применённых "трюков".
А не надо применять "трюки".
L>>Короче, для кода САПР — это IDE со всеми плюшками. V>САПР в программировании — это примерно такое:
Ага, вот именно вот так и продавались аналоги RR в начале нулевых. Как пылесосы Кирби.
L>>Не примерно, а не просто бесполезна, но еще и вредна.
V>В нашем деле вредна лишь категоричность и прочие проявления узости ума.
Категоричность?
Софтовые конторы сейчас рисуют подробные UML модели примерно... ээ, да никогда.
Затраты времени на их построение себя не оправдывают.
Вот набросать квадратиков за 15 минут — да.
L>>Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем. V>Увы для тебя, бум автоматизации не совпал с бумом доткомов — он начался примерно на 7 лет раньше.
Увы, но ты опять не умеешь читать.
L>>Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил V>Но без махровых ООП-иерархий наследования — читай внимательней.
Махровые ООП иерархии — это такой же карго-культ, как и любая другая дичь.
V>>>Это называет "эрудиция". L>>Некоторые и умение "ботать по фене" эрудицией называют. V>Угу, тоже порой помогает понять собеседника.
Чтобы понять, что с "собеседником" беседы не получится, не обязательно обладать такой "эрудицией".
L>>Нет смысла запоминать изначально ущербную вымученную нотацию. V>"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так. V>Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного. V>И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.
Иными словами — это лишняя сущность. Вымученная. О чем я тебе и говорю.
V>Я для случая писательства не помню всех тонкостей UML, ес-но, но когда пришлось пару раз поупражняться — открыл описание нотации, открыл примеры, нарисовал за 15 мин. V>Всё, вопрос исчерпан.
Ага. No Hire
L>>>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram. V>>>Разве ты не проходил их в ВУЗ-е? L>>Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?
V>Как-то странно ты скипнул часть вопроса: V>Резьба по цитатам — это способ юления такой или как понимать?
Если ты собрался брать меня на слабо, то ты опоздал на сорок лет.
Конечные автоматы — моя любимая фишка в принципе. Наличие state diagram в любом UML редакторе лично мне помогает вбивать в голову юным падаванам правильные инженерные практики.
V>Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности. V>Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости.
Пока что только ты показываешь узость кругозора и приписываине собеседнику своих домыслов.
L>>Не некое, а подавляющее. V>Пока что ты подзалетел в обсуждении несколько раз, так шта, назовём это как оно и называется — самомнением.
Скажем так, оно довольно обоснованное. В отличие от.
L>>Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".
V>Да ладно, многие коллеги прекрасно читают без словаря.
А ты сам?
V>Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. ))
И чтобы на этот уровень выйти, нужно на языке общаться, читать и писать. А не пытаться запомнить синтетические правила, натужно натягиваемые на живой язык.
V>В UML примерно так же, как и в любой другой области. V>Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их. V>Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п.
Какая-то у тебя каша в голове, честное слово.
Re: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Dym On, Вы писали:
DO>Здравствуйте, Shmj, Вы писали:
S>>Ваше мнение? DO>Я за low-compile-code. Поясню. Вот есть некий сложный объект, на котором установлена некоторая система автоматизации чего-то там. В какой-то момент было модно сложную конфигурацию делать на C#. И вот ты сидишь на объекте, к тебе прибегают взмыленные сотрудники заказчика с выпученными глазами: "Нужно вот это, аааааа, срочнаааа". Ты понимаешь, что для того, чтобы удовлетворить пожелания заказчика тебе нужно всего лишь поменять у одного параметра 5 на 6 и всё. Но, чтобы поменять, тебе нужно открыть MSVS, подгрузить сольюшен, нугетовские пакеты, поменять одну цифру, скомпилировать и обновить dll-ки. Только вот на площадке заказчика нет ни студии ни сольюшена, вообще из IDE только notepad.exe. Ну и чего делать? Завонишь в свою же поддержку, где сидит индус, которого наняли вчера, он проект видит первый раз в жизни, пытаешься ему полдня объяснить что нужно сделать, он чего-то делает, присылает, оказывется, что это не то, и он ни хрена не понял. И простая операция растягивается на несколько дней.
Вот в этом смысле офигенно работают just-in-time вещи типа того же PHP. В целом, понятное дело, PHP — отстой, но вот что в нём круто — так это как раз возможность открыть проект прямо в проде прямо при помощи хоть vi, хоть notepad.exe и поправить его на лету.
Если мы берём ту же идею и переносим её на нормальную реализацию, получаем JSP, где у нас, фактически, конвеер зависимостей *.jsp -> *.java -> *.class -> x64.
То есть сочетаем преимущества скриптанины с преимуществами статики.
Примерно то же, на пару десятков лет моложе, имеем в виде ASP.NET.
Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений. Copy-deployment и source-level-edit — это ж то, что доктор прописал, и в очень многих сценариях.
Ну, понятно, что десктопному приложению заменять на лету определение класса не с руки — что делать с состоянием? А вот для каких-нибудь workflow движков это было бы очень даже к месту.
Я вот сейчас отлаживаю коннектор для PowerBI, и волшебным образом оказывается, что можно прямо в десктопном приложении безо всякого перезапуска переподкладывать dll. То есть я внёс изменения -> перекомпилировал -> скопировал в папочку Documents/Power BI Desktop/Custom Connectors — и всё, достаточно нажать Refresh, чтобы данные перезакачались через новую версию коннектора.
Если выкинуть из этой технологической цепочки Visual Studio и Power Query SDK, то всё станет ещё лучше — почему бы мне не править просто исходник коннектора, чтобы powerbi сам его пересобирал при необходимости?
Тем более, что сборка там занимает миллисекунды.
То, что это работает, естественно, построено на statelessness коннектора. Нет никаких объектов "устаревших классов", которые нужно как-то перетащить из старой версии в новую.
Имхо, в эту сторону и надо копать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Sinclair, Вы писали:
S>Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений.
Так для этого делают скриптовые интерфейсы, разве нет? Autocad, Photoshop, Wireshark — все они содержат в себе интерпретатор, который позволяет оперировать примитивами на уровне пользователя. Разве этого мало?
Игры так вообще сценарии всегда на скриптах делали (luajit на них и поднялась).
Re[4]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Nuzhny, Вы писали: N>Так для этого делают скриптовые интерфейсы, разве нет? Autocad, Photoshop, Wireshark — все они содержат в себе интерпретатор, который позволяет оперировать примитивами на уровне пользователя. Разве этого мало?
Да, пожалуй, вы правы. О них я как-то не подумал. N>Игры так вообще сценарии всегда на скриптах делали (luajit на них и поднялась).
С играми я достаточно слабо знаком. Полагаю, что скрипты там делали вовсе не потому, что хотелось править ошибки прямо на машине пользователя.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Sinclair, Вы писали:
S>Вот в этом смысле офигенно работают just-in-time вещи типа того же PHP. В целом, понятное дело, PHP — отстой, но вот что в нём круто — так это как раз возможность открыть проект прямо в проде прямо при помощи хоть vi, хоть notepad.exe и поправить его на лету.
То ли у вас очень странный прод, то ли ты забываешь про то что нод с рнр файлами обычно больше одной.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Sinclair, Вы писали:
S>Вот в этом смысле офигенно работают just-in-time вещи типа того же PHP. В целом, понятное дело, PHP — отстой, но вот что в нём круто — так это как раз возможность открыть проект прямо в проде прямо при помощи хоть vi, хоть notepad.exe и поправить его на лету.
Тем удивительнее желание некоторых накрутить поверх JIT старый добрый конвеер. (Вы, конечно, понимаете, о ком я). Компиляция в этом случае отлавливает ну настолько тривиальные ошибки, что за 2 года работы над достаточно сложным (назовём его так) JIT-проектом ни одна не пролезла через защитный барьер автотестов (в виде исключения «метод не найден» или чего-то вроде). При этом я регулярно сталкивался с прессингом смежных сиплюсплюсников, которым мозолило глаза отсутствие привычных вещей: этапа сборки, CMake или чего-то вроде, киловаттов на билд-сервере и т.д., и которые регулярно предлагали зачем-то («Для безопасности!». «От кого? От фашистов, что ли?») прикрутить язык, компилируемый в JIT-язык.
Я выдвинул два простых соображения:
1. У нас в управляемых средах (а именно на них крутятся JIT-языки) таких ошибок, как у вас, вообще не бывает. Когда вы вчетвером мозговые штурмы по полгода устраиваете, чтобы просто понять, где была прострелена нога. У нас ошибки другие, и компиляцией они ловятся именно что малоэффективно. Статистика саппорта/фидбека подтверждает.
2. Конвеер не бесплатен. Скорость быстрого реагирования — а с ней багофикса, внедрения, латания дыр, обхаживания клиентов и тому подобных вещей из жизни реальных проектов — снизится на порядок.
Второе соображение было услышано не очень хорошо. Когда люди носят вериги, они перестают замечать неудобства.
Мантра-оберег: в целом, понятное дело, Ecmascript — отстой, но...
S>Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений. Copy-deployment и source-level-edit — это ж то, что доктор прописал, и в очень многих сценариях.
Вредители, сэр. Ну, или дело в дотком-буме, может? Когда быстрое реагирование впервые стало по-настоящему быстрым, без этих вот «5.0, 6.0», разделяемых годами.
За пределами веба я на эту тему таких чудес насмотрелся. В одном случае нужны были скрипты для управления промышленным оборудованием. Парни хотели взять готовый движок — на тот момент, если не ошибаюсь, для этих целей актуален был Tcl — но им не дали. Тогда они сели колхозить свой (!!!), с кучей багов, кривой, ни с чем не совместимый урод, и это прошло на ура. Так я потом имел приватный разговор с европейским дилером, который сказал, что и за этот-то колхоз будет вечно за них бога молить — хоть как-то жить можно! Отдельный прикол в том, что другую часть проекта так и оставили на плюсах. Благодаря этому было создано отдельное рабочее место (позже — второе), получено одно повышение, оплачена куча перелётов по всему миру — всё это только потому, что дилер (сотрудник той же компании! финансово — все в одной лодке!) не мог, работая с промоборудованием, доступиться до него не через голову программистов. Кто ж от такого откажется.
А вообще, хоть это и казалось на уровне подкорки очевидным, давайте считать ценным вкладом в тему: low-code из формулы no-code/low-code должен быть JIT/managed.
Do you want to develop an app?
Re[4]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Nuzhny, Вы писали:
S>>Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений. N>Так для этого делают скриптовые интерфейсы, разве нет? Autocad, Photoshop, Wireshark — все они содержат в себе интерпретатор, который позволяет оперировать примитивами на уровне пользователя. Разве этого мало?
Ой, это капля в море. Как в смысле ассортимента, так и реализации. Если бы это было развито на уровне веб-приложений, было бы ядро с операциями, на которое можно натягивать любые наборы кнопок. Такое только MSO на моей памяти разрешал, да и то через три ... колено.
N>Игры так вообще сценарии всегда на скриптах делали (luajit на них и поднялась).
Осталось понять, что общего у ворона и письменного стола. В смысле, у игр и веб-приложений, которые в этом смысле действительно похожи.
Do you want to develop an app?
Re[4]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Nuzhny, Вы писали: S>>Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений. N>Так для этого делают скриптовые интерфейсы, разве нет?
Ага. И эти вещи можно было делать еще 20 лет назад
Здравствуйте, Shtole, Вы писали:
S>Ой, это капля в море. Как в смысле ассортимента, так и реализации. Если бы это было развито на уровне веб-приложений, было бы ядро с операциями, на которое можно натягивать любые наборы кнопок. Такое только MSO на моей памяти разрешал
Как минимум в упомянутом Автокаде тоже самое.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, Shtole, Вы писали:
S>Представьте себе таблицу. Но не таблицу «Тебе, дебилушка!», как в Excel. Во-первых, её колонки типизированы, а во-вторых имеют имена. О да, это требует указать типы (число, строка, дата, флаг, ссылка) и немыслимо напрячься, вбивая имена колонок. Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ
По сути, Access получится.
Sapienti sat!
Re[2]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Dym On, Вы писали:
DO>Здравствуйте, Shmj, Вы писали:
S>>Ваше мнение? DO>Я за low-compile-code. Поясню. Вот есть некий сложный объект, на котором установлена некоторая система автоматизации чего-то там. В какой-то момент было модно сложную конфигурацию делать на C#. И вот ты сидишь на объекте, к тебе прибегают взмыленные сотрудники заказчика с выпученными глазами: "Нужно вот это, аааааа, срочнаааа". Ты понимаешь, что для того, чтобы удовлетворить пожелания заказчика тебе нужно всего лишь поменять у одного параметра 5 на 6 и всё. Но, чтобы поменять, тебе нужно открыть MSVS, подгрузить сольюшен, нугетовские пакеты, поменять одну цифру, скомпилировать и обновить dll-ки. Только вот на площадке заказчика нет ни студии ни сольюшена, вообще из IDE только notepad.exe.
А рабочий ноутбук на проходной отобрали? А когда следующее обновление заказчику будете ставить — там этот фикс учтется?
Может все-таки над деплойментом немного поработать чтобы он был автоматизированее и желания лезть руками на прод не возникало.
Re[3]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, Константин Б., Вы писали:
КБ>А рабочий ноутбук на проходной отобрали? А когда следующее обновление заказчику будете ставить — там этот фикс учтется? КБ>Может все-таки над деплойментом немного поработать чтобы он был автоматизированее и желания лезть руками на прод не возникало.
На прошлой работе на проходной даже сотовые телефоны и флешки просили сдавать. Чтобы пронести ноутбук — это надо у замминистра разрешение оформлять пару недель и не факт, что дадут. Пару раз было такое, что распаковывал jar, менял там в конфиге значение и запаковывал взад. Или на месте компилировал нужный файл и менял class-файл. Потому, что по уму делать — несколько дней минимум на все согласования, это неприемлемо. Потом в следующем обновлении, конечно, уже по уму было сделано.
Но всё же это особая особенность заказчика, думаю, такое редко встречается.
Здравствуйте, landerhigh, Вы писали:
V>>Изачально ведь был автокод. V>>Это и был "технический проект"? V>>А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый. L>И? Они до сих пор оба используются. Кое-где.
Дык, они и тогда использовались "кое-где", а основное сложное ПО, про которое можно было сказать, что это ПО имеет архитектуру — оно писалось на автокоде.
Повторяю вопрос: автокод — это и был "технический проект"?
L>Только какое они имеют отношение к осбуждаемой теме?
Это демонстрация изрекаемой тобой чуши.
"Технический проект" начинал свою жизнь задолго до реализации его на автокоде.
Т.е. на бумаге, будучи представлен графикой и словесным описанием.
L>>>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы. V>>Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое. L>Совершенно верно. И в большинстве случаев — совершенно бессмысленно.
Большинство написанного кода тоже выкидывается.
Хотя бы в процессе его улучшения/переписывания.
Означает ли это, что код не надо писать вовсе? ))
L>Если разработчику при работе над конкретным модулем нужно держать в голове 7 уровенй иерархий проектирования
Семь было про шаги алгоритма.
Да, бывают такие алгоритмы, в которые лучше подсматривать при их кодировании.
И таких алгоритмов большинство из тех, которые можно назвать хоть сколько-нибудь полезными, т.е. делающими хоть что-то требуемое в современном мире, начиная от работы планировщиков ОС, до мультимедии и сетевых протоколов.
L>то вы проектируете что-то не то. Или не так. Или все вместе.
Или ты сталкивался только с простейшими вещами по работе.
V>>Поэтому, графические представления никогда из программирования не уйдут. V>>И не важно, по какой нотации они выполнены. L>Натравливаешь на код doxygen, он рисует достаточное графическое представление.
))
V>>Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде. V>>Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось. L>Так согласно одной довольно известной догме программирования, это означает, что код — говно-с
С таким подходом для тебя любой код говно-с, который чуть сложнее 2+2.
Чтобы понимать код, в первую очередь надо понимать, что именно он делает.
И вот код делает что-то нетривиальное — без предварительного понимания закодированных процессов смотреть в код бесполезно.
L>А если серьезно, то никаких проблем в комментариях описать диаграмму поведения модуля на языке plantuml, и доксиген тебе ее интегрирует прямо в документашку.
Диаграмма поведения на ём толком не описывалась и сегодня имеет ряд ограничений.
Например, мне надо несколько стартовых точек и несколько конечных.
И эта диаграмма описывает поведение системы из примерно десятка объектов.
В комментари к какому из них мне нарисовать диаграмму их общей многопоточной активности?
Правильный ответ — ни к какому, оно будет жить отдельно от каждого из участвующих объектов, как и есть сейчас.
V>>Туда же псевдокод для обяснения сущности применённых "трюков". L>А не надо применять "трюки".
Бгг, "трюки" нужны для кодирования даже банального JPG (БПФ).
L>>>Короче, для кода САПР — это IDE со всеми плюшками. V>>САПР в программировании — это примерно такое: L>Ага, вот именно вот так и продавались аналоги RR в начале нулевых. Как пылесосы Кирби.
Да там один вменяемый был аналог.
L>Категоричность? L>Софтовые конторы сейчас рисуют подробные UML модели примерно... ээ, да никогда.
"Подробные" — это стадия торговли.
Или таки абсолютно никогда?
Если последнее — сразу ха-ха три раза.
Это в наколенных конторах не рисуют, где ничего сложного и не разрабатывают.
L>Затраты времени на их построение себя не оправдывают. L>Вот набросать квадратиков за 15 минут — да.
Оно примерно столько времени и требует.
Пусть иногда чуть больше, чем 15 минут, а даже около часа на некую подробную sequence-диаграмму, но оно потом экономит многие человекодни.
L>>>Нет смысла запоминать изначально ущербную вымученную нотацию. V>>"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так. V>>Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного. V>>И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна. L>Иными словами — это лишняя сущность. Вымученная. О чем я тебе и говорю.
Твоё "говорю" означает "раздавать оценочные суждения", т.е. суждения нулевой полезности. ))
L>Если ты собрался брать меня на слабо, то ты опоздал на сорок лет. L>Конечные автоматы — моя любимая фишка в принципе. Наличие state diagram в любом UML редакторе лично мне помогает вбивать в голову юным падаванам правильные инженерные практики.
Но state diagram однопоточна.
Что делать в случае трёх и более взаимодействующих потоков?
Неужели надо брать другой вид диаграммы?
V>>Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности. V>>Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости. L>Пока что только ты показываешь узость кругозора и приписываине собеседнику своих домыслов.
Пока что мне просто весело от такой незамутнённости.
V>>Да ладно, многие коллеги прекрасно читают без словаря. L>А ты сам?
Длиннее в любом случае.
V>>Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. )) L>И чтобы на этот уровень выйти, нужно на языке общаться, читать и писать.
Отож.
V>>В UML примерно так же, как и в любой другой области. V>>Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их. V>>Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п. L>Какая-то у тебя каша в голове, честное слово.
Да там сразу было понятно, что тебе ничего не понятно.
State-диаграмм ему достаточно.
Ну ОК, с этого надо было начинать. ))
Здравствуйте, vdimas, Вы писали:
V>И таких алгоритмов большинство из тех, которые можно назвать хоть сколько-нибудь полезными, т.е. делающими хоть что-то требуемое в современном мире, начиная от работы планировщиков ОС, до мультимедии и сетевых протоколов.
Назови хоть один. Не подлядывая в вики.
V>Но state diagram однопоточна. V>Что делать в случае трёх и более взаимодействующих потоков?
Ты изобретаешь многопоточный конечный автомат?
У меня для тебя плохие новости.
V>Неужели надо брать другой вид диаграммы?
Боюсь, не поможет.
Re: Опять поднимают про low-code и помоечку для средняков...
Строители "программируют" BIM–объекты мышкой. В игровых проектах умеренной сложности рулит Unreal'овские Blueprints. У промавтоматчиков, наверное, до сих пор жив MЭK 61131. В экспериментальном секторе промоборудования вполне основательно себя чувствует LabView, завязанный не на алгоритмы, а на диаграммы потоков данных. RF–алгоритмы тоже, я видел, стало модно накидывать виртуальными кубиками-проводами с крутилками. Аналитики прутся от Tableau. И т.д. и т.п.
Единственная проблема — всемогутор общего назначения таким путём не создать. Только нишевые решения, без всяких шагов влево-вправо. Связано это и с нехваткой выразительных средств nocode/lowcode. И с лютeйшим ростом когнитивной сложности графического представления — на сложных сценариях классический текст программы становится понятнее.
Re: Опять поднимают про low-code и помоечку для средняков...
low-code/no-code нужны для начала для GUI. Реализовать UI максимально полно, и предоставлять пользователю максимальную гибкость для настройки.
Чтобы не надеяться, что разработчик догадается — что нужно пользователю.
Например Visual Studio — чего там только нет, но очень нужного для меня там нет. В Solution Explorer, для перехода к проекту(когда их много), хочется не скроллировать все дерево:
— Либо как в редакторе кода — сверху combo box с проектами, при выборе перепрыгивает на нужный проект.
— Либо двойное окно. В главном видны только проекты, в дочернем содержимое выбранного проекта.
— Или другие стандартные известные трюки навигации по деревьям.
Хотя для этого есть workaround: Tab control для открытых документов закрепить слева, а не сверху. Настроить чтобы открытые документы группировались в проекты, и открыть из каждого проекта по одному документу — тогда можно быстро прыгать по проектам.
Но это тоже криво. И почему-то в этом окне при клике на проект(заголовок группы) ничего не делается — логично было бы перепрыгивать к проекту в Solution Explorer. И не помешала бы опция — показывать в нем проект, даже если в нем нет открытых документов.
Прогресс есть — движение к полноте в UI. Раньше даже tab control нельзя было закрепить слева. Но до идеального результата еще далеко.
P.S. low-code/no-code для начала нужна полнота, в базовой части.
