Этого треда уже нет.
Это копия, сохраненная 14 сентября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 14 сентября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
30 Кб, 524x493
131 Кб, 984x554
После просмотра очередной бессмысленной темы о языке %TEMPLATE%, я в очередной раз убедился, что уважаемые аноны занимаются переливанием из пустого в порожнее. Их разговор сводится к спору двух инвалидов, без чего же лучше жить - без руки или ноги.
Сам я зарабатываю себе на бутерброды в embedded области. Да, там в 2015 году, когда человечество бороздит просторы космоса, ещё большей частью идёт разработка на Си в обвязку с осцилографом. Начинает потихоньку появляться компиляторы для c++ под экзотические платформы. Как правило, стандарт для c++ поддерживается давно протухший. Если честно - смена Си на плюсы для embedded - это смена говна на мочу.
Качественный прыжок вперёд даёт моделирование. Например, мы используем тулзу от IBM - Rhapsody. Тулза неплохая (когда не виснет и не глючит), генерит доволно компактный Си код из UML - стейтчарты, диаграммы классов/объектов и та дэ. Делает дополнительную верификацию модели на консистентность. Врабатываться в неё - ад, плюс стоит невероятно невъебенных денег. Но и в этой тулзе есть предел. Она хоть и вводит дополнительный уровень абстракции, поддерживая части языка UML, но проблема в том, что этот уровень слабо связан с уровнем абстракции Си. Нет плавного перехода. Просто гиганский прыжок. Из стейтчартов можешь вызвать Си функцию. Из Си функции - послать сообщение в стейтчарт, что приведёт к смене состояния. И всё. UML сильно абстрактный язык и не заточен под конкретные проблемы.
Вот тут смышлённый анон уже смекнул в какую сторону я клоню. Проблема должна определять инструмент. Для своей проблемы - свой язык. Синтаксис и грамматикая языка может определяться разными способами - всякие картинки-стрелочки для описания стейтчартов или структур, как в UML, таблицы, математическая формулы и модели, графики. Всё, что человечество использовало доселе для решения определённых проблем. Ну, чтобы каждый раз не изобретать заново велосипед. Если для решения моей конкретной проблемы мне нужно описать структуру ПИД-регулятора - то у меня должана быть возможность сделать это так, как сегодня принято в Matlab/Simulink.
Тут я сделаю маленькое отступление. Предметно-специфичные языки или как их на новоязе - Domain Specific Language разделяются на две категории. Внешние и встраиваемые. Внешние - это если проект на Си, а кто-то прикрутил генератор кода из описания структуры коммуникационного протокола в XML, используя питон с соответствующей библиотекой. Или особо хардкорные напишут парсер грамматики и свой компилятор на yacc/lex. Про них мы речь сейчас вести не будем.
Сам я зарабатываю себе на бутерброды в embedded области. Да, там в 2015 году, когда человечество бороздит просторы космоса, ещё большей частью идёт разработка на Си в обвязку с осцилографом. Начинает потихоньку появляться компиляторы для c++ под экзотические платформы. Как правило, стандарт для c++ поддерживается давно протухший. Если честно - смена Си на плюсы для embedded - это смена говна на мочу.
Качественный прыжок вперёд даёт моделирование. Например, мы используем тулзу от IBM - Rhapsody. Тулза неплохая (когда не виснет и не глючит), генерит доволно компактный Си код из UML - стейтчарты, диаграммы классов/объектов и та дэ. Делает дополнительную верификацию модели на консистентность. Врабатываться в неё - ад, плюс стоит невероятно невъебенных денег. Но и в этой тулзе есть предел. Она хоть и вводит дополнительный уровень абстракции, поддерживая части языка UML, но проблема в том, что этот уровень слабо связан с уровнем абстракции Си. Нет плавного перехода. Просто гиганский прыжок. Из стейтчартов можешь вызвать Си функцию. Из Си функции - послать сообщение в стейтчарт, что приведёт к смене состояния. И всё. UML сильно абстрактный язык и не заточен под конкретные проблемы.
Вот тут смышлённый анон уже смекнул в какую сторону я клоню. Проблема должна определять инструмент. Для своей проблемы - свой язык. Синтаксис и грамматикая языка может определяться разными способами - всякие картинки-стрелочки для описания стейтчартов или структур, как в UML, таблицы, математическая формулы и модели, графики. Всё, что человечество использовало доселе для решения определённых проблем. Ну, чтобы каждый раз не изобретать заново велосипед. Если для решения моей конкретной проблемы мне нужно описать структуру ПИД-регулятора - то у меня должана быть возможность сделать это так, как сегодня принято в Matlab/Simulink.
Тут я сделаю маленькое отступление. Предметно-специфичные языки или как их на новоязе - Domain Specific Language разделяются на две категории. Внешние и встраиваемые. Внешние - это если проект на Си, а кто-то прикрутил генератор кода из описания структуры коммуникационного протокола в XML, используя питон с соответствующей библиотекой. Или особо хардкорные напишут парсер грамматики и свой компилятор на yacc/lex. Про них мы речь сейчас вести не будем.
>>522265
В будущем будут писать на коммутативных диаграммах, готовьте ваши очеллы.
В будущем будут писать на коммутативных диаграммах, готовьте ваши очеллы.
>>522265
Речь пойдёт о языках встраивемых.
Вот мы клепаем код на Си и потом нам приходит в голову, что в Си вроде бы как не хвататет лямбда-исчиления, чтобы решить определённую проблему икс. Щелчок пальцами, подгружаем модульчик - и обращаемся к лямда исчислению прям из Си кода. Нет языка для описания нашей архитектуры? Мы создаём язык для описания архитектуры и описывем её. Стейтчарт с формальной верификацией на уровне генерации/компиляции, с поддержкой синтакса редактором? А почему нет, если это помогает решать класс проблем (а в embedded там только тем и занимаешься) - да и да. Должна быть возможность легко и непренуждённо создавать новые языки со своей грамматикой, синтаксисом и семантикой.
Чем более язык заточен под задачу, тем более узкий круг проблем он позволяет решать с минимальным количеством кода/ошибок. Классическая проблема DSL - любой язык имеет тенденцию со временем разрастись и превратиться в Си.
Нужен модульный подход, чтобы брать концепты одного языка, дополнять их использовать в дизайне языков нового, более абстрактного уровня. Комбинировать их и создавать конкретный инструмент под конкретную задачу с минимальным количеством геморроя.
Речь пойдёт о языках встраивемых.
Вот мы клепаем код на Си и потом нам приходит в голову, что в Си вроде бы как не хвататет лямбда-исчиления, чтобы решить определённую проблему икс. Щелчок пальцами, подгружаем модульчик - и обращаемся к лямда исчислению прям из Си кода. Нет языка для описания нашей архитектуры? Мы создаём язык для описания архитектуры и описывем её. Стейтчарт с формальной верификацией на уровне генерации/компиляции, с поддержкой синтакса редактором? А почему нет, если это помогает решать класс проблем (а в embedded там только тем и занимаешься) - да и да. Должна быть возможность легко и непренуждённо создавать новые языки со своей грамматикой, синтаксисом и семантикой.
Чем более язык заточен под задачу, тем более узкий круг проблем он позволяет решать с минимальным количеством кода/ошибок. Классическая проблема DSL - любой язык имеет тенденцию со временем разрастись и превратиться в Си.
Нужен модульный подход, чтобы брать концепты одного языка, дополнять их использовать в дизайне языков нового, более абстрактного уровня. Комбинировать их и создавать конкретный инструмент под конкретную задачу с минимальным количеством геморроя.
1 Кб, 469x223
>>522294
Поздравляю, сэр, вы только изобрели новый диалект Лиспа.
Назовите его вашим благородным именем, сэр.
>Нужен модульный подход, чтобы брать концепты одного языка, дополнять их использовать в дизайне языков нового, более абстрактного уровня. Комбинировать их и создавать конкретный инструмент под конкретную задачу с минимальным количеством геморроя.
Поздравляю, сэр, вы только изобрели новый диалект Лиспа.
Назовите его вашим благородным именем, сэр.
5 Кб, 455x383
40 Кб, 276x450
>>522294
Теперь ещё маленькое отступление. Как работает компилятор языка? Очень упрощённо - запускается парсер кода, который строит синтаксическое дерево. Синтаткическое дерево разбирается с помощью AST и трансформируется в баткод за энное кол-во проходов правилами редукции.
Давайте представим себе, что мы опустим парсер. Программирование будет сводиться к созданию синтактического дерева. Это - наша модель. Из этого дерева мы можем создать проекцию, которое, к примеру, выглядит как си код (если мы пишем на си). Если наш язык - это описание стейтчартов с переходами при определённых событиях, то мы можем его проецировать в картинку со стрелочками, можем проецировать в таблицу или в текстовое представление стейтчарта. Дерево - первично, проекция - вторична.
Чтобы создать новый язык более высокого уровня, нам нужно будет
1) определить структуру абстракного синтаксического дерева
2) определить правила редукции для преобразования конкретного синтаксического дерево с помощью 1) в дерево языка более низкого уровня
3) создать 1 ... n проекций пункта 2) для удобоваримого усваивания человеком
Чтобы не изобретать велосипед, иметь возможность пользоваться в языках более выского уровня концептами более низкого уровня и подргружать их как модуль. Например, если наш язык должен уметь сложение-вычитание, можно заюзать Си expression для этого.
Теперь ещё маленькое отступление. Как работает компилятор языка? Очень упрощённо - запускается парсер кода, который строит синтаксическое дерево. Синтаткическое дерево разбирается с помощью AST и трансформируется в баткод за энное кол-во проходов правилами редукции.
Давайте представим себе, что мы опустим парсер. Программирование будет сводиться к созданию синтактического дерева. Это - наша модель. Из этого дерева мы можем создать проекцию, которое, к примеру, выглядит как си код (если мы пишем на си). Если наш язык - это описание стейтчартов с переходами при определённых событиях, то мы можем его проецировать в картинку со стрелочками, можем проецировать в таблицу или в текстовое представление стейтчарта. Дерево - первично, проекция - вторична.
Чтобы создать новый язык более высокого уровня, нам нужно будет
1) определить структуру абстракного синтаксического дерева
2) определить правила редукции для преобразования конкретного синтаксического дерево с помощью 1) в дерево языка более низкого уровня
3) создать 1 ... n проекций пункта 2) для удобоваримого усваивания человеком
Чтобы не изобретать велосипед, иметь возможность пользоваться в языках более выского уровня концептами более низкого уровня и подргружать их как модуль. Например, если наш язык должен уметь сложение-вычитание, можно заюзать Си expression для этого.
Это РЕФЕРАТ что ли или где? В чем смысл треда?
ОП говорит что его узкоспециализированное дрочево можно решать диаграммками. И думает что это будущее погромирования.
17 Кб, 541x362
>>522369
Почему нужно создавать языки с произвольной грамматикой/синтаксисом? Чтобы более эффективно решать определённые специфичные задачи.
Анон, конечно, возразит, что для этого можно создать библиотеку/фреймворк на базе существующего языка %TEMPLATE%. Дорогой анон. Все проблемы в программировании решаются Си с помощью библиотеки. Я из байтоёбов, туда обратно не хочу. Библиотека не проверяет синтакс по мере ввода кода. Библиотека не занимается верификацией абстрактной модели на уровне компиляции, а если занимается - то это в библиотеке получается сделать ОЧЕ через жопу.
Угорел по концепту и по инструментарию, который представляет некая тулза.
Тулза представляет собой платформу для относительно простого создания языков любого уровня, IDE, projectional editor -> не знаю, как это на русский перевести. Редактор, который позволяет править синтаксное дерево посредством проецирования его в произвольный синтакс. Редактор не позволяет задавать невалидные ветви дерева.
Тулза опенсурсная, но без говнеца в жизни не бывает.
Из минусов:
- воняет Явой (со всеми последствиями)
- заставляет пользоваться всторенной IDE/редактором (vim низзя, пичалька)
- Редактор оче специфичный, к нему нужно минимум день, чтобы привыкнуть
- это всё ещё немного сыровато
Из плюсов:
- завелась на моих прыщах с пол-оборота
- просто бесконечный потенциал
http://mbeddr.com <- тулза, базируется в свою очередь опенсорсной тулзой MPS (meta programming systems) от JetBrains (те, кто клепают IntelliJ IDEA)
Смотрите на трубе скринкасты, которые ищутся по тегу mbeddr
Почему нужно создавать языки с произвольной грамматикой/синтаксисом? Чтобы более эффективно решать определённые специфичные задачи.
Анон, конечно, возразит, что для этого можно создать библиотеку/фреймворк на базе существующего языка %TEMPLATE%. Дорогой анон. Все проблемы в программировании решаются Си с помощью библиотеки. Я из байтоёбов, туда обратно не хочу. Библиотека не проверяет синтакс по мере ввода кода. Библиотека не занимается верификацией абстрактной модели на уровне компиляции, а если занимается - то это в библиотеке получается сделать ОЧЕ через жопу.
Угорел по концепту и по инструментарию, который представляет некая тулза.
Тулза представляет собой платформу для относительно простого создания языков любого уровня, IDE, projectional editor -> не знаю, как это на русский перевести. Редактор, который позволяет править синтаксное дерево посредством проецирования его в произвольный синтакс. Редактор не позволяет задавать невалидные ветви дерева.
Тулза опенсурсная, но без говнеца в жизни не бывает.
Из минусов:
- воняет Явой (со всеми последствиями)
- заставляет пользоваться всторенной IDE/редактором (vim низзя, пичалька)
- Редактор оче специфичный, к нему нужно минимум день, чтобы привыкнуть
- это всё ещё немного сыровато
Из плюсов:
- завелась на моих прыщах с пол-оборота
- просто бесконечный потенциал
http://mbeddr.com <- тулза, базируется в свою очередь опенсорсной тулзой MPS (meta programming systems) от JetBrains (те, кто клепают IntelliJ IDEA)
Смотрите на трубе скринкасты, которые ищутся по тегу mbeddr
>>522392
Узкоспециализированное дрочево решает узкий специалист, а не байтоёб.
Кстати, про картинки - спешу разочаровать. Тулза проецирует, как правило в текст. В картинки только начинает.
Узкоспециализированное дрочево решает узкий специалист, а не байтоёб.
Кстати, про картинки - спешу разочаровать. Тулза проецирует, как правило в текст. В картинки только начинает.
>>522398
Открыл Америку, поздравляю.
Таки интересно, насколько хорошо можно формально верифицировать этой тулзой проект тырпрайз размеров
Открыл Америку, поздравляю.
Таки интересно, насколько хорошо можно формально верифицировать этой тулзой проект тырпрайз размеров
>>522403
В embedded, в safety-critical областях, примерно треть времени уходит на разработку фич, две трети - на тесты/верификацию. Это ОЧЕ долгий, нудный, болезненный и кропотливый процесс. Который не всегда приводит к желаемым результатам (http://arstechnica.com/information-technology/2015/06/airbus-confirms-software-configuration-error-caused-plane-crash/)
А так мопед не мой - просто разместил объяву:
http://mbeddr.com/files/dscv-ase2014.pdf
>>522404
Из всего, что существует на рынке для embedded разрабодки - это самое инновационное (хоть и оче сырое), что я до сих пор видел.
Я ощутил на своей шкуре вкус разных там интырпрайз штучек. Да, есть в них что-то, что помогает байтоёбу-обезьяне сделать в джва раза больше работы с половиной ошибок. Но интерпрайз имеет в себе ряд недостатков. Оно статическое, монолитное и просит много долларов за каждый лишний чих.
Хоть и та же Rhational Rhapsody по фичам на сегодняшний день уделает этот mbedder, но это лишь вопрос времени.
В embedded, в safety-critical областях, примерно треть времени уходит на разработку фич, две трети - на тесты/верификацию. Это ОЧЕ долгий, нудный, болезненный и кропотливый процесс. Который не всегда приводит к желаемым результатам (http://arstechnica.com/information-technology/2015/06/airbus-confirms-software-configuration-error-caused-plane-crash/)
А так мопед не мой - просто разместил объяву:
http://mbeddr.com/files/dscv-ase2014.pdf
>>522404
Из всего, что существует на рынке для embedded разрабодки - это самое инновационное (хоть и оче сырое), что я до сих пор видел.
Я ощутил на своей шкуре вкус разных там интырпрайз штучек. Да, есть в них что-то, что помогает байтоёбу-обезьяне сделать в джва раза больше работы с половиной ошибок. Но интерпрайз имеет в себе ряд недостатков. Оно статическое, монолитное и просит много долларов за каждый лишний чих.
Хоть и та же Rhational Rhapsody по фичам на сегодняшний день уделает этот mbedder, но это лишь вопрос времени.
>>522468
О да, спасибо. Нынешяя тема - частный случай этого вопроса. Лично меня интересует разработка для embedded.
О да, спасибо. Нынешяя тема - частный случай этого вопроса. Лично меня интересует разработка для embedded.
>>522294
Десятое правило Гринспена.
>любой язык имеет тенденцию со временем разрастись и превратиться в Си.
Десятое правило Гринспена.
>>522403
Как это может работать очень интересно посмотреть на примере:
https://vimeo.com/78422792
Если ты проект тырпрайз размера с умом поделишь на модули (используя язык описания-взаимодействия модулей), то будешь заниматься верификацией отдельных модулей.
Это тебя не избавит от всех ошибок в проекте, но позволит свести их к минимуму на этапе компиляции. Чем более абстрактный язык, тем больше ты можешь верифицировать уже на уровне модели (а не заставишь сидеть сутками байтоёба с дебаггером).
Остальное выявляется втроенным языком автоматизированных юнит-тестов.
Как это может работать очень интересно посмотреть на примере:
https://vimeo.com/78422792
Если ты проект тырпрайз размера с умом поделишь на модули (используя язык описания-взаимодействия модулей), то будешь заниматься верификацией отдельных модулей.
Это тебя не избавит от всех ошибок в проекте, но позволит свести их к минимуму на этапе компиляции. Чем более абстрактный язык, тем больше ты можешь верифицировать уже на уровне модели (а не заставишь сидеть сутками байтоёба с дебаггером).
Остальное выявляется втроенным языком автоматизированных юнит-тестов.
>>522398
У нас есть например английский язык, есть русский. На них мы можем изложить практически любую научную работу.
Нет, давайте изобретем жопохуйский язык, вдруг на нем будет эффективнее.
>Почему нужно создавать языки с произвольной грамматикой/синтаксисом? Чтобы более эффективно решать определённые специфичные задачи.
У нас есть например английский язык, есть русский. На них мы можем изложить практически любую научную работу.
Нет, давайте изобретем жопохуйский язык, вдруг на нем будет эффективнее.
Когда котупрограммисту нечего делать - он яйца лижетизобретает новый язык программирования.
А что, embedded какое-то особенное программирование? Ах там мало памяти и процессор надо экономить! Пидон с жабой не засунешь, вот беда-то.
>embedded embedded embedded
А что, embedded какое-то особенное программирование? Ах там мало памяти и процессор надо экономить! Пидон с жабой не засунешь, вот беда-то.
>>523204
У нас уже есть рычание и сопение. На них мы можем телеграфировать что хотим спариваться или жрать.
Нет, давайте изобретем жопохуйский язык, вдруг на нем будет эффективнее.
У нас уже есть рычание и сопение. На них мы можем телеграфировать что хотим спариваться или жрать.
Нет, давайте изобретем жопохуйский язык, вдруг на нем будет эффективнее.
>>524706
На С/С++ можно написать Linux и Windows XP, игоры, офисы, драйверы, САПР, даже небо, даже Аллаха.
Но у некоторых выходит лишь кряхтение и пердение.
На С/С++ можно написать Linux и Windows XP, игоры, офисы, драйверы, САПР, даже небо, даже Аллаха.
Но у некоторых выходит лишь кряхтение и пердение.
>>522265 (OP)
Оп, ты в ересь впал. То что ты описал называется Model Driven Development. Такое еще иногда используется у джавистов. Инструмент полезный, но слишком негибкий.
Вот к примеру https://trimm.tigerteam.dk/trimm-jpa/
Оп, ты в ересь впал. То что ты описал называется Model Driven Development. Такое еще иногда используется у джавистов. Инструмент полезный, но слишком негибкий.
Вот к примеру https://trimm.tigerteam.dk/trimm-jpa/
>>524836
Как отличить профи от юнца? Профи никогда не поставит с и с++ рядом, больно они разные.>
>На С/С++
Как отличить профи от юнца? Профи никогда не поставит с и с++ рядом, больно они разные.>
>>524863
А вот и разработчики лаб подъехали.
А вот и разработчики лаб подъехали.
>>523868
Я, в отличие от петяна из десятого бэ не пытаюсь выдать свои частные проблемы за вселенские. В чём разбираюсь/с чем связан, о том и пишу. Если кто-то видит, что это применимо и для его области разработки - веллком в эту тему.
В embedded своя специфика - ОЧЕ ограниченные ресурсы, иногда управление всякими физическими штуками, которые могут что-то или кого-то захуярить. Для этой специфики нужен соответствующий инструмент, позволяющий разрабатывать быстро, надёжно и получать компактные решения. Нужно клепать стейтчарты для аппликативной логики, нужно клепать коммуникационные протоколлы (с помощью стейтчартов). Нужно использовать ТАУ модели для управления всякой хренью - рилтайм во все поля, дискретную математику для обработки сигнала и т.п.
>чому embedded
Я, в отличие от петяна из десятого бэ не пытаюсь выдать свои частные проблемы за вселенские. В чём разбираюсь/с чем связан, о том и пишу. Если кто-то видит, что это применимо и для его области разработки - веллком в эту тему.
В embedded своя специфика - ОЧЕ ограниченные ресурсы, иногда управление всякими физическими штуками, которые могут что-то или кого-то захуярить. Для этой специфики нужен соответствующий инструмент, позволяющий разрабатывать быстро, надёжно и получать компактные решения. Нужно клепать стейтчарты для аппликативной логики, нужно клепать коммуникационные протоколлы (с помощью стейтчартов). Нужно использовать ТАУ модели для управления всякой хренью - рилтайм во все поля, дискретную математику для обработки сигнала и т.п.
>>524840
Ты на правильном пути, анон. Model Driven Development - это то, чем я уже сегодня занимаюсь. Мой инструментарий позволяет использовать СТАТИЧЕСКИЙ набор языков (некое подмножество UML) для описания модели с какими-то правилами проверки её на консистентность в процессе компиляции, которые слишком абстрактны и недостаточны для МОИХ моделей, дописать свои просто так я не могу - шаг вправо или влево - расстрел или попадалово на бабло.
Не смотря на это, если сравнивать байтоёбство на голом си с MDD - просто огромный качественный прыжок вперёд. Особенно окупается для больших проектов - позволяет их сдавать в меньший срок, с меньшим количеством ошибок.
В этой конкретной теме речь идёт о ещё об одном качественном прыжке вперёд - иметь возможность создавать инструментарий для описания моделей любого уровня абстракции. С блекджеком и шлюхами. Да ещё и опенсорс инструмент, у которого потенциала в десятки раз больше того, чем я пользуюсь сегодня и за что моя контора платила невъебическое бабло.
Ты на правильном пути, анон. Model Driven Development - это то, чем я уже сегодня занимаюсь. Мой инструментарий позволяет использовать СТАТИЧЕСКИЙ набор языков (некое подмножество UML) для описания модели с какими-то правилами проверки её на консистентность в процессе компиляции, которые слишком абстрактны и недостаточны для МОИХ моделей, дописать свои просто так я не могу - шаг вправо или влево - расстрел или попадалово на бабло.
Не смотря на это, если сравнивать байтоёбство на голом си с MDD - просто огромный качественный прыжок вперёд. Особенно окупается для больших проектов - позволяет их сдавать в меньший срок, с меньшим количеством ошибок.
В этой конкретной теме речь идёт о ещё об одном качественном прыжке вперёд - иметь возможность создавать инструментарий для описания моделей любого уровня абстракции. С блекджеком и шлюхами. Да ещё и опенсорс инструмент, у которого потенциала в десятки раз больше того, чем я пользуюсь сегодня и за что моя контора платила невъебическое бабло.
5 Кб, 482x262
>>523884
Оп-хуй спрашивает себя, сможешь ли ты на лиспе использовать синтаксис как на пикче, чтобы эффективно решать проблемы, которые нужно часто решать опу.
Оп-хуй спрашивает себя, сможешь ли ты на лиспе использовать синтаксис как на пикче, чтобы эффективно решать проблемы, которые нужно часто решать опу.
>>524863
C и C++ родственные, но всё таки разные языки.
C и C++ родственные, но всё таки разные языки.
>>527175
И как там использовать синтаксис без скобок?
И как там использовать синтаксис без скобок?
5 Кб, 130x165
>>527330
За кем же еще, если не за нами?
За кем же еще, если не за нами?
>>526874
А потому что это говно на ПЛИСах проще решается и HDLом прекрасно описывается. Какой ты язык не изобретай, микропроцессоры сосут в реалтайме, единственное их преимущество это гибкость.
>Нужно клепать стейтчарты для аппликативной логики, нужно клепать коммуникационные протоколлы (с помощью стейтчартов). Нужно использовать ТАУ модели для управления всякой хренью - рилтайм во все поля
А потому что это говно на ПЛИСах проще решается и HDLом прекрасно описывается. Какой ты язык не изобретай, микропроцессоры сосут в реалтайме, единственное их преимущество это гибкость.
>>527933
рилтайм не главный критерий, а один из
ПЛИС стоит много денег и жрёт энергию как свинья помои
разработка под него - жопа, обмазывался VHDL, в курсе
рилтайм не главный критерий, а один из
ПЛИС стоит много денег и жрёт энергию как свинья помои
разработка под него - жопа, обмазывался VHDL, в курсе
Тред утонул или удален.
Это копия, сохраненная 14 сентября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 14 сентября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.