Комментарии 53
Что за язык, что за среда разработки, как все это работает на нижнем уровне…
http://www.it-dc.org/projects/g5
Замечания принимаются :)
Язык пятого поколения: программист должен думать об алгоритмах, а не о языке.
Вроде не так: юзер должен задекларировать условия/ограничения, а язык все сделает типа сам (https://en.wikipedia.org/wiki/Fifth-generation_programming_language).
А что за IDE на видео?
Это качественная IDE, с интеграцией кучи объектов в код. Где тут язык пятого поколения, я не увидел.
Все языки 4-го поколения (С++, Python и т.д.) предполагают, что их исходный код — текстовые файлы.
Существующие языка 5-го поколения — графические (BPML и т.д.).
Я предлагаю сделать микс: текст + картинки где это удобно.
И главная цель — программист должен как можно меньше думать о специфике языка, код должен быть компактным.
Определение 5-го поколения, в вики, Вам привели выше в
https://habrahabr.ru/post/305444/?reply_to=9696938#comment_9696044
Так где Ваш концепт языка умеет решать проблему по набору ограничений и условий? Я например, как и многие другие, вижу тот же Delphi/C#/QtQuick/etc. без принципиальных отличий. Делать же интерактивные объектные вставки можно и на базе текстового представления. Посмотрите например инспект элементов в студии.
И, кстати, по вашему концепту
- Почему опять ООП всего и вся? Чем плохи обычные свободные функции? Зачем Main делать классом?
- Если у вас такое всё из себя объектное представление, почему нужны 2 вида файла с исходниками, в стиле "заголовок-имплементация"? Почему не давать доступ к исходнику на уровне функции? Или хотя бы держать всё в одном "файле", но при этом сортировать по какому-то критерию?
2) Вы либо плохо смотрели видео, либо плохо владеете английским: был создан один файл и на экране лишь два представления этого файла. Представления таки нужны, ибо это удобно — скрыть реализацию класса одним щелчком.
Представления таки нужны, ибо это удобно — скрыть реализацию класса одним щелчком.
Для этого достаточно сворачивания по членам класса (одним щелчком, да). Еще лучше для этого подходят интерфейсы.
1) По поводу структурированности можно поспорить, т.к. не везде и не всегда. Но не будем разводить холивар.
2) Я написал "2 вида". Мне только непонятно, почему эти два вида — суть калька с "заголовок-реализация". Как я написал, вполне можно делать всё одним экраном — но сортировать элементы по месту, позволять экспанд-коллапс и т.п.
В целом, среды, хранившие исходники в отличном от текста представлении, уже были. Не взлетели. Потому что для текста инструментария для текста завались. А вот для вашего гипотетического представления — когда появится дифф, блэйм и т.д.?
Облегчение программирования за счет этой самой интеграции объектов.
Угу. Есть куча программистов, которые с вашими объектами (текстами и картинками) вообще не работают (точнее, они их видят только как пользовательские данные). И как ваше предложение им поможет?
программист должен как можно меньше думать о специфике языка, код должен быть компактным.
Эти два тезиса никак не связаны.
Скажите, пожалуйста, чем ваш язык отличается от существующих?
http://www.it-dc.org/projects/g5
И там по этому поводу нет ничего. Описанный там язык — совершенно обычное третье поколение. Более того, я вообще там не вижу ни одной фичи, которой бы не было в существующих языках (именно с точки зрения языка).
http://www.it-dc.org/projects/g5#TOC-Restrictions
If restriction is violated exception will be generated.
Здравствуй, Eiffel. А теперь внимание, вопрос: чем это отличается от Code Contracts в .net?
«Code Contracts» нельзя задать для чисто виртуальных методов, т.к. у них нет тела. В моем случае ограничения задаются отдельно от тела.
Синтаксис «Code Contracts» отвратителен — но это дело вкуса.
И что её реализации для существующих языков/платформ достаточно убоги (как и тот факт, что оно, как правило, реализуется сторонними библиотеками/расширениями, а не в «ядре» языка).
Другое дело, что у ТС вообще пока нет никакой реализации, — и что она будет (если вообще будет!) красивой и непротиворечивой — совсем не факт. P.S.: ес-но, это должно быть compile-time check, а не runtime exceptions.
Ну, я думаю Вы не будете спорить, что такая штука — «a must» для современного языка.
"A must" — буду. Без DbC можно жить, точно так же, как можно жить без статической системы типов. Но дело даже не в этом, а в том, что добавление DbC не меняет поколение языка — он как был третьим, так и остался.
Другое дело, что у ТС вообще пока нет никакой реализации
Именно.
ес-но, это должно быть compile-time check, а не runtime exceptions.
… чего автор "языка пятого поколения" не понимает.
Предлагаю на эту тему не спорить, ибо очень скользкая
SQL-подобные я бы вообще не назвал языком программирования.
Здрасте пожалуйста, это с чего бы? Ничем не хуже других декларативных языков, местами прекрасная функциональщина видна.
Предлагаю на эту тему не спорить, ибо очень скользкая
Предлагаю в таком случае убрать из вашего текста все упоминания "пятого поколения", чтобы не было, о чем спорить.
Конечно в редких случаях может сработать и compile-time check, добавлю это на страничку :)
Как вы себе представляете «compile-time check»?
Анализом контрактов (и поведения программы) вверх по стеку. Как, собственно, это и сделано в Code Contracts.
Например, я из внешнего источника по ходу выполнения программы получаю число и передаю в функцию: на этапе компилирования это невозможно выявить, тут только runtime exceptions.
Ну и смысл тогда в таком "ограничении"? Оно прекрасно покрывается валидационными правилами.
Превратили хабр в твиттер, блин
А система ничего так. Похуже, конечно, чем VS+C#, например, но зато есть куда расти.
Почему нет русской версии?
В чём-то Вы движетесь в очень правильном направлении.
Только не уверен, что Вы делаете достаточно (в смысле, новая технология, чтобы быть успешной, должна быть на значимую величину быть лучше существующих, а не быть в чём-то лучше, но объявлять себя новым поколением).
Знаете ли, кушать хочется, и работаю фулл-тайм на одного работодателя :)
И личная жизнь у меня таки есть :)))
Иногда бывают перерывы между проектами, и могу заниматься своими, но не так быстро как хотелось бы.
Если это только концепт («нарисовал её в Paint»). То скажу, что Ваша идея, имхо, не нова. Вы гуглили про projectional editing? В частности JetBrains MPS.
«Знаете ли, кушать хочется». Я на самом деле не про недостаток вложенных усилий, а про несоответствие степени новизны и описания. Т.е. ИМХО Вы движетесь в правильном направлении, но почему-то называете всё слишком громкими словами («полноценная замена», «пятого поколения»).
этим все сказано
А вообще было-бы в первую очередь интересно узнать, какие насущные проблемы этот фреймворк и этот язык позволяет решить?
Современные ЯП и так справляются с задачей «программист должен думать об алгоритмах, а не о языке.»
Про новизну и Delphi сказали выше. Добавлю, что у меня возникла сильнейшая ассоциация с Wolfram Mathematica:
Концепт фреймворка и языка пятого поколения