Ниша и целевая аудитория

Мне вот кажется, что "чистый вычислитель" мало кому будет интересен - на рынке много чего есть и нового и старого. Не говоря уже о смартфонах.

Таки надо что-то карманное, работающее долго-долго от батареек, с привлекательным языком программирования (при всем моем уважении не Форт), со всевозможными "подключалками". Простой и удобный механически-электронно-софтовый интерфейс для создания своих модулей расширения (с опенсорсными печатными платами и файлами корпуса для 3Д печати)

И тогда потянутся люди. И начнется сообщество

Я всё таки должен напомнить, почему Форт и для чего он там. Сам Форт конечно трудно рассматривать как язык пользовательского уровня. Но его среда выполнения очень удобна для создания более высокоуровневых конструкций в рамках единой унифицированной системы. По сути предлагается использовать Форт-образную среду как основу для остальных конструкций в калькуляторе, по пути RPL машин. Сами же надстраиваемые языки не обязаны иметь с Фортом ничего общего, как Java не похожа на свою стековую машину.

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

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Пользователь, если он без хакерских замашек, не увидит Форт и скорее всего даже не будет знать о нём. Для него там будет какой нибудь Бейсик. И даже продвинутый пользователь будет пользоваться каким то высокоуровневым языком вроде Лиспа или Акторного Оберона, со всякими вкусными макросистемами и продвинутой системой обработки ошибочных ситуаций, хотя у него будет доступ к Форту и даже машкоду (т.к. это хакерский проект в первую очередь). Все эти языки смогут вызывать процедуры друг друга, т.к. под низом они будут превращаться в код на Форте или вызываться через него. Все процедуры управления памятью, драйверы устройств и т.п. системные программные интерфейсы будут общими и доступны из всех языков этой платформы.
В общем не Форт это, как язык программирования, а виртуальная Форт-машина как среда сборки и выполнения.

http://www.mosaic-industries.com/Products/Software/
но, наверное, со всемии исходниками и вариантами аьтернативных реализаций.

Идея слишком хороша, чтобы её никто не реализовал. А по факту начиная с P-кода (который кстати имеет отношение к этим вашим Паскалям и Виртам), заканчивая JVM (да и CLR .NET) - это одна сплошная попытка виртуализации. Если что-то можно использовать в готовом виде для ARM Cortex-M0+ и специфичной STM32 периферии - это отличная новость. Нам останется собрать железо и хотелка воплощена в жизнь :-)

Пробежался внимательнее по ссылке. Они запилили это дело под специфичное железо. Но ведь почти 1:1 идея модульной автоматизации. Только они не стали делать калькуляторообразный пульт управления и наколеночного программирования. Не выглядит достаточно открыто, чтобы на этом базировать кружки робототехники, домашнюю автоматизацию и прочие типичные для таких вещей применения. Думаю, если делать на STM32 и вообще с прицелом на ARM как один из вариантов платформы, то будет гораздо легче распространять в разных видах. Но учитывая виртуальность машины, потом можно будет взять какой нибудь MIPS или даже мобильный X86 и перекинуть всё на него. Надо постараться оградить разработчиков от фактического железа, чтобы им хватало Форта в качестве машинного языка. А если, что плохо компилируется и рожает не эффективный код на целевом процессоре, то подкручивать и добавлять конструкции в Форт, а не решать прямыми ассемблерными вставками.

Недавно попалась одна такая задача. На Форте не решаемо в принципе. Надо максимально быстро считать из порта N значений подряд. Добились этого ассемблерной вставкой, которая переключает режим работы порта на вход и быстро читает (5 чтений 5 инструкций по 2 такта на каждую). Возможно для таких случаев надо реализовать инлайновую конструкцию типа DOANDFASTREADN, которая принимает аргументы и генерирует прямо максимально сжатый код. Причём Сишечка со встренным ассемблером сильно обгадилась, при фактическом наличии более 7 регистров, она позволила использовать только 5 и то со скрипом, в этом гамноассемблере почему то нельзя было читать из памяти. Кому захочется хакерский тул с такими ограничениями ?

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

Вот в IAR ассемблер в какой то мере высокоуровневый, например он оперирует виртуальными регистрами и подставляет всякие вещи из аргументов. А нельзя ли практически для произвольной архитектуры создать такой полуассемблер, чтобы можно было написать что тебе надо, а оно родило максимально быстродействующий код на этой архитектуре ? Как пример - язык Си уже фактически является таким ассемблером, но там не хватает каких то аннотаций, которые бы сообщали компилятору о твоих намерениях. Например он не знает, что тебе важно прочитать максимально быстро N раз, а потом уже неспешно разгребать, в итоге он экономит регистры, делает на каждое чтение из порта по две ARM инструкции, первая загружает адрес в регистр, вторая читает и т.д.

Человеческая реализация выглядит так:
ЗАПИСАТЬ ПеременнаяРЕЖИМ, [РегистрУказывающийНаРегистрРежимаПорта]
ПРОЧИТАТЬ Регистр1, [РегистрУказывающийГдеРегистрЗначенийПорта]
ПРОЧИТАТЬ Регистр2, [РегистрУказывающийГдеРегистрЗначенийПорта]
ПРОЧИТАТЬ Регистр3, [РегистрУказывающийГдеРегистрЗначенийПорта]
ПРОЧИТАТЬ Регистр4, [РегистрУказывающийГдеРегистрЗначенийПорта]
ПРОЧИТАТЬ Регистр5, [Ре5истрУказывающийГдеРегистрЗначенийПорта]
ЗАПИСАТЬОПТОМ РегистрУказывающийНаМассив, [Регистры1-5]

В какой нибудь X86 не будет столько регистров, но возможно будет какая нибудь
инструкция для быстрого чтения оптом.

Я подозреваю, что в кодогенераторах компиляторов уже есть что то такое, но на ум приходит методика GOAP (Goal Oriented Action Planning), которая использует методы планировщиков, которые развиваются уже 40 лет. Идея такова, что мы описываем операторы - например как наборы инструкций машины (и установка их аргументов), и их эффекты, что было до и что станет после. А цель планировщика - найти такую последовательность операторов, которая бы имела минимальную стоимость по времени выполнения или по размеру. Я не понимаю, почему при наличии всех этих методик компиляторы всё равно рожают не оптимальный код !!!

Я ему говорил "экономь регистры" ? Нет! Я говорю "Оптимизация FULL, без ограничений на размер!" А эта скотина всё равно генерирует код, где две инструкции на чтение!

А всё от того, что в Си нет конструкций объясняющих, например, что чтение должно быть максимально быстрым, отдельно от сохранения его результатов, с точки зрения оптимизатора считывать медленно, но сразу в память вполне нормальный результат.

Теперь понял, после вашего с Сергеем постов

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

c Питоном на борту.
Какой из Фортов можно на него собрать?

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Можно использовать что то из готовых жирных систем. JVM или другие многоязыковые среды, да и это не обязательно, там уже есть Линукс.

Форт чисто из спортивного интереса. Карманная машинка с железной клавиатурой

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Дискуссионный опрос на Github - Кто какие Форт использует.
https://github.com/ForthHub/discussion/issues/2

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

I know Forth is the best language so far. I'm pleased at its success, especially in the ultra-conservative arena of Artificial Intelligence. I'm disturbed that people who should, don't appreciate how it embodies their own description of the ideal programming language.

Но даже Чаку Муру не всех удаётся убедить в достоинствах Форта — хотя многих удалось, конечно, включая меня (англ.):

Nonetheless, I failed to persuade Charlottesville that Forth was suitable. I wasn't going to be allowed to program the VLA. Of any group, 25% like Forth and 25% hate it. Arguments can get violent and compromise is rare. So the friendlies joined forces and formed Forth, Inc. And that's another story.

В любой группе 25% нравится Форт, а 25% его ненавидят. Аргументы могут приводить к насилию, а компромиссы редки. Поэтому стратегия — объединять тех, кто любит Форт, считает его привлекательным. И делать вместе прекрасные вещи, которые нужны как минимум этим 25%.

Мне, например, очень не хватало Форта на МК-61. И когда появилась «Электроника МК-161», я себя часто ловил на мысли, насколько проще и удобней было бы очередную нужную задачу запрограммировать на Форте, а не языке МК. Я явно из тех 25%, что считают Форт одним из лучших языков на свете. :-)

Несомненно, если выбирать между Фортом и ассемблером МК161 или между Фортом и RPN HP42s, выберу Форт :)

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Хоть в чём-то сошлись. :-) Хотя я, конечно, формулировал бы в других словах. И у меня даже есть цитата Трохименко, подтверждающая разницу между ассемблерами (какой есть, например, у МК51) и входным компактным языком МК.

Ну, почти ассемблер ;)

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Если кратко, ассемблер это язык второго поколения. Успешная попытка выразить машинный язык (заданный железкой) в человеческих словах вроде ADD и PUSH.

Компактный ЯВУ это язык третьего поколения. Он задаётся не оборудованием, а требованиями задачи (производить расчёты) — и уже под особенности мышления человека, под удобство непрофессионального владельца ПМК разрабатывается оборудование.

Компактный ЯВУ, в отличии от алгоритмических, отражает особенности карманных устройств. Для советского времени это крохотный цифровой индикатор и скромная клавиатура. В отличии от ассемблера он оперирует абстракциями высокого уровня (максимально близкими к человеческим, научным), среди прочего:

  • Десятичные числа. Десятичные мантисса и экспонента, фиксированная запятая и плавучка при выходе за диапазон, проверки переполнения и неверных аргументов. Работа с такими числами на ассемблере требует отдельных подпрограмм, особенно при отсутствии FPU или сопроцессора. Здесь же сложение этих сущностей происходят в одно нажатие кнопки или один шаг.
  • Математические функции. Если в ассемблере FPU они реализованы ближе к железу и программисту на ассемблере требуется, например, приводить аргумент синуса к нужному диапазону, здесь одно нажатие клавиши реализует математическую абстракцию, нужную прикладнику. Опять же, в программе синус вычисляется в один шаг.
  • Ввод-вывод. На ассемблере и даже Си программирование ввода-вывода это отдельная история. Здесь же просто С/П и всё отображается автоматически в стандартном формате, тщательно разработанным для владельцев ПМК.

Инструмент - всего лишь инструмент. Например можно ли ненавидеть пассатижи, если тебе для работы нужны кусачки ? :-) Можно испытывать к инструментам некую неприязнь по причине плохого качества, например классический С++ - это тот ещё набор костылей. Но фактически профессионал просто берёт и пользуется то что предложит начальник чем можно сделать работу или не пользуется, а испытывать чувства - это IMHO удел самых маленьких :-)

P.S.
Всё равно Паскаль - гамно :-)

Говорят, что выше уровня приложений (верхний уровень модели OSI) есть экономический, политический и религиозный. :-)

Часто вопрос выбора языка программирования это не просто технический вопрос. Во времена Sun были гранты и другие поощрения за использование Java. Майкрософт активно всех подсаживает на C# и винду — даже с сообществом Оберона попытались в России такое проделать, задокументировано. Есть фанаты Линукса и даже отдельных его дистрибутивов.

Понятно, что в идеале винты закручиваются отвёрткой, а гвозди забиваются молотком. Но в риал-лайф инструмент может быть задан другими соображениями. Тем более, что у всех языков есть расширения для более-менее удовлетворительного решения типовых задач. И когда появляется знающий человек с весомыми аргументами, например, про выразительность и удобство языка Форт, это вызывает раздражение у тех, чей ответ уже заранее опубликован в конце задачника.

Однобокая политика какая-то. Например, использование сред Борланда, Турбо-Паскаля, прежде всего, в еще советских и позже российских вузах у тебя почему-то не проходит по графе "корпорации подсаживают". А не принадлежащие никаким корпорациям Си/Си++, PHP, Руби, Яваскрипт и многие другие вообще не упоминаются. Так легче убеждать себя, что проблемы Форта в корпорациях :)

Си/C++ это очень крупная корпорация AT&T — американский монополист, РосТелеком и МГТС в одном лице. С ней даже американцы многие борются, и появление T-Mobile в США один из результатов этой борьбы. К сожалению или счастью, у мелких конкурентов AT&T недостаточно средств для создания раздутых уродств вроде C++ с последующим агрессивным внедрением.

Паскаль и Оберон это уникальная языковая ветвь, связанная с наукой. Эти языки разработаны не в недрах корпораций, а в университетах и развиваются, как научные проекты — с публикациями, диссертациями, учебниками, семестрами и экзаменами. Есть разница между computer science и R&D, которая выражается в разной ангажированности и фундаментальности разработок. Очень хорошо, что советские ВУЗы пошли по пути Паскаля и Оберона, хотя сейчас наука и образование в РФ беднеют, а зарубежные корпорации наступают.

Про Яваскрипт и поддержку можно почитать в Википедии, никто этого не скрывает. А вот Форт — действительно исключение. Язык, созданный обычным профессиональным программистом «для себя» и обладающий такой притягательностью, что существует и развивается вдали от больших денег и образовательных гигантов. На энтузиазме вроде моего, силами независимых одиночек-профессионалов и горстки отдельных мелких компаний, среди которых самая крупная Forth Inc.

В начале своего развития, правда, Форт получил поддержку от МАК. Астрономы довольно консервативны и независимы, а дальнейшее развитие аппаратных форт-процессоров некоторое время поддерживалось НАСА. Но в целом Форт существует благодаря своей внутренней красоте и эффективности, а не колоссальному финансовому вливанию, как Джава или C++.

Слово-то какое, "монополист" :) Во-первых, AT&T не монополист. Монополистом были IBM, и это для них плохо кончилось в связи с наличием в США антимонопольного законодательства. Во-вторых, компиляторов Си и Си++ от разных производителей, включая открытые реализации GNU или Open Watcom - воз и маленькая тележка, буквально десятки, не считая тех, что идут в комплекте с микропроцессорами. В-третьих, существует отраслевой стандарт на язык. В-четвертых, Страуструп именно что был обычным профессиональным программистом и создавал язык «для себя» и коллег по работе. Отсюда многие косяки и нестыковки в ранних концептах - проектирование велось снизу вверх. Но в итоге у него неплохо получилось: 35 лет прошло, а на караван все еще лают :)

Страуструп работал в AT&T и создавал язык для своей (и не только своей) профессиональной деятельности в AT&T, за зарплату в AT&T. И да, это обычное для буржуазного мира. Когда корпорация проталкивает свой язык, она приглашает другие корпорации для создания отраслевого стандарта.

Так со всеми нововведениями, от упомянутого выше Javascript до крайне закрытого Blu-ray. Поддерживать независимые реализации или бороться с ними, облагая поборами, это уже зависит от стратегии. У AT&T относительно либеральное отношение к внедрению C++. Можно писать свои независимые компиляторы C++ без «маски-шоу» — которые устраивали независимым программистам, например, держатели отраслевого стандарта DVD.

Уникальность Форта в том, что Чак Мур работал на себя — переходя с одной работы на другую, но сохраняя за собой исходники Форта, совершенствуя их по мере обретения личного профессионального опыта. И когда формировались стандарты Форта от МАК до ANSI, это не было проталкиванием доминирования на деньги какой-либо корпорации. Финансовые показатели Forth, Inc. и AT&T несопоставимы, различаясь на много порядков.

Сейчас группа по разработке нового стандарта Форта открыта. Будь у меня небольшой бюджет на это, хотя бы $3k в год, и я бы летал на встречи и участвовал в стандартизации Форта, проводя интересы Каллисто. :-) В моей реализации есть интересные идеи, которые уже получили своих сторонников.

Конечно, на бешеные деньги AT&T эта языковая помойка C++ проживёт ещё 50 лет, если корпорация не решит внезапно перейти на другой язык.

Язык, контролируемый корпорацией - это, например, Ява. По этой причине Сан "поссорился" и долго судился с Микрософтом, который в итоге плюнул на попытку оптимизации Явы под Windows и сделал свою платформу .NET. Причем сделал так, что появился независимый стандарт платформы и языка C#, успешно реализованных любителями опенсурса под названием Mono, входящего в состав ключевых компонентов Линукса.

AT&T не контролирует ни стандарт Си++, ни коды многочисленных компиляторов языка.

Сергей, я с вами здесь бесплатный ликбез провожу. Вы же вместо «спасибо» хамите.

Ваше мнение «не принадлежащие никаким корпорациям Си/Си++» услышано. Вам сообщили, что Си и C++ это разработка AT&T, а именно лаборатории Bell. Вы же вместо извинений пытаетесь читать нотации — дескать в AT&T тоже гомо сапиенс работают, а не роботы, и у них есть имена/фамилии. Когда правда вам противоречит это неприятно, но от этого она не перестаёт быть правдой.

  1. Си и C++ это разработка корпорации.
  2. Паскаль и Оберон это научная разработка.
  3. Форт это авторская разработка Чака Мура и (начиная примерно с 1994 года, когда Чак отказался от лидерства и ушёл в разные colorForth) консенсус отдельных коллективов.

Когда этот минимум усвоите и научитесь уважать учителей, продолжим разговор. Можете даже не посылать мне, за мою неблагодарную профессиональную работу с вами, пожертвования на PayPal arvi1973 AT gmail.com, просто сдерживайте иногда свои хамские побуждения.

Также можем разобрать ваше высказывание насчёт «комбинации интерпретатора и компилятора» — опять же, бесплатно. Много интересного и полезного узнаете про интерпретацию и компиляцию (которые во всех Фортах присутствуют), шитый (как в Каллисто и в её советских предшественниках) и подпрограммный (как в SP-Forth) код. Но усвоить этику общения с учителями вам придётся, если хотите избавиться от ватного варварства и хотя бы немного подняться над уровнем стада (агрессивной «паствы» РПЦ). Что, увы, в «путинские» десятилетия «духовного возрождения» действительно сложно для русского человека.

Вернемся к сути. Утверждение о неконтролируемости ANSI стандарта Си/Си++ и его многочисленных компиляторов корпорацией AT&T осталось в силе. Если есть что сказать - не стесняйся.

P.S. Хотел еще спросить, разрешает ли учитель считать SQL свободной технологией? А то ведь тоже научная разработка корпорации IBM. Или Smalltalk. С какой даты их можно амнистировать?

и его историческую судьбу. :)

Этот разговор мне интересен в контексте входного языка ПМК. Не особенно хочется привязывать отечественный калькулятор, например, к американской фирме Интел, которая поураганила в ISO/IEC 9899 — тем более дважды глупо сдавать им позиции России при нуле финансирования с их стороны.

Конечно, приходится учитывать объективный фактор, знакомство русских программистов с зарубежными языками. Чьи мозги уже скупила та или иная корпорация, забив своими C++, здесь уже ничего не поделаешь.

С другой стороны, Оберон является коммерчески нейтральным научным вариантом. Язык Форт также не сильно завязан на корпорации, а его отечественные реализации обеспечивают некоторую пользовательскую базу. Тем более, что его здесь не забросили после болезненной оккупации СССР — сейчас копаюсь в недрах SP-Forth, и он мне начинает нравиться. :-) Глазу приятны даже комментарии на русском языке, после чтения многих мегабайтов англоязычных стандартов.

Каллисто-2 будет разрабатываться не просто на СП-Форте, но с учётом этой реализации Форта. Уже перенёс много исходного кода слов на вики, буду сравнивать и изучать. Хотя основной прогиб планируется под архитектуру ПМК — ещё сильнее, чем в Каллисто Классик, чтобы вывести быстродействие на максимум и сделать среду интерактивней.

ещё одна из уникальных операционок сделанная ядром рускоязычных разработчиков :)

Я знаю.

И даже задумываюсь, делать кросс-компилятор Каллисто-2 под ДОС или Колибри. Плюс ДОСа в том, что я его хорошо знаю. Огромный опыт, много документации под рукой, реализации везде — и под Линухом, и под виндой, и на маке, и даже на мобильниках есть ДОС.

Под Колибри мне нужно будет покупать отдельный компьютер, или собирать из уже имеющейся комплектухи. И не знаю, насколько там есть минимальный «плоский» формат исполняемого файла, наподобие COM-файла.

насколько мне известно и без подводных камней.
"Инфраструктура" под Колибри достаточно разнообразна (в том числе и инструментальная). Сама Колибри запускается практически на любом железе (да и в эмуляторе типа QEmu) Под XP есть и отдельный эмулятор Колибри реализованный на Fasm.
SP-Forth в Колибри не совсем синхронизован с последними иходниками SP-Forth и на данный момент сам себя не собирает в Колибри ОС. Хотя это можно сделать. В сжатом формате исполняемого файла (kPack) его размер
примерно 24Кб. (макрооптимизатор включён)

P.S. С документацией в Колибри всё достаточно хорошо, на форуме отвечают на все вопросы. :)
Под Колибри работает и DosBox. Одно время под DOS экспериментировал с SPF 2.0 и SPF 2.5.
Для Дос есть разные Форт системы (DX-Forth до сих пор, например, автор обновляет).
Моей Форт системой под Дос был Astro-Forth. :)
Колибри ОС может составить базис Форт ОС для x86 компьтеров. Вариант такого форка (со встроенным SP-Forth) уже был.
Здесь https://sites.google.com/site/forthoperatingsystem/ делается вариант частной разработки Форт Оси.

Плоский файл это хорошо. Ещё интересно, как в Колибри с кодировкой.

В конечном итоге это будет самокомпилирующаяся среда с кодовой страницей (256 символов) от МК-161 и каким-то способом вводить все эти ↑ ↔ ↵ ≥ ÷ × с клавиатуры ПК. Но как важный промежуточный этап это SP Forth, компилирующий исходник, написанный в UTF-8. Под виндой такое проходит «на ура».

Самокомпиляция SP Forth не требуется. Задача SPF — просто скомпилировать первую версию Каллисто, которой уже постепенно скармливать собственный исходник.

Подробностями не интересовался.
Сейчас SPF для Колибри получается из Fasm файла, получаемого при сборке Колибри исходников SPF из под Linux или Windows с помощью SPF4. Также можно поступить и со сборкой Калисто из исходников как в самой Колибри так и кросс вариантом.

А на STM32 это дело можно нахлобучить ?

т.к. не только процессор другой, так и железо периферии не повторить в общем случае, но чем то и x86 асм код проекта может быть полезен, как реализованный какой то функционал, если вопрос в этом.
Проще повторить что то подобное TACHYON https://github.com/rosco-pc/propeller-wiki/wiki/Programming-in-Forth
с какими то базовыми примитивами на ассемблере STM32, например, одном из варианте на базе кода Merisp-Stellaris или реализацией базиса Форт системы на C компилятора.

P.S. У меня в задумках продолжить освоение STM32 на базе VFX Forth c базой его кода и поделится уже некоторым текущим и будущим опытом. И закрыть в коде те возможности, которых нет в доступной Lite версии. :)

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

Вот это было бы идеальным. Надёжный старый ноутбук, который можно купить за бесценок или даже забрать даром.

Сама «контролируемость ANSI стандарта» это странное понятие.

Стандарт это уже застывший, зафиксированный факт. Во время разработки ANSI Си на него оказал большое влияние язык Си, разработанный AT&T. Когда стандарт уже опубликован, корпорация может перестать заботиться о чужих реализациях — если они удовлетворяют стандарту, они удовлетворяют тому, насколько индустрия смогла на данный язык повлиять. Вот, например, корпорации, повлиявшие на последний стандарт Си (ссылка) и немножко натянувшие одеяло на себя:

  • Cisco Systems Inc
  • GrammaTech Inc
  • Gwyn
  • Hewlett Packard Enterprise
  • IAR Systems AB
  • IBM Corporation
  • Intel Corporation
  • Keaton Consulting
  • LDRA Technology Inc
  • Lawrence Berkeley National Laboratory
  • Lawrence Livermore National Laboratory
  • Oracle
  • Perennial
  • Plum Hall Inc
  • Red Hat Inc
  • Seymour
  • Software Engineering Institute/CERT, a division of Carnegie Mellon University
  • Sony Computer Entertainment
  • Synopsys Inc
  • The Planet Earth Society Inc
  • Tydeman Consulting

«Амнистии» здесь не при чём. Это же не судебная система. Просто языки, разработанные индустрией, отличаются от языков, разработанных учёными или профессионалами-одиночками.

У корпораций множество собственных экономических интересов. От банальной защиты инвестиций, совместимости «снизу вверх» и повторного использования накопленного ими кода до промывки мозгов (обеспечения лояльности) программистов и затруднения перехода под влияние других корпораций. Например, если ты кодируешь на Objective C или Swift, для перехода под C# придётся переучиваться.

Научно-разработанные языки не могут, конечно, обеспечить прибавку к зарплате просто за факт их использования и нахождение в сфере влияния Apple или Microsoft. Зато они меньше засоряют мозги, последовательно используют мощные научно-обоснованные концепции и лаконичны, предназначены для формулировки научных достижений, объединения прогрессивных людей разных стран и убеждений.

Фиксируем, корпорация AT&T не контролирует ни стандарты языка Си++, меняющиеся постоянно при активном участии профессионального сообщества, ни его многочисленные реализации. То есть сказанное тобой несколько постов выше - ложь.

В списке "топ 20" контрибьюторов Линукса - 19 крупных корпораций. Это так, к слову.

На смену "монополизму корпораций" ты стал употреблять малопонятный термин "научно-разработанный язык". Поскольку вопрос про SQL был проигнорирован, то эта научно-исследовательская разработка IBM, видимо, тобой не относится к научным. Или все же относится?

И последние 2 вопроса, исключительно для понимания (да/нет):
- является ли массовое использование продуктов корпорации Борланд, Турбо паскаля прежде всего, в советских и позже российских вузах "насаждением корпоративных технологий"?
- является ли корпоративной технологией язык советских ПМК, разработанных концерном "Кристалл"?

Повторюсь, стандарты «контролируются» на этапе их создания, а не после их публикации — когда стандарт опубликован, он уже сам становится инструментом контроля. Не ложь выискивай, как свинья грязь, а правде учись. :-)

Взаимодействие между университетами и корпорациями идёт всегда. Оно неизбежно, даже в приведённом списке разработчиков стандарта есть университеты.

Борьба идёт за то, чтобы наука, университеты, играли ведущую роль в разработке языков. Например, в приведённом тобой примере с Борланд язык был создан профессором Виртом, а корпорация имела средства, чтобы довести Паскаль до широкой публики. Конечно, в процессе доведения напильником некоторые влияния коммерческих интересов были неизбежны. Юниты и Object Pascal это уже попытка толстосумов порвать с научной разработкой (Модула-2, Оберон) и начать лидировать.

В случае же разработки стандарта Си за основу бралась разработка AT&T, а университет Карнеги играл ведомую роль — скатившись до «научно-исследовательских разработок», а точнее R&D в пользу корпораций. Университет не мог, например, через стандарт заставить индустрию отказаться от общепринятого заблуждения, использования математического знака равенства для операции присваивания. Когда же шло взаимодействие с публикой через Борланд, профессору Вирту это удалось.

Важная идея школы профессора Вирта — университеты должны лидировать, а индустрия учиться у них и реализовывать научные достижения университетов.

P.S. Текст про монополизм AT&T в трёх абзацах я составил. Его публикация обойдётся вам в 500 рублей, счёт PayPal опубликовал выше. Троллей, кто «подсел» на добычу знаний от учителей под угрозой оскорблений, надо наказывать рублём.

Как и ожидалось, уход от темы. Более вопросов не имею. Конспирологию о контроле над постоянно развивающимся стандартом в рамках ANSI не комментирую.

Оплату за продвижение продуктов фирм Oberon Microsystems, XDS и прочих логичнее просить непосредственно у производителей. Напоминаю, что на нашем сайте размещение/удаление рекламы производится на усмотрение его редакции.

Участие корпораций в стандартизации Си это не секрет — я опубликовал список выше. Языки Си и C++ созданы в AT&T, их стандарты задаёт индустрия $$$

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

И тут уже дело хозяйское, заниматься наукой или плестись в хвосте у крупного бизнеса. Хотите поддерживать только тех производителей, кто занимается антинаучной деятельностью? Ктож вам запретит… сторонников гелиоцентризма вообще на площадях сжигали. Однако со временем победило не мракобесие, а наука.

В top 10 языков программирования Си идет вторым после Питона.
В топ-10 языков по уровню зарплаты Си-Плюсы и Си идут на 4 и 6 местах.

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

и субъективных суждениях.
https://youtu.be/kYgPEFlHtRI Компьютер программируемый на Форт в моде RedPower2
игры MineCraft

P.S. Для Phyton, тем временем, вышла переводная книга
и доступна в электронном виде. Крэйг Ричардсон "Программируем с Minecraft. Создай свой мир с помощью Python" (2017)
Вот так и будем ориентироваться на западных авторов не задумываясь о методологической основе данной литературы?

Профессионала никто не спрашивает об экономике, политике и религии! Это не его уровня вопросы. Удел профессионала в области программировании - уметь программировать, используя широкий набор инструментов. Если профессионал подневольный, то он ещё и лишается права выбирать инструменты произвольно. Наверное он должен испытывать недовольство, что его ограничивают "менее удобными" инструментами, но ведь ныть по поводу крутости и удобства инструментов - это удел студентов, а не профессионалов.

Собственно, в этом и была проблема на определённом жизненном этапе Чака Мура — когда в Виргинии его начальником оказался ненавистник, которого не устраивало, что Чак Мур успешно решал поставленные задачи с помощью Форта.

В «Монти Пайтоне» была шутка по этому поводу, когда дали задачу срубить дерево. А потом уточнили — с помощью селёдки.

Это в корне неверная позиция, для инженера и программиста недопустимо пренебрежение как продолжающимся всю жизнь обучением так и основам экономической грамотности. Об этом, например, писал Лу Гринзоу в "Философия программирования" еще в 1990-х.

Для "вертикального" full-stack программиста выбор средств является одним из ключевых факторов успеха проекта. Программисты, специализирующиеся на каком-либо уровне, разумеется, ограничены в выборе инструментов, адекватными этому уровню. Наконец, программисты-техники, занимающиеся массовым кодированием, еще более ограничены в выборе технологиями, успешный опыт использования которых имеется в данной фирме.

Должны быть ещё и предпринимателями, чтобы привлекать деньги на своё вольное программирование.
Лично я считаю, что программист (разработчик ПО) должен уметь программировать на чём угодно (потенциально), то есть при необходимости освоить наиболее правильный инструмент и на нём решить задачу, либо построить инструмент под задачу (что ещё лучше). Но это идеализм :-)

Совершенно необязательно быть предпринимателем. Большинство французских (и европейских) фулл-стек программистов - консультанты, работающие на площадках заказчика. Часть из них имеет статус ИП, но для заказчика это не имеет значения, ему нужно выполнить работы. Ограничения инструментария нередко могут быть выдвинуты и со стороны заказчика. Например, СУБД.

Это индивидуальные предприниматели торгующие собственными услугами :)

Консультант - наемный работник, ему ищет заказчика, оплачивает "социал" и отпуск фирма. ИП всем этим занимается сам.

Если с консультантом трудовой договор, то по ТК ему конечно положен социал и отпуск. А если это договор на оказание услуг с физ.лицом, нет трудового договора, то никакого социала и отпуска не будет.

Консультант - наемный работник консалтинговой фирмы (размер 100-10000 сотрудников), которого она отправляет на площадки своих заказчиков. Это наиболее распространенный случай, потому что крупные клиенты полагаются на крупных подрядчиков даже по совокупности мелких проектов. "Домашние" разработки экстернализированы уже давно, никаких своих программистов в отделах ИТ в фирмах нет. Второй вариант, многократно более редкий, консультант является ИП. Это обычная практика в Европе.

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

Выбор инструментария не зависит от статуса консультанта, но зависит от ИТ-среды заказчика. Никакой "свободный предприниматель" не сможет убедить заказчика сменить Oracle на PostgreSQL, потому что он ему больше нравится, но у заказчика уже имеется соответствующая инфраструктура.

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

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

На каком поле играть. Если он решает проблемы с помощью PostgreSQL и на нём себя позиционирует, то найдутся и в этой нише заказчики, которых не надо убеждать сменить Oracle. Главное чтобы решалась за удобные деньги некая потребность заказчика. В жизни есть выбор, выбираешь проктологию и твоя жизнь будет протекать в задницах :-)

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

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

GForth в Android-e
https://net2o.de/Gforth.apk (есть и в GooglPlay с положительными отзывами)
https://wiki.forth-ev.de/doku.php/en:projects:gforth-android:start Начальный старт.

P.S. s" minos2/gl-example.fs" included Выводит разноцветный треугольник и позволяет его повращать.
В консоли можно посмотреть и "начинку" слов (see слово) и в формате ассемблерного содержания, если слово- примитив (Arm ассемблер, но как это работает на х86 андроиде интересно).
На Github или SourceForge, например, тоже много чего можно найти по слову Forth :)
Мозги, конечно, у большинства программистов (не знакомых со словом Forth) на понимание методологии использования Форт не "переформатируешь", поэтому должны быть какие то примеры для тех кого ещё не зацепила круговерть "продакшен".
При желании и весь аппарат ООП-ности можно применить в Форт, но проще (из существующих или сделанных для себя). В Win32Forth, например, используется определённая ООП модель кода в программах.

Вы описали всё предельно точно.

Так и есть в МК-161. Виртуальная машина ЯМК, поверх которой можно делать свои языки.

Кстати, новосибирская «виртуальная машина» достаточно быстрая. Некоторые тормоза Каллисто из-за последовательного классического подхода. Чтобы был «тот самый Форт», который мы изучали в 90-ые. Например, переменная BASE в классическом Форте 16-битная. Хотя основания системы счисления больше 16 используются редко, а больше 36 не положены по стандарту.

В результате BASE можно в лёгкую хранить в одном байтовом регистре. И не дёргать каждый раз второй байт, при вводе-выводе чисел. Таких мест для оптимизации выявлено много, они значительно ускорят Каллисто-2. Хотя результат будет дальше от того Форта, про который можно прочитать в книжках и к которому все привыкли.

Виртуальная машина ЯМК, поверх которой можно делать свои языки.

Можно, но работать они будут ОЧЕНЬ медленно и у вас не хватит памяти для реализации чего то нормального.

Основные непреодолимые недостатки:

1) ЯМК слишком и необратимо высокоуровневый (следовательно тормозной), чтобы в него компилировать код произвольных языков. Тот же Форт может оперировать указателями и т.п. низкоуровневыми вещами, и ничем не отличаться от ассемблера, если потребуется.
2) ЯМК не содержит средств самомодификации и генерации программ на ЯМК, следовательно все метаязыковые вещи обречены на интерпретацию, забивание памяти и тормоза. Не уверен, что программе на ЯМК позволено писать на диск программу на ЯМК (в память точно нельзя).
Про оптимизирующие компиляторы на борту можно забыть.

3) Если писать свою прошивку. Безнадёжное железо МК-161 с замороженным контроллером 8052, не способным писать даже в собственную флэш память (не говоря уж об оперативной памяти программ, которой вообще нет и не будет) = САМАЯ УБОГАЯ ПЛАТФОРМА для Форт ПМК, которую только можно придумать.

Это упражнение для ума, средство показать хакерскую доблесть, но не путь к ПМК мечты :-)

1. Согласен про высокий уровень. С одной стороны, просто реализовывать математику, она будет работать надёжно и шустро. С другой стороны, низкий уровнь даже в Форте будет эмулироваться поверх этой плавучки.

2. Вот именно тут я стою на развилке. Самокомпиляция Каллисто невозможна на МК-161, поэтому придётся делать исполняемую версию под компьютер (Колибри или ДОС). Там можно перевести примитивы на ассемблер (чем я и займусь), но также можно оставить уровень ЯМК (присобачив, например, мой эмулятор ВК-6).

Вот в этом случае код ЯМК будет создавать другой код ЯМК. Хотя дело будет проходить не на МК-161, конечно. Просто для МК-161, как целевой платформы.

3. Здесь как раз проблем нет. Конечного пользователя не интересует, сколько труда и доблести вложил программист — работает тот же МК-161, и хорошо. В том же Форте и Бейсике легко отделяется память только для чтения и память для данных.

В-общем, меня не затруднит весь исполняемый код держать во флэше, а шитый код пользователя вне камня. Так Каллисто и работает — исполняемый код ЯМК в памяти программ (только для чтения), а разрабатываемые программы в памяти данных.

новой платформы. Я сейчас конкретно погряз в STM32L0 (на работе), видимо это просто так не кончится. Очень скоро я полезу прилаживать код BCD библиотеки с WP34, если оно покатит, то учитывая более другую степень свободы на новых архитектурах (моделях контроллеров) реализовать аналог МК-161 будет не так уж сложно. По поводу Форта мне думается для сохранения возможности писать расширения и приложения на Си надо смотреть в сторону околосишных реализаций Форта или фортоподобных языков. Вообще хотелось бы оптимизирующий кодогенератор, а не интерпретатор Форта. Для самых маленьких он может быть внешним. Для жирных контроллеров, где много ОЗУ и прочих ресурсов можно и на борт. Пускай оно будет внешне выглядеть как Форт, а реализация будет двойная. Что то вроде Си с ассемблерными вставками ?????

Я всё таки подумываю, что в будущем это могут быть не только STM32 (и вообще ARM), но и MIPS и какие то более другие архитектуры на основе ПЛИС, поэтому сильно на конкретную машину нельзя затачивать, надо предусмотреть пути реализации для разных платформ. Тот же встроенный ассемблер GCC (и IAR) живёт на разных архитектурах и умеет автоматом подставлять всякие вещи в регистры целевой архитектуры.

Но в ближайшее время, все игры будут на STM32 :-) Мой 3D принтер дышит прелестно (запускал его на выходных) в рамках выбранного температурного профиля вроде больше не забивается, прототипы корпусов и клавиатур буду пилить :-) Главное чтобы было какое то сообщество, где можно этим всем поделиться (а может и похвастаться в хорошем смысле этого слова).

Так тут и надо делиться наработками и хвастаться. Я из числа сильно сочувствующих, жду фоток 3Д-печатанного корпуса с нетерпением :)

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

СолидВоркс превращается в тыкву. Проектирование клавиатуры (делал несколько попыток) вырождается в какое то выпиливание табуретки перочинным ножичком. Вроде немного поднял уровень знания Солида, но всё равно идёт нелегко. В целом тренировки не проходят зря, получается всё лучше, надо продолжать до победного :-)

А OnShape сервис не пробовали? Бесплатен, если модели выкладывать в публичный доступ

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Таков и есть план. Каллисто-2 — важный шаг к самокомпиляции и мультиплатформе. Решения, которые ускорят транслятор на МК-161, дадут ещё большую выгоду на следующих платформах.

Следующим этапом будет (1) обращение в Новосибирск для реализации адресного интерпретатора, как команд входного языка МК. Или (2) самостоятельный порт под W77LE516P, если кто-нибудь напишет на ней Hello, world!

Также возможна (3) смена аппаратной платформы, если к тому времени появятся другие отечественные разработки. Пока я отношусь скептически, что у нашего сообщества что-нибудь получится. Здесь есть замечательные железячники и программисты, но опытных бизнесменов не вижу. Хотя кто знает, поживём-увидим.

Оптимизирующий кодогенератор в машинный код не так интересен. У нас же не обработка видео в реальном времени. Проблемы с быстродействием не носят объективный характер, они вызваны лишь закрытостью прошивки МК-161. Насколько я знаю, никакие ПМК (ни отечественные, ни зарубежные) не занимались из коробки оптимизирующей компиляцией в машинный код «на борту».

Ещё одна важная вещь. Сам по себе Форт это моноязычная операционная система, с нуля (уровня драйверов) и до верху (диалог с оператором, прикладные программы). Исторически этот подход «всё на одном языке» даже предшествовал Си — возможно вдохновил Bell Labs на создание Юникса, где внезапно тоже начали писать операционки на ЯВУ. Наши тормоза как раз от того, что мы пока не можем сделать Каллисто моноязыком и совмещаем его с ЯМК.

Конечно, поверх Форта писались и Бейсик, и другие языки. Но для этого в первую очередь нужна надёжная и быстрая форт-машина, которую надо обеспечить. И особой необходимости в этих языках нет, разве что кому-то они субъективно нравятся больше. Такие вещи существуют, как FreePascal или Перл в Гну-Линуксе — который практически полностью на Си написан.

Здесь есть замечательные железячники и программисты, но опытных бизнесменов не вижу.

Так и у СЕМИКО нет бизнесменов, иначе бы они не публиковали фото своего товара с задрипанной линейкой и замученным коробком спичек, с обилием тирад в стиле "потребитель со своими хотелками иди в ж..., что хотим то и выпускаем". Проект МК был явно убыточный.

Насколько я знаю, никакие ПМК (ни отечественные, ни зарубежные) не занимались из коробки оптимизирующей компиляцией в машинный код «на борту».

Ну степень оптимизации и сложность такого компилятора может варьироваться в широких пределах. Самое простое - короткие слова Форта инлайнятся в виде кода без манипуляций со стеком вообще.
Высший пилотаж - полная оптимизация с учётом стоимости инструкций и разной компоновки процедур. Думаю простые варианты можно накопать и в прошивке HP 50g.

Я не специалист в создании компиляторов, но я имею опыт написания оптимизирующих планировщиков, что в плане оптимизации используют те же алгоритмы.

Конечно, поверх Форта писались и Бейсик, и другие языки. Но для этого в первую очередь нужна надёжная и быстрая форт-машина, которую надо обеспечить. И особой необходимости в этих языках нет, разве что кому-то они субъективно нравятся больше. Такие вещи существуют, как FreePascal или Перл в Гну-Линуксе — который практически полностью на Си написан.

С моей точки зрения не обязательно всё сваливать на уровень Форта, Форт можно использовать как связующую и вспомогательную среду (в прошивке ZX Spectrum для этого был "калькулятор").
Часть допустим выполняется как инструкции Форта, а часть прямо компилируется в машинный код. Особенно беда - с тяжёлыми циклами и всякими частыми обращениями, если их делать на Форте - будут сильные тормоза.

Необходимость высокоуровневых языков очевидна. Они не "нравятся больше", они объективно лучше подходят под любые калькуляторные и даже контроллерные задачи, чем галимый Форт или ЯМК.
Любое значительное облагораживание Форта неизбежно выльется в новый язык, что совершенно оправдано, особенно если сохранятся сильные стороны Форта. Например для Erlang машины родился Elixir, который гораздо лучше Erlang, родного языка этой машины, и может то же самое + намного больше.

Предпринимательский талант Новосибирска лучше нашего, т.к. они наладили выпуск ЭКВМ, а мы наладили только обсуждение чужих калькуляторов. :-)

Буквальный перенос подхода с настольных компьютеров на ПМК успеха не принесёт. Тут, скорее, пригодится опыт карманных мобильников. Разработка приложений на ПК с последующей их передачей в ПМК, в двоичном виде (айфон) или в исходниках (андроид).

При разработке «на борту» машинный код не нужен, и даже алгоритмические языки не оптимальны — нужны компактные языки.

Облагораживание Форта в его компактную версию Каллисто шло по двум направлениям. Первое это использование устоявшихся коротких мнемоник ПМК, вроде ↑ и ↔ вместо DUP и SWAP. Второе это использование десятичных чисел для стека данных и основных математических операций. Это обеспечило запуск советских программ (написанных как для МК-61, так и Форта) с минимальными изменениями.

Кто почему-то считает, что другой язык подходит лучше — пишите трансляторы. Никто не мешает, например, сделать на МК-161 эмулятор HP 15 или ещё какого-нибудь зарубежного входного языка. Моё мнение, что лучше Форта может быть только компактная версия Оберона. Но как эту компактную версию разработать, пока остаётся загадкой. :-)

Одна из проблем здесь как раз та, что поднята вами. Вам хочется компилятор в машинный код, да ещё и с оптимизацией. Это и есть путь Оберона и внезапно SP Форта. Мне же хотелось бы оставить интерпретацию и диалоговый режим, когда 2+2= или 2 2 + дают 4. Отсюда я рассматриваю компромиссы, вроде виртуальной машины и Оберона поверх шитого кода Форта — что довольно близко к тому, о чём вы настойчиво пишете. Но пазл пока не складывается.

стократно более сложных и качественных электронных устройств, чем жалкий МК-161. Не переоценивайте достижения СЕМИКО. На уровне всей индустрии их изделия это поделки на уровне студенческих проектов. Вся проблема лишь в том, что штуки в формате ПМК на рынке не востребованы. А наше "предпринимательство" не стоит так ругать, мы никому ничего не обещали и нам никто ничего не обещает за создание каких либо программ или устройств.
Скажем так, за бюджет, который потратило СЕМИКО на разработку этого гробика другая российская фирма могла бы создать нормальный ПМК, аппаратно не ниже уровня DM42.
В общем не в предпринимательстве дело вовсе, а в целеполагании и позиционировании устройства. А для того чтобы понять как его позиционировать, надо создать какой то прототип и примерить разные применения, а не как СЕМИКО - создать необъятный гроб и раскручивать его так что пуп развязался, а все так и не поняли, зачем он нужен: недо-портативный, недо-ПМК, недо-контроллер, недо-ЭВМ, недо-игровое устройство ???? По сути он ни одну функцию он нормально выполнять не может, всё сделано на тройку.

Если у нас что то получится, то оно хотя бы сможет быть микроконтроллером и скорее всего будет портативным :-)

Хорошо, что вы живёте в таком оптимистичном окружении. :-)

В этой невостребованности и проблема. Здесь надо либо быть гением маркетинга, изучая и формируя рынки. Либо иметь возможность спонсировать свои разработки. Делают же разные Медведевы себе дворцы на юге России, виноградники в Тоскане — калькулятор выпустить дешевле.

Моя оценка ЭКВМ отличается. Само устройство крепкое и надёжное, хорошо документированное и работает безглючно. Такое индустриальное качество, пусть избыточное для бытовой вещи, меня радует и оплачивать его готов. Не нравятся мыльницы, ломающиеся через пару лет — а МК-152 уже 10 лет отслужил. Согласен, что МК-161 не идеально вписывается в наши ожидания. Но техзадание никто из нас не читал. Чтобы начать производить такие вещи в той России, которая увы есть, надо обладать некоторым талантом — и соглашусь, что он заключается не в технической подготовке.

Ещё раз, я не сомневаюсь, что силами сайта можно разработать идеальный ПМК и даже выпустить 1-2 прототипа. Это само по себе подвиг, но собравшиеся здесь люди на такое способны и свои проекты до работающего состояния доводили. Скептически я отношусь к следующему этапу — тому «налаживанию производства», которое вы вынесли в заголовок. Когда в любой момент какой-нибудь левый придурок в форме может зайти и помешать, просто из собственной непроходимой тупости и жадности.

При налаживании серийного производства придётся иметь дело и с бюрократией, и с деньгами. Если же вы хотите сделать производство ПМК не убыточным, это ещё более сложная задача, чем исполненная Новосибирском.

может конечно зайти, на моей памяти хаживали и пожарные и милиция (не шучу), ФСБ присматривает, чтобы всё было ОК, а производство всё равно работает, так что не так оно страшно как его малюют. Да и какое уж тут производство. Ну придёт придурок в форме и что ? Программатор 3-копеечный утащит или файлы из облака ? Само производство (платы, монтаж) обычно размещается под заказ где нибудь в крупной электрической конторе. Если это мелкая серия, то и прийти то некуда будет, я может у себя в подвале как физ лицо для своего удовольствия клепаю калькуляторы (у меня там место под небольшое сборочное производство нашлось бы). Тут такая тема, что ты со своей мелочёвкой, никому не нужен, особенно ленивым придуркам в форме. А если жирком обрастать начнёшь, надо конечно налаживать связи, думать как поделиться с нужными людьми, чтобы добро своё сохранить. Глядя вокруг я вижу, что 99% предпринимателей это удаётся (не без труда конечно).

Вот эти умения и навыки отличны от программирования и разработки железа. То есть в команде должен быть предприниматель со знанием русских реалий, чтобы разработанный ПМК перешёл со стадии «работающий макет» до «товар на полках магазинов» — и начал если не приносить доход, то хотя бы самоокупаться.

Правда тут электронная специфика, но её можно до некоторой степени поручить внешним фирмам.