Язык ДРАКОН, вариации на тему "No OS" Опции

[Гость_MrYuran_*]

И я тоже.
ПМСМ, Паронджанова надо занести в раздел Великих людей.
Заслужил...

30 числа дал отмашку на печать новой книги.
Так что скоро будет продолжение.

[Гость_MrYuran_*]

Сегодня решил прошвырнуться по kickstarter.com и нашел очень интересный проект.
К вопросу о финансировании стартапов...

http://www.modk.it/editor/preview/

Лего-программа для лего-ардуины.
В общем-то, по уровню исполнения проект стоит тех 11+ к$, которые народ насобирал.

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

[Гость_MrYuran_*]

Вот он, ЯЗЬ!
http://www.kickstarter.com/projects/791396...-ard?ref=search

Кстати говоря,
$8,195 PLEDGED OF $4,300 GOAL

[Гость_MrYuran_*]

http://forum.oberoncore.ru/viewtopic.php?f=78&t=3992

Крутой программЁр пытается открыть глаза олдфагам и недоучкам из разных космических НИИёв.
Распальцовка - шо у твоего Фредди
Жаль, тему рано закрыли...

[orthodox]

http://forum.oberoncore.ru/viewtopic.php?f=78&t=3992

Крутой программЁр пытается открыть глаза олдфагам и недоучкам из разных космических НИИёв.
Распальцовка - шо у твоего Фредди
Жаль, тему рано закрыли...

Олдфаги тоже хороши.
Кстати, вопросы он поднимал реальные.
Уж не знаю, как рассматривать ситуацию —
если как прорыв из жутко секретной темы
к народу малой толики информации, что полезна,
но в такой дозе, чтобы враг не смог пользоваться —
то тут есть патриотическая цель и я её уважаю:
народ должен гордиться и он будет гордиться,
хотя использовать не сможет.

А если призыв к реальному использованию —
то можно тоже обьявить сбор денег и идей,
(ясно же, что это не «инновация» и под это дело государство
не вложит и гроша, так как реальный результат гарантирован,
а инновация любит риск, то есть спаленные деньги, их, вероятно,
пилить проще. Впрочем, они и не скрывают..)
для чтобы организовать компилятор с Дракона, например,
для эмбеддеров. Я бы, кстати, не пожалев труда
возможно, возникшего бы на этой задаче сообщества,
предложил бы пользоваться ассемблерами для конкретных
камней, и компилировать, конечно, со всеми их особенностями —
чем накладывать ещё слой ЯВУ сверху, иначе бы и гроша не вложил
в эту тему — так как роль ЯВУ как раз сам Дракон и должен играть,
иначе смысл теряется. А если бы не флоукоде ожидался, а что посерьезнее —
то для святого дела полполучки не жалко...Потому что через ЯВУ наворачивать —
дерьмо по изначальной задумке, но пока только это и есть.

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

Практика — критерий истины.
Пока что все о Драконе — как призыв делать
изложенное выше, не более... Боюсь даже предположить,
что нету и призыва, а есть просто «хорошо бы»

[Гость_MrYuran_*]

Практика — критерий истины.
Пока что все о Драконе — как призыв делать
изложенное выше, не более... Боюсь даже предположить,
что нету и призыва, а есть просто «хорошо бы»

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

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

Кстати, недавно разгребал свою почту, брошенную на произвол судьбы на пару месяцев.
Нашел там несколько писем от разработчиков Code Rocket по поводу моих ощущений от триала.
Черкануть чтоли фидбек, заодно укажу на drakon editor Степана Миткина. Тем более что страничка прилично смотрится и адаптирована под буржуев.

DRAKON's motto: took a glance — understood at once.

[orthodox]

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

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

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

Это одно преимущество. Далее, второе — когда уже нарисовано и все соответствует
правилам Дракона — весьма наглядна становится вся структура, и происходит
естественным образом её оптимизация, ещё ни строчки программы не написавши.
Тоже неплохо.

Ну, про понятность и так на каждом углу, контроль ошибок и все такое...
Запишем это как третье. А программирование, которое становится чисто
формальным занятием, доступным самому необученному академику —
следствие первых двух преимуществ. Но основные всё же они потому,
что влияют на сам алгоритм, а не только из за формализации последующего
программирования. Ведь при хорошо составленном алгоритме всегда это происходит,
разве нет? Лично я предполагаемую программу именно так готовлю, если надо её передать
программисту, чтобы ни двусмысленности не было в ТЗ, ни потребности в элегантных
и хитрых трюках. Естественно, для этого немножко стараюсь знать о программировании...

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

Вот всё это надо и было продвигать.
Кто бы понял, кто нет — но это было бы правильно, по-моему.
Кстати, для примера — когда-то был такой smArtwork —для печатных плат.
Он спрайтовый, для CGA и оттого в нем не сильно много возможностей настройки.
BGA не развести, это точно ...
Но помню, когда появились штуки типа Пикада, с невъебенными возможностями —
работа замедлилась, пока не научились оставлять только те возможности, что нужны.
Короче, ум нормально работает только имея дискретизацию в предметной области,
мы же, кстати, не аналогово мыслим. Так что чем меньше лишнего — тем больше творчества.

Конечно, красивее иметь редактор с разными фонтами и их размерами и расположением.
Но во времена, когда стиль четко определялся возможностями машин под ДОС —
текстов набирали больше, потому что именно это делали, а не укладывали покрасивее
написанное.

В общем, в двух словах так:
В наших мозгах думают нейроны, а у них
всего несколько состояний, но европейское мышление все равно двоично по сути.
Но даже если усовершенствовать способ мышления, на что уходит от 3 месяцев
и более — то всё равно оно останется дискретным. Хотя вычислительная мощь и
резко возрастет — но мы знаем, как легко по новой загрузить даже очень ускоренную
машину, что опять и снова начнёт тормозить.

Потому любые способы исполнить любую работу должны учитывать это.
И Дракон, как мне кажется, как раз и учитывает — в чем его глобальная польза.

PS Хотя, справедливости ради, надо отметить, что в книгах про Дракон всё
же не зря приводятся алгоритмы как бы нетехнические. То есть, как бы похожие мысли бродят.
Но если они все же ориентированы на инженеров — то можно было и прямо
сказать примерно то, что я изложил выше. Было бы эффективнее, как мне кажется.

[Прохожий]

...

Фсе ниасилил.
Многа букофф.
Но основная мысль, ПМСМ, следующая:

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

И заочно возражу программеру из ссылки:
1. В природе нет алгоритмов не реализуемых на КА или их совокупности.
2. Мьютексы, очереди сообщений, боязнь глобальных переменных - это для людей, не умеющих мыслить параллельно.
3. ДРАКОН приучает к параллельному мышлению, но если человек - линейник, то здесь ему никто не поможет.

[Гость_MrYuran_*]

Вот и конкуренты подтянулись.
Кстати, как ощущения от буржуинской версии? Желательно честно-взвешенные.

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

[Гость_MrYuran_*]

Приложите свои силы на то, чтобы конкуренты окончательно задавили ещё неокрепшего дракончика

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

[orthodox]

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

Смотря в чьи лапы попадет - Гуру Киллер отчасти прав.
Но только практика покажет.
Кстати, если бы они четко знали, как приложить
всё это к делу - наверное бы уже приложили.

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

Так что время давно настало, но если это не будет продукт, реально
упрощающий работу - он не нужен. А ведь если с электрическими схемами
случай проще — все УЖЕ общались на языке схем, просто симуляторы отстали
поначалу — то с программами всё сложнее, тут такой традиции изначально
как бы почти не было, несмотря что о блок—схемах трындели ещё с института,
тут код — основа всего пока что.

[orthodox]

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

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

Ну не нравится мне это прохождение опять через ЯВУ.
Лучше бы сообщество попотело, да родило бы всё заново.
Иначе это будет как IBM — овская или Виндовская совместимость,
наложение недостатков один на один.

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

[Idle]

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

а чем поможет сервак в политехе? чем плох сам кикстартер?

[_pasha]

(ну я знаю, знаю про этот известный миф — переносимость...)

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

[orthodox]

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

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

[_pasha]

Ну, то просто особенность
конкретной нашей темы.

В этих всех C vs ASM есть одно свойство: тема сферическая до бараньего яйца, а для того, чтобы что-то доказать - надо сделать довольно дурную работу - переписать с одного языка на другой какой-нить значимый проект - хотя бы больше килослова флеша, а это уже гемор. И провести сравнение. Хто кого натянул и на скока пгоцентов. Но есть оптимизм такой, что натянуть Си на настоящем этапе развития мона не более чем на 20% по размеру и 20-30% по скорости. У меня в приводном 18-м пике, я вроде уже говорил, есть большая ассемблерная вставка с генерацией шима и всеми прерываниями, плюс таблица инициализации самописная, ибо то, что хочет МСС18 -прогнуться под coff файл и строить .bss на 24-битных указателях - совершеннейшая чушь, - нужна ведь всего пара значений,- байт на адрес SFR, байт на данные. За счет этого асм конечно выигрывает.

[orthodox]

У меня в приводном 18-м пике, я вроде уже говорил, есть большая ассемблерная вставка с генерацией шима и всеми прерываниями, плюс таблица инициализации самописная,

А у меня кроме этого, почти и нету ничего....
Не считать же математику, хотя если её считать,
то разница была бы типично из прошлого — десятки раз,
я думаю. Пиша (пися??) на Си, трудно, вероятно, подгонять
всю эту математику под особенности двоичного исчисления,
типа замены деления вычитанием. Ну и там многое другое, Вы-то и так в курсе.
Так что если бы я вставки делал, то кроме них осталась бы только main void {} и всё...
Железо такое железо...
Хотя я мог бы писать на Си и математику, не выпуская из головы
реальных особенностей всей этой хрени,
то есть руками прописать в Си табличное деление, к примеру.
но вот смысл такого действа от меня ускользает...

И всё же, поскольку мы говорим не об этом, а Драконе, как альтернативе ЯВУ
а не надстройке над ЯВУ, ранее известными —
то можно как-то взять многое и от любого другого ЯВУ, так как все они, по большому счету,
просто набор функций на АСМ... Ну а квадратики в Драконе всё одно заполнять кодом надо.
Так что-то просто можно тупо скомпилить в Си, к примеру — если хорошо, то отчего не использовать.
А и оставить возможности самому как-то заполнить эти квадратики, и более того — запомнить их,
как вот люди макросы для себя копят. Ну естественно, с возможными оговорками, как самописные классы
не обязаны стыковаться со всем подряд и в общем случае, могут таки не полностью соответствовать стандартам языка,
о чем известно объектно-ориентированным людям, и не мешает особо. Ибо есть время для универсальных классов,
и есть время для оптимизированных под предметную область классов, и даже под один тип задач. И каждому — свое.
И да не используют printf не только для мигания светодиодами, а и для вывода на ЖКИ дисплей, может, не стоит....

Однако, что-то мне подсказывает, что именно в Драконе можно было бы
меньше «не соответствовать» стандартам при написании самописных вариантов
заполнения, структурированность помогла бы... Да и можно было бы, возможно,
эти варианты делать через подсхемы, то есть из стандартных кусков большей частью...
Все ассоциации навеяны Микрокапами всякими и к действительности отношение иметь не обязаны...

[_pasha]

Пиша (пися??) на Си...

На Си писЯ
Всегда коси
Под суперпрограммиста.
ПиСи рыдает от стыда:
Ну всё, асталависта!!!

И всё же, поскольку мы говорим не об этом, а Драконе, как альтернативе ЯВУ
а не надстройке над ЯВУ, ранее известными —

Дык Си и не ЯВУ, ни во сне, ни наяву Там только С++ можно вывести в ранг ЯВУ, и то с усилиями, ибо шаблоны до сих пор вещь мутная и сильно специфичная от компилера к компилеру.

[orthodox]

Дык Си и не ЯВУ, ни во сне, ни наяву

Единственный за последние полгода аргумент,
достаточно глубокий, чтобы заставить меня по крайней мере
задуматься... Мерси.
Собственно, есть такое, что ни на чем больше и не сделать...
Просто потому, что изначально библиотека на нём...и вообще...

Дракон это аббревиатура или самоназвание?
Если название, то несколько вычурное, с претензией на.

Да аббревиатура, в начале ветки была расшифровка.
Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность.
Кстати, кому как, а мне буква Р в нем доставляет.
Не менее, чем остальные. А в чем-то и более.

[orthodox]

Огв. Значит буквы большие.

У меня капслок далеко,
а шифт держать — пальцы отвалятся...
Экономлю...