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

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

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

Sbtrn. Devil
> в древних барсиках команды на редактирование программы были частью барсика
не уверен насчёт команд insert/update, но точно помню, что "первые" бейсики требовали нумерацию строк.
Если во время правки указывался номер, который уже существует, то строка заменялась на новую.
А иначе строка вставлялась в соответствии с её номером

от сюда пошла мода исползовать 10-й отступ между строк.

10 print "hello";
20 print "world";
30 goto 10
Потому что простого способа "сдвигать" строки, в бейскиках предусмотрено не было.
А значит приходилось оставлять "запас" чтобы можно было впихнуть что-нить "между строк".

Зачем к такой жести возвращаться?
(даже если мы не говорим о построчном редактировании, но редакторивании отдельных единиц кода - функций/методов/объявлений)

+ Показать

За исходные файлы - более менее адекватными, мне кажутся модули паскаля.
Потому что они разбиты секции интерфейса и реализации.
Что даёт мне возмжность, как разработичку, более простой способ восприятя того как модуль должен использоваться.
Т.к внешняя часть записана отдельно.

Набор h/c или hpp/cpp не является идентичным, потому что в хедерах, тоже можно каши наворотить.

Да, это идёт с некоторым дублированием, что какую-нить функцию нужно описывать дважды.
Да, в interface-ной части приходится писать "private" секции класов.

Но в итоге с кодом работать проще, чем с бесконечными мешаниниами методов и объявления, как C-подобных языках (C,С++, C# ,Java,JS, PHP ну и т.д.)


#16
17:21, 25 мар. 2019

Sbtrn. Devil
Идея бесполезная, но забавная с точки зрения левой резьбы. Предлагаю скачать из инторнетов парсер сишки (без крестов) и, собственно, запилить.

#17
(Правка: 19:58) 19:58, 25 мар. 2019

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

#18
20:31, 25 мар. 2019

Вот это вода. Простыни. Прямо лев, не побоюсь, толстой.
А я заархивирую всю эту воду в ОДНУ строку.
Смотрите. Барабаны, хоп:

А хорошо бы, чтоб компилятор сам исправлял ошибки кода.

#19
22:10, 25 мар. 2019

122
> А хорошо бы, чтоб компилятор сам исправлял ошибки кода.
Благодарен.

#20
8:54, 26 мар. 2019

122
> А хорошо бы, чтоб компилятор сам исправлял ошибки кода.
Он не может, т. к. в коде ошибок не существует.

#21
12:10, 26 мар. 2019

gudleifr
> Убедили. Выложите, пожалуйста, список литературы к этой Вашей простыне.
[1] Paul McFedries - The Complete Idiot's Guide to Using Your Computer - for Seniors
[2] Clayton Walnum - The Complete Idiot's Guide to Programming Basics
[3] А.Зарецкий, А.Труханов, М.Зарецкая - Энциклопедия профессора Фортрана
[4] Симонович С.В., Евсеев Г.А. - Занимательное программирование на Visual Basic: Книга для детей, родителей и учителей

Есть и ещё более продвинутая литература, но Вам лучше начать с этой.

jaguard
> Видно что очень хотелось, но причину для использования такого подхода у тебя
> придумать все-таки не получилось. Натянутый на яйца кота пример тому
> свидетельством.
А с чего ты взял, что у меня не получилось придумать, а не у тебя не получилось понять приведённого примера? :) Речь-то не столько о компиляторе, сколько о человеке, сидящем за редактором. Приходилось разгребать код из 15+ методов, из которых на экране одновременно помещается в среднем один? Погляди исходники жабных классов, например. А между тем, за счёт одного только форматирования и перестановки деклараций один и тот же код можно представить кучей способов, каждый из который удобнее в каком-то контексте. Например, интересующий нас метод А вызывает методы Б и Ц, разбросанные по разным концам файла. Хорошо бы их на время разбирательства и редактирования передвинуть их все рядом друг к другу и рассматривать как цельный кусок текста. Но нет. Структура исходника священна. Сказано "в разных концах" - значит, в разных концах.

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

> Редактировать текст, через командный интерфейс это чуть-чуть зашквар.
> И по-этому сад текстовых редакторов буйно расцветал на заре unix систем (vim-ы
> и emacs-ы)
Так текстовый редактор-то никуда не девается. Просто некоторые части текста смогут пониматься как команды для его же, текста, продвинутого редактирования.

> Да, это идёт с некоторым дублированием, что какую-нить функцию нужно описывать
> дважды.
> Да, в interface-ной части приходится писать "private" секции класов.
> Но в итоге с кодом работать проще, чем с бесконечными мешаниниами методов и
> объявления, как C-подобных языках
Это до тех пор, пока мы рассматриваем модуль снаружи и не начинаем применять по существу. А едва начинаем...
А между тем, такой проблемы, как "какая структура файлов лучше", даже возникать не должно. Почему нельзя взять файл, и не отходя от кассы, скомпоновать его в любой структуре, которая нужна и удобна вот прямо щас? Почему нельзя подтянуть на одну страницу с полуторастрочным методом X::a полуторастрочный метод Y::b, который из него вызвается и сейчас будет редактироваться вместе с ним, и прототип с док-комментарием к методу Z::c, который тоже из них вызывается? А потому что не положено.

122
> Смотрите. Барабаны, хоп:
и мимо. Стоило бы всё-таки прочитать.

Faceroll
> Идея бесполезная, но забавная с точки зрения левой резьбы. Предлагаю скачать из
> инторнетов парсер сишки (без крестов) и, собственно, запилить.
Тут, к сожалению, "просто к сишке" не прикрутишь. Придётся перерабатывать язык, потому что несколько более другая семантика, требующая несколько более другой структуры операторов.

#22
12:36, 26 мар. 2019

Sbtrn. Devil
> литература
Теперь понятно, откуда взялся нульпост. Ориентация на программиста-идиота явно обозначена.

Коллега прав:
122
> А хорошо бы, чтоб компилятор сам исправлял ошибки кода.

#23
(Правка: 13:57) 13:49, 26 мар. 2019

Sbtrn. Devil
Интересно.
У меня была чем-то похожая идея запилить язык типа ATS с интерактивным пруф-ассистентом.
Сначала декларируешь то, что хочется получит в итоге (на высокоуровневом подмножестве языка).
Потом реализуешь на низкоуровневом подмножестве, с помощью пруф-ассистента, параллельно доказывая корректность соответствие желаемому.

kipar
> Но вот как должен правильный GUI в этом случае выглядеть - неочевидно.
В моем случае где-то так:
(слева код программы, справа поточные "цели" модуля, подсказки ассистента и консоль)
Изображение

#24
14:30, 26 мар. 2019

Ну, раз топикстартер тормознул с литературой, подкину статейку:

У. Льюис Джонсон, Эллиот Солоуэй
PROUST (автоматический отладчик для программ на языке Паскаль)

из сборника "Реальность и прогнозы искусственного интеллекта", М. "Мир" 1987

#25
14:49, 26 мар. 2019

Sbtrn. Devil
> Например, интересующий нас метод А вызывает методы Б и Ц, разбросанные по
> разным концам файла. Хорошо бы их на время разбирательства и редактирования
> передвинуть их все рядом друг к другу и рассматривать как цельный кусок текста.
> Но нет

Вот теперь ты правильные вещи говоришь. Хорошо. Только решение для этой проблемы - это исключительно уровень ИДЕ. И некоторые даже умеют открывать посередине исходника окошко с текстом метода для инплейс редактирования. Не помню только, в xcode я это видел, или в студии..

Как дополнительный удобный функционал (он будет нужен где-то 5% времени, но весьма полезен все-равно) - это вполне себе одобрямс.
Я тут еще помнится искал фичу для студии, так до сих пор и жду - интерактивный (да хотя бы и не интерактивный для начала) поиск, который результаты сформирует на одной странице, с возможностью редактировать прямо там. Т.е. такой grep для текста всего проекта c редактированием. В Visual Assist есть похожая штука, но только либо для методов текущего файла, либо для символов в проекте. Невероятно полезно, но вот того что я хочу все-равно не хватает.

Но свой отдельный внутренний формат все-равно не нужен.

#26
15:14, 26 мар. 2019

Sbtrn. Devil
> Например, интересующий нас метод А вызывает методы Б и Ц, разбросанные по
> разным концам файла. Хорошо бы их на время разбирательства и редактирования
> передвинуть их все рядом друг к другу и рассматривать как цельный кусок текста.
> Но нет. Структура исходника священна.
Ну, эту-то проблему местный бомонд точно победить не способен - https://gamedev.ru/flame/forum/?id=236791

#27
(Правка: 16:18) 16:17, 26 мар. 2019

jaguard
+1
> Но свой отдельный внутренний формат все-равно не нужен.
Более того, исходный файл, на конкретном языке программирования уже сам по себе является БД для кода на этом самом языка программирования.
(т.е. распарсив исходник, можно получить список объявленных/описанных в языке сущностей)

Sbtrn. Devil
> Например, интересующий нас метод А вызывает методы Б и Ц, разбросанные по
> разным концам
> Но нет. Структура исходника священна. Сказано "в разных концах" - значит, в разных концах.
> ...
> Почему нельзя подтянуть на одну страницу с полуторастрочным методом X::a
> полуторастрочный метод Y::b, который из него вызвается и сейчас будет
> редактироваться вместе с ним, и прототип с док-комментарием к методу Z::c,
> который тоже из них вызывается? А потому что не положено.
> и прототип с док-комментарием к методу Z::c, который тоже из них вызывается? А потому что не положено.

во-первых, ничего плохого, чтобы "смотреть" несколько методов рядом нет.

+ Позволяет ли твоя текущая IDE это делать или нет, это уже другой вопрос

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

#28
17:50, 26 мар. 2019

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

#29
(Правка: 18:22) 18:11, 26 мар. 2019

kipar
> В момент коммита можно автоматизированно генерить исходники с детерминированным
> расположением (скажем с функциями отсортированными по имени).

а переименование функций запретить?
(переименование может привести к тому, что функция целиком переедет в другое место файла, теряя построчную историю изменений)

Приведу в пример опять SQL.
там есть хранимые процедуры, функции, представления (view).
Для них можно получить код в любой момент, в любой комбинации.
Причём закриптовано (а что означает, что изменения можно внести сразу же после изменений):

create ProcName
alter ProcName
drop ProcName
create ProcName
И хранятся они, как раз в физической бд.

Т.е. можно в один файл получить N кол-во кода и смотреть, и работать как нравится.
Правда при таком подходе проблемы возникают с использованием сторонних компонентов... их почти нет.

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