Pull to refresh

Comments 123

есть замечательный посыл — «если критикуешь, предложи альтернативу». потрындели-потрындели, и что?
А там вначале есть ссылка — Kythe. Это ещё не «оно самое», но хотя бы шаг в направлении. Мне интересно мнение людей о нём.
Labview, Matlab/Simulink, SPW (или помер за давностью лет?). Срочно переучиваемся!
Как активный разработчик на LabVIEW (больше пятнадцати лет) могу сказать, что визуальное программирование — это удобно в том смысле, что я прямо в код могу вставить любую картинку с пояснениями. Если я пишу модуль общения с железкой, у меня прямо в коде кусок документации с протоколом, если это математика — то я могу вставить формулу прямо в код, если где-то нетривиальная геометрия — то тут само собой поясняющая картинка. Даже анимированную гифку могу вставить — если в коде бага, то по экрану весело ползает жучок и всё такое.

Но есть и пара ложек дёгтя — файлы исходников двоичные со всеми вытекающими. Мы ещё пользуемся MS Source Safe, размер репозитория — больше двадцати гигабайт. Чекаут эксклюзивный — есля я работаю с файлом, то коллега с ним работать уже не может. Diff и merge имеются, но это сторонные инструменты, их можно интегрировать в систему контроля версий, но я б не сказал что пользоваться удобно, diff используется редко, а merge и того реже. Стандарта «языка» нет как такового, тут NI правит бал, впрочем они в каждой версии расширяют язык по запросам пользователей, но альтернатив никаких нет. Про поддержку юникода я просто умолчу. Ну и стоимость средств разработка какая-то ненормальная. В очень долгосрочной перспективе я верю, что за визуальными средствами будущее, но это очень далёкое будущее. Сначала должен появиться стандарт, долны появиться открытые средства или альтернативы, система контроля должна нативно поддерживать форматы исходников, ну а там всё остальное «приложится». Пока что всё это «эзотерика», если можно так выразиться.
Есть еще литературное программирование, где в описании программы доступна любая TeXовская разметка. При этом все языконезависимо.
Читал этот поток сознания и думал, что вы что-то хотите предложить. Но нет.
А вообще, самое главное в коде это его читабельность другими людьми и самим собой через месяц. Ну, кроме эффективности и правильной работы :)
Хотя, конечно, немаловажны системы сборки и IDE.
Аннотация в Java, как и декораторы в Python, аттрибуты в C#, комментарии к методам в любом языке и т.д. — должны быть метаданными


Python-декораторы здесь не в тему
Почему? Сами по себе, они, конечно, код. Но способ их связи с другим кодом — это метаданные.

На самом деле нет.
Вызов через @ это просто синтасический сахар для выражения вида:


def fn(x):
    return x*2
fn = convert(fn)
Вот интересно, а чем плохи аннотации как метаданные? И какой иной механизм расстановки метаданных вы предлагаете? (надеюсь не xml?)
опять ты выходишь на связь? на одном узко известном в широких кругах форуме тебе уже всё пояснили и теперь ты сюда принёс?
опять же, давай по частям разберём
инструментам, которыми должны строится звездолёты

например каким?
Программисты его выбирают для своего проекта, стараются соблюдать (тратят время на это),

как много потратится время на нажатие твоего любимого хоткея в IDE для выправления кодстайла? меньше секунды на нажатие alt+shift+f
Представьте себе идеальный мир, где код хранится в бинарном файле, в виде связного набора сущностей, обозначающих классы, методы, циклы, переменные, условия.

и тут мы пришли к уже существующим .obj или .coff или .class файлам
Но «вшитие» их в код — это как каждую понравившуюся картинку сразу выбивать себе на груди татуировкой. Слишком кардинально, слишком большие последствия.

это уже сделано и прекрасно работает
Насколько хороши в ней ваши любимые grep и find? А функционал вроде Find References? А средства рефакторинга? Текст — медленная и неуклюжая штука. Каждый, кто хочет быстро им оперировать — вынужден строить какие индексы. Эти индексы долго строятся, живут отдельно от самого кода, переизобретаются каждым инструментом. Мы сами создали себе проблему, которую пытаемся героически решить.

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

особенно клёво когда компилируется прямо во время написания кода, как в java ide, что некисло так добавляет тормозов
опять же, нормальные проекты гоняют тесты после компиляции кода, ты предлагаешь прямо во время работы программиста тестировать код? бро, не у всех рабочая машина i7 на 16 ядер и 32гб оперативки
А вот если бы код был кодом, и там кодом (с функциями, параметрами, циклами, условиями) и тут тоже кодом, то между ними можно было бы пробрасывать мостики, а затем по этим мостикам удобно ходить.

ну так с этого и надо было начинать, надо было сразу написать, что ты не хочешь учиться программировать на том, что деды писали, а сраху хочешь свой новый ещё один общий для всех язык программирования!
ну так сядь и напиши его, что ты как не этот?! компилятор реализуй, хотябы для двух основных платформ — x86, arm, если взлетит — сообщество само допишет тебе для других архитектур. IDE не забудь, с дебагером который может дебагать даже небо даже б-га.
Ах да, ещё не забудь сделать новую VCS чтобы удобно версионировать бинарные файлы с кодом
на одном узко известном в широких кругах форуме тебе уже всё пояснили и теперь ты сюда принёс?

А что за форум?
за упоминание этого форума тут забанить могут
Ну в личном сообщении напишите:)
на одном узко известном в широких кругах форуме тебе уже всё пояснили и теперь ты сюда принёс?

Что кому где, простите, объяснили?
извините, видимо это были не вы
просто на одном форуме пару недель назад один анонимус уже предлагал уйти от кода в виде декста и перейти на что-то новое, да хоть те-же картиночки
> как много потратится время на нажатие твоего любимого хоткея в IDE для выправления кодстайла? меньше секунды на нажатие alt+shift+f

Дело не во времени, а в удобочитаемости и привычке. При смене места работы/команды/проекта приходится придерживаться нового стиля, это раздражает и добавляет проблем в виде разногласий с другими членами команды и ухудшению продуктивности.

> и тут мы пришли к уже существующим .obj или .coff или .class файлам

Это все же про другое, некий промежуточный универсальный язык, байткод. Если я правильно понимаю автора, то речь идет о возможности хранения кода, например С/С++, в виде синтаксического дерева в некоторой БД. Каждый программист может сам выбирать правила форматирования отображаемого кода. Многие уже сейчас строят костыли в виде скриптов, которые переформатируют код перед каждым коммитом/пушем в git.

> это уже сделано и прекрасно работает

Что работает? Аннотации в Java? Работают, но это не значит, что можно сделать лучше.

> всё уже давно сделано и изобретено, у всякой уважаемой себя ide есть вот это всё

А если конкретно в моей нет или оно страшно глючное? Кстати в альтернативных IDE — немногим лучше.

> особенно клёво когда компилируется прямо во время написания кода

Ну вот clang например каждый раз парсит DSL для каждого отдельного файла, подтягивая всю цепочку импортировнных заголовков. Как по мне — это пустая трата ресурсов.

Удивляет, что такой консервативный комментарий набирает столько плюсов.
:: При смене места работы/команды/проекта приходится придерживаться нового стиля, это раздражает и добавляет проблем

Если это раздражает то надо не среду менять, а таблетки. И учиться постоянно. Мне лично вообще неважен стиль. Главное чтобы было единообразно. Главное код, а не пробел там или табуляция. Имхо
А вы, простите, какие таблетки принимаете?

Разным людям нравится разное форматирование кода (а еще — разные инструменты/IDE/ОС/ноутбуки).
Банально — непривычно форматированный код читать сложнее, уходит время, чтоб натренировать глаз. Новонабранная команда будет неделю холиварить по поводу табов/пробелов в новом проекте. Это все не выдумки, а реальные проблемы.
Почему бы не дать возможность сделать форматирование индивидуальным, как цветовую схему редактора?
Нравится и мешает работать — принципиально разные вещи.

Почему бы не дать? Можно, конечно. Только вот эта «статья» тут вообще ни при чём. Поток сознания «на тему». Напомнило мне из Гоголя «Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича — я бы тогда тотчас же решилась. А теперь поди подумай!»
Так ведь мешает же, не самая главная проблема, но она есть.
это раздражает и добавляет проблем в виде разногласий с другими членами команды и ухудшению продуктивности

ну не знаю, если честно, я работал в нескольких конторах с разным кодстайлом. Абсолютно не заметил разницы если честно, просто сразу предоставляется настройка кодстайла для местной ide и всё, дальше всё форматируется хоткеями
Это все же про другое, некий промежуточный универсальный язык, байткод. Если я правильно понимаю автора, то речь идет о возможности хранения кода, например С/С++, в виде синтаксического дерева в некоторой БД

ну, возможно я что-то не так понял. Я понял так, что автор хочет хранить код в промежуточном виде, а отображать как душенька пожелает. Те же самые байткоды джавы и c# почти прямо отображаются в исходный код
Многие уже сейчас строят костыли в виде скриптов, которые переформатируют код перед каждым коммитом/пушем в git.

и это правильно, я считаю. Я уже сталкивался с тем, что форматирование кем-то кода не так как у всех очень большой diff даёт.
Что работает? Аннотации в Java? Работают, но это не значит, что можно сделать лучше.

конечно можно, но пока никто не сделал, если у автора взлетит — респект ему
А если конкретно в моей нет или оно страшно глючное? Кстати в альтернативных IDE — немногим лучше.

а что за ide, если не секрет?
Ну вот clang например каждый раз парсит DSL для каждого отдельного файла, подтягивая всю цепочку импортировнных заголовков. Как по мне — это пустая трата ресурсов.

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

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

ну, возможно я что-то не так понял. Я понял так, что автор хочет хранить код в промежуточном виде, а отображать как душенька пожелает.

Ну это он уже немного ушел от основной идеи — хранение обычного кода на обычном ЯП в подобии AST. Как один из профитов — получаем отделение форматирования от кода. Но так как ООП языки имеют много общих парадигм, то, следовательно, одно и то же AST можно было бы транслировать (не без ограничений конечно) в разные языки.

а что за ide, если не секрет?

В мире разработки под iOS их всего две — Xcode от Apple и AppCode от Jetbrains. Первый не умеет нормальный рефакторинг, кроме самых базовых вещей, и то — очень глючно. Во втором есть мощный рефакторинг, анализатор и много чего еще, но индексирование занимает вечность.

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

Это умеет сам компилятор (например GCC). Но при сборке «начисто» все прекомпилированные заголовки создаются заново. Кроме того приходится ручками составлять .pch файл с библиотечными заголовками, чтобы ускорить компиляцию. Все это выглядит как большой костыль, чем он по сути и является.
Так AppCode же вроде недавно выпустили и он тупо ещё сырой? Idea для java глючит очень мало где (в стандартных юзкейсах — глюки это вообще редкость).

PS и да, в Java, благодаря несколько иному процессу компиляции и отсутствию шаблонов (или как там эти куски динамического кода #define называются) парсинг подключённых библиотек происходит крайне быстро… по сути не-системные библиотеки больше сказываются на размере поставляемого файла, чем на времени компиляции… Имхо в плюсах этого подхода очень нехватает… с другой стороны там и удобного для этих целей байткода нет…
The first public preview version of AppCode became available in April 2011. 5 лет уже какбэ. Релиз 1.0 вроде в сентябре 2011 был.
С IDEA не сталкивался, но вроде многие её так же ругают за ресурсоемкость.
и тут мы пришли к уже существующим .obj или .coff или .class файлам

Эти файлы в принципе не являются представлением исходного кода, они не предназначены для их просмотра и изменения человеком.
особенно клёво когда компилируется прямо во время написания кода, как в java ide, что некисло так добавляет тормозов

Если компиляция на заднем плане добавляет тормозов редактированию текста на переднем плане — то это неправильное понимание многозадачности авторами IDE.

В мою бытность студентом на одной машине под RSX-11M одновременно десяток студентов редактировали и компилировали свои программы с терминалов. Машина однопроцессорная. Компиляция даже небольшой программы занимала минуты. Если одновременно компилировалось несколько программ — то значительно дольше. Но это нисколько не мешало остальным студентам редактировать свои программы, потому что процесс редактора имел более высокий приоритет, чем процесс компилятора. Только и всего. Реакции на действия человека надо дать более высокий приоритет, чем компиляции на заднем плане.
UFO just landed and posted this here
Автор предлагает не картинки, а двоичное представление — аналог «распарсенного абстрактного синтаксического дерева» сохранённого в двоичном представлении.
UFO just landed and posted this here
Так доколе?
До последнего патрона.

Программы пишутся не только (и не столько) для компьютеров, но и для программистов. И писать их нужно так, чтобы их мог читать, понимать и изменять человек, а не машина. А тут предлагается ради упрощения парсеров и улучшения подсказок (которыми не пользуется процентов 30-40 разработчиков на низкоуровневых языках) сломать последовательно и редакторы, и компиляторы, и системы контроля версий, и вообще практически все наработки вокруг программирования за последние 50 лет ради того, чтобы разработчикам утилит было проще жить. Бинарные логи systemd и реестр Windows — теперь у вас в IDE, ура!
Пока не придуман прямой интерфейс мозг-машина и мозг-мозг, текст — лучшее, что у нас есть. Пожалуйста, не трогайте его, с ним все хорошо и так.
UFO just landed and posted this here
Этот текст конвертируется в пиксели на экране. Если хранить AST то его тоже можно представлять как текст. Или как другие пиксели на экране человеком.

Можно конвертировать также для любых других потребителей, которые любят текст.

Я ещё вспомнил Gupta (и вздрогнул) ©«Не дай бог никому»
Текст может недостаточно точно передавать то, что происходит в программе, например, если код параллельный или дофига прерываний. Но с альтернативой как-то грустно, LabView и Simulink отвратительны. Да и на лиспе, когда надо думать AST-деревьями, тяжко бывает.
Любопытно, а что вам лично кажется отвратительным в LabVIEW? В контексте статьи — с точки зрения визуального представления кода? Я ни в коем случае не в порядке разжигания холивара, более того, я пишу и на C#. Просто у меня зреет пара статеек на хабр, я мог бы там, возможно, какие-то моменты, которые вызывают отторжение, так сказать, осветить. Язык далёк от идеала, но всё же не «ужас-ужас», на мой взгляд.
По своему опыту: при программировании «квадратиками» уходит больше времени и внимания за счёт переключения между полями-настройками квадратика, сложно одновремменно держать в голове всю схему и прорабатывать данный конкретный элемент. Плюс, при чтении чьей-то большой схемы становится непонятно, что к чему из-за большого числа элементов и мешанины стрелочек.
Я понимаю. что теоретически возможно делать как в SpaceChem — нарисовать какой-то путь, потом на него нанизать квадратики, потом эти квадратики по одному детализировать от конца к началу… Но потом оказывается, что ты забыл что-то в середине и ты с матюками долго это всё раздвигаешь, чтобы не рисовать «петлю».
Ещё вспоминается «проблема Алгола»: квадратиков 100500 типов, ощущение как в языке с чудовищно перегруженным из-за обилия фич синтаксисом.

По слухам: в LabView схемы начинают сбоить при большом числе элементов, т.е. не отрабатываться какие-то входы или пути. Сам не сталкивался, на уровне городских легенд.
Понял, спасибо. Единственно, что могу сказать — при разработке большой программы на LabVIEW очень важна хорошая «структуризация». При правильно поставленной разработке каждая блок-диаграмма должна укладываться в один экран. Если она разрастается и становится похожей на спагетти и нечитаемой — значит требуется рефакторинг и структурная декомпозиция. Это с опытом приходит. При большом (скажем так, вменямом) числе элементов сбоев нет, это и правда легенды, но есть баги в рантайме, у меня их целая коллекция накопилась. У нас трое программистов работают с этой системой и особых проблем с чтением чужого кода нет.
Полностью согласен, что построение грамотной и понятной блок-схемы — это вопрос опыта. Посоветуйте, плз, инструмент рефакторинга, руками растаскивать лениво. Возможно, было бы удобнее, если бы можно было рисовать трехмерные блок-схемы: каждый этаж — это своя логика, а между слоями — вертикальные связи.

Мне не нравится, что LabView позиционировали как ЯП для не-программистов. Этого, имхо, не получилось, но его до сих пор иногда вкрючивают в качестве скриптоязыка. Так вот, как непрограммист, который иногда сталкивается с LabView: не надо, пожалуйста :) Лучше BeanShell, Python, матлаб или ещё что-нибудь упрощённое С-подобное.
Да в общем-то нет специальных инструментов — в основном руками. Часть диаграммы, логически впысывающуюся в отдельный модуль, можно выделить и сделать из неё подприбор. Там можно воспользоваться встроенным средством чистки диаграммы — на небольших приборах работает приемлемо. Растаскивать диаграмму можно, удерживая клавишу «контрол» — в последней версии LabVIEW там довольно удобно реализовали.

Этот язык действительно позиционируется как язык для «непрограммистов», но на мой взгляд это позиционирование сильно ошибочно — там простота кажущаяся. К LabVIEW имеет смысл подходить после изучения традиционных языков, скажем, учебного Паскаля и Си. Опять же чтобы пользоваться классами надо понимать основы объектно-ориентированного программирования.
Есть хороший эксперимент у JetBrains — Meta Programming System. Я еле-еле прошёл туториал, мозги выносит напрочь.
Прикольная штука, спасибо за упоминание.
Мне кажется, было бы разумно с кодом хранить индекс. Тогда без IDE можно было бы рефакторить и искать изпользования класса/метода из командной строки или API
только для джавы 3 популярных IDE
как ты предлагаешь их индексы стандартизировать?
Так в том и идея, чтобы индекс хранился с кодом. Какой то открытый стандарт, который понимают все IDE и комманд лайн тулы
Какой то открытый стандарт

почему не воспользоваться одним из? зачем надо писать новый?
image
Что-то похожее на ctags?
Ну я больше представлял себе индекс IDEA, который хранится и апдейтится с кодом
1) Почему цветовая схема хранится в IDE, а форматирование — с кодом? И то, и другое — как CSS в HTML — должно быть отдельно от кода
2) А как насчет хранения кода вообще языконезависимо? Хочешь — смотришь на него на на Джаву, хоочешь — как на C#

Короче — мне нравится идея
Хочешь — смотришь на него на на Джаву, хоочешь — как на C#

с удовольствием посмотрю на один и тот же код на ASM и на java
Любую идею можно довести до абсурда. А вот какой то алгоритм на Скале, С++, Java — почему бы и нет?
нет погодь, что за виляния начались? мы же говорим про универсальный код?
а ты уже начинаешь какие-то странные ограничения, то не хочу, это не буду… джаву хочу, ассемблер не хочу
а как насчёт отображения на хаскеле?
Ну, пример подобного — IL.
Теоретически, можно интерпретировать по-разному: от C++ до Delphi, емнип. Что сейчас с ним будет — хороший вопрос.
верно, но прямо на нём писать тяжко, тоесть мы опять возвращаемся к тому, с чего начали
стопицот языков <-> промежуточный код. А уж как его назовём, IL, java bytecode, LLVM не суть факт важно. Главное, что на нём всё равно писать нельзя напрямик можно, но больно
Поддержу.

Наш мозг работает с образами и их причинно-следственными связями. Если процесс программирования больше творческий, то почему нужно пользоваться бюрократическими методами.
Взять те же детские среды программирования, как Scratch или Lego Mindstorms. Дети влет усваивают основные принципы создания алгоритма.
А ведь алгоритм в сознании представляет собой не черно-белый набор символов, а некий порядок действий с некими представлениями объектов-данных.

Имхо, при прочтении статьи пришла на ум поговорка «Сапожник без сапог». Как по мне она вполне четко отражает текущее положение дел, именно в плане взаимодействий «Машина» — «Программист»
У нас уже появились более адеватные, нежели клавиатура, интерфейсы к компьютеру? Пока нет возможности взаимодействия мозг-компьютер единственное что у нас остаётся для взаимодействия с компьютером — руки.
А для рук, как ни крути, клавиатура даёт одну из лучших производительностей. Автоматически, цепочкой, подтягивается следующее ограничение — что удобнее всего делать на клавиатуре? Набирать текст. Круг замкнут.
Тут, в таком случае, думать стоит не о том, как приспособить мозг к клавиатуре, а прежде всего о том, чем и как её родную можно заменить.
Так в том и проблема, что нечем:
— глазные детекторы… вы можете своими глазами управлять в достаточной мере, чтобы работа была комфортной?
— прочие детекторы — там управлять ещё сложнее.
Можно, конечно, сделать какой-нибудь детектор на пальцы, но это будет лишь аналогом клавиатуры.
Остаётся ждать когда интерфейсы съёма нейро-импульсов дорастут до полноценных интерфейсов мозг-компьютер… Ну или штырёк (как в матрице) научатся втыкать.
А теперь представьте: [...] легко, одна команда на изменение атрибутов всех методов (что-то типа «SET logging=true Where item=»method") + 1 строчка кода, определяющая формат лога

А зачем это представлять, когда aspectJ так и работает? И взаимодействует отнюдь не с файлами исходников.
Было что-то похожее Хранение кода в бд или собираем код по кирпичикам.

Наверно было бы интересно посмотреть на что-то такое, что хранит скомпилированный код в виде синтаксического дерева в БД, с возможностью просмотра историй обновления по любой сущности любого уровня -сборка-класс-функция-блок кода. Вообщем весь функционал version control по типу git, только на уровне вплоть до блоков/атомарных инструкций. А некая IDE, в solution explorer в древовидном виде отображала бы эти сущности и позволяла их редактировать — и в привычном текстовом виде и виде графических диаграмм. Будет ли универсальным это обратное преобразование в текст для любого языка — вопрос, но в один конкретный, заранее заданный язык наверно не так сложно. Зато все эти возможности find reference и быстрой компиляции могут быть реализованы намного проще, ведь код заливается в систему контроля версий уже в скомпилированном бинарном/IL виде и готовым для индексации. Как-то так наверно можно сделать удобным и для человека и для машины работу с исходным кодом.
но зачем менять скомпилированный код? ведь всё равно при следующей сборке всё это перетрётся
в один конкретный, заранее заданный язык наверно не так сложно

java bytecode и MS IL декомпилируются практически в идентичный java и C# код соответственно
Статья понравилась, и как любая хорошая статья заставляет осмотреться и осознать, что тема намного глубже и вопросов после прочтения стало больше. И каждый из этих вопросов стоит отдельной темы.
Ведь у любого подхода есть свои преимущества, и свои недостатки. И решая одни вопросы, мы будем создавать новые.

Связывая среду разработки с самим языком, мы сильно ограничиваем его в развитии и расширяемости, так как любое нововведение будет требовать серьёзных затрат.

Большая гибкость обычно приводит к излишней запутанности и сложности.

Усложняя систему, загружая её большим количеством возможностей, мы увеличиваем порог вхождения для новичков и приводим к сложности в использовании.

Есть очень много задач, в решение которых разумнее использовать простой молоток, быстрый и легкодоступный. При этом в сложном и длительном проекте разумнее использовать его технологически более развитого собрата, пневматический молоток, с автоматической подачей гвоздей и защитой от стрельбы себе в ногу.

Языки программирования развиваются. Появляются новые языки, изменяются существующие. И это разнообразие замечательно, так как заставляет текущие языки развиваться быстрее.
Так сложилось, что на прошлом месте работы у меня основным инструментом был язык BPMN, на котором бизнес-процессы описываются в виде схемок из квадратиков и стрелочек. А на текущем — SQL Server Integratiion Services, где в таком же виде описываются так называемые процессы ETL. Так я просто скажу — терпеть не могу и тех и других.

Потому что и те и другие — не текст. Потому что в итоге сделать diff (а также и merge) мы не можем, картинки не сравниваются и не объединяются, потому что компонуются программы из таких блоков прямо скажем фигово (по сравнению с функциональным программированием и ООП). Потому что языка картинок не хватает для того, чтобы реализовать все нужное, и к нему в реальности быстро добавляется обычный классический язык программирования — и мы сразу имеем зоопарк из двух языков, а то и из трех. Потому что у каждого квадратика есть еще и атрибуты, и немало, которые становятся еще и третьим способом представления информации о процессе.
Чем это BPMN не текст? Обычная хмл-ка, дифом вполне сравнивается.
Теоретически — сравнивается. А практически — это дает столько мусора, что выделить из этого шума полезные данные очень сложно. Т.е. как инструмент для починки, когда что-то сломалось — это работает, а как повседневный инструмент — нет.

Дело в том, что BPMN, а еще SVG и скажем WordML, а еще UML-диаграммы где-нибудь в Rational — они все xml. SSIS кстати тоже. Но поскольку предполагается, что рисовать их вы все-таки будете инструментом, сериализованное представление в xml может быть любого формата.

Кроме всего прочего, разработчики инструментов вовсе не горят желанием показывать вам xml представление. Я не про всех, конечно. Многие.
Замечу, что для звездолетов практически наверняка применяется ЕСКД или что-то подобное.
Ставлю плюсик, тема интересная.
Но на самом деле нет никакого противоречия между текстовым и бинарным представлением кода. Ведь текст — это тоже бинарные данные, такие же байты.
Дело не в том, использовать ли в коде «невводимые с клавиатуры» байты или нет, а в том что синтаксическая структура языка должна быть такова, чтобы парсинг файла производился «на лету» и мгновенно. Антипример — С++. Впоследствии разработчики языков стали учитывать ошибки С++, и например C# гораздо лучше парсится «на лету».
Собственно, если задаться целью, то вполне можно спроектировать синтаксис языка безупречным для машинного анализа, всяческих select-ов по коду и т.п., с сохранением привычного текстового формата. Работать будет, и очень быстро — без всякой «двоичности». Но вот до сих пор ни в одной известной мне IDE не реализована даже простейшая функция поиска по файлу с простейшим лексическим фильтром — искать только в коде, в строках, в комментариях (с возможностью отметить нужное).

А почему нужен текстовый формат? Дело в том, что в отличие от БД, код имеет право пребывать в «неправильном» состоянии (т.е. с нарушением целостности) — в процессе редактирования. Да, конечно можно довести все до состояния полного скрытия текста от программиста, создать специальную IDE (как MS Word для текста), это не такая проблема. Проблема в том, что программистам придется полностью переучиваться самому способу ввода и редактирования программ, а это гораздо сложнее чем даже выучить новый язык программирования, т.к. ломаются фундаментальные подсознательные привычки.
" Но вот до сих пор ни в одной известной мне IDE не реализована даже простейшая функция поиска по файлу с простейшим лексическим фильтром — искать только в коде, в строках, в комментариях (с возможностью отметить нужное)."

что за простейший лексический фильтр? Или вы имеете в виду «где искать» (код/строки/комментарии)? Если второе, то IDEA и построенные на ней IDE умеют (правда не на файле, а на папке с файлами… ну так там можно указать и конкретный файл — с помощью маски файлов).
Антипример — С++. Впоследствии разработчики языков стали учитывать ошибки С++, и например C# гораздо лучше парсится «на лету».

Проблема парсинга C++ не столько в том, что его парсить долго, сколько в том, что его парсить много:
$ cat hw.cpp
#include <iostream>
int main() { std::cout << "Hello, World!\n"; }

$ g++ -std=c++11 -E hw.cpp | wc
  24304   53850  597619
Там, где другие распарсили бы 2 строчки, компилятор C++ парсит почти 0.6 Мб.
А это уже недостаток не самого языка, а тяжеловесной библиотеки iostream.

Можно было бы сделать для винды такой код:
extern "C" int __stdcall MessageBoxA(void* hWnd, const char*lpText, const char* lpCaption, unsigned uType);

int WinMainCRTStartup(void)
{
    MessageBoxA(0, "Hello World", "Warning", 0x30 /*MB_OK | MB_ICONEXCLAMATION*/);
    return 0;
}

Ну или использовать какой-либо другой системный вызов низкого уровня для применяемой ОС. Тогда размер кода получится значительно меньше. Только что скомпилировал вышеприведенную программу с полным отключением Runtime Library. Получился экзешник с размером 2560 байт (Visual Studio 2013, оптимизированные опции компиляции) с единственной внешней зависимостью — user32.dll, функция MessageBoxA. Компилятору и компоновщику работать пришлось очень мало.
UFO just landed and posted this here
Посмотрите с другой стороны.

Согласитесь, на то время не было направлений разработки абстракций связанных с психологией человека и увеличению его эффективности.
О применении нейро-интерфейсов, отслеживанию биометрики, трехмерной графики и интерфейсов не стоит и вспоминать.
UFO just landed and posted this here
Поясню.

В моем воображении идея развилась до следующей концепции: «Программист создает программу любым доступным ему способом. Алгоритм есть возможность представить в любом другом доступном виде.»
Мое мнение, это основной посыл данного поста.

> По этой теме всё уже было продумано и сказано десятилетия назад.

Как следствие выше сказанному, по этой теме «продумано и сказано» еще не все, отсюда появляются идеи, вполне реализуемых в современном мире интерфейсов.

Право, моя вина в том, что я не донес эту мысль в моем предыдущем комментарии.
Локальный оптимум это ловушка эволюции. И теперь уже армии программистов будут сопротивляться бинарному формату исходников, оправдывая это чем угодно, например, отсутствием инструментов для диффа. Лицемерное утверждение, ведь бинарники можно диффать, а представить изменения в наглядном виде можно уже разобрав бинарный формат (google://pdf diff). И так во всём, что касается темы бинарных сырцов.

Консерватизм в ИТ просто поражает иногда, а ведь это должна была быть индустрия прогресса. Видимо, сейчас сработал железный закон олигархии и альтернативы мейнстриму уже не имеют шанса получить хоть какую-то поддержку.
Аналогичные мысли посещают меня уже пару лет. Предложить альтернативу — достаточно сложно. Инициатором по хорошему должен быть разработчик одной из популярных IDE. Так как внедрить в существующие IDE (для меня Xcode) новый формат хранения кода, да еще и с поддержкой компилятора, системы контроля версий, довольно сложно, если не невозможно (на должном уровне). Единственное — можно написать конвертер текстновый формат, и надеятся, что разработчики IDE его подхватят.
Это примерно как с HTML, никто не предполагал делать на нем то, что делают сейчас, но и альтернатив нет, а предлагать их должны не разработчики сайтов, но разработчики браузеров.
А я понял статью как призыв к тому, чтобы текст не заменялся, а дополнялся.
Т.е. Вот мы пишем программу на шарпе в ИДЕ. Вокруг того что мы написали строились бы бинарные данные, всё это компилировалось\интерпретировалось в отдельный слой, эдакую стандартизированную VM со своим байткодом и функциями для любого языка, которая сама по себе не является необходимой.
Имея же на руках стандартизированный бинарный машиночитаемый код все инструменты анализа, новые компиляторы могли бы им пользоваться.
Итого это была бы некая унификация всех языков в 1, но с выбором на каком писать удобнее и проще. А ка бонусом все плюсы из статьи.

Может я что не так понял, но сама идея не отказываться от 50 лет опыта этой сфере, но поднять её на новый уровень вызывает у меня приступ мечтательных настроений.
Текстовые файлы очень удобны для написания кода на профессиональном уровне, и за ~60 лет существования отрасли отлично проработаны машинные парсеры. Для не-новичка не проблема настрочить пяток if'ов и for'ов за полминуты, и для компилятора (да и для программиста тоже) не проблема их распознать, а представьте, сколько времени понадобится, чтобы это мышкой натыкать? А если блоки вводить текстом внутри визуальных, то «проблема» парсеров не исчезает.
Здравая мысль — возможность высокоуровневого анализа кода, визуализации и рефакторинга. Но сейчас индексация выполняется в IDE, исходники и индекс хранятся отдельно. Не думаю, что следует объединять эти данные в одной сущности — работа с форматом станет более сложной и требовательной к ресурсам (компиляция+индексация при каждом сохранении), а существенных преимуществ нет.
Ну и напоследок, не хотелось бы увидеть ещё один бинарный проприетарный формат на том месте, где достаточного общепринятого текстового.
А меня вот бесит постоянно отваливающийся индекс в IDE и то, что его постройка занимает иногда весьма внушительное время.
Опять же, в чем разница — открыть нужный файл, или открыть нужный класс из БД. Я был бы рад не заморачиваться созданием нового файла на каждый класс, класть его в свой каталог, как-то называть. Мне ведь нужен класс, а не файл, и было бы круто, если бы я мог его создать в неком общем репозитории, а при необходимости — экспортировать в текстовом виде или в той же БД.
Вот наличие обширной инфраструктуры — это большой плюс текстовых файлов, но это никак не может быть стопором для альтернативных подходов. Вполне можно объединять две парадигмы в одном проекте, как совмещают несколько языков программирования.
Эта тема кстати близка теме поиска альтернативы устаревающей парадигме файловой системы. Некоторые новые ОС уже копают в данном направлении.
Не факт, что индекс в БД не будет так же отваливаться и/или тормозить. Сейчас, по крайней мере, есть альтернатива «не использовать индекс IDE».
Задач у разработчиков нового формата будет очень много, навскидку:
1) Сохранение
2) Ввод и визуализация
3) Индексация (в т.ч. анализ и рефакторинг)
4) Версионирование (+ обмен изменениями с коллегами)
Сейчас этим занимаются различные (достаточно сложные) инструменты, и то не без багов.
Да, это всё реализуемо, и есть некоторый смысл к этому идти, но вероятно получится убервелосипед.
Ну БД по сути и есть индекс. Механизмы работы с БД также хорошо отлажены за много лет.

1) Сохранение

Сейчас многие редакторы не требуют сохранения, оно перманентно, Ctrl/Cmd+S — устаревшая парадигма, от которой пытаются уйти.

2) Ввод и визуализация

Все точно так же, как и сейчас, но вместо файла — открываем класс или, возможно, модуль.

3) Индексация (в т.ч. анализ и рефакторинг)

Все точно как сейчас, просто меняем парсинг и работу с индексом на запрос к БД.

4) Версионирование (+ обмен изменениями с коллегами)

Вот тут проблема, так как использовать существующие VCS, работающие с текстовыми файлами, — невозможно.
Нужна имплементация на уровне БД. Для гитхаба можно было бы делать экспорт в git.
>Сейчас многие редакторы не требуют сохранения, оно перманентно, Ctrl/Cmd+S — устаревшая парадигма, от которой пытаются уйти.
>оно перманентно
NVRAM как бы ещё не внедрена повсеместно. Да и вообще, речь не о шорткатах.
Я имел в виду банальные вызовы fwrite(), которые будут заменены десятками запросов в случае использования БД. Запись стрима (даже с кодированием) в файл наверняка проще, чем запись структурированных данных в некое хранилище. А значит, меньше шанс наплодить багов.
В остальных пунктах — аналогично, «меньше кода — меньше багов».
Так кода ведь не меньше, просто он в другом месте (тот же индекс или парсинг AST), и в нем были, есть и будут баги. Кроме того он выполняется во время набора текста, что ничем не отличается от варианта с БД, кроме возможности объединить эти операции в одну атомарную транзакцию.

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

* UML и другие воплощения идеи «а давайте у нас менеджеры будут программировать диаграммами». Коротко говоря: ужасно. Причин несколько: 1) менеджеры это не программисты, 2) утечка абстракций, 3) проприетарные закрытые ни с чем не совместимые форматы данных и средства разработки, 4) широко распространённые средства работы с исходниками (sed/grep/diff/merge итд) не работают с этими форматами, 5) итд. В общем, это скорее средства для попила бюджетов, чем для программирования.

* Исходники на каком-нибудь DSL (хорошо если основанном на чём-то широко известном), снабжённые метаинформацией и вместе с ней хранимые в XML. Т.е. вместо просто имени переменной идёт xml-элемент, содержащий её имя, описание, тип и чёрте знает что ещё. Коротко говоря: очень плохо. Причин несколько: 1) специализированный ни с чем не совместимый XML, 2) следствие: разрабатывать возможно только в одной специализированной среде, у которой куча проблем с юзабилити и производительностью, 3) опять же, всякие диффы плохо работают с XML, 4) итд

* Исходники на DSL, хранимые вместе с метаинформацией в бинарном формате. Коротко: очень плохо. Причины те же что с предыдущим, только стандартные средства ещё хуже работают с бинарными файлами, а формат конечно же уникальный и ни с чем не совместимый.
Хм. Понимаете, автор всерьез уверен, что xml сравнивается диффом. Ну о чем тут можно говорить? Сравнивается — ну отлично, пусть пойдет, и попробует сравнить два документа word, где все содержимое в одной строке (вторая — xml заголовок).

Ну не понимает человек, что <a x=«a» y=«b»/> и <a y=«b» x=«a»>&lt/a> это семантически одинаковые документы, а дифф при этом будет весьма и весьма толстый.

Что можно поменять в UML (или BPMN) скажем стрелочку, «чтоб было красиво», семантически это останется тоже самое — а дифф мы снова поимеем при этом неизвестного размера. И самое главное — мы не сможем выделить из него то, что на самом деле важно, и то, что является украшательством.

Т.е. даже если формат не проприетарный, как BPMN, а вместо менеджеров диаграммами программируют бизнес-аналитики — это мало что меняет. Все равно на выходе из таких идей как правило получается один г****код.

Хм, вы про какого автора говорите? На сколько я понял, tangro как раз и предлагает чтобы код вместо простого текста был чем-то, имеющим внутреннюю структуру (AST). А вот конкретный формат этого аст — дело десятое. Хоть xml, хоть какая-нибудь бинарная штука. Как раз прелесть этого решения в том, что гораздо проще будет сделать семантический дифф.

Я про этого самого автора, хоть и отвечал в данном случае не ему.

Понимаете, я бы лично для начала хотел бы поглядеть на этот самый семантический дифф. Исходя из того, что автор предлагает в комментах обычный дифф для xml, у него такого на самом деле нет. И я такого никогда не видел. Т.е. проблема (одна из главных) инструментов, которые чуть выше обсуждаются, для работы с UML, с BPMN, которого я нахлебался по самое немогу, и другими вполне читаемыми человеком форматами — типа SVG, ровно в том, что нет хорошо сформулированной семантики такого диффа.

Ну хоть какой-нибудь паршивенький семантический дифф для SVG картинок? Вы думаете я против? Я только за — но я никогда не видел ни одного хорошего примера подобного решения.
Так дифф нужно строить по AST, а не по его представлению в хранилище. Если семантический дифф по коду вполне себе строится, то по AST этого же языка — и подавно.
Так где можно посмотреть работающий пример?
Вроде ж мы про код говорим? Простой поиск выводит на stackoverflow http://stackoverflow.com/questions/523307/semantic-diff-utilities (сам, правда, не пользовался)
Мы говорим про код, который не являлся бы текстом. Вон чуть выше коммент от Portnov, с которым я вполне согласен — все известные мне попытки уйти от текстового представления практически сводятся примерно к перечисленным, и все они очень плохи на практике. В том числе потому, что практически работающего диффа нигде нет. То что вы показали, хотя бы для java, выглядит неплохо, но почему-то в реальной жизни все что встречается — это структурный поиск/замена у IDEA.

На самом деле у меня есть подозрение, почему это так. Текст это одномерная структура. Как только мы уходим от одномерности к многомерности, аналогичные алгоритмы на дереве или графе сразу становятся значительно более дорогими вычислительно. И значительно более сложными для понимания. Что косвенно подтверждается комментарием к 8 ответу по вашей ссылке — сложность O(n^2) это ни в какие ворота обычно.
Тут вопрос, это принципиальная сложность или мы просто не доросли в каком-то смысле для решения этой задачи. Я думаю, для любой работающей технологии можно найти предыдущие попытки сделать то же самое, но неудачно.

Можно переходить к хранению градуированно?

— сначала сделать запасной текстовый интерфейс (хоть даже файловую систему виртуальную)
— потом перетаскивать сценарии использования на AST или даже какой-нибдуь semantic tree

Сейчас у нас фактически двойное хранение — у IDE в кешах и в тексте, причем тектовое представление первично. Может быть можно как-то стандартизировать кеши сначала как базу данных с публичным API, потом запретить хранить текст который содержит какую-то информацию не содержащуюся в базе данных, потом в какой-то момент сделать базу данных первичной.
Прежде чем куда-то переходить, нужно для начала продемонстрировать, что семантический дифф реально удобнее обычного, а этого пока не видать. Даже для простого в целом xml я не видел реально работающей технологии. При этом совершенно понятно, что работать с AST внутри кода намного удобнее, чем с текстом. И скажем рефакторинг вряд ли кто-то делает в здравом уме на тексте. Но с показом человеку все хуже.
В принципе, человеку показыают уже не только текст но и AST (цветом и сворачивалками) а кое где и графикой image
Ещё 15 лет назад у нас, по безальтернативности, была масса Java-кода в репозитории VisualAge, представляющем собой сервер с объектной базой данных. Ну и что сейчас можно сделать с этим репозиторием (огромным бинарным файлом dat)?

Не надо изобретать велосипед и ходить по давно известным граблям.
>что сейчас можно сделать
Конвертнуть в git скриптом.
Крайне сомневаюсь в наличии такого скрипта, который выдернет из репозитория VA что-то, кроме текстов программ. Особенно учитывая, что минимальной единицей версионности в git является файл целиком, а в VA версионируются в том числе методы и члены классов. А тогда возвращаемся к тому, с чего начали.
>Посмотрите на нынешний интерес к книгам — существенно упал. Потому, что многие представление информации воспринимаются нами живее, быстрее. Тот же аудиовизуальный ряд. Или инфографика.

Вот из этой херни автор выводит то, что код текстом — неудачен? Автор неудачен скорее, текст — лучшее изобретение человечества и не устареет ещё долго.

Статья выглядит страшно, так и хочется сделать больно тому, кто делится такими мыслями с миром. Читать он не научился, зато писать, писать горазд.
Интересно, какой формат у файлов ДРАКОН, и у прочих полностью визуальных языков программирования?
Проблема будет решена сама-собой когда появится ОС без файлов. А это станет актуальным (и будет быстро реализовано) когда сотрётся грань между ОЗУ и «диском». Сам текст, конечно, никуда не денется, человек ДУМАЕТ текстом, это самое близкое представление напрямую связанное с мышлением, однако, обогащение текста «няшками» типа структурирования, визуализации, кликабельности, перехода по ссылками и проч., постепенно будет происходить. Но не революционно, а так, как добавляются новые фичи в языки, одну тут добавили, через 5 лет стало майнстримом, одну тут.
> ДУМАЕТ текстом

Можно пруф в контексте программирования? Может я не такой, он я скорее думаю геометрически.
«Математики делятся на алгебраистов и геометров. Первые „рассуждают“ формулами, вторые — образами.» © математический фольклор
Я не знаю точного определения слова «текст» и мне лень смотреть. Но формула как графическое предстваление это не последовательность символов там символы вступают в некоторые геометрические отношения (над/под и т.д.)
когда появится ОС без файлов
Уже были, минимум с 1993 года. Newton OS, Palm OS. Лет 13-14 назад это практически взорвало мой мозг, но потом как-то заглохло. С файлами, которые можно «сохранить», оно как-то надёжнее видится. Хотя файл иногда кажется искусственной промежуточной сущностью. Но древовидность файловой системы тоже позволяет много что моделировать и структурировать.
человек ДУМАЕТ текстом
Человек ГОВОРИТ текстом, думает — далеко не всегда.
А кто сказал, что PalmOS без файлов? У нее просто немного специфическая структура, там грубо говоря одна только база данных фиксированной структуры, и все. Если это база — то оно что-ли уже не файлы?
«База данных» может быть и просто на диске или во флэш-памяти без такой промежуточной сущности, как файл. Вместо «смещения относительно начала файла» — абсолютный адрес c в памяти или смещение относительно начала диска.
Даже не во флэш-памяти, а в RAM.
В базе данных роль файлов играют схемы и таблицы. Смещения и адреса лежат ниже уровня, доступного пользователю. Так что разницы в общем почти никакой и нет.
Вспомнилось. Когда-то давно у меня был интересный девайс — МК-85. Программируемый калькулятор с LCD-дисплеем и килобайтом памяти. В нём был единственный язык — Бейсик. Но поскольку памяти было ужасно мало, текст программ (они редактировались построчно) сразу после ввода парсились и сохранялись во внутреннем представлении. Все инструкции занимали один байт (использовались значения, не занятые латиницей и кириллицей). Пробелы вообще не сохранялись. Получалось довольно компактно. Адов был девайс. Я на нём тетрис писал. И даже с красивой заставкой! Славные были времена. Хорошо, что они кончились.
Здравствуйте. Мне статья очень понравилась. Мои ощущения можно выразить так: Накипело! Наконец-то пришло время ставить вопрос ребром! Мне очень понравились коментарии. Чего здесь не было далее ниже.
!) В кибернетике есть теорема суть которой в следующем: Сумма (модернизация) N алгоритмов, дающих прекрасный результат, будет во много раз превосходить по качеству, чем самый лучший из этих алгоритмов. Суть: Давайте объединим все наработки и предложим качественно новый продукт. Поясню: на сколько я помню в Windows 95 реестр был текстовый. Это как бы было удобно. Но в Windows XP реестр бинарный и это было ешё удобней — тормоза системы уменьшились в разы. MS Word 2003 имел бинарный файл (.doc), а MS Word 2007 тоже бинарный, но в 3 раза меньше. Более того он (.docx) читается и на MS Word 2003. Плюсы налицо. (Говорят, что интерфейс MS Word 2007 _намного_ удобнее чем у MS Word 2003). Давайте объединим текст+графику+медиа+эффекты в одной среде. Математические формулы удобно видеть в виде картинки (как в MathLab), а для компьютера это будет всегда _однообразное, жёсткостандартизованое представление_ (я специально не написал слово код). Строчные выражения (формулы, названия, комментарии, определения...) удобно писать в виде текста с клавиатуры. Диалоговые окна удобно видеть так как они будут выглядеть для пользователя (конечно со слоем для программиста, и может, не только его), то есть рисовать их. Для эффектов тоже можно кое-что придумать (я имею ввиду полупрозрачность, наведение резкости, форма движения...)
!!) Наконец-то придумать нормальный (эффективный) diff-инструментарий, который показывал то что нам нужно(без утомительных настроек этого). Хватит пользоваться каменными топорами для синтетических изделий. Переменная — это переменная, у неё есть смысл(!) (при чём может быть разный для разных частей кода. Видите ли мы так экономим). Инициализацию прошла? — Нет. Вот у нас то есть баг, то нету (зависит от ПК).…
!!!) Давно жду этой опциональности: логи то нужны, то не нужны. Коменты хочу видеть/ не хочу. Параметры запуска то одни, то другие. Существующие средства сильно отвлекают от сути. Пока сообразишь, забудешь для чего. (Если их не много это другой случай)
!V) Масштабируемость просмотра как на Google/maps. Суть-детальней-детальней-код.
V) Тотальная стандартизация и открытый формат. Так будет и программистам удобней и компьютеру. (Вспоминаю анектод: Чем больше я узнаю людей — тем больше люблю компьютеры)
V!) Модульность фоновой компиляции. Программист не меняет весь код сразу, а только его часть. Вопрос: чего ждёт компьютер — компилируй остальную часть (части (модули, классы, автономные структуры)). На выходе ведь тот же «напильник»(ну, ручка другая). Тогда «студент» сдаст сессию вовремя и без пота (да и программисту не надо ЖДАТЬ компиляцию и пить 2е ведро чая)(Ждать — бич сегодняшнего времени)
V!!) Удобно сразу видеть структуру — методы, классы, переменные, области видимости. Я считаю, что компьютер программисту друг. Вот пусть и помогает. Помогает искать, менять, даже объяснять (для этого нужны метаданные (от программиста, конечно))

В общем, нужно нечто новое. Идею дал, а Вы реализуйте (сам не могу по объективным причинам). Спасибо за внимание. Жду комменты (для этого и пишу).
>MS Word 2003 имел бинарный файл (.doc), а MS Word 2007 тоже бинарный, но в 3 раза меньше.
docx — архив с пачкой xml внутри. Дальше не читал, пишете фигню.
вот и редактируйте его в блокноте. Пофиг в чём хранится, главное редактор, а ещё лучше процессор. Ой, не читайте, умник.
Так я оттуда и знаю — я тесты пишу на формирование docx именно с опорой на этот формат. Построить дифф на xml, особенно построчный — проще простого.
Расширю ответ МонкАлекса:
1. xlsx/docx — архив с текстовыми и бинарными данными. Бинарные данные — картинки и прочее не представимое текстом. Риббоны в офисе 2007 на мой вкус ужасны (хотя некоторым нравятся) — добраться до нужного функционала стало почти нереально (раньше было просто долго). Математические формулы удобно видеть в виде сложно-форматированного текста. В картинке часть текста не выделишь. Диалоговые окна — было и есть давно уже (в Delphi, редакторы форм в Netbeans/прочих IDE). Применяется очень мало где, ибо польза сомнительная (слишком большой оверхед получается по сгенерированному коду).
2. для текста диф уже вполне функциональный. Обучить его контексту языков — мало пользы и много гемороя. В некоторых языках компиляция кода с неинициализированной переменной невозможна (например — в Java при попытке использовать неиницаилизированные локальные переменные будет выдана ошибка компиляции). Т.е. это возможно но не для всех языков (для JS есть различные линтеры для этой же цели).
3. Логи уже давно опциональны. В Java при некотором желании можно даже динамически управлять их детализацией. Комменты в IDE можно настроить на сокрытие (возможно не во всех).
4. Для этого есть разные view и модели пакетирования кода. В некоторых языках — архитектурно нереализуемо. Хотя можно обеспечить какой-нибудь суррогат.
5. Идите в лес, грибочки собирать. Текстовые файлы исходного кода для каждого языка — и есть единый открытый формат для данного языка.
6. Давно есть (не во всех языках). В Java можно даже в работающее приложение пропихнуть обновлённый класс. Но релизную сборку всегда делают на чистой копии.
7. В том или ином виде давно реализовано. Опять же не для всех языков.

Ну а по итогу «возьмите-ка свою идею и… куда нибудь её утилизируйте». Всё о чём вы сказали или бред, или давно реализовано, или нереализуемо для части языков (я сомневаюсь что программисты c/c++ все поголовно мазохисты… вполне могли бы многое уже адаптировать идеи из других языков… но почему-то делается это далеко не со всеми идеями).

И статья — такая же бредовая. Нет пока более эффективного инструмента дающего сравнимую производительность. Просто из-за ограничений интерфейсов взаимодействия компьютер-человек. Вот когда будут нейроинтерфейсы, дающие возможно «думать в компьютер» — тогда появится что-то более удобное.
Спасибо за ответ и за внимание webkumo и MonkAlex. «Манит меня в небесах тот звёздный свет, но достать его нелегко, хоть цель близка» (из песни). Буду думать.
Горы этого кода!!! Как Вы не запутываетесь?!
За других не скажу, но мой опыт последних лет — это разработка Java-бекэндов и JS-фронтендов.
В JS появились практки, делающие его более-менее модульным, Java всегда был модульным (мавен артефакты — внешний модуль + пакеты — внутренний модуль). Именно модульность с изоляцией неймспейсов значительно снижает потребность помнить что и где лежит и позволяет сосредоточиться на конкретных участках.
Сейчас в Java хотят дать внешней модульности более глобальное определение (обещают в 9ой выпустить).

PS но в конечном счёте всё упирается в конкретный проект… даже модульность не спасёт от лапши и классов по 3к строчек, если не следить за отсутствием антипаттернов.
Ну, так как код — вещь древовидная, то, да, неплохо было бы иметь поддержку этой древовидности то ли на уровне ОС то ли ещё где-то на уровне среды. Чтоб невозможно было бы случайно как-нибудь поломать «всё» из-за удаления закрывающей или открывающей скобки. С хранением времени модификации (и, возможно, истории) каждого узла. С механизмами диффов, патчей и матчинга для древовидных структур.

Возникает, правда, уточняющий вопрос — а как насчёт переменных и прочего data flow, ведь современной программирование — оно «не столько про код, сколько про структуры данных»? Для начала можно его, чисто «императивно», обойти, посчитав, что хватит и «встроенной древовидизации» кода.

Тут мы рано или поздно опять, скорее всего, упрёмся в «нам нужен пятнадцатый стандарт», а так как уже есть «стандарт номер ноль» в виде тёплого лампового текста, то и «предыдущие 14 стандартов» с 99% вероятностью рискуют так и остаться непридумаными…
Старая шутка:
Настоящий программист пишет программы так:
«copy con file_prog.exe»

Есть среды разработки, которые хранят код и метаданные в одном файле. Например, 1С Предприятие. И, если не ошибаюсь, Flash. Даже макросы в Word или Excel — вместе с формами хранятся в документе.
Почему удобнее хранить код в виде текста? Именно потому — что так его проще и удобнее читать, удобнее искать файл по содержимому.
Когда мы пишем код мы фантазируем некоторый функционал реализуемый данным кодом. Проблема в том, что фантазия может быть неправильной, то есть содержать ошибку, которую придётся найти и исправить. (И неважно мы пишем, рисуем или говорим). Чтобы не было такого (правильно люди говорят) надо думать «прямо в компьютер». А пока такого нет — текст лучшее решение. Мы же с Вами общаемся и покамест лучшего способа не придумали (математики формулы не рисуют, а пишут). А автора поправлю: мы пишем не буквы, а предложения, то есть смысл.
Где вы в статье увидели замену текстовому вводу? Автор предлагает альтернативу текстовым файлам. Для программиста все будет практически так же — окошечко с текстом, который можно редактировать. Но этот текст хранится не как есть, а в некотором оптимизированном виде, что позволяет получить определенные преимущества относительно пачки текстовых файлов.
Я думал про блок-схемы или ещё что. А вообще Вы правы. Я «перенапрягся».
UFO just landed and posted this here
Sign up to leave a comment.