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

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

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

Xunter
> Smalltalk Image изобретаешь? Пробуй https://pharo.org
Так это ж на уровне ИДЕ. А речь о том, что навороты на уровне ИДЕ - это слишком толсто, и лучше не отрываться от текста. Тут, скорее, в сторону попыток Вирта в Оберон ОСе, если примерные аналогии искать.

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

jaguard
> Если текст метода больше страницы, то листание страниц аналогично переключению
> в другой файл или переходу к тексту метода по хоткею.
Ctrl-F - наше всё. :) К тому же, проблема чаще всего возникает как раз тогда, когда методы небольшие, но их сцуко много, и вложенность их вызовов многоуровневая. Вот тут-то бы и уметь выстроить их примерно в порядке вызова, чтобы удобнее было читать сверху вниз. Но... да-с.

> Ну в общем ты согласен, что корень решения - не в том, что ты предлагаешь?
А корень решения всё равно получается таким. Показывай мы хоть в ИДЕ, хоть как - придётся проэкт прекомпилировать в некую индексируемую и семантически размеченную форму. А от исходного представления остаётся только каркас, причём ИДЕ как раз для борьбы с ограничениями этого каркаса и создавалась. Так нужно ли за него цепляться?

> В твоем варианте такая же зависимость - от внешней тулзы, ведь возможность
> запустить на любом калькуляторе vi и тупо редактировать код - пропадает.
А эта тулза будет частью компилятора. И возможность тупо редактировать код как раз останется. Просто мы будем редактировать не сам код непосредственно, а его представление, отражающее нужные нам части в нужной нам комбинации. И это же представление, местами, будет как бы терминалом для ввода команд и ответных сообщений компилятора.

skalogryz
> Естественно, всё это должно работать, как расширение к некой IDE.
> по нажатию одной кнопки, в прямо в исходом файле показывались строки с
> докумнетацией (как раз "инлайном"), с возможностью непосредственной правки.
> (Как вишенка на торт, система должна была определять изменения, хотя бы в
> интерфейсой части, чтобы находить несоответствия между документацией и кодом)
Это был (бы?) хороший шаг вперёд. Трудясь над корпоративным кодом, постоянно ловлю себя на мысли, что чего-то такого не хватает. Но этого мало. :) Документационных пометок к одной сущности может быть много, они могут быть разбросаны по разным контекстам (например, упоминание в каком-то месте, где применяется такая-то сущность, связанного с ней бага или нестандартного поведения), могут иметь между собой свою группировку и перекрёстные ссылки... В общем, постановка задачи не такая простая, как кажется.

gudleifr
> И как-то в теме пропустили тот факт, что есть разные способы борьбы со
> сложностью программ. Со своими разными дисциплинами.
> Топикстартер как начал скрещивать ужа с ежом - быдлоспособ с масштабированием,
> так и пошло перескакивание с одного на другое. А структурное программирование и
> проблемно-ориентированные языки остались за кадром.
Вы забыли сказать, что эти способы и дисциплины остались примерно в конце 70-х-начале 80-х, когда стало ясно, что программы достигли масштабов, на которых они больше не работают. И остались там вместе со структурным программированием и проблемно-ориентированными языками, про которые стало ясно примерно то же и тогда же.


#46
16:40, 28 мар. 2019

Sbtrn. Devil
> Вы забыли сказать, что эти способы и дисциплины остались примерно в конце 70-х-начале 80-х
Ну, это очевидно. Ведь, с тех пор, не появилось ничего нового.
Как увидел я впервые в начале 80-х приведенный Вами в нуль посте анализ "разрешения ссылок" в виде 6-метрового листинга компилятора PL/I...

#47
20:46, 28 мар. 2019

Sbtrn. Devil
> Ctrl-F - наше всё. :) К тому же, проблема чаще всего возникает как раз тогда,

Ctrl-F говно, Find Symbol и go to declaration/definition - гораздо удобнее.
Но там где последние не справляются, ctrl-F помогает, и работает он, внезапно, по всему проекту (ctrl-shift-F или твой любимый хоткей) - т.е. никакой разницы, в этом же он файле или в другом.

> когда методы небольшие, но их сцуко много, и вложенность их вызовов
> многоуровневая. Вот тут-то бы и уметь выстроить их примерно в порядке вызова,
> чтобы удобнее было читать сверху вниз. Но... да-с.

Ну тут очевидный вопрос - как бы их быстро так выстроить с помощью твоей технологии? Я тебе на это уже на протяжении не одного поста намекаю. Потому что сейчас у тебя есть механизм закладок, например (Ctrl-k-k в VS). Тебе ведь придется неоднократно такие выстраивания делать, и тут важно быстро собирать и разбирать эти самые модели.

> А эта тулза будет частью компилятора. И возможность тупо редактировать код как

Предлагаю уже остановиться в мечтах в каком-то разумном месте. Не будет она никогда частью никакого стандартного компилятора типа GCC. А значит в сферическом линуксе в вакууме ты сможешь спокойно удаленно запустить vi, но со своим лапшакодом сделать не сможешь вообще ничего.

#48
(Правка: 21:03) 21:01, 28 мар. 2019

Sbtrn. Devil
Не, там именно формат исходника такая БД, Strongtalk такой же был, и Squeak тоже
https://youtu.be/mIIGj_riZGE?t=135
Вопрос как такое мержить конечно не ясен

#49
(Правка: 12:31) 12:30, 29 мар. 2019

gudleifr
> Ну, это очевидно. Ведь, с тех пор, не появилось ничего нового.
Потому что стало ясно, что пытаться решать эти вопросы способами и дисциплинами - тупиковый путь и наукообразная алхимия. Софт в процессе жизненного цикла, внезапно, оказался несколько отличным от библиотек и архивов.

Xunter
> Не, там именно формат исходника такая БД, Strongtalk такой же был, и Squeak
> тоже
Ну формат - это пол-дела. Вторая половина фишки - это использование вместо гуя промежуточных текстовых файлов, как человекоредактируемых исходников, и по совместительству как интерфейса по продвинутым манипуляциям этими же файлами.

jaguard
> Ну тут очевидный вопрос - как бы их быстро так выстроить с помощью твоей
> технологии? Я тебе на это уже на протяжении не одного поста намекаю.
А очень просто их выстроить. У нас есть человекоредактируемый файл-преставление, с которым мы работаем (пусть он называется, допустим, helloworld.cppp, или даже helloworld.view.cppp, чтобы подчеркнуть, что это не исходник как таковой, а только представление). Допустим, у нас там:

void main ()
{
 method1 ();
}

Дописываем в нужное нам место специальную команду:

#pull_here method1

void main ()
{
 method1 ();
}

Пускаем компилятор. Он, кроме всего прочего, редактирует нам этот файл-представление и делает так:

void method1 ()
{
 printf ("Hello, world\n");
}

void main ()
{
 method1 ();
}
Переоткрываем этот файл в блокноте (если блокнот сам не умеет рефрешить) и работаем дальше.

Естественно, написать можно и много команд за один раз:

#pull_here method1
#pull_here printf
#pull_here putc { prototype }
#pull_here exit { doc_comment }

void main ()
{
 method1 ();
}

#50
12:48, 29 мар. 2019

Sbtrn. Devil
> Софт в процессе жизненного цикла, внезапно, оказался несколько отличным от
> библиотек и архивов.
Отнес в перлы.

#51
(Правка: 13:07) 13:00, 29 мар. 2019

Подобные идеи бродят и у разработчиков компиляторов
Ссылка на ютуб

#52
13:42, 29 мар. 2019

Parfen Rogozhin
там нигде нет стрелочки назад от внутреннего представления к исходному тексту. Так что это все таки другие, менее кардинальные идеи.

#53
17:27, 29 мар. 2019

kipar
Дядька говорит про то, что семантическое представление должно быть первичным, а способ его хранения(текст, база данных) это уже детали. То про что ТС и писал. А если есть апи компилятора для полной работы с семантикой, то реализовать тулзу, которую хочет ТС, дело техники.

#54
17:55, 29 мар. 2019

Всем привет, немного выскажу своего мнения:
Я долго страдал от перегруза мозга во время программирования(после программирования мозг становится ватным.. сильно...).
Искал решения, читал всякие книжки типа "программист прагматик", Мартин Р. - Чистый код. , code_simplicity  и тд.
Так вот проблемма исходного кода — это проблемма восприятия, мозг слишком мал чтобы вообразить большую программу целиком, поэтому и придумали всякие ООП, модульное программирование, куча файлов и тд.
Решение которое я использую для себя оно очень простое — это блок-схемы.
Правда с оговорками я не строю блок - схему для всего исходного кода, а только для ключевых моментов.
Я бы хотел программировать на блюпринтах, но сейчас блюпринты имеют очень ограниченый функционал.
Думаю будущее за языком программирования, который развит идею блюпринтов до нормальной работы.

#55
(Правка: 18:01) 18:00, 29 мар. 2019

AizbegtGames
> Так вот проблемма исходного кода — это проблемма восприятия, мозг слишком мал чтобы вообразить большую программу целиком,

Это было проблемой 50 лет назад. Сейчас - это основное преимущество профессии. Гигатонны документооборота и полная невозможность найти крайнего.

AizbegtGames
> поэтому и придумали всякие ООП, модульное программирование, куча файлов и тд.

Как за 500 лет до этого - двойную бухгалтерию.

#56
20:28, 29 мар. 2019

gudleifr шарит.

#57
14:44, 30 мар. 2019

AizbegtGames
> Так вот проблемма исходного кода — это проблемма восприятия, мозг слишком мал
> чтобы вообразить большую программу целиком, поэтому и придумали
Именно!

gudleifr
> Отнес в перлы.
Отнесите. Пусть в вашей библиотеке будут хоть какие-нибудь умные и актуальные буквы. А пока будете нести, задумайтесь, почему сегодня все научно-компьютерные журналы, статьи и т. п. - об алгоритмах, подходах, задачах, моделях и т. д. - и ни одной про усовершенствование собственно процесса программирования и сопровождения программ. А вопросов процесса программирования касаются только книжки вида "руководство для мартышек". Которые состоят из:
- на 50% состоят из чисто эмпирических банальностей (ака "паттерны"),
- на 25% - из перепечаток замшелых заблуждений типа "всячески избегайте оператора goto!",
- на 12.5% - из банальностей совсем уж неприличных (вроде "начните с постановки задачи") и откровенных благоглупостей ("любая программа начинается с ч0ткого ТЗ"),
- на остальное - из оглавления, списка литературы и ритуальных благодарностей легендарным личностям.
Ибо компьютерная наука давно расписалась в своём бессилии перед процессом разработки. Последний раз, когда она пыталась заниматься этим вопросом - видимо, Кнут с его "литератным программированием" (и то неизвестно, сколько там уже оставалось от науки), и результаты всем известны. (Что там из зала говорят? Известны мало кому? Ну да, именно об этом я и говорю.) И это было закономерно, потому что разработка - это не о машинах тьюринга, а о занимающемся ею человеке, который слаб и иррационален, и желает удобства и понимания. Умные учёные это поняли и ещё в 80-х свалили в изобретение алгоритмов и абстракций. А "научность программирования", "математическая доказуемость" и прочие химеры заняли подобающее им место рядом с флогистоном, самозарождением мышей в грязи, философским камнем и прочими заблуждениями прошлого.

#58
15:27, 30 мар. 2019

Sbtrn. Devil
> задумайтесь, почему сегодня все научно-компьютерные журналы, статьи и т. п. -
> об...
> на остальное - из оглавления, списка литературы и ритуальных благодарностей
> легендарным личностям.
Покупая книгу сейчас, я плачу деньги за обещание стать программистом за 21 день. Содержание не важно в принципе.

#59
16:54, 30 мар. 2019

Sbtrn. Devil
> почему сегодня все научно-компьютерные журналы, статьи и т. п. - об алгоритмах, подходах, задачах, моделях и т. д.

Именно потому:
gudleifr
> Это ["поиски серябряной пули"] было проблемой 50 лет назад. Сейчас - это основное преимущество профессии.
> Гигатонны документооборота и полная невозможность найти крайнего.

Sbtrn. Devil
> Ибо компьютерная наука давно расписалась в своём бессилии перед процессом разработки.
Да. Но это не повод раскапывать фигню 50-летней давности, чтобы выдать ее за "инновацию".

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