Comments 42
В sikuli X применена пятая идея про картинки. Правда это скорее среда для создания макросов.
Что-то типа визуального редактора для с++? оригинальненько :)
Разве сейчас в современных IDE типа Xcode и Eclipse не примерно так?
Ну там вроде никак нельзя перетащив в редактор картинку присвовить ее переменной, а тут судя по пункту 5 имеется ввиду и подобное…
Скорее на пути к тому. Сам текст исходника в конечно итоге мы видим таким, какой он есть. То есть, например, проблема описанная в пункте 2 не решена пока нигде. Хотя, может я что-то и пропустил.
Проблема 2, это скорее проблема конкретных людей. Так-то давным давно придумали стандарты именования и т.д.
Ну мы все конкретные люди. Если посмотреть, например, исходники поставляемые с Delphi, то вы найдете в большом количестве String как с заглавной, так и с маленькой буквы.
Есть люди которые халтурят, забивают и гавнакодят, а есть которые следуют стандартам.
Впрочем конечно, всегда можно ошибиться и где-то не поставить например заглавную букву — но это не столь существенно.
Повторюсь проблема не в языках — а в людях, люди всегда при желании найдут где накосячить.
И думаю что на Delphi уже ориентироваться не стоит.
Впрочем конечно, всегда можно ошибиться и где-то не поставить например заглавную букву — но это не столь существенно.
Повторюсь проблема не в языках — а в людях, люди всегда при желании найдут где накосячить.
И думаю что на Delphi уже ориентироваться не стоит.
Простите за праздный вопрос, но позвольте поинтересоваться — а насколько «достаточно давно» (с возрастом в профиле ознакомился)?
Возможно я не проникся сутью и это прорывная идея которая первернёт мир, но мне она представляется довольно странной. Кроме того google выпустил же систему для визуального программирования, возможно она Вас удовлетворит…
Возможно я не проникся сутью и это прорывная идея которая первернёт мир, но мне она представляется довольно странной. Кроме того google выпустил же систему для визуального программирования, возможно она Вас удовлетворит…
Мне кажется, или вы только что изобрели literate programming, где мультимедии побольше, чем на прошлой итерации? Или, быть может, это мультимедиа-UML?
Меня эта тема тоже занимает, но интересно увидеть хотя бы эскизы того, как это могло бы быть в реальной жизни на реальном проекте. Потому что дополнительный уровень абстракции создаётся (что в теории хорошо), но может слишком много потеряться по дороге. Пока ничего на эту тему пристойного не встречал.
Меня эта тема тоже занимает, но интересно увидеть хотя бы эскизы того, как это могло бы быть в реальной жизни на реальном проекте. Потому что дополнительный уровень абстракции создаётся (что в теории хорошо), но может слишком много потеряться по дороге. Пока ничего на эту тему пристойного не встречал.
Нужно разделять: вы либо придумываете эдакий визуальный ЯП, либо размышляете над унификацией исходников в некоторый формат. ИМХО визуальный ЯП в виде, как вы описали — бессмысленный, т.к. печатать такое на порядок быстрее (autocomplete, сниппеты — кучи способов ускориться), чем тыкать мышкой. Говорю со всей уверенностью, т.к. последний без-немного-год работаю с XSLT, а это чертовский многословный язык.
Если я правильно понимаю то, о чём вы говорите, то большая часть задач уже решена различными IDE (и даже текстовыми редакторами).
1. Уже давно код форматирует кто как хочет. Для тех же С и С++ существуют программы, способные привести код к нужному виду (скобочки-пробелы-переносы строк). Для других языков тоже не проблема. Хотя зачастую, есть заданные правила форматирования (как пример — python)
2. С разделением сущностей всё тоже более менее «прозрачно»: существует грамматика языка, в соответствии с которой всегда можно чётко определить типа того или иного «слова». Ну это вы и без меня должны знать…
3. Документирование — не проблема исходного кода как такового, на мой взгляд. Двухуровневая организация кода вас не спасёт тут.
4-5 ресурсы в исходном коде — спорный подход. не готов сейчас говорить за всех, но лично я против подобного.
В целом, мне кажется, что двухуровневая организация исходного кода — бессмысленна. Она добавит сложности, не дав ощутимых (для меня) плюсов.
1. Уже давно код форматирует кто как хочет. Для тех же С и С++ существуют программы, способные привести код к нужному виду (скобочки-пробелы-переносы строк). Для других языков тоже не проблема. Хотя зачастую, есть заданные правила форматирования (как пример — python)
2. С разделением сущностей всё тоже более менее «прозрачно»: существует грамматика языка, в соответствии с которой всегда можно чётко определить типа того или иного «слова». Ну это вы и без меня должны знать…
3. Документирование — не проблема исходного кода как такового, на мой взгляд. Двухуровневая организация кода вас не спасёт тут.
4-5 ресурсы в исходном коде — спорный подход. не готов сейчас говорить за всех, но лично я против подобного.
В целом, мне кажется, что двухуровневая организация исходного кода — бессмысленна. Она добавит сложности, не дав ощутимых (для меня) плюсов.
Много думал про это, но по-настоящему удобной визуальной среды представить так и не смог.
Большая программа с кучей модулей так или иначе превращается в ковер с прокруткой.
Большая программа с кучей модулей так или иначе превращается в ковер с прокруткой.
Это так. Большая программа в маленькую не превратиться никогда. Мы можем только совершенствовать средства работы с ней. Ну согласитесь одно дело работать с многомегабайтными исходниками в обычном текстовом редакторе и совсем другое, скажем, в IntelliJ IDEA. Хотя знаю, некоторые с этим тезисом не согласятся.
Большинство современных IDE решают почти все проблемы.
> 1. Решается проблема унификации форматирования кода.
Многие IDE умеют переформатировать код как Вам удобнее. При этом можно даже не менять сам текст — только представление.
> 2. Решается проблема разделения сущностей.
Собственно, современные IDE и без тегов и тп опознают классы и типы, подсвечивая их соответственно. И даже локальные/глобальные переменные по разному подсвечивают. И многое ещё, включая виртуальные функции.
> 3. Решается проблема документирования исходного кода.
Системы докогенерации могут включать и исходники функций, где будут доступны все прочие комментарии.
> 4. Мы сможем хранить ресурсы, любые, вплоть до звуков и картинок, непосредственно в исходном коде, причем связывая их с ним напрямую.
Это тоже уже делается, ресурсы кодируются в base64 и хранятся прямо в коде. Кое-где это делается почти автоматически, и сделать плагин для любимой IDE, который будет обрабатывать драг-н-дроп в код и вставлять base64, декодируемый в нужный тип — легко.
> 5. Станут доступны следующие, ныне совершенно немыслимые конструкции
Как и в пункте 4, плагин может это взять на себя: при встрече блока в base64 отображать его в виде миниатюры картинки. Вполне реально сделать уже сейчас, было бы желание.
Так что, как мне кажется, ничего инновационного Вы не предложили. Всё это или уже есть, или легко делается на базе готовых IDE. Но если это легко делается, почему этого нет до сих пор? Мне кажется, это никому не нужно. Очень удобно разделять ресурсы и исходники, и мешание всего этого в кучу — лишнее запутывание, ИМХО.
> 1. Решается проблема унификации форматирования кода.
Многие IDE умеют переформатировать код как Вам удобнее. При этом можно даже не менять сам текст — только представление.
> 2. Решается проблема разделения сущностей.
Собственно, современные IDE и без тегов и тп опознают классы и типы, подсвечивая их соответственно. И даже локальные/глобальные переменные по разному подсвечивают. И многое ещё, включая виртуальные функции.
> 3. Решается проблема документирования исходного кода.
Системы докогенерации могут включать и исходники функций, где будут доступны все прочие комментарии.
> 4. Мы сможем хранить ресурсы, любые, вплоть до звуков и картинок, непосредственно в исходном коде, причем связывая их с ним напрямую.
Это тоже уже делается, ресурсы кодируются в base64 и хранятся прямо в коде. Кое-где это делается почти автоматически, и сделать плагин для любимой IDE, который будет обрабатывать драг-н-дроп в код и вставлять base64, декодируемый в нужный тип — легко.
> 5. Станут доступны следующие, ныне совершенно немыслимые конструкции
Как и в пункте 4, плагин может это взять на себя: при встрече блока в base64 отображать его в виде миниатюры картинки. Вполне реально сделать уже сейчас, было бы желание.
Так что, как мне кажется, ничего инновационного Вы не предложили. Всё это или уже есть, или легко делается на базе готовых IDE. Но если это легко делается, почему этого нет до сих пор? Мне кажется, это никому не нужно. Очень удобно разделять ресурсы и исходники, и мешание всего этого в кучу — лишнее запутывание, ИМХО.
5. Станут доступны следующие, ныне совершенно немыслимые конструкции, типа
Неужто, немыслимые?
Неужто, немыслимые?
Откуда скришот?
Интересно. А можно поинтересоваться как выглядит сам текст данного исходника?
Сам текст? Вообще говоря, в Математице обычно не имеют дело с внутренностями .nb файлов, и программа вводится как есть на скриншоте.
Но вот сам .nb файл
Но вот сам .nb файл
Poterin, думаю, лет через 10-20 именно так все и будет, как вы написали.
При вставке ресурсов прямо в код есть же гораздо более частая на практике необходимость — это поддержка многоязычности. Не знаю, есть ли сейчас хотя бы одна среда/система/фреймворк, которые позволяли бы работать с многоязычными строковыми константами так же удобно, как если мы напрямую правим их в коде/шаблоне/форме в одноязычном случае. Я такой не видел. Все текущие способы с отдельными ресурсами/суррогатными константами/gettext далеки от удобства.
При вставке ресурсов прямо в код есть же гораздо более частая на практике необходимость — это поддержка многоязычности. Не знаю, есть ли сейчас хотя бы одна среда/система/фреймворк, которые позволяли бы работать с многоязычными строковыми константами так же удобно, как если мы напрямую правим их в коде/шаблоне/форме в одноязычном случае. Я такой не видел. Все текущие способы с отдельными ресурсами/суррогатными константами/gettext далеки от удобства.
Спасибо за мысль. Это нужно добавить еще одним пунктом.
6. Локализация непосредственно в исходном коде…
6. Локализация непосредственно в исходном коде…
А переводчику нужно будет весь исходник перелопатить, или предусмотрен специальный режим «показывать только локализацию»?
Имхо, что-то подобное когда-то кто-то уже пытался сделать, да и во многих специализированных математических, статистических и тому подобных пакетах все уже есть.
НО, plain text он потому и выжил, потому что в итоге оказывается наиболее переносимым, наиболее обрабатываемым и т. д. А все что больше — создает больше проблем, чем преимуществ.
НО, plain text он потому и выжил, потому что в итоге оказывается наиболее переносимым, наиболее обрабатываемым и т. д. А все что больше — создает больше проблем, чем преимуществ.
Ну вообще если вспомнить о нелинейной сути программы, то можно сформулировать текущую ситуацию следующим образом: программа — это многомерный граф связанных между собой объектов, а исходный код — проекция этого безобразия на двумерный массив символов. Собственно все «последние» выдумки программистов (аспектно-ориентированное программирование, к примеру) — это попытки улучшить презентабельность этой проекции. То есть, грубо говоря, начиная навешивать аннотации на классы, мы добавляем в нашу программу еще 1 «измерение». Добавляя xml-файлы с описанием — тоже. И еще, и еще.
Так что все автор верно говорит. Рано или поздно мы придем к пониманию того, что голый текст — далеко не лучшее представление программы, и даже продвинутые IDE уже не очень помогают. Будут сделаны специальные редакторы для кода. В них программист будет явно создавать различные программерские «объекты» (типы, функции, определения) уже не голым текстом, а в специальном интерфейсе. Соответственно, связи между этими вещами будут храниться нативно, и не составит никакого труда написать удобные инструменты для просмотра программы под разными углами (можно сказать мы будем «вертеть» многомерный граф программы руками, рассматривая его различные грани с удобных для нас позиций).
Так что все автор верно говорит. Рано или поздно мы придем к пониманию того, что голый текст — далеко не лучшее представление программы, и даже продвинутые IDE уже не очень помогают. Будут сделаны специальные редакторы для кода. В них программист будет явно создавать различные программерские «объекты» (типы, функции, определения) уже не голым текстом, а в специальном интерфейсе. Соответственно, связи между этими вещами будут храниться нативно, и не составит никакого труда написать удобные инструменты для просмотра программы под разными углами (можно сказать мы будем «вертеть» многомерный граф программы руками, рассматривая его различные грани с удобных для нас позиций).
Было, уже пытались много раз. Например — ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D
Не взлетает.
Не взлетает.
Ну я вообще-то не о том писал. Я не предлагал изобретать новый язык программирования, это совершенно отдельная и серьезная тема. Речь шла только о том как хранить и работать с исходниками. А язык программирования при этом может быть совершенно любым, в том числе любым из ныне здравствующих.
Спасибо, интересная ссылка. Но судя по тому, что там они сделали — вполне понятно, почему оно не взлетает. Оно и не взлетит, если излишне пытаться сделать ВСЁ графическими примитивами. На мой взгляд всю их блоксхему как раз проще запихнуть в один «квадратик» а внутри квадратика написать код обычным текстом. А вот уже с чем связать этот квадратик — другой вопрос.
Sign up to leave a comment.
Двухуровневая организация исходного кода. Неизбежно или бессмысленно?