Этого треда уже нет.
Это копия, сохраненная 14 сентября 2015 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
30 Кб, 524x493
131 Кб, 984x554
Какой язык и в чём же вообще будущее? #522265 В конец треда | Веб
После просмотра очередной бессмысленной темы о языке %TEMPLATE%, я в очередной раз убедился, что уважаемые аноны занимаются переливанием из пустого в порожнее. Их разговор сводится к спору двух инвалидов, без чего же лучше жить - без руки или ноги.

Сам я зарабатываю себе на бутерброды в embedded области. Да, там в 2015 году, когда человечество бороздит просторы космоса, ещё большей частью идёт разработка на Си в обвязку с осцилографом. Начинает потихоньку появляться компиляторы для c++ под экзотические платформы. Как правило, стандарт для c++ поддерживается давно протухший. Если честно - смена Си на плюсы для embedded - это смена говна на мочу.

Качественный прыжок вперёд даёт моделирование. Например, мы используем тулзу от IBM - Rhapsody. Тулза неплохая (когда не виснет и не глючит), генерит доволно компактный Си код из UML - стейтчарты, диаграммы классов/объектов и та дэ. Делает дополнительную верификацию модели на консистентность. Врабатываться в неё - ад, плюс стоит невероятно невъебенных денег. Но и в этой тулзе есть предел. Она хоть и вводит дополнительный уровень абстракции, поддерживая части языка UML, но проблема в том, что этот уровень слабо связан с уровнем абстракции Си. Нет плавного перехода. Просто гиганский прыжок. Из стейтчартов можешь вызвать Си функцию. Из Си функции - послать сообщение в стейтчарт, что приведёт к смене состояния. И всё. UML сильно абстрактный язык и не заточен под конкретные проблемы.

Вот тут смышлённый анон уже смекнул в какую сторону я клоню. Проблема должна определять инструмент. Для своей проблемы - свой язык. Синтаксис и грамматикая языка может определяться разными способами - всякие картинки-стрелочки для описания стейтчартов или структур, как в UML, таблицы, математическая формулы и модели, графики. Всё, что человечество использовало доселе для решения определённых проблем. Ну, чтобы каждый раз не изобретать заново велосипед. Если для решения моей конкретной проблемы мне нужно описать структуру ПИД-регулятора - то у меня должана быть возможность сделать это так, как сегодня принято в Matlab/Simulink.

Тут я сделаю маленькое отступление. Предметно-специфичные языки или как их на новоязе - Domain Specific Language разделяются на две категории. Внешние и встраиваемые. Внешние - это если проект на Си, а кто-то прикрутил генератор кода из описания структуры коммуникационного протокола в XML, используя питон с соответствующей библиотекой. Или особо хардкорные напишут парсер грамматики и свой компилятор на yacc/lex. Про них мы речь сейчас вести не будем.
#2 #522268
>>522265
В будущем будут писать на коммутативных диаграммах, готовьте ваши очеллы.
#3 #522294
>>522265
Речь пойдёт о языках встраивемых.

Вот мы клепаем код на Си и потом нам приходит в голову, что в Си вроде бы как не хвататет лямбда-исчиления, чтобы решить определённую проблему икс. Щелчок пальцами, подгружаем модульчик - и обращаемся к лямда исчислению прям из Си кода. Нет языка для описания нашей архитектуры? Мы создаём язык для описания архитектуры и описывем её. Стейтчарт с формальной верификацией на уровне генерации/компиляции, с поддержкой синтакса редактором? А почему нет, если это помогает решать класс проблем (а в embedded там только тем и занимаешься) - да и да. Должна быть возможность легко и непренуждённо создавать новые языки со своей грамматикой, синтаксисом и семантикой.

Чем более язык заточен под задачу, тем более узкий круг проблем он позволяет решать с минимальным количеством кода/ошибок. Классическая проблема DSL - любой язык имеет тенденцию со временем разрастись и превратиться в Си.

Нужен модульный подход, чтобы брать концепты одного языка, дополнять их использовать в дизайне языков нового, более абстрактного уровня. Комбинировать их и создавать конкретный инструмент под конкретную задачу с минимальным количеством геморроя.
1 Кб, 469x223
#4 #522357
>>522294

>Нужен модульный подход, чтобы брать концепты одного языка, дополнять их использовать в дизайне языков нового, более абстрактного уровня. Комбинировать их и создавать конкретный инструмент под конкретную задачу с минимальным количеством геморроя.


Поздравляю, сэр, вы только изобрели новый диалект Лиспа.
Назовите его вашим благородным именем, сэр.
5 Кб, 455x383
40 Кб, 276x450
#5 #522369
>>522294

Теперь ещё маленькое отступление. Как работает компилятор языка? Очень упрощённо - запускается парсер кода, который строит синтаксическое дерево. Синтаткическое дерево разбирается с помощью AST и трансформируется в баткод за энное кол-во проходов правилами редукции.

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

Чтобы создать новый язык более высокого уровня, нам нужно будет
1) определить структуру абстракного синтаксического дерева
2) определить правила редукции для преобразования конкретного синтаксического дерево с помощью 1) в дерево языка более низкого уровня
3) создать 1 ... n проекций пункта 2) для удобоваримого усваивания человеком

Чтобы не изобретать велосипед, иметь возможность пользоваться в языках более выского уровня концептами более низкого уровня и подргружать их как модуль. Например, если наш язык должен уметь сложение-вычитание, можно заюзать Си expression для этого.
#6 #522371
>>522357

Туперь научи на лиспе программировать бородатых дядек для embedded и получи медальку.
#7 #522384
Это РЕФЕРАТ что ли или где? В чем смысл треда?
#8 #522392
ОП говорит что его узкоспециализированное дрочево можно решать диаграммками. И думает что это будущее погромирования.
17 Кб, 541x362
#9 #522398
>>522369

Почему нужно создавать языки с произвольной грамматикой/синтаксисом? Чтобы более эффективно решать определённые специфичные задачи.

Анон, конечно, возразит, что для этого можно создать библиотеку/фреймворк на базе существующего языка %TEMPLATE%. Дорогой анон. Все проблемы в программировании решаются Си с помощью библиотеки. Я из байтоёбов, туда обратно не хочу. Библиотека не проверяет синтакс по мере ввода кода. Библиотека не занимается верификацией абстрактной модели на уровне компиляции, а если занимается - то это в библиотеке получается сделать ОЧЕ через жопу.

Угорел по концепту и по инструментарию, который представляет некая тулза.

Тулза представляет собой платформу для относительно простого создания языков любого уровня, IDE, projectional editor -> не знаю, как это на русский перевести. Редактор, который позволяет править синтаксное дерево посредством проецирования его в произвольный синтакс. Редактор не позволяет задавать невалидные ветви дерева.

Тулза опенсурсная, но без говнеца в жизни не бывает.
Из минусов:
- воняет Явой (со всеми последствиями)
- заставляет пользоваться всторенной IDE/редактором (vim низзя, пичалька)
- Редактор оче специфичный, к нему нужно минимум день, чтобы привыкнуть
- это всё ещё немного сыровато

Из плюсов:
- завелась на моих прыщах с пол-оборота
- просто бесконечный потенциал

http://mbeddr.com <- тулза, базируется в свою очередь опенсорсной тулзой MPS (meta programming systems) от JetBrains (те, кто клепают IntelliJ IDEA)
Смотрите на трубе скринкасты, которые ищутся по тегу mbeddr
#10 #522399
>>522392

Узкоспециализированное дрочево решает узкий специалист, а не байтоёб.

Кстати, про картинки - спешу разочаровать. Тулза проецирует, как правило в текст. В картинки только начинает.
#11 #522403
>>522398
Открыл Америку, поздравляю.
Таки интересно, насколько хорошо можно формально верифицировать этой тулзой проект тырпрайз размеров
#12 #522404
Нахуярили какую-то обертку над MPS и пиарят на дваче. Ну охуеть теперь.
#13 #522438
>>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, но это лишь вопрос времени.
#14 #522468
Вот тут уже поднимался вопрос:
>>494718
#15 #522548
>>522468

О да, спасибо. Нынешяя тема - частный случай этого вопроса. Лично меня интересует разработка для embedded.
#16 #522940
>>522294

>любой язык имеет тенденцию со временем разрастись и превратиться в Си.


Десятое правило Гринспена.
#17 #523022
>>522403

Как это может работать очень интересно посмотреть на примере:

https://vimeo.com/78422792

Если ты проект тырпрайз размера с умом поделишь на модули (используя язык описания-взаимодействия модулей), то будешь заниматься верификацией отдельных модулей.

Это тебя не избавит от всех ошибок в проекте, но позволит свести их к минимуму на этапе компиляции. Чем более абстрактный язык, тем больше ты можешь верифицировать уже на уровне модели (а не заставишь сидеть сутками байтоёба с дебаггером).

Остальное выявляется втроенным языком автоматизированных юнит-тестов.
#18 #523204
>>522398

>Почему нужно создавать языки с произвольной грамматикой/синтаксисом? Чтобы более эффективно решать определённые специфичные задачи.


У нас есть например английский язык, есть русский. На них мы можем изложить практически любую научную работу.
Нет, давайте изобретем жопохуйский язык, вдруг на нем будет эффективнее.
#19 #523254
>>523204

Школьник, что ты делаешь /pr/? Иди учи английский за три дня без смс в лингвач.
#20 #523868
Когда котупрограммисту нечего делать - он яйца лижетизобретает новый язык программирования.

>embedded embedded embedded


А что, embedded какое-то особенное программирование? Ах там мало памяти и процессор надо экономить! Пидон с жабой не засунешь, вот беда-то.
#21 #523884
Мне одному показалось, что ОП-хуй пытается изобрести лисп?
#22 #524706
>>523204
У нас уже есть рычание и сопение. На них мы можем телеграфировать что хотим спариваться или жрать.
Нет, давайте изобретем жопохуйский язык, вдруг на нем будет эффективнее.
#23 #524836
>>524706
На С/С++ можно написать Linux и Windows XP, игоры, офисы, драйверы, САПР, даже небо, даже Аллаха.
Но у некоторых выходит лишь кряхтение и пердение.
#24 #524840
>>522265 (OP)
Оп, ты в ересь впал. То что ты описал называется Model Driven Development. Такое еще иногда используется у джавистов. Инструмент полезный, но слишком негибкий.

Вот к примеру https://trimm.tigerteam.dk/trimm-jpa/
#25 #524850
>>524836

>На С/С++


Как отличить профи от юнца? Профи никогда не поставит с и с++ рядом, больно они разные.>
#26 #524863
>>524850

>больно они разные


на астигматизм проверься
#27 #525214
>>524863
А вот и разработчики лаб подъехали.
#28 #526874
>>523868

>чому embedded



Я, в отличие от петяна из десятого бэ не пытаюсь выдать свои частные проблемы за вселенские. В чём разбираюсь/с чем связан, о том и пишу. Если кто-то видит, что это применимо и для его области разработки - веллком в эту тему.

В embedded своя специфика - ОЧЕ ограниченные ресурсы, иногда управление всякими физическими штуками, которые могут что-то или кого-то захуярить. Для этой специфики нужен соответствующий инструмент, позволяющий разрабатывать быстро, надёжно и получать компактные решения. Нужно клепать стейтчарты для аппликативной логики, нужно клепать коммуникационные протоколлы (с помощью стейтчартов). Нужно использовать ТАУ модели для управления всякой хренью - рилтайм во все поля, дискретную математику для обработки сигнала и т.п.
#29 #526882
>>524840

Ты на правильном пути, анон. Model Driven Development - это то, чем я уже сегодня занимаюсь. Мой инструментарий позволяет использовать СТАТИЧЕСКИЙ набор языков (некое подмножество UML) для описания модели с какими-то правилами проверки её на консистентность в процессе компиляции, которые слишком абстрактны и недостаточны для МОИХ моделей, дописать свои просто так я не могу - шаг вправо или влево - расстрел или попадалово на бабло.

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

В этой конкретной теме речь идёт о ещё об одном качественном прыжке вперёд - иметь возможность создавать инструментарий для описания моделей любого уровня абстракции. С блекджеком и шлюхами. Да ещё и опенсорс инструмент, у которого потенциала в десятки раз больше того, чем я пользуюсь сегодня и за что моя контора платила невъебическое бабло.
5 Кб, 482x262
#30 #526886
>>523884

Оп-хуй спрашивает себя, сможешь ли ты на лиспе использовать синтаксис как на пикче, чтобы эффективно решать проблемы, которые нужно часто решать опу.
Sage #31 #527128
>>524863
C и C++ родственные, но всё таки разные языки.
#32 #527137
>>526886
Да, автоматы с состояниями пишутьса на лиспе.
#33 #527173
>>522294

> в Си не хватает лямбда исчисления


А в Хаскеле не хватает машины Тьюринга?
#34 #527175
>>526886
На лиспе можно использовать любоё синтаксис, кек
#35 #527231
>>527175
И как там использовать синтаксис без скобок?
#36 #527330
Будущее за .batниками.
5 Кб, 130x165
#37 #527341
>>527330
За кем же еще, если не за нами?
#38 #527898
>>527137

Анон, не притворяйся глухим, именно синтаксис как на пикче. Кватратики, стрелочки, и та дэ.
#39 #527933
>>526874

>Нужно клепать стейтчарты для аппликативной логики, нужно клепать коммуникационные протоколлы (с помощью стейтчартов). Нужно использовать ТАУ модели для управления всякой хренью - рилтайм во все поля


А потому что это говно на ПЛИСах проще решается и HDLом прекрасно описывается. Какой ты язык не изобретай, микропроцессоры сосут в реалтайме, единственное их преимущество это гибкость.
#40 #528612
>>527933

рилтайм не главный критерий, а один из

ПЛИС стоит много денег и жрёт энергию как свинья помои

разработка под него - жопа, обмазывался VHDL, в курсе
Тред утонул или удален.
Это копия, сохраненная 14 сентября 2015 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /pr/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски