Обсуждение

Дайте пожалуйста ссылку на учебник и лингафонные материалы по английскому, которые можно использовать с anki

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

Эх, надо бы тоже штоле по системной инженерии что-нить почитать :) Я ведь раньше в основном с позиции софтверной инженерии рассматривал, как весьма близкой теме Но судя по всему системная инженерия становится актуальной даже на небольших проектах (например с точки зрения избегания типовых ошибок) с другой стороны, список "надо бы почитать" стал столь велик что до конца жизни уже боюсь ниасилить

Скромно предложу мою книжку: http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf

ISO 81346 это идеологически докомпьютерный стандарт, несмотря на время зарождения. Когда задача впихивания всего и вся в бумажные таблицы исчезла, то стало возможным использовать человекочитаемые идентификации вроде transmitter.R23, но мышление авторов осталось на уровне бумажных таблиц. Чтобы не угробить проект на старте, можно поступить так: сделать два синтаксических скина. Один для работы (где foreign designations, содержащие спец. символы, используются в кавычках), другой для "подстраивания под бумажных инженеров". Оба транслируются в один и тот же AST, с возможностью автоматической конверсии между исходниками. Далее, на каком-то этапе оценить поведение пользователей и избавиться от второго синтаксиса, если им будут пользоваться всего полтора анонимуса.

Дискуссия про значимые и незначимые десигнаторы идёт давно и долго. Идея иметь разные синтаксические скины мне приходила в голову, но там ведь проблема не только в спецсимволах (которые будут всенепременно, я уже поминал про тяжкий путь спецсимволов и русских букв в имена виндовных файлов). Там есть ещё непонятки с функциями и их позиционностью (т.е. десигнаторы частичто таки значимые, что бы ни говорили авторы стандарта), а также странным использованием типизации (комментарием вроде бы даётся тип, но если там два одинаковых объекта, то комментарий вдруг неожиданно к типу добавляет номер). Плюс разборка с обозначениями описаний, плюс системная иерархия с чуждыми именами и т.д. Но я считаю, что начинать разборки с языком нужно путём разборок с системными десигнаторами -- пониманием того, как мы будем обозначать систему. Это самое важное. В реальной производственной практике поведение инженеров (и разработчиков программных средств) полностью контролируются стандартами. Если какое-то датское строительство сказало, что десигнации будут ISO 81346 (а это, похоже, так), то 100% строителей будут их использовать, и это не полтора анонимуса. Скорее, фри-стайл десигнаторами будут пользоваться полтора анонимуса. Итого: даже в дискуссии transmitter.R23 интересно, слово transmitter это тип или десигнатор надсистемы? Ибо инженеры чаще всего строят десигнаторы как тип+цифра порядкового номера. Чаще всего, не всегда, но когда в системе 3 миллиона индивидуальных десигнаторов очень похожих друг на друга индивидуальных деталей, это понимаемо.

Не знаю насчёт native. У меня вышло С2/С2, но я всё же смотрю кино в основном с субтитрами и испытываю трудности на телеконференциях. Как я говорю - отдельный вопрос, но это не тестируется :-)

То есть и у меня есть надежда? )))

Так никто не мешает инженерам и в цивильных языках использовать легаси из !%$#^!$%!%#$^!#$%!, но в кавычках. А без кавычек опасно, сам язык начнёт деградировать до уровня !%$#^!$%!%#$^!#$%!. transmitter может быть чем угодно в данном локальном контексте. Излишние порядковые номера шумят, поэтому естественно в одной схеме использовать единственный display, а в другой display1 и display2 (но не D1 и D2). В свою очередь, для резисторов, креплений и прочей мелочи удобнее использовать индекс буква+номер.

Я понимаю, что ЛПЧ -- "кодируем помаленьку". Но я не понимаю, стоит ли идентификаторы брать в кавычки, даже если в них есть спецсимволы. Я так понимаю, обсуждается несколько разных идей: -- реализовать в языке ISO 81346 как главный вариант, "поддержать стандарт" в полной мере. Кто не поместился в этот стандарт, тот виноват. -- иметь варианты языка (скины) для разных primary designation system разных проектов, в которых десигнаторы поддерживаются не "вообще", а соответствуют какому-то определённому стандарту: ISO 81346, RDS-PP, KKS, ЕСКД, РТМ и т.д.. Иметь кит расширения языка для корпоративных десигнаций. В случае инженерии предпринятий (все эти "табельные номера") тоже иметь скины. Вопросы остаются по одновременному использованию разных скинов. -- иметь свой вариант рационально сделанного стандарта ISO 81346 в языке точно так же, как в этом же языке имеем свой вариант рационально сделанного ISO 15926. Устаревшие варианты обоих разрешать, но через какой-нибудь мэппинг, кавычки или прочие скобки, наряду с плагинами для честного ISO 15926-8, если кому-то это потребуется. -- не выделываться, язык считать языком программирования, и десигнаторы систем считать обычными строчками, которые обрабатываются языком: литералы, значения переменных и т.д.. То есть системы не являются первоклассными объектами: нет головы, нет проблемы, синтаксис десигнаторов никого не волнует, кроме самих инженеров. Язык запросов к данным, а не язык запросов к системе. Мне эта идея не нравится, но я на неё готов, если будет рассказано, как на таком языке программирования/запросов написать SysMoLan (я понимаю, как это сделать даже на Forth -- сам когда-то таким развлекался, но тут ведь будет предложено что-то покруче, да?).

1. Стандарты для designations взаимно противоречивы. Единственная возможность их поддержать (и поддержать мэппинг между ними) в одной среде - поставить все эти URI в кавычки. Альтернативные синтаксические скины можно рассматривать рассматривать как маркетинг-фичу. Применять это будут лишь те полтора анонимуса, которые гарантированно не полезут за пределы бумажной песочницы 81346 или другого локально-непротиворечивого набора стандартов отдельно взятого проекта (и даже не предприятия!). 2. Да, сначала язык программирования. Даже для такой простой вещи как поддержка составных идентификаций уже нужны функции. Кроме того, любой "язык запросов" это недоделанный "язык мэппинга", надо сразу заниматься мэппингом, а не просто запросами. Нужна база. Создание новой языковой базы требует значительного количества времени и специальных знаний. Я этим занимаюсь, но у меня более жёсткие требования именно к части программирования/мэппинга. Со статикой проще. Недавно я говорил Илье, что в вашем случае можно использовать один существующих языков (Python, Lua, ...) в качестве базы, постепенно дополняя необходимыми конструкциями. Иначе не хватит ресурсов.

Мне тоже кажется, что какой-то расширяемый язык взять за основу проще. Но если и делать SysMoLan, то я хотел бы моделировать на нём архитектуры прежде всего -- если выяснится, что будет хорошо видна структура запросов, структура мэппингов, но плохо видна структура системы, то тогда лучше придумать свой язык. Я понимаю, что все эти ArchiMate, Modelica и AADL как раз из этого исходили. А то тоже бы расширяли Lua и не мучились. Так что пока два разных проекта, два разных набора требований, два разных набора применений, два разных языка. В одном проекте все эти десигнаторы -- данные, не более, а вот операторы языка удобно писать. В другом проекте все эти операторы и запросы -- нашлёпка (то, что пишется в кавычках, чтобы не мозолить глаз и не отвлекать инженеров от парсирования глазами их моделей) над значимыми для инженеров моделями, выраженными в терминах десигнаторов. Как объединить оба проекта, непонятно. Куда пихать кавычки, если я хочу писать что-то типа:

-p1 приёмник   <<цена<<20 руб   -D1 детектор<<цена<<2 руб   -L1 катушка       <<цена<<3 руб       <<индуктивность<<5 генри       -W1 намотка       -S1 шпулька<<диаметр<<20 мм    -A1 антенна::antenna<<uri<<...

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

Конечно, нужно время. Я понимаю, что это всё "статика", и дальше будет всё ещё хуже ))) Как я понимаю, вот это моё предложение (к которому у меня и у самого более чем хватает вопросов) вчера отмоделировали, и в результате получили мультиграф. Я понимаю, что мультиграф сейчас самый писк в представлении онтологии в современном AI и у нас даже есть знакомые, которые ими занимаются. Но я почему-то считаю, что ежели всё это уйдёт в мультиграф, то вся конструкция не взлетит. Ибо умеющих написать запрос к мультиграфу будет даже поменьше чем умеющих программировать на Хаскеле и coq.

Мультиграф это представление. Из базы жж можно получить мультиграфовую картинку с рёбрами "A комментировал в журнале у B". А можно просто граф, таблицу, дерево, hive plot, whatever. Ничего сложного.

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

Тож самое. При концентрированном прохождении получил C1/C2. Хотя не считаю свой уровень близким к нативному. Тест слишком простой.

Спасибо, с нее бы непременно и начал :)