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

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

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

Поцоны, это все хорошо, но за такой кодинг денег вам точно не дадут.
А работы - дадут. Так что не выеживайтесь.


#31
19:48, 26 мар. 2019

beejah
> за такой кодинг денег вам точно не дадут.
С кодом но без денег ... бомжевание.

#32
12:45, 27 мар. 2019

gudleifr
> Теперь понятно, откуда взялся нульпост. Ориентация на программиста-идиота явно
> обозначена.
Вот я и говорю, что для понимания нульпоста Вам необходим некоторый квалификационный минимум.

> PROUST (автоматический отладчик для программ на языке Паскаль)
> из сборника "Реальность и прогнозы искусственного интеллекта", М. "Мир" 1987
Попытка блеснуть эрудицией для 1987 года, возможно, и неплоха. Но, увы, не для 2019, когда понятие "статический анализ кода" уже успело обрасти бородой и стать обыденностью. И да, к нульпосту всё это по-прежнему не имеет отношения. Но для понимания этого, напоминаю, необходимо иметь квалификацию, дотягивающую хотя бы до
> программиста-идиота

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

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

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

> Например в MSVS есть возможность сделать SplitView.
Одно дело - сплит-редактор (довольно глупое, кстати: один сплит - минус 50% активной области), а совсем другое дело - если это монолитный текст, редактируемый как единое целое. Навигация с использованием только стрелок, pgup/pgdn, home/end и ctrl-F (даже без мыши) - слишком большое удобство, чтобы им можно было пренебрегать.

> в-третьих: структура файла священа, в качестве отслеживания изменений. Хранение
> изменений пока что выполняется исключительно на уровне измения текста.

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

#33
12:50, 27 мар. 2019

Sbtrn. Devil
> Вот я и говорю, что для понимания нульпоста ... необходим некоторый квалификационный минимум.
Которого у Вас нет.

Sbtrn. Devil
> И да, к нульпосту всё это по-прежнему не имеет отношения.
Да, статья 87-го будет повыше уровнем...

#34
12:55, 27 мар. 2019

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

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

#35
13:02, 27 мар. 2019

kipar
> По-моему его с небольшими костылями все-таки можно совместить с существующими
> системами контроля версий
Вызываем дух Луки Пачоли?

#36
13:52, 27 мар. 2019

kipar
> Переименование да, косяк, системы контроля версий не умеют в перенос процедуры внутри файла.
git умеет, только по дефолту не показывает.

#37
17:04, 27 мар. 2019

Sbtrn. Devil
Smalltalk Image изобретаешь? Пробуй https://pharo.org

#38
(Правка: 17:13) 17:12, 27 мар. 2019

Xunter
> Smalltalk Image изобретаешь?
Нет, просто топикстартер заметил, что в современной С++ программе на долю полезного функционала приходится от 1 до 10%, и решил довести эту долю до честного 0%. И тогда он сможет программировать...

#39
(Правка: 6:58) 6:51, 28 мар. 2019

Sbtrn. Devil
> Вот поэтому и нужен внутренний формат с внутренними идентификаторами. В нём
> можно ничего не менять и ничего не двигать - все манипуляции только в человекоредактируемом представлении.
такой формат, скорее всего не будет человекоредактируемым.
мясные ублюдки очень любят писать, то как им вздумается, что обычно определяется их набором ген, и мерой испорченности.
Когда их заставляешь писать, как-то более дисциплинированно, то они либо начинают ныть, либо изобретают для себя IDE, чтобы за них работали роботы.

Например XML.
Теоретически это человекоредактируемый формат, но на самом деле нет.  (чем больше заложено в XML информации, тем менее человекоориентированным он становится)
Те же дела с JSON-ом.

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

Sbtrn. Devil
> Наконец, кроме редактирования, есть ещё и другие задачи, вроде кодогенерации и
> аннотирования (не в смысле аннотаций к объектам, а в смысле комментариев к
> участкам, которые можно было бы убирать из текста, но где-то в общей базе они
> хранятся, по ним можно искать с учётом контекста редактирования). И тут уже без
> внутреннего формата затруднительно.
мне такое уже предлагали 10 лет назад.

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

Естественно, всё это должно работать, как расширение к некой IDE.
по нажатию одной кнопки, в прямо в исходом файле показывались строки с докумнетацией (как раз "инлайном"), с возможностью непосредственной правки.
(Как вишенка на торт, система должна была определять изменения, хотя бы в интерфейсой части, чтобы находить несоответствия между документацией и кодом)

я б такое сейчас за день бы написал... для паскаля

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

}:+()___ [Smile]
> git умеет, только по дефолту не показывает.
в отдельно ссылке, или теме, можно ли показать как?!
на ранней презентации Линус хвалился, что с дополнительными костылями git можно отследить перенос функции между файлами.
Но даже в его словах слышалась неуверенность.

#40
9:41, 28 мар. 2019

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

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

skalogryz
> Задача была простая - изолировать документацию от исходников.
Курить CWEB Кнута...

#41
(Правка: 13:50) 13:48, 28 мар. 2019

Sbtrn. Devil
> Если он один. Или два. не, больше одного вроде никто не умеет. Да и
> переключаться между окошком и основным текстом - та ещё процедура, в плане
> эргономики.

Ага. Зато у отдельного окошка есть отдельный скролл, а "встроенный" метод будет актуален только если занимает меньше полстраницы текста. Если текст метода больше страницы, то листание страниц аналогично переключению в другой файл или переходу к тексту метода по хоткею. Вся разница что вместо pgup ты жмешь alt-g или ctrl-click.

> Я какое-то время назад выдвигал ещё одну идею - чтобы файлы умели открываться
> не в табах, а прямо инлайном, чтобы их можно было редактировать как часть

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

> хранятся, по ним можно искать с учётом контекста редактирования). И тут уже без
> внутреннего формата затруднительно.

Да в общем тоже нет.

Sbtrn. Devil
> Уровень ИДЕ - это, конечно, хорошо, но ИДЕ-независимость - тоже полезно.

В твоем варианте такая же зависимость - от внешней тулзы, ведь возможность запустить на любом калькуляторе vi и тупо редактировать код - пропадает.

#42
(Правка: 14:53) 14:44, 28 мар. 2019

jaguard
> Я тут еще помнится искал фичу для студии, так до сих пор и жду - интерактивный
> (да хотя бы и не интерактивный для начала) поиск, который результаты сформирует
> на одной странице, с возможностью редактировать прямо там.
Что значит на одной странице? Найденные строчки просто склеенные? А если надо строчкой ниже что-то отредактировать?

Вроде нормально просто в одном окне показывать с возможностью редактирования.

+ Показать

Я так понял, ты хочешь прямо в верхнем окошке-списке редактировать.

#43
14:50, 28 мар. 2019

skalogryz
> в отдельно ссылке, или теме, можно ли показать как?!
Вот тут пишут про это, хотя интерфейс, на мой взгляд, крайне неинтуитивный.

#44
15:09, 28 мар. 2019

entryway
>
> А если надо строчкой ниже что-то отредактировать?

Значит переходим туда обычным способом и редактируем.

entryway
> Я так понял, ты хочешь прямо в верхнем окошке-списке редактировать.

Да.

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