Добрый день!
Устроит любая платформа на ARM процессоре для разработки ОСРВ.
ОС планируется на языке Forth для обеспечения максимальной переносимости и возможности использования её при встраивании аппаратного Forth-процессора собственной разработки в ПЛИС.
Исходя из теоремы Гёделя о неполноте, можно заключить, что не существует языка программирования крутость (эффективность, красивость, элитарность… нужное подчеркнуть) которого можно доказать только исходя из анализа фич, синтаксиса и чего угодно еще только лишь этого языка. Крутость языка начинает иметь смыслы только с введением внешней системы, то есть с добавлением программиста. Следовательно, для разных пар «язык — программист» доказано будет крутость разных языков. Так о чем спор? ;)
Никак не могу отделаться от ощущения, что что-то в этом мире все время идет не так. Вот зачем изобретать какое-то API, если потом нужно изобрести еще 100500 фреймворков, что бы можно стало нормально работать? Почему бы сразу не делать фреймворк элементом архитектуры, как была спроектирована например BeOS? Понятно что кому-то покажется что фреймворк неправильный и надо делать по другому, но вдруг таких будет меньшинство?
Или может быть правы считающие излишним переусложнение программ в попытках сделать их компоненты сверхуниверсальными на все случаи жизни и надо решать только конкретную проблему стоящую перед задачей, на что вполне хватает и API?
Вот, даже не смотря на то, что я никак не могу придумать зачем нужна такая ОС, я все равно испытываю некоторый восторг от того, что такие вещи кто-то делает. Ибо, на мой взгляд, программирование на ассемблере это искусство и оно должно быть даже просто само по себе.
Молодцы!!!
А вот такой вопрос, а поддержка JS в браузере планируется?
Ну вот в порядке фантастического бреда можно набросать такую концепцию, которая идеально ложится под функциональное программирование…
Итак :) Когда-то, помимо цифровых ЭВМ существовали аналоговые, которые, по тем временам, позволяли смоделировать некоторые процессы быстрее и точнее чем в цифре. Потом то цифра их превзошла количеством операций за единицу времени, но не суть… Просто аналоговые машины функционировали так сказать в непрерывном потоке, в отличии от цифровых с их статичным промежуточным состоянием. Это раз.
В те же былинные времена существовали ЭВМ реализованные не на двоичной, а на троичной элементной базе. Тут могу соврать, не разбирался точно, но вроде там все кодировалось не напряжением, а направлением и отсутствием тока… Главное, что процессы тоже все были непрерывные. Это два.
Так вот, функциональная программа, где структуры данных реализованы как функции, тоже работает непрерывно, без явных точек останова с фиксацией состояния. Т.е. функциональная программа идеально ложится на аналогово-троичную ЭВМ! ;)
Осталось только такую изобрести и функциональщина тут же станет мэйнстримом! ;)
Основной смысл приведенных примеров в том, что в языке реализующем удобную работу с лямбда исчислением можно все операции свести к вызову функций. Вот еще интересная статья на хабре на эту тему Чисто функциональные структуры данных
Задолго до Оберона концепцию программы как расширения среды презентовал Smalltalk. Но почему-то идея так и не прижилась. Может быть потому что размер «Блокнота» в таком варианте стремился к размеру «Офиса»? Эта концепция хороша в замкнутой экосистеме где среда фактически сливается с ОС и все программы только в ней и существуют. Но как отдельное приложение это не рационально и зачастую неудобно.
А недостатки динамической перезагрузки модулей в Java это не проблемы языка или архитектуры платформы, это проблемы реализации. Можно подумать в Обероне не к чему придраться…
Мне кажется что самая большая беда Оберона в том что он не приносит никаких новых концептуальных идей по сравнению с другими языками. Я не отрицаю версии, что именно он лег в основу Java, хотя и сомневаюсь в столь однозначных параллелях, но это не делает Оберон уникальным. Если на то пошло, то почти все концепции были впервые реализованы в Lisp и Smalltalk. Вот и получается что никакого интереса перехода на Оберон как бы и нет. Все чем он может похвастаться, это компактность описания синтаксиса, но и здесь его переплюнет тот же Форт. А если упирать на надежность, то уж лучше на какой-нибудь Eiffel посмотреть, больше идей принесет.
Пока сочинял свой ответ Вы уже написали. Я с Вами полностью согласен. Пора заставить компьютер думать за меня там, где он сможет это сделать. Т.е. там где возможен логический анализ. Ведь если сейчас компиляторы оптимизируют код чуть ли не лучше профессионалов ассемблера, то почему не перенести эти подходы на более высокий уровень.
Просто на сегодняшний момент все известные мне системы кодогенерации работают просто как трансляторы из одной формальной модели в другую, совершенно не занимаясь оптимизациями. Т.е. фактически они работают как макроязыки. Что приводит либо к необходимости написания сложной и подробной первоначальной модели (а тогда и упрощение от такого средства сомнительна), либо к избыточности и неэффективности порождаемого кода.
Именно из-за формального подхода падает эффективность различных ORM, когда запрос работающий с несколькими объектами превращается в тормозного монстра из мешанины мелких SQL запросов. Хотя если написать такой запрос с учетом всех возможностей SQL, то размер и производительность улучшаются на порядок. А всего лишь надо, чтобы система могла произвести не только синтаксический, и даже не только семантический, но и логический разбор входного кода и произвела его оптимизацию (например, абстрактно, вместо двух одинаковых циклов по разным полям объединила эти запросы в один)
И так со всем остальным. Все в выводе кода, что можно описать в виде логических правил на языке типа Пролога, должно быть описано и выводится автоматом, а не заставлять программиста писать тонны связующего кода.
За мной должно остаться только придумывание общего алгоритма, выбор дополнительных функциональных блоков, возможность внести изменения в сгенерированный код и интерфейс.
Причем язык должен быть спроектирован так, что мои изменения встраиваются в базу фактов и учитываются при новом логическом выводе. Например, если автогенератор применил алгоритм сортировки пузырьком, а я изменил на сортировку вставками, то в следующий раз он тоже отсортирует также. Если я определил дополнительный блок проверки прав доступа к базе, то он должен автоматически встроиться во все места где происходит доступ, без необходимости мне писать вручную хоть строчку.
Т.е. моя формула нового даже не языка, а среды разработки = минимальный синтаксис + аспектное программирование + логическое программирование + неявная передача параметров с их автоподстановкой.
Вот такие вот фантазии :)
Мне кажется что многие люди подсознательно ставят знак равенства между понятиями «простой» и «легкий». Вот например язык Forth обладает очень простым синтаксисом. Фактически в нем вся программа это просто набор слов (под которыми скрыт аналог вызова функции с неявной передачей параметров через стек). Но вот написать на нем достаточно большую программу занятие далеко не легкое.
Простые по синтаксису языки позволяют гораздо лучше контролировать производимые действия на низком уровне, т.е. мы можем детально разобрать применяемый алгоритм, распределение памяти, затраты машинного времени и прочее. Но оборотной стороной является необходимость писать очень много кода несущественного для основного алгоритма задачи, но требуемого для связки низкоуровневых инструкций. Так в Forth нужно тратить силы на манипуляции с порядном данных в стеке, а в Oberon следить за вложенностью циклов и выходом индексов за границы массивов, в то время как весь полезный алгоритм можно описать парой или тройкой комбинаций MapReduce.
Но с другой стороны, понять какой-то кусок современной программы на Lisp, JavaScript или Java/C# без понимания что скрыто за применяемыми абстракциями практически невозможно. А уж тем более затруднительно оценить ресурсоемкость таких программ. Наверно поэтому языки со сборкой мусора очень трудно проникают в программирование систем реального времени.
Фактически наличие дополнительных синтаксических конструкций приводит к проблеме любого DSL. Он вроде бы облегчает написание, пока задача укладывается в его возможности и хорошо ложится на его конструкции, но совсем не упрощает поиск причин проблем возникающих в скрытом слое или реализацию задач не вписывающихся в его парадигму.
А так как, семантика решаемых задач практически бесконечна, то и лавину фреймворков, «сахарных» конструкций, библиотек API и прочее, прочее, прочее… остановить вряд ли возможно.
Но, может быть, решение не в рамках создания универсальных языков, вынуждающих или писать много низкоуровневого кода или изучать внутреннее строение монструозных фреймворков? Почему не возложить на среду разработки генерацию любого промежуточного кода («промежуточный» — это код связанный с передачей и преобразованием данных от одного модуля или функции к другим). Возражения о не оптимальности кода созданного автоматически это лишь признак плохого проектирования системы автогенерации. А нам лишь нужен язык достаточно простой для автоматизации типовых операций, передачи параметров, комбинирования функций и построению сложных объектов из более простых (т.е. с упором на контейнеры, а не наследуемые объекты). И тогда, основной алгоритмы задачи можно описать очень просто, а вся сложность перенесется на логический вывод автогенерируемого кода.
Немного не по теме, но может кто-то не знает и ему будет интересно. Существует язык для программирования не просто музыки, а начиная с конструирования звука из составляющих гармоник. Вообщем, не просто пишем музыку, а сначала придумываем инструменты… ru.wikipedia.org/wiki/Csound
В Форте вполне возможно метапрограммирование. Так же как и Лисп, Форт позволяет переключаться между режимами «компиляции» и «интерпретации», что открывает дорогу для создания макросов, так как помимо стека данных в Форте программисту доступен и стек возвратов, что дает неограниченный простор для создания собственных структур управления и реализации метапрограммирования.
Ну мне вот тоже не понятно, почему любую критику тут же минусуют? Ну да это роиторический вопрос.
Дело не в том чем вы отличаетесь от Google Wave, а в том что по интерфейсу ваш продукт очень похож. То есть, стиль работы подразумевает такой же. Но на мой взгляд, по крайне мере для меня, такой способ не очень удобен. И то что вайв не пошел, по моему, говорит что я не одинок в таком взгляде. Вот поэтому и возникает вопрос, на какую аудиторию расчитан проект и какие исследования позволяют расчитывать на его удобство и полезность?
А вас почему-то обижает сравнение…
Из всей статьи почерпнул только один единственный полезный факт — где-то еще в России делают очередной клон Google-Wave… Вот если бы были более подробно изложены выводы по результатам тестирования, с указанием рекомендации по типичной реакции пользователя на те или иные элементы интерфейса и методы исправления узких мест… Вот тогда бы статья была полезной. А так…
Я конечно же желаю вам удачной разработки, но вот сам не могу понять — зачем делать клон провалившегося продукта? Ведь его интерфейс кажеться понятным лишь избранным… плохо представляю целевую аудиторию продукта :(
Для меня это бесспорное утверждение. :) Функциональный подход позволяет многие алгоритмы выражать гораздо проще и эффективней.
А ещё добавить изучение SmallTalk для понимания истиного ООП и Forth для того, чтобы проникнуться низкоуровневыми конструкциями :)
После этого сразу видно откуда в C# и Java у разных фишек ноги растут.
Есть такой язык - Ada. Мне кажется там есть многое из того, о чём пишет автор...
Устроит любая платформа на ARM процессоре для разработки ОСРВ.
ОС планируется на языке Forth для обеспечения максимальной переносимости и возможности использования её при встраивании аппаратного Forth-процессора собственной разработки в ПЛИС.
Или может быть правы считающие излишним переусложнение программ в попытках сделать их компоненты сверхуниверсальными на все случаи жизни и надо решать только конкретную проблему стоящую перед задачей, на что вполне хватает и API?
Молодцы!!!
А вот такой вопрос, а поддержка JS в браузере планируется?
Итак :) Когда-то, помимо цифровых ЭВМ существовали аналоговые, которые, по тем временам, позволяли смоделировать некоторые процессы быстрее и точнее чем в цифре. Потом то цифра их превзошла количеством операций за единицу времени, но не суть… Просто аналоговые машины функционировали так сказать в непрерывном потоке, в отличии от цифровых с их статичным промежуточным состоянием. Это раз.
В те же былинные времена существовали ЭВМ реализованные не на двоичной, а на троичной элементной базе. Тут могу соврать, не разбирался точно, но вроде там все кодировалось не напряжением, а направлением и отсутствием тока… Главное, что процессы тоже все были непрерывные. Это два.
Так вот, функциональная программа, где структуры данных реализованы как функции, тоже работает непрерывно, без явных точек останова с фиксацией состояния. Т.е. функциональная программа идеально ложится на аналогово-троичную ЭВМ! ;)
Осталось только такую изобрести и функциональщина тут же станет мэйнстримом! ;)
Вот они то совсем мозг разрывают :)
А недостатки динамической перезагрузки модулей в Java это не проблемы языка или архитектуры платформы, это проблемы реализации. Можно подумать в Обероне не к чему придраться…
Именно из-за формального подхода падает эффективность различных ORM, когда запрос работающий с несколькими объектами превращается в тормозного монстра из мешанины мелких SQL запросов. Хотя если написать такой запрос с учетом всех возможностей SQL, то размер и производительность улучшаются на порядок. А всего лишь надо, чтобы система могла произвести не только синтаксический, и даже не только семантический, но и логический разбор входного кода и произвела его оптимизацию (например, абстрактно, вместо двух одинаковых циклов по разным полям объединила эти запросы в один)
И так со всем остальным. Все в выводе кода, что можно описать в виде логических правил на языке типа Пролога, должно быть описано и выводится автоматом, а не заставлять программиста писать тонны связующего кода.
За мной должно остаться только придумывание общего алгоритма, выбор дополнительных функциональных блоков, возможность внести изменения в сгенерированный код и интерфейс.
Причем язык должен быть спроектирован так, что мои изменения встраиваются в базу фактов и учитываются при новом логическом выводе. Например, если автогенератор применил алгоритм сортировки пузырьком, а я изменил на сортировку вставками, то в следующий раз он тоже отсортирует также. Если я определил дополнительный блок проверки прав доступа к базе, то он должен автоматически встроиться во все места где происходит доступ, без необходимости мне писать вручную хоть строчку.
Т.е. моя формула нового даже не языка, а среды разработки = минимальный синтаксис + аспектное программирование + логическое программирование + неявная передача параметров с их автоподстановкой.
Вот такие вот фантазии :)
Простые по синтаксису языки позволяют гораздо лучше контролировать производимые действия на низком уровне, т.е. мы можем детально разобрать применяемый алгоритм, распределение памяти, затраты машинного времени и прочее. Но оборотной стороной является необходимость писать очень много кода несущественного для основного алгоритма задачи, но требуемого для связки низкоуровневых инструкций. Так в Forth нужно тратить силы на манипуляции с порядном данных в стеке, а в Oberon следить за вложенностью циклов и выходом индексов за границы массивов, в то время как весь полезный алгоритм можно описать парой или тройкой комбинаций MapReduce.
Но с другой стороны, понять какой-то кусок современной программы на Lisp, JavaScript или Java/C# без понимания что скрыто за применяемыми абстракциями практически невозможно. А уж тем более затруднительно оценить ресурсоемкость таких программ. Наверно поэтому языки со сборкой мусора очень трудно проникают в программирование систем реального времени.
Фактически наличие дополнительных синтаксических конструкций приводит к проблеме любого DSL. Он вроде бы облегчает написание, пока задача укладывается в его возможности и хорошо ложится на его конструкции, но совсем не упрощает поиск причин проблем возникающих в скрытом слое или реализацию задач не вписывающихся в его парадигму.
А так как, семантика решаемых задач практически бесконечна, то и лавину фреймворков, «сахарных» конструкций, библиотек API и прочее, прочее, прочее… остановить вряд ли возможно.
Но, может быть, решение не в рамках создания универсальных языков, вынуждающих или писать много низкоуровневого кода или изучать внутреннее строение монструозных фреймворков? Почему не возложить на среду разработки генерацию любого промежуточного кода («промежуточный» — это код связанный с передачей и преобразованием данных от одного модуля или функции к другим). Возражения о не оптимальности кода созданного автоматически это лишь признак плохого проектирования системы автогенерации. А нам лишь нужен язык достаточно простой для автоматизации типовых операций, передачи параметров, комбинирования функций и построению сложных объектов из более простых (т.е. с упором на контейнеры, а не наследуемые объекты). И тогда, основной алгоритмы задачи можно описать очень просто, а вся сложность перенесется на логический вывод автогенерируемого кода.
Дело не в том чем вы отличаетесь от Google Wave, а в том что по интерфейсу ваш продукт очень похож. То есть, стиль работы подразумевает такой же. Но на мой взгляд, по крайне мере для меня, такой способ не очень удобен. И то что вайв не пошел, по моему, говорит что я не одинок в таком взгляде. Вот поэтому и возникает вопрос, на какую аудиторию расчитан проект и какие исследования позволяют расчитывать на его удобство и полезность?
А вас почему-то обижает сравнение…
Я конечно же желаю вам удачной разработки, но вот сам не могу понять — зачем делать клон провалившегося продукта? Ведь его интерфейс кажеться понятным лишь избранным… плохо представляю целевую аудиторию продукта :(
А ещё добавить изучение SmallTalk для понимания истиного ООП и Forth для того, чтобы проникнуться низкоуровневыми конструкциями :)
После этого сразу видно откуда в C# и Java у разных фишек ноги растут.