Олег Тельнов @TelnovOleg
Руководитель, Программист
Информация
- В рейтинге
- Не участвует
- Откуда
- Омск, Омская обл., Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Backend Developer, 1C Developer
Middle
От 150 000 ₽
Golang
Git
Database
Docker
Есть такой язык - 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 у разных фишек ноги растут.