Войти
ФлеймФорумПрограммирование

Исходный код - (задушено цензурой). Сущность, стоящую за этим понятием, нужно улучшить!

Страницы: 1 2 3 4 5 Следующая »
#0
19:43, 24 мар. 2019

Многие печали в современном программировании исходят от разрыва между двумя представлениями исходного кода: человеко-оптимальным и машинно-оптимальным.
Для машины желательно, чтобы были уникальные идентификаторы без всяких там неймспейсов. Чтобы поменьше синтаксических сущностей. Чтобы код хранился в уже распарсенном и удобнозагружаемом виде - бинарно, а то и вовсе в БД. Чтобы побольше хинтов, кросс-референсов и семантических тэгов на каждый пук. Парадоксально, но эти вещи пошли бы на благо самому же программисту: по машинно-оптимальному коду легче предоставить навигацию, инспекцию, рефакторинг и пр.
Для человека желательно, чтобы код можно было писать и читать. Чтобы его можно было разбивать на человеко-редактируемые файлы. Чтобы были человекочитаемые имена. Поскольку человекочитаемые имена норовять конфликтовать - чтобы были неймспейсы. Чтобы был синтаксический сахер, ибо базовыми средствами языка многие понятия выражать слишком геморно. Чтобы было побольше сокращений и умолчаний, ибо описывать каждую сущность исчерпывающим образом - слишком многословно. Парадоксально, но со временем это даже усложняет программисту жизнь: сахеры и умолчания становятся всё многочисленнее и всё сложнее для запоминания, а организация исходного кода в виде свалки файлов и папок читаемости ему не прибавляет.

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

Попытки осмыслить и преодолеть данный разрыв наблюдаются - тот же ви$уал бар$ик, где код хранится в машинно-оптимальном виде, а в/из человекоредактируемого компилируется по надобности. Но подобные решения, прибивающие язык программирования к толстой и узкоспециализированной ИДЕ, столь ограниченны, что о них и говорить нечего. Пока не появится решение, с которым человеку будет достаточно блокнота и компилятора - проблема не решена. И Языков По-Настоящему Пятого Поколения у нас, по существу, нет.

Как же её можно решить?

Для начала, пора обновить заскорузлую парадигму тыща девятьсот бородатых годов. Основной формой исходного кода должна стать машинная, а не блокнотная. Она должна быть самодостаточной. Блокнотный исходник возможен, но постоянно существовать не обязан - машинный исходник может обойтись и без него. По существу, это БД распарсенного кода.
Роль блокнотного же исходника кардинально переосмысливается. Это больше не сакральный первообраз, которому машинное представление должно сответствовать от и до. Это - запрос к БД. Подразумевающий, что БД не пересоздаётся с нуля из этого запроса, а что она может уже иметь какое-то состояние, и что это состояние можно не только изменять, но и читать тоже.
В любой момент может быть сгенерирован "дамп" базы в виде блокнотного кода. Если нужно - полного, который воссоздаёт базу в данном состоянии, будучи применён "с нуля". А если нужно - частичный, который имеет дело только с определёнными сущностями. Естественно, программист может отредактировать этот дамп и применить обратно. И таким образом происходит редактирование исходного кода.

Таким образом, блокнотный исходный код превращается из "одностороннего" списка инструкций в этакий "двусторонний" интерфейс между человеческим и машинным представлениями, которое может создавать/редактировать не только человек, но и компилятор. И человек сможет вставлять в код не только программу и прагмы, но и запросы по представлению самого кода. Например: "Вставь-ка в это место такую-то функцию", или "Вот этого класса мне сейчас не надо, спрячь нафик." Но что ещё более важно и интересно - компилятор тоже сможет вставлять в код запросы и уточнения (например, в случае неоднозначности между А или Б - маркер с предложением вставить такую-то уточняющую инструкцию, если имеется в виду А, или такую-то, если Б).

Как это может выглядеть на практике? Примерно следующим образом.

Допустим, пишется программа helloworld. Компилятор у нас, допустим, запускается с командной строки командой sdcc.

# создаём пустую программу
sdcc helloworld.bin++

// создаём файл helloworld.cpp

// помним, что теперь у нас не программа, а инструкция по обновлению программы!
// и сейчас мы добавляем новую, ранее не существовавшую функцию
insert void main(void)
{
 printf("hello world\n");
}
sdcc helloworld.bin++ helloworld.cpp

# ошибка - функция printf неизвестна.

insert void main(void)
{
 // добавлено компилятором:
 //~ERR: undefined symbol printf, define or import
 // suggestions:
 //#import "<module>"
 //#search ["<path>",] printf
 printf("hello world\n");
}

Последуем совету компилятора:

#search printf

insert void main(void)
{
 //~ERR: ...привет от компилятора пока остаётся...
 printf("hello world\n");
}
# helloworld.cpp указывать явно уже не нужно - база-программа в курсе, что добавилось такое "окно"-файл для работы с ней
sdcc helloworld.bin++

# search request resolved
# 1 неустранённая ошибка

#search printf
//~RESULT:
//#import "stdio.h"
// proto: printf(const char *, ...)
// desc: print a formatted string
// more info:
//#man "stdio.h"::printf

insert void main(void)
{
 //~ERR: ...привет от компилятора пока остаётся...
 printf("hello world\n");
}

Как нам подсказали, так и делаем:

#import "stdio.h"

insert void main(void)
{
 //~ERR: ...привет от компилятора пока остаётся...
 printf("hello world\n");
}
sdcc helloworld.bin++

# import request resolved
# успех!

// компилятор импортнул нужную библиотеку и оставил нам памятку для удобства, можно стереть
//~INFO:
// imported "stdio.h"
// инклудить в helloworld.cpp ничего уже не надо, т. к. всё, что нужно, уже занесено в helloworld.bin++

// функция вставилась, её дальнейшая редактура здесь будет, очевидно, уже обозначать апдейт -
// и компилятор, опять-таки для нашего удобства, делает эту замену
update void main(void)
{
 // комментарий по ошибке от компилятора отсюда стёрся, ибо уже не нужен
 printf("hello world\n");
}

С helloworld.cpp закончили, держать его дальше в рабочем пространстве нет смысла...

#dismiss_viewfile . // пишем инструкцию, чтобы компилятор удалил текущий (".") файл-"окно"
//~INFO:
// imported "stdio.h"
// инклудить в helloworld.cpp ничего уже не надо, т. к. всё, что нужно, уже занесено в helloworld.bin++

update void main(void)
{
 printf("hello world\n");
}
sdcc helloworld.bin++

# helloworld.cpp dismissed
# успех!
Подождите, у нас появились какие-то новые планы на функцию main. Хотим её обратно!

// helloworld.cpp - создаём заново

// функция main...
#checkout main
// неосилятор Зефик досюда опять не дочитает
# helloworld.cpp снова нужно указать, т. к. мы только что его выкидывали из пространства
sdcc helloworld.bin++ helloworld.cpp

# checkout request resolved
# успех!

// функция main...
// (компилятор вставил код main вместо #checkout main)
update void main(void)
{
 printf("hello world\n");
}
// неосилятор Зефик досюда опять не дочитает

Вот как-нибудь примерно так оно и может работать.


#1
19:53, 24 мар. 2019

Sbtrn. Devil
> // неосилятор Зефик досюда опять не дочитает
Наивный, никто вообще не будет читать твою простыню, это работает не как "читал-читал не осилил", а как - "какая-то простыня, автор поехавший если думает что это говно кто-то будет читать, закрыть".

#2
20:06, 24 мар. 2019

Я то думал что Девил наконец затронет такую болезненную для меня тему. Поднимет вопрос о том, что низкоуровневое представление намертво прибито к синтаксису.
Но нет, все с точностью наоборот...

#3
20:06, 24 мар. 2019

Sbtrn. Devil
Что сказать то хотел?

#4
22:16, 24 мар. 2019

Идея интересная, но интерфейс общения выглядит неудобно. Все эти #search printf набирать и потом читать что там за комментарии сгенерились.
Логично что это можно в IDE обернуть, но тогда может и описывать стоит сессию общения с IDE, зачем к консольному интерфейсу привязываться. Хотя с точки зрения донесения идеи - да, в таком виде понятнее что происходит.

Но вот как должен правильный GUI в этом случае выглядеть - неочевидно. Во всяких IDE для ПЛК ведь есть что-то похожее - общего текста программы нет, вместо него внутреннее представление, а текст процедуры открывается когда мы кликаем по блоку. Ну да, ограничено одной процедурой. Но что-то я не уверен что с одним файлом будет удобнее.

#5
0:56, 25 мар. 2019

SuperInoy
> Наивный, никто вообще не будет читать твою простыню
Но ты-то дочитал. Каким местом, это отдельный вопрос, но факт-то налицо.

Жора Монтировка
> Что сказать то хотел?
А ты что услышать-то хотел?

Great V.
> однимет вопрос о том, что низкоуровневое представление намертво прибито к
> синтаксису.
> Но нет, все с точностью наоборот...
А что наоборот-то?

kipar
> Все эти #search printf набирать и потом читать что там за комментарии
> сгенерились.
> Логично что это можно в IDE обернуть, но тогда может и описывать стоит сессию
> общения с IDE, зачем к консольному интерфейсу привязываться.
Проблема ИДЕ в том, что ИДЕ слишком толстые, а настройки, которые им нужно накрутить для полноты возможностей, слишком индивидуальные и слишком нетривиально разбросаны по гую. Если нам хочется, чтобы исходник имел хоть какую-нибудь кросс-ИДЕшную портабельность, на гуй и ИДЕ закладываться нельзя. А если не на них - то только текстовый интерфейс. И почему бы, раз уж подвернулся случай, не сделать его "инлайновым"?
Превращение исходника в этакий "терминал" имеет все силы и слабости командной строки. С одной стороны, да, самые базовые команды придётся заучить. С другой стороны - командами можно быстро решить задачи, которые через гуй решаются долго. С третьей стороны - поскольку команды инлайнятся в исходник, у них, в отличие от отдельной командной строки, имеется место, контекст и состояние. А из этого можно раскрутить хороший профит - хотя бы контекстные подсказки, как минимум.

Один из юзкейсов, который меня давно вводит в уныние - документационные комментарии. Если класс или интерфейс с кучей методов хорошо документирован, то его исходник становится нечитаемым - одна декларация на страницу, остальное - куча комментариев. Так и хочется сказать: "Товарищ! Вот тебе документационный комментарий, и скрой его пока, ни к чему, чтобы не болтался на глазах." А потом, если надо, показать его, и желательно там, где он нужен. Текстово-исходниковый интерфейс под такое ложился бы вот прям очень хорошо:

+ Показать

А уж организовать вокруг этой фичи гуй, если вдруг понадобится - это будет уже не вопрос, задача примерно того же уровня, как автосвёртывание блоков.

> Но что-то я не уверен что с одним файлом будет удобнее.
А блокното-редактируемый файл не должен будет быть обязательно один. Юзер может скомандовать развернуть в текстовую форму хоть весь проект, и хоть с какой угодно группировкой объектов по файлам (в пределах возможностей компилятора, само собой), и редактировать каждый себе на здоровье. А когда понадобится - свернуть ненужное обратно.

#6
0:59, 25 мар. 2019

прикольная идея,
я бы наверное даже денег дал,
за такую штуковину у меня в IDE

#7
1:07, 25 мар. 2019

Sbtrn. Devil
> Но ты-то дочитал.
Нет, я просмотрел по диагонали код, не более.

#8
1:41, 25 мар. 2019

Sbtrn. Devil
> А уж организовать вокруг этой фичи гуй, если вдруг понадобится - это будет уже
> не вопрос, задача примерно того же уровня, как автосвёртывание блоков.
Но эта задача и без этого решена. Автосворачивание комментариев длинее одной строки, а когда набираем doSomething жмем ctrl-shift-space (ну или в зависимости от иде) и он в подсказке отображает этот комментарий.

#9
6:13, 25 мар. 2019

kipar
> Автосворачивание комментариев длинее одной строки, а когда набираем doSomething
> жмем ctrl-shift-space (ну или в зависимости от иде) и он в подсказке отображает
> этот комментарий.
Это фигня, а не решения. Заманаешься сворачивать/разворачивать.

Я как-то читал один код, там файл был под 20к строк кода (идея одного заголовка "все включено"(типа STB)).
И все было разбито специальными регионами для удобного сворачивания, плюс поиск и подстветку выделенного тоже никто не отменял... Но я задолбался, и просто взял и вручную порезал на несколько файлов


я тоже считаю что давно пора уйти от plain text кода в более адекватные форматы

#10
7:18, 25 мар. 2019

лол, insert и update.
это получается базовым языком становится sql?! без него программировать нельзя.

вообще иньекции кода, это либо для хакеров, либо для отладки.

#11
9:24, 25 мар. 2019

SuperInoy
> какая-то простыня, автор поехавший если думает что это говно кто-то будет читать, закрыть".
  Даже не так: "опять какая-то простыня от поехавшего автора" и всё.

#12
9:38, 25 мар. 2019

Sbtrn. Devil
Что меня всегда бесит в этих простынях, так это то, что их авторы сами ничего не читают.

#13
12:25, 25 мар. 2019

war_zes
> И все было разбито специальными регионами для удобного сворачивания
Вот, кстати, да - только вспомнил, что в природе существует region/endregion. Это ведь, по сути, уже первые зачатки описанного мной направления. Самые-самые зачатки, но, по крайней мере, наличие идеи уже обозначилось.

skalogryz
> лол, insert и update.
> это получается базовым языком становится sql?!
В каком-то некотором смысле можно и так сказать. Кстати, идея не то чтобы уж совсем инновационная - в древних барсиках команды на редактирование программы были частью барсика, в форте тоже что-то такое было наподобие.

SuperInoy
> Нет, я просмотрел по диагонали код, не более.
Но самый ключевой момент в нём разглядел, тем не менее.

gudleifr
> Что меня всегда бесит в этих простынях, так это то, что их авторы сами ничего
> не читают.
Так начните что-то читать, и Ваши простыни больше не будут Вас бесить.

#14
12:42, 25 мар. 2019

Sbtrn. Devil
> Так начните что-то читать
Убедили. Выложите, пожалуйста, список литературы к этой Вашей простыне.

Страницы: 1 2 3 4 5 Следующая »
ФлеймФорумПрограммирование