Простые текстовые форматы данных — прекрасная штука. Нет, без шуток. Возьмём, например, банальные txt-файлы. Ну красота же! В любом утюге есть текстовый редактор, можно открыть файл, почитать, записать. Любой уважающий себя язык программирования из коробки даст вам средства работы с текстовыми файлами. Или вот ранние сетевые протоколы — SMTP, POP3, HTTP 1.0. Это вообще такое блаженство, что слёзы на глаза наворачиваются. Можно взять telnet, приконнектиться к серверу, отдавать команды и читать ответы! Писать клиенты, серверы, снифферы, прокси — одно удовольствие.
Но время не стоит на месте и удобство работы программиста, к сожалению (или к счастью!), давно перестало быть главным критерием выбора технологий. В прекрасные текстовые файлы понадобилось вдруг добавлять графики, картинки и ссылки — и вот у нас есть форматы pdf и doc. С сетевыми протоколами вообще беда — людям зачем-то понадобились сжатие трафика, шифрование, мультиплексирование и другие страшные вещи. И вот уже у нас есть HTTP/2, с которым телнетом не очень-то поработаешь. Даже всем красивый REST разные негодяи типа Google нет-нет, да и пытаются заменить на какой-нибудь gRPC. И это я ещё не начал рассуждать о том, что мало что нынче сохраняется текстовые файлы — все почему-то используют какие-то базы данных, совершенно нечитабельные при открытии их текстовым редактором, но
И вот здесь мы подходим к теме того, что я хотел бы обсудить. Как видите, все форматы хранения данных, протоколы и прочие штуки прошли длинный путь в поисках своего оптимального вида. Однако мы, программисты, продолжаем писать код наших программ в текстовых файлах, как делали это наши дедушки лет 50 назад (или уже больше?). Какую бы ОС мы ни использовали, какой бы модный язык ни выбрали, как бы ни была крутой наша IDE — результатом написания кода будут буквы в текстовом файле. Что, согласитесь, в теории совершенно не обязательно, ибо наши буквы компьютеру нужны как зайцу стоп-сигнал. Ему нужны машинные команды для выполнения, это просто нам удобнее описывать их какими-то там буквами. А на самом деле ведь «цикл» или «функция» будут тем, чем они являются, как ты их не назови и где ты их не храни. «Роза пахнет розой, хоть розой назови её, хоть нет».
Да, мы привыкли писать код в текстовые файлы. Вы открываете файл — ну и вроде бы видите код своей программы. Какую-то его часть, вернее. Как-то видите. Понимаете. Ну или думаете, что понимаете. Но вот пост на Facebook вы тоже открываете, видите и понимаете — а ведь Facebook точно этот пост не в текстовом файле хранил.
Давайте же посмотрим, какие проблемы нам создаёт хранение кода в виде набора текстовых строк.
Всё это страшно неудобно обрабатывать всем используемым нами инструментам
Весь тот код, который мы напишем, в последствии будет читать куча программ: IDE, её плагины, компилятор, дебаггер, средства статического анализа, контроля версий, билд-сервер и т.д. Всем им вот просто невероятно нравятся текстовые форматы (на самом деле — нет). Каждый из них будет их читать, анализировать (т.е. вы уже видите бесполезный труд десятков команд разработчиков, для каждого языка программирования), тратить на это время. А ещё они иногда будут ошибаться, ну или не ошибаться, а понимать ваш код слегка по разному. Не секрет, что IDE и какой-нибудь её плагин могут предложить разное автодополнение и разные средства рефакторинга для одного и того же кода. А как было бы хорошо, если бы один инструмент один раз превратил написанные вами буквы в некоторое AST-подобное представление (возможно, расширенное, с метаданными) и сохранил это всё в базе, которую мы и будем называть «кодовой базой проекта». А дальше уже каждый инструмент обращался бы к этой базе, по определённым протоколам, получая стабильные, стандартизированные и предсказуемые результаты. Ближайшим приближением к идеалу, о котором я на сегодняшний день знаю, является проект от Google, называющийся Kythe. Там ещё далеко до идеала, но направление верное.
Всё это страшно неудобно читать и писать людям
«Что может быть понятнее текста?!» — спросите вы. Да много чего может. Текст — хорошее средство представление информации, но не единственно возможное, и не всегда лучшее. Посмотрите на нынешний интерес к книгам — существенно упал. Потому, что многие представление информации воспринимаются нами живее, быстрее. Тот же аудиовизуальный ряд. Или инфографика. Или даже текст — но не сплошной стеной, а как-то структурированный, отсортированный, сгруппированный и отфильтрованный. Да, мы можем сделать наш код таким. Если вот сами поставим себе эту цель, сядем и сделаем. И делаем ведь — приходится, других вариантов нет. А как было бы классно получить всё это даром, автоматически. Иметь возможность увидеть код таким, как его хочется видеть. Чтобы написать SELECT по коду — и увидеть только те артефакты, которые соответствуют параметрам запроса. Или представить пересылку данных между двумя узлами в виде диаграммы. Или анимации. Поискать функцию не по названия, а по воспоминанию «там было больше трёх параметров и она меняла второй из них». Или по тому, что в ней было три цикла. Или «она что-то делала со временем». Есть у нас сейчас такие инструменты? Нет их! Сиди и пиши регулярные выражения, как дурак.
С написанием кода дело ещё хуже, чем с чтением. Кто-то из программистов изучает слепой набор текста, кто-то зубрит хоткеи Vim, кто-то тыкает мышкой по менюшкам любимой IDE. То, что нам приходится этим заниматься — это ужас! Создание алгоритмов — это искусство, это магия, это акт творения. А мы берём свои каменные топоры и идём с их помощью строить звездолёт. А у нас нет сегодня ничего, кроме этих молотков. И каждый день появляются новые молотки, которые существенно меняют форму ручки и тип крепления к ней булыжника, на самом деле ни на йоту не приближая нас к тем инструментам, которыми должны строится звездолёты.
Стили форматирования кода
Вы помните холивары «табы против пробелов» на Хабре? Вот это были сражения. «Стиль форматирования кода» — это понятие, которое, почему-то существует, хотя его существовать не должно в принципе. Программисты его выбирают для своего проекта, стараются соблюдать (тратят время на это), иногда даже друг друга попрекают, если кто-то ненароком нарушает. Да что за бред? Представьте себе идеальный мир, где код хранится в бинарном файле, в виде связного набора сущностей, обозначающих классы, методы, циклы, переменные, условия. В этом случае каждый программист может настроить свой инструмент просмотра этого кода таким образом, чтобы ему рисовались хоть табы, хоть пробелы, хоть иконки котят. Все эти «на какой строке фигурная скобка» и «нужен ли пробел после запятой» просто ушли бы в прошлое. Точно так же при сохранении кода в базу он преобразовывался бы из кода, оформленного в стиле данного программиста, в просто код без форматирования. А потом импортировался другим программистом в его IDE в удобном ему виде.
Метаданные в коде
Недавно на хабре промелькнул пост о том, что аннотациям — не место в Java-коде. Конечно, им там не место. Потому, что это не код. Это метаданные. Мы пишем их в код, потому что больше некуда. Ну разве что в другой XML-файл рядом, что ещё хуже. Аннотация в Java, как и декораторы в Python, аттрибуты в C#, комментарии к методам в любом языке и т.д. — должны быть метаданными. У нас должны быть удобные инструменты поиска по этим метаданным, быстрого их включения\отключения, рефакторинга. Конечно, должна быть возможность показать их «как сейчас, в коде». Но «вшитие» их в код — это как каждую понравившуюся картинку сразу выбивать себе на груди татуировкой. Слишком кардинально, слишком большие последствия.
Аспектно-ориентированное программирование
Каждый, кто впервые читает об аспектно-ориентированном программировании, проникается красотой идеи. Мне оно нравится даже больше функционального. Но постойте, а где оно в реальном мире? А нет его. Потому, что аспектно-ориентированное программирование попросту не ложится на концепцию кода, записанного в виде последовательности текстовых строк. Попытки написать хоть что-то в аспектном стиле либо уводят нас в дебри рефлексии, либо требуют массовых правок, пронизывающих всю кодовую базу и не поддающихся автоматизированию.
А теперь представьте, что наш код эффективно сохранён в структурированный формат. И у нас есть инструмент для работы с ним. Итак, нужно добавить логирование всех входных параметров всех методов всех классов? Да легко, одна команда на изменение атрибутов всех методов (что-то типа «SET logging=true Where item=»method") + 1 строчка кода, определяющая формат лога. Точно так же в два клика это убирается. Что там ещё нам нужно делать в каждой функции? Профилирование? Аутентификация и проверка прав доступа? Проверять контракты? А почему бы и нет, если вот они — все наши классы, методы и добавление всего вот этого НЕ МЕНЯЕТ ИХ КОД. Добавили, потестировали, возможно убрали, а возможно оставили. А может быть сохранили несколько наборов аспектов (что-то для дебаг-окружения, что-то другое для продакшена).
Большой размер кодовой базы
Google недавно рассказывал, что у них 100 млн строк кода (уже, наверное, больше). Так много, наверное, ни у кого больше нет, но 1-2 миллиончика строк для энтерпрайз-проекта крупной организации уже является вполне обыденной вещью. И как вы, скажите пожалуйста, по этой кодовой базе навигируетесь? Насколько хороши в ней ваши любимые grep и find? А функционал вроде Find References? А средства рефакторинга? Текст — медленная и неуклюжая штука. Каждый, кто хочет быстро им оперировать — вынужден строить какие индексы. Эти индексы долго строятся, живут отдельно от самого кода, переизобретаются каждым инструментом. Мы сами создали себе проблему, которую пытаемся героически решить. В этом месте мне вспомнился недавний доклад о структурном логировании, рассказывающий о подобной же проблеме: мы придумали писать логи в текстовые форматы, чтобы потом придумать отдельные программы вроде Logstash для парсинга этих текстовых форматов с целью извлечения из них ранее записанной информации (при этом, конечно, и пишется не всё и извлекается не всё, и контексты теряются, и рассинхронизация на каждом шагу). В общем, интересный доклад, посмотрите. Ну так вот, для логов до понимания масштабов беды мы уже дошли, а до самого кода — ещё, получается, нет.
Длительное время компиляции
Посмотрите на первый попавшийся язык программирования и попробуйте угадать, какую фичу хотят его пользователи. Как в том анекдоте про «4 ствола и всё небо в попугаях» можно пальнуть наугад и окажется, что «неплохо бы ускорить время компиляции\интерпретации» — вот из свеженького, просьбы к Яндексу (а почему не в Спортлото?) улучшить С++. Это же надо, оказывается, что компилятор\интерпретатор ничего не делают в том время, когда вы задорно молотите по клавиатуре (а вы это частенько делаете) и лишь время от времени, проснувшись от летаргического сна командой запуска сборки или требованием интерпретации скрипта они съедают всю память и все ядра CPU, чтобы выполнить свою работу. И, прямо как у студента, ничего не делавшего весь семестр, внезапно оказывается, что нужно напрягаться, тратить много времени и сил. А чего же ты, спрашивается, раньше ничего не делал? Если бы формат сохранения кода предполагал перевод написанного текста программы в некоторую промежуточную форму (что-то чуть-чуть большее, чем поток лексем, но чуть-чуть меньшее, чем готовый бинарный код), то и компиляция была бы значительно более быстрой.
Отсутствие кросс-языковых инструментов разработки
Из-за того, что каждый язык программирования, каждый фреймворк и каждая ОС — это монастырь со своим уставом, у нас совершенно нет никаких инструментов удобной координации написания различных частей системы. Нет, IDE, конечно, всякие есть. Но покажите-ка мне дебаггер, который даст возможность пройти совершенно типичный нынче процесс «скрипт на Python запустил программу на C++, которая дёрнула по сети микросервис на Go, который полез в базу, где дёрнул пару хранимок, после чего это всё вернулось скрипту на Python». И вот чтобы дебаггер дал мне всё — точки останова на любом уровне от скрипта до хранимки, стек вызовов, всё окружение. Чтоб понимал, что вот параметр передался через командную строку, а вот тут он же — сериализировался в REST-запрос, а тут вернулся вот таким образом. Есть такое? Нет такого. Потому, что код — это буковки. Там такие, а здесь другие. Там их один компилятор собрал, здесь — другой. А как-то их связать — сложно это. А вот если бы код был кодом, и там кодом (с функциями, параметрами, циклами, условиями) и тут тоже кодом, то между ними можно было бы пробрасывать мостики, а затем по этим мостикам удобно ходить.
Так доколе?
Комментарии (119)
nerudo
30.05.2016 12:01+4Labview, Matlab/Simulink, SPW (или помер за давностью лет?). Срочно переучиваемся!
AndreyDmitriev
30.05.2016 14:26+9Как активный разработчик на LabVIEW (больше пятнадцати лет) могу сказать, что визуальное программирование — это удобно в том смысле, что я прямо в код могу вставить любую картинку с пояснениями. Если я пишу модуль общения с железкой, у меня прямо в коде кусок документации с протоколом, если это математика — то я могу вставить формулу прямо в код, если где-то нетривиальная геометрия — то тут само собой поясняющая картинка. Даже анимированную гифку могу вставить — если в коде бага, то по экрану весело ползает жучок и всё такое.
Но есть и пара ложек дёгтя — файлы исходников двоичные со всеми вытекающими. Мы ещё пользуемся MS Source Safe, размер репозитория — больше двадцати гигабайт. Чекаут эксклюзивный — есля я работаю с файлом, то коллега с ним работать уже не может. Diff и merge имеются, но это сторонные инструменты, их можно интегрировать в систему контроля версий, но я б не сказал что пользоваться удобно, diff используется редко, а merge и того реже. Стандарта «языка» нет как такового, тут NI правит бал, впрочем они в каждой версии расширяют язык по запросам пользователей, но альтернатив никаких нет. Про поддержку юникода я просто умолчу. Ну и стоимость средств разработка какая-то ненормальная. В очень долгосрочной перспективе я верю, что за визуальными средствами будущее, но это очень далёкое будущее. Сначала должен появиться стандарт, долны появиться открытые средства или альтернативы, система контроля должна нативно поддерживать форматы исходников, ну а там всё остальное «приложится». Пока что всё это «эзотерика», если можно так выразиться.
potan
30.05.2016 21:21+1Есть еще литературное программирование, где в описании программы доступна любая TeXовская разметка. При этом все языконезависимо.
Revertis
30.05.2016 12:02+7Читал этот поток сознания и думал, что вы что-то хотите предложить. Но нет.
А вообще, самое главное в коде это его читабельность другими людьми и самим собой через месяц. Ну, кроме эффективности и правильной работы :)
Хотя, конечно, немаловажны системы сборки и IDE.
hellman
30.05.2016 12:09+10Аннотация в Java, как и декораторы в Python, аттрибуты в C#, комментарии к методам в любом языке и т.д. — должны быть метаданными
Python-декораторы здесь не в темуtangro
30.05.2016 22:15-1Почему? Сами по себе, они, конечно, код. Но способ их связи с другим кодом — это метаданные.
SirEdvin
30.05.2016 23:47+2На самом деле нет.
Вызов через @ это просто синтасический сахар для выражения вида:
def fn(x): return x*2 fn = convert(fn)
webkumo
31.05.2016 12:51Вот интересно, а чем плохи аннотации как метаданные? И какой иной механизм расстановки метаданных вы предлагаете? (надеюсь не xml?)
Terranz
30.05.2016 12:16+24опять ты выходишь на связь? на одном узко известном в широких кругах форуме тебе уже всё пояснили и теперь ты сюда принёс?
опять же, давай по частям разберём
инструментам, которыми должны строится звездолёты
например каким?
Программисты его выбирают для своего проекта, стараются соблюдать (тратят время на это),
как много потратится время на нажатие твоего любимого хоткея в IDE для выправления кодстайла? меньше секунды на нажатие alt+shift+f
Представьте себе идеальный мир, где код хранится в бинарном файле, в виде связного набора сущностей, обозначающих классы, методы, циклы, переменные, условия.
и тут мы пришли к уже существующим .obj или .coff или .class файлам
Но «вшитие» их в код — это как каждую понравившуюся картинку сразу выбивать себе на груди татуировкой. Слишком кардинально, слишком большие последствия.
это уже сделано и прекрасно работает
Насколько хороши в ней ваши любимые grep и find? А функционал вроде Find References? А средства рефакторинга? Текст — медленная и неуклюжая штука. Каждый, кто хочет быстро им оперировать — вынужден строить какие индексы. Эти индексы долго строятся, живут отдельно от самого кода, переизобретаются каждым инструментом. Мы сами создали себе проблему, которую пытаемся героически решить.
всё уже давно сделано и изобретено, у всякой уважаемой себя ide есть вот это всё
компиляция была бы значительно более быстрой.
особенно клёво когда компилируется прямо во время написания кода, как в java ide, что некисло так добавляет тормозов
опять же, нормальные проекты гоняют тесты после компиляции кода, ты предлагаешь прямо во время работы программиста тестировать код? бро, не у всех рабочая машина i7 на 16 ядер и 32гб оперативки
А вот если бы код был кодом, и там кодом (с функциями, параметрами, циклами, условиями) и тут тоже кодом, то между ними можно было бы пробрасывать мостики, а затем по этим мостикам удобно ходить.
ну так с этого и надо было начинать, надо было сразу написать, что ты не хочешь учиться программировать на том, что деды писали, а сраху хочешь свой новый ещё один общий для всех язык программирования!
ну так сядь и напиши его, что ты как не этот?! компилятор реализуй, хотябы для двух основных платформ — x86, arm, если взлетит — сообщество само допишет тебе для других архитектур. IDE не забудь, с дебагером который может дебагать даже небо даже б-га.
Ах да, ещё не забудь сделать новую VCS чтобы удобно версионировать бинарные файлы с кодомtangro
30.05.2016 22:17+5на одном узко известном в широких кругах форуме тебе уже всё пояснили и теперь ты сюда принёс?
Что кому где, простите, объяснили?Terranz
01.06.2016 11:26извините, видимо это были не вы
просто на одном форуме пару недель назад один анонимус уже предлагал уйти от кода в виде декста и перейти на что-то новое, да хоть те-же картиночки
t-nick
30.05.2016 23:56+1> как много потратится время на нажатие твоего любимого хоткея в IDE для выправления кодстайла? меньше секунды на нажатие alt+shift+f
Дело не во времени, а в удобочитаемости и привычке. При смене места работы/команды/проекта приходится придерживаться нового стиля, это раздражает и добавляет проблем в виде разногласий с другими членами команды и ухудшению продуктивности.
> и тут мы пришли к уже существующим .obj или .coff или .class файлам
Это все же про другое, некий промежуточный универсальный язык, байткод. Если я правильно понимаю автора, то речь идет о возможности хранения кода, например С/С++, в виде синтаксического дерева в некоторой БД. Каждый программист может сам выбирать правила форматирования отображаемого кода. Многие уже сейчас строят костыли в виде скриптов, которые переформатируют код перед каждым коммитом/пушем в git.
> это уже сделано и прекрасно работает
Что работает? Аннотации в Java? Работают, но это не значит, что можно сделать лучше.
> всё уже давно сделано и изобретено, у всякой уважаемой себя ide есть вот это всё
А если конкретно в моей нет или оно страшно глючное? Кстати в альтернативных IDE — немногим лучше.
> особенно клёво когда компилируется прямо во время написания кода
Ну вот clang например каждый раз парсит DSL для каждого отдельного файла, подтягивая всю цепочку импортировнных заголовков. Как по мне — это пустая трата ресурсов.
Удивляет, что такой консервативный комментарий набирает столько плюсов.
vdasus
31.05.2016 13:36-1:: При смене места работы/команды/проекта приходится придерживаться нового стиля, это раздражает и добавляет проблем
Если это раздражает то надо не среду менять, а таблетки. И учиться постоянно. Мне лично вообще неважен стиль. Главное чтобы было единообразно. Главное код, а не пробел там или табуляция. Имхоt-nick
31.05.2016 13:49А вы, простите, какие таблетки принимаете?
Разным людям нравится разное форматирование кода (а еще — разные инструменты/IDE/ОС/ноутбуки).
Банально — непривычно форматированный код читать сложнее, уходит время, чтоб натренировать глаз. Новонабранная команда будет неделю холиварить по поводу табов/пробелов в новом проекте. Это все не выдумки, а реальные проблемы.
Почему бы не дать возможность сделать форматирование индивидуальным, как цветовую схему редактора?vdasus
31.05.2016 13:55Нравится и мешает работать — принципиально разные вещи.
Почему бы не дать? Можно, конечно. Только вот эта «статья» тут вообще ни при чём. Поток сознания «на тему». Напомнило мне из Гоголя «Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича — я бы тогда тотчас же решилась. А теперь поди подумай!»
Terranz
01.06.2016 11:32+1это раздражает и добавляет проблем в виде разногласий с другими членами команды и ухудшению продуктивности
ну не знаю, если честно, я работал в нескольких конторах с разным кодстайлом. Абсолютно не заметил разницы если честно, просто сразу предоставляется настройка кодстайла для местной ide и всё, дальше всё форматируется хоткеями
Это все же про другое, некий промежуточный универсальный язык, байткод. Если я правильно понимаю автора, то речь идет о возможности хранения кода, например С/С++, в виде синтаксического дерева в некоторой БД
ну, возможно я что-то не так понял. Я понял так, что автор хочет хранить код в промежуточном виде, а отображать как душенька пожелает. Те же самые байткоды джавы и c# почти прямо отображаются в исходный код
Многие уже сейчас строят костыли в виде скриптов, которые переформатируют код перед каждым коммитом/пушем в git.
и это правильно, я считаю. Я уже сталкивался с тем, что форматирование кем-то кода не так как у всех очень большой diff даёт.
Что работает? Аннотации в Java? Работают, но это не значит, что можно сделать лучше.
конечно можно, но пока никто не сделал, если у автора взлетит — респект ему
А если конкретно в моей нет или оно страшно глючное? Кстати в альтернативных IDE — немногим лучше.
а что за ide, если не секрет?
Ну вот clang например каждый раз парсит DSL для каждого отдельного файла, подтягивая всю цепочку импортировнных заголовков. Как по мне — это пустая трата ресурсов.
типичные плюсовые заморочки. Если мне не изменяет память, то была какая-то программа, которая делает прекомпилированные файлы заголовков и их не надо постоянно парсить на каждый чихt-nick
01.06.2016 13:17просто сразу предоставляется настройка кодстайла для местной ide и всё, дальше всё форматируется хоткеями
У нас тоже так, но вот новоприбывшего (несколько месяцев назад) девелопера и одного из старожилов до сих пор приходится тыкать носом на каждом код ревью. К тому же сам инструмент (clang-format) очень далек от идеала и практически не имеет настроек, что не позволяет применять его к каждой строке кода.
ну, возможно я что-то не так понял. Я понял так, что автор хочет хранить код в промежуточном виде, а отображать как душенька пожелает.
Ну это он уже немного ушел от основной идеи — хранение обычного кода на обычном ЯП в подобии AST. Как один из профитов — получаем отделение форматирования от кода. Но так как ООП языки имеют много общих парадигм, то, следовательно, одно и то же AST можно было бы транслировать (не без ограничений конечно) в разные языки.
а что за ide, если не секрет?
В мире разработки под iOS их всего две — Xcode от Apple и AppCode от Jetbrains. Первый не умеет нормальный рефакторинг, кроме самых базовых вещей, и то — очень глючно. Во втором есть мощный рефакторинг, анализатор и много чего еще, но индексирование занимает вечность.
типичные плюсовые заморочки. Если мне не изменяет память, то была какая-то программа, которая делает прекомпилированные файлы заголовков и их не надо постоянно парсить на каждый чих
Это умеет сам компилятор (например GCC). Но при сборке «начисто» все прекомпилированные заголовки создаются заново. Кроме того приходится ручками составлять .pch файл с библиотечными заголовками, чтобы ускорить компиляцию. Все это выглядит как большой костыль, чем он по сути и является.webkumo
01.06.2016 14:50Так AppCode же вроде недавно выпустили и он тупо ещё сырой? Idea для java глючит очень мало где (в стандартных юзкейсах — глюки это вообще редкость).
PS и да, в Java, благодаря несколько иному процессу компиляции и отсутствию шаблонов (или как там эти куски динамического кода #define называются) парсинг подключённых библиотек происходит крайне быстро… по сути не-системные библиотеки больше сказываются на размере поставляемого файла, чем на времени компиляции… Имхо в плюсах этого подхода очень нехватает… с другой стороны там и удобного для этих целей байткода нет…t-nick
01.06.2016 15:13The first public preview version of AppCode became available in April 2011. 5 лет уже какбэ. Релиз 1.0 вроде в сентябре 2011 был.
С IDEA не сталкивался, но вроде многие её так же ругают за ресурсоемкость.
MichaelBorisov
31.05.2016 00:48+3и тут мы пришли к уже существующим .obj или .coff или .class файлам
Эти файлы в принципе не являются представлением исходного кода, они не предназначены для их просмотра и изменения человеком.
особенно клёво когда компилируется прямо во время написания кода, как в java ide, что некисло так добавляет тормозов
Если компиляция на заднем плане добавляет тормозов редактированию текста на переднем плане — то это неправильное понимание многозадачности авторами IDE.
В мою бытность студентом на одной машине под RSX-11M одновременно десяток студентов редактировали и компилировали свои программы с терминалов. Машина однопроцессорная. Компиляция даже небольшой программы занимала минуты. Если одновременно компилировалось несколько программ — то значительно дольше. Но это нисколько не мешало остальным студентам редактировать свои программы, потому что процесс редактора имел более высокий приоритет, чем процесс компилятора. Только и всего. Реакции на действия человека надо дать более высокий приоритет, чем компиляции на заднем плане.
deniskreshikhin
30.05.2016 12:59+19«Что может быть понятнее текста?!» — спросите вы. Да много чего может. Текст — хорошее средство представление информации, но не единственно возможное, и не всегда лучшее.
Зачем тогда писать статью, если текст не единственно возможное и не всегда лучшее средство?
Можно было ограничится картинками. Как доказательство.
4p4
31.05.2016 09:32Автор предлагает не картинки, а двоичное представление — аналог «распарсенного абстрактного синтаксического дерева» сохранённого в двоичном представлении.
deniskreshikhin
31.05.2016 11:36Можно АСТ, главное что бы не текстом. Но я думаю и картинок было бы достаточно для демонстрации. Опять же картинка с АСТ была бы хорошей иллюстрацией тезиса. Т.е. открываешь статью, а там АСТ в виде картинке, и никакого текста. И всем все ясно без текста.
Я это представляю так.
CodeRush
30.05.2016 13:04+14Так доколе?
До последнего патрона.
Программы пишутся не только (и не столько) для компьютеров, но и для программистов. И писать их нужно так, чтобы их мог читать, понимать и изменять человек, а не машина. А тут предлагается ради упрощения парсеров и улучшения подсказок (которыми не пользуется процентов 30-40 разработчиков на низкоуровневых языках) сломать последовательно и редакторы, и компиляторы, и системы контроля версий, и вообще практически все наработки вокруг программирования за последние 50 лет ради того, чтобы разработчикам утилит было проще жить. Бинарные логи systemd и реестр Windows — теперь у вас в IDE, ура!
Пока не придуман прямой интерфейс мозг-машина и мозг-мозг, текст — лучшее, что у нас есть. Пожалуйста, не трогайте его, с ним все хорошо и так.
Aingis
30.05.2016 22:31+3«Программы должны писаться для того, чтобы их читали люди, и лишь во вторую очередь для выполнения машиной,» — Абельсон и Сассман, «Структура и интерпретация компьютерных программ».
ApeCoder
31.05.2016 06:03+1Этот текст конвертируется в пиксели на экране. Если хранить AST то его тоже можно представлять как текст. Или как другие пиксели на экране человеком.
Можно конвертировать также для любых других потребителей, которые любят текст.
Gryphon88
30.05.2016 14:41+2Текст может недостаточно точно передавать то, что происходит в программе, например, если код параллельный или дофига прерываний. Но с альтернативой как-то грустно, LabView и Simulink отвратительны. Да и на лиспе, когда надо думать AST-деревьями, тяжко бывает.
AndreyDmitriev
30.05.2016 15:08+1Любопытно, а что вам лично кажется отвратительным в LabVIEW? В контексте статьи — с точки зрения визуального представления кода? Я ни в коем случае не в порядке разжигания холивара, более того, я пишу и на C#. Просто у меня зреет пара статеек на хабр, я мог бы там, возможно, какие-то моменты, которые вызывают отторжение, так сказать, осветить. Язык далёк от идеала, но всё же не «ужас-ужас», на мой взгляд.
Gryphon88
30.05.2016 15:20+3По своему опыту: при программировании «квадратиками» уходит больше времени и внимания за счёт переключения между полями-настройками квадратика, сложно одновремменно держать в голове всю схему и прорабатывать данный конкретный элемент. Плюс, при чтении чьей-то большой схемы становится непонятно, что к чему из-за большого числа элементов и мешанины стрелочек.
Я понимаю. что теоретически возможно делать как в SpaceChem — нарисовать какой-то путь, потом на него нанизать квадратики, потом эти квадратики по одному детализировать от конца к началу… Но потом оказывается, что ты забыл что-то в середине и ты с матюками долго это всё раздвигаешь, чтобы не рисовать «петлю».
Ещё вспоминается «проблема Алгола»: квадратиков 100500 типов, ощущение как в языке с чудовищно перегруженным из-за обилия фич синтаксисом.
По слухам: в LabView схемы начинают сбоить при большом числе элементов, т.е. не отрабатываться какие-то входы или пути. Сам не сталкивался, на уровне городских легенд.AndreyDmitriev
30.05.2016 15:35+1Понял, спасибо. Единственно, что могу сказать — при разработке большой программы на LabVIEW очень важна хорошая «структуризация». При правильно поставленной разработке каждая блок-диаграмма должна укладываться в один экран. Если она разрастается и становится похожей на спагетти и нечитаемой — значит требуется рефакторинг и структурная декомпозиция. Это с опытом приходит. При большом (скажем так, вменямом) числе элементов сбоев нет, это и правда легенды, но есть баги в рантайме, у меня их целая коллекция накопилась. У нас трое программистов работают с этой системой и особых проблем с чтением чужого кода нет.
Gryphon88
30.05.2016 15:48+1Полностью согласен, что построение грамотной и понятной блок-схемы — это вопрос опыта. Посоветуйте, плз, инструмент рефакторинга, руками растаскивать лениво. Возможно, было бы удобнее, если бы можно было рисовать трехмерные блок-схемы: каждый этаж — это своя логика, а между слоями — вертикальные связи.
Мне не нравится, что LabView позиционировали как ЯП для не-программистов. Этого, имхо, не получилось, но его до сих пор иногда вкрючивают в качестве скриптоязыка. Так вот, как непрограммист, который иногда сталкивается с LabView: не надо, пожалуйста :) Лучше BeanShell, Python, матлаб или ещё что-нибудь упрощённое С-подобное.AndreyDmitriev
30.05.2016 16:29Да в общем-то нет специальных инструментов — в основном руками. Часть диаграммы, логически впысывающуюся в отдельный модуль, можно выделить и сделать из неё подприбор. Там можно воспользоваться встроенным средством чистки диаграммы — на небольших приборах работает приемлемо. Растаскивать диаграмму можно, удерживая клавишу «контрол» — в последней версии LabVIEW там довольно удобно реализовали.
Этот язык действительно позиционируется как язык для «непрограммистов», но на мой взгляд это позиционирование сильно ошибочно — там простота кажущаяся. К LabVIEW имеет смысл подходить после изучения традиционных языков, скажем, учебного Паскаля и Си. Опять же чтобы пользоваться классами надо понимать основы объектно-ориентированного программирования.
Jedi_Knight
30.05.2016 16:21+2Есть хороший эксперимент у JetBrains — Meta Programming System. Я еле-еле прошёл туториал, мозги выносит напрочь.
javax
30.05.2016 16:32Мне кажется, было бы разумно с кодом хранить индекс. Тогда без IDE можно было бы рефакторить и искать изпользования класса/метода из командной строки или API
Terranz
30.05.2016 17:33только для джавы 3 популярных IDE
как ты предлагаешь их индексы стандартизировать?javax
30.05.2016 16:54+31) Почему цветовая схема хранится в IDE, а форматирование — с кодом? И то, и другое — как CSS в HTML — должно быть отдельно от кода
2) А как насчет хранения кода вообще языконезависимо? Хочешь — смотришь на него на на Джаву, хоочешь — как на C#
Короче — мне нравится идеяTerranz
30.05.2016 17:34+1Хочешь — смотришь на него на на Джаву, хоочешь — как на C#
с удовольствием посмотрю на один и тот же код на ASM и на javajavax
30.05.2016 17:36Любую идею можно довести до абсурда. А вот какой то алгоритм на Скале, С++, Java — почему бы и нет?
Terranz
30.05.2016 17:37+1нет погодь, что за виляния начались? мы же говорим про универсальный код?
а ты уже начинаешь какие-то странные ограничения, то не хочу, это не буду… джаву хочу, ассемблер не хочу
а как насчёт отображения на хаскеле?
marcor
30.05.2016 17:52Ну, пример подобного — IL.
Теоретически, можно интерпретировать по-разному: от C++ до Delphi, емнип. Что сейчас с ним будет — хороший вопрос.Terranz
30.05.2016 17:59верно, но прямо на нём писать тяжко, тоесть мы опять возвращаемся к тому, с чего начали
стопицот языков <-> промежуточный код. А уж как его назовём, IL, java bytecode, LLVM не суть факт важно. Главное, что на нём всё равно писать нельзя напрямикможно, но больно
terentjew-alexey
30.05.2016 22:20+1Поддержу.
Наш мозг работает с образами и их причинно-следственными связями. Если процесс программирования больше творческий, то почему нужно пользоваться бюрократическими методами.
Взять те же детские среды программирования, как Scratch или Lego Mindstorms. Дети влет усваивают основные принципы создания алгоритма.
А ведь алгоритм в сознании представляет собой не черно-белый набор символов, а некий порядок действий с некими представлениями объектов-данных.
Имхо, при прочтении статьи пришла на ум поговорка «Сапожник без сапог». Как по мне она вполне четко отражает текущее положение дел, именно в плане взаимодействий «Машина» — «Программист»webkumo
31.05.2016 10:14+3У нас уже появились более адеватные, нежели клавиатура, интерфейсы к компьютеру? Пока нет возможности взаимодействия мозг-компьютер единственное что у нас остаётся для взаимодействия с компьютером — руки.
А для рук, как ни крути, клавиатура даёт одну из лучших производительностей. Автоматически, цепочкой, подтягивается следующее ограничение — что удобнее всего делать на клавиатуре? Набирать текст. Круг замкнут.terentjew-alexey
03.06.2016 00:14Тут, в таком случае, думать стоит не о том, как приспособить мозг к клавиатуре, а прежде всего о том, чем и как её родную можно заменить.
webkumo
03.06.2016 10:04Так в том и проблема, что нечем:
— глазные детекторы… вы можете своими глазами управлять в достаточной мере, чтобы работа была комфортной?
— прочие детекторы — там управлять ещё сложнее.
Можно, конечно, сделать какой-нибудь детектор на пальцы, но это будет лишь аналогом клавиатуры.
Остаётся ждать когда интерфейсы съёма нейро-импульсов дорастут до полноценных интерфейсов мозг-компьютер… Ну или штырёк (как в матрице) научатся втыкать.
EaE
30.05.2016 17:51+1А теперь представьте: [...] легко, одна команда на изменение атрибутов всех методов (что-то типа «SET logging=true Where item=»method") + 1 строчка кода, определяющая формат лога
А зачем это представлять, когда aspectJ так и работает? И взаимодействует отнюдь не с файлами исходников.
bethoven
30.05.2016 17:54+1Было что-то похожее Хранение кода в бд или собираем код по кирпичикам.
Наверно было бы интересно посмотреть на что-то такое, что хранит скомпилированный код в виде синтаксического дерева в БД, с возможностью просмотра историй обновления по любой сущности любого уровня -сборка-класс-функция-блок кода. Вообщем весь функционал version control по типу git, только на уровне вплоть до блоков/атомарных инструкций. А некая IDE, в solution explorer в древовидном виде отображала бы эти сущности и позволяла их редактировать — и в привычном текстовом виде и виде графических диаграмм. Будет ли универсальным это обратное преобразование в текст для любого языка — вопрос, но в один конкретный, заранее заданный язык наверно не так сложно. Зато все эти возможности find reference и быстрой компиляции могут быть реализованы намного проще, ведь код заливается в систему контроля версий уже в скомпилированном бинарном/IL виде и готовым для индексации. Как-то так наверно можно сделать удобным и для человека и для машины работу с исходным кодом.Terranz
30.05.2016 18:01но зачем менять скомпилированный код? ведь всё равно при следующей сборке всё это перетрётся
в один конкретный, заранее заданный язык наверно не так сложно
java bytecode и MS IL декомпилируются практически в идентичный java и C# код соответственно
klev
30.05.2016 18:19+2Статья понравилась, и как любая хорошая статья заставляет осмотреться и осознать, что тема намного глубже и вопросов после прочтения стало больше. И каждый из этих вопросов стоит отдельной темы.
Ведь у любого подхода есть свои преимущества, и свои недостатки. И решая одни вопросы, мы будем создавать новые.
Связывая среду разработки с самим языком, мы сильно ограничиваем его в развитии и расширяемости, так как любое нововведение будет требовать серьёзных затрат.
Большая гибкость обычно приводит к излишней запутанности и сложности.
Усложняя систему, загружая её большим количеством возможностей, мы увеличиваем порог вхождения для новичков и приводим к сложности в использовании.
Есть очень много задач, в решение которых разумнее использовать простой молоток, быстрый и легкодоступный. При этом в сложном и длительном проекте разумнее использовать его технологически более развитого собрата, пневматический молоток, с автоматической подачей гвоздей и защитой от стрельбы себе в ногу.
Языки программирования развиваются. Появляются новые языки, изменяются существующие. И это разнообразие замечательно, так как заставляет текущие языки развиваться быстрее.
sshikov
30.05.2016 20:08+5Так сложилось, что на прошлом месте работы у меня основным инструментом был язык BPMN, на котором бизнес-процессы описываются в виде схемок из квадратиков и стрелочек. А на текущем — SQL Server Integratiion Services, где в таком же виде описываются так называемые процессы ETL. Так я просто скажу — терпеть не могу и тех и других.
Потому что и те и другие — не текст. Потому что в итоге сделать diff (а также и merge) мы не можем, картинки не сравниваются и не объединяются, потому что компонуются программы из таких блоков прямо скажем фигово (по сравнению с функциональным программированием и ООП). Потому что языка картинок не хватает для того, чтобы реализовать все нужное, и к нему в реальности быстро добавляется обычный классический язык программирования — и мы сразу имеем зоопарк из двух языков, а то и из трех. Потому что у каждого квадратика есть еще и атрибуты, и немало, которые становятся еще и третьим способом представления информации о процессе.tangro
30.05.2016 22:21Чем это BPMN не текст? Обычная хмл-ка, дифом вполне сравнивается.
sshikov
31.05.2016 06:56Теоретически — сравнивается. А практически — это дает столько мусора, что выделить из этого шума полезные данные очень сложно. Т.е. как инструмент для починки, когда что-то сломалось — это работает, а как повседневный инструмент — нет.
Дело в том, что BPMN, а еще SVG и скажем WordML, а еще UML-диаграммы где-нибудь в Rational — они все xml. SSIS кстати тоже. Но поскольку предполагается, что рисовать их вы все-таки будете инструментом, сериализованное представление в xml может быть любого формата.
Кроме всего прочего, разработчики инструментов вовсе не горят желанием показывать вам xml представление. Я не про всех, конечно. Многие.
kzn
30.05.2016 20:25Замечу, что для звездолетов практически наверняка применяется ЕСКД или что-то подобное.
NeoCode
30.05.2016 20:49+3Ставлю плюсик, тема интересная.
Но на самом деле нет никакого противоречия между текстовым и бинарным представлением кода. Ведь текст — это тоже бинарные данные, такие же байты.
Дело не в том, использовать ли в коде «невводимые с клавиатуры» байты или нет, а в том что синтаксическая структура языка должна быть такова, чтобы парсинг файла производился «на лету» и мгновенно. Антипример — С++. Впоследствии разработчики языков стали учитывать ошибки С++, и например C# гораздо лучше парсится «на лету».
Собственно, если задаться целью, то вполне можно спроектировать синтаксис языка безупречным для машинного анализа, всяческих select-ов по коду и т.п., с сохранением привычного текстового формата. Работать будет, и очень быстро — без всякой «двоичности». Но вот до сих пор ни в одной известной мне IDE не реализована даже простейшая функция поиска по файлу с простейшим лексическим фильтром — искать только в коде, в строках, в комментариях (с возможностью отметить нужное).
А почему нужен текстовый формат? Дело в том, что в отличие от БД, код имеет право пребывать в «неправильном» состоянии (т.е. с нарушением целостности) — в процессе редактирования. Да, конечно можно довести все до состояния полного скрытия текста от программиста, создать специальную IDE (как MS Word для текста), это не такая проблема. Проблема в том, что программистам придется полностью переучиваться самому способу ввода и редактирования программ, а это гораздо сложнее чем даже выучить новый язык программирования, т.к. ломаются фундаментальные подсознательные привычки.webkumo
30.05.2016 21:17" Но вот до сих пор ни в одной известной мне IDE не реализована даже простейшая функция поиска по файлу с простейшим лексическим фильтром — искать только в коде, в строках, в комментариях (с возможностью отметить нужное)."
что за простейший лексический фильтр? Или вы имеете в виду «где искать» (код/строки/комментарии)? Если второе, то IDEA и построенные на ней IDE умеют (правда не на файле, а на папке с файлами… ну так там можно указать и конкретный файл — с помощью маски файлов).
Balthasar
30.05.2016 23:53+2Антипример — С++. Впоследствии разработчики языков стали учитывать ошибки С++, и например C# гораздо лучше парсится «на лету».
Проблема парсинга C++ не столько в том, что его парсить долго, сколько в том, что его парсить много:
Там, где другие распарсили бы 2 строчки, компилятор C++ парсит почти 0.6 Мб.$ cat hw.cpp #include <iostream> int main() { std::cout << "Hello, World!\n"; } $ g++ -std=c++11 -E hw.cpp | wc 24304 53850 597619MichaelBorisov
31.05.2016 01:35+1А это уже недостаток не самого языка, а тяжеловесной библиотеки 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. Компилятору и компоновщику работать пришлось очень мало.
eugzol
30.05.2016 22:06+3Если программист испытывает острое желание разработать сложный двоичный формат файла или сложный двоичный прикладной протокол, как правило, мудрым решением будет приостановить работу до тех пор, пока это желание не пройдет. (перевод по русскому изданию)
(When you feel the urge to design a complex binary file format, or a complex binary application protocol, it is generally wise to lie down until the feeling passes.)
The Art of Unix Programming
По этой теме всё уже было продумано и сказано десятилетия назад.terentjew-alexey
03.06.2016 00:48Посмотрите с другой стороны.
Согласитесь, на то время не было направлений разработки абстракций связанных с психологией человека и увеличению его эффективности.
О применении нейро-интерфейсов, отслеживанию биометрики, трехмерной графики и интерфейсов не стоит и вспоминать.eugzol
03.06.2016 01:10> Согласитесь, на то время не было направлений разработки абстракций связанных с психологией человека и увеличению его эффективности.
Ну как-то совсем не в тему моего комментария! Как это не было, если, по заверению авторов Юникса, весь он целиком был сделан в большей мере для удобства человека (программиста), а не машины?
> О применении нейро-интерфейсов, отслеживанию биометрики, трехмерной графики и интерфейсов не стоит и вспоминать.
Из всего вами перечисленного сейчас хоть какое-то массовое практическое применение имеет только трёхмерная графика (широко внедрённых трёхмерных UI нет). Опять же, не понятно, как это относится к мысли создателя Юникса :)terentjew-alexey
03.06.2016 01:49Поясню.
В моем воображении идея развилась до следующей концепции: «Программист создает программу любым доступным ему способом. Алгоритм есть возможность представить в любом другом доступном виде.»
Мое мнение, это основной посыл данного поста.
> По этой теме всё уже было продумано и сказано десятилетия назад.
Как следствие выше сказанному, по этой теме «продумано и сказано» еще не все, отсюда появляются идеи, вполне реализуемых в современном мире интерфейсов.
Право, моя вина в том, что я не донес эту мысль в моем предыдущем комментарии.
ditu
30.05.2016 22:22+3Локальный оптимум это ловушка эволюции. И теперь уже армии программистов будут сопротивляться бинарному формату исходников, оправдывая это чем угодно, например, отсутствием инструментов для диффа. Лицемерное утверждение, ведь бинарники можно диффать, а представить изменения в наглядном виде можно уже разобрав бинарный формат (google://pdf diff). И так во всём, что касается темы бинарных сырцов.
Консерватизм в ИТ просто поражает иногда, а ведь это должна была быть индустрия прогресса. Видимо, сейчас сработал железный закон олигархии и альтернативы мейнстриму уже не имеют шанса получить хоть какую-то поддержку.
t-nick
30.05.2016 22:22+1Аналогичные мысли посещают меня уже пару лет. Предложить альтернативу — достаточно сложно. Инициатором по хорошему должен быть разработчик одной из популярных IDE. Так как внедрить в существующие IDE (для меня Xcode) новый формат хранения кода, да еще и с поддержкой компилятора, системы контроля версий, довольно сложно, если не невозможно (на должном уровне). Единственное — можно написать конвертер текстновый формат, и надеятся, что разработчики IDE его подхватят.
Это примерно как с HTML, никто не предполагал делать на нем то, что делают сейчас, но и альтернатив нет, а предлагать их должны не разработчики сайтов, но разработчики браузеров.
Aitd
30.05.2016 22:23+1А я понял статью как призыв к тому, чтобы текст не заменялся, а дополнялся.
Т.е. Вот мы пишем программу на шарпе в ИДЕ. Вокруг того что мы написали строились бы бинарные данные, всё это компилировалось\интерпретировалось в отдельный слой, эдакую стандартизированную VM со своим байткодом и функциями для любого языка, которая сама по себе не является необходимой.
Имея же на руках стандартизированный бинарный машиночитаемый код все инструменты анализа, новые компиляторы могли бы им пользоваться.
Итого это была бы некая унификация всех языков в 1, но с выбором на каком писать удобнее и проще. А ка бонусом все плюсы из статьи.
Может я что не так понял, но сама идея не отказываться от 50 лет опыта этой сфере, но поднять её на новый уровень вызывает у меня приступ мечтательных настроений.
Akon32
30.05.2016 22:23-1Текстовые файлы очень удобны для написания кода на профессиональном уровне, и за ~60 лет существования отрасли отлично проработаны машинные парсеры. Для не-новичка не проблема настрочить пяток if'ов и for'ов за полминуты, и для компилятора (да и для программиста тоже) не проблема их распознать, а представьте, сколько времени понадобится, чтобы это мышкой натыкать? А если блоки вводить текстом внутри визуальных, то «проблема» парсеров не исчезает.
Здравая мысль — возможность высокоуровневого анализа кода, визуализации и рефакторинга. Но сейчас индексация выполняется в IDE, исходники и индекс хранятся отдельно. Не думаю, что следует объединять эти данные в одной сущности — работа с форматом станет более сложной и требовательной к ресурсам (компиляция+индексация при каждом сохранении), а существенных преимуществ нет.
Ну и напоследок, не хотелось бы увидеть ещё один бинарный проприетарный формат на том месте, где достаточного общепринятого текстового.t-nick
30.05.2016 23:06+1А меня вот бесит постоянно отваливающийся индекс в IDE и то, что его постройка занимает иногда весьма внушительное время.
Опять же, в чем разница — открыть нужный файл, или открыть нужный класс из БД. Я был бы рад не заморачиваться созданием нового файла на каждый класс, класть его в свой каталог, как-то называть. Мне ведь нужен класс, а не файл, и было бы круто, если бы я мог его создать в неком общем репозитории, а при необходимости — экспортировать в текстовом виде или в той же БД.
Вот наличие обширной инфраструктуры — это большой плюс текстовых файлов, но это никак не может быть стопором для альтернативных подходов. Вполне можно объединять две парадигмы в одном проекте, как совмещают несколько языков программирования.
Эта тема кстати близка теме поиска альтернативы устаревающей парадигме файловой системы. Некоторые новые ОС уже копают в данном направлении.Akon32
31.05.2016 11:44Не факт, что индекс в БД не будет так же отваливаться и/или тормозить. Сейчас, по крайней мере, есть альтернатива «не использовать индекс IDE».
Задач у разработчиков нового формата будет очень много, навскидку:
1) Сохранение
2) Ввод и визуализация
3) Индексация (в т.ч. анализ и рефакторинг)
4) Версионирование (+ обмен изменениями с коллегами)
Сейчас этим занимаются различные (достаточно сложные) инструменты, и то не без багов.
Да, это всё реализуемо, и есть некоторый смысл к этому идти, но вероятно получится убервелосипед.t-nick
31.05.2016 12:03Ну БД по сути и есть индекс. Механизмы работы с БД также хорошо отлажены за много лет.
1) Сохранение
Сейчас многие редакторы не требуют сохранения, оно перманентно, Ctrl/Cmd+S — устаревшая парадигма, от которой пытаются уйти.
2) Ввод и визуализация
Все точно так же, как и сейчас, но вместо файла — открываем класс или, возможно, модуль.
3) Индексация (в т.ч. анализ и рефакторинг)
Все точно как сейчас, просто меняем парсинг и работу с индексом на запрос к БД.
4) Версионирование (+ обмен изменениями с коллегами)
Вот тут проблема, так как использовать существующие VCS, работающие с текстовыми файлами, — невозможно.
Нужна имплементация на уровне БД. Для гитхаба можно было бы делать экспорт в git.Akon32
31.05.2016 13:33>Сейчас многие редакторы не требуют сохранения, оно перманентно, Ctrl/Cmd+S — устаревшая парадигма, от которой пытаются уйти.
>оно перманентно
NVRAM как бы ещё не внедрена повсеместно. Да и вообще, речь не о шорткатах.
Я имел в виду банальные вызовы fwrite(), которые будут заменены десятками запросов в случае использования БД. Запись стрима (даже с кодированием) в файл наверняка проще, чем запись структурированных данных в некое хранилище. А значит, меньше шанс наплодить багов.
В остальных пунктах — аналогично, «меньше кода — меньше багов».t-nick
31.05.2016 14:16Так кода ведь не меньше, просто он в другом месте (тот же индекс или парсинг AST), и в нем были, есть и будут баги. Кроме того он выполняется во время набора текста, что ничем не отличается от варианта с БД, кроме возможности объединить эти операции в одну атомарную транзакцию.
Хотя я вижу одну потенциальную проблему, — если софт работы с БД глючный, то мы можем полностью потерять доступ к коду. Текстовый файл мы в любой момент можем открыть в любом из бесчисленного количества текстовых редакторов. Если баг в парсере, то мы теряем возможность компиляции, но сам код всегда остается доступен, его можно собрать на другой машине например. В качестве решения можно предложить экспорт в виде git репозитория с обычной файловой структурой и текстовыми файлами, одним словом — бэкап.
Portnov
30.05.2016 22:23+1Вообще-то по-хорошему эта статья должна бы иметь в конце предложение альтернативы и доводы, почему она лучше.
Я несколько альтернатив видел (в разной степени), и ни про одну не могу сказать что она лучше чем текст:
* UML и другие воплощения идеи «а давайте у нас менеджеры будут программировать диаграммами». Коротко говоря: ужасно. Причин несколько: 1) менеджеры это не программисты, 2) утечка абстракций, 3) проприетарные закрытые ни с чем не совместимые форматы данных и средства разработки, 4) широко распространённые средства работы с исходниками (sed/grep/diff/merge итд) не работают с этими форматами, 5) итд. В общем, это скорее средства для попила бюджетов, чем для программирования.
* Исходники на каком-нибудь DSL (хорошо если основанном на чём-то широко известном), снабжённые метаинформацией и вместе с ней хранимые в XML. Т.е. вместо просто имени переменной идёт xml-элемент, содержащий её имя, описание, тип и чёрте знает что ещё. Коротко говоря: очень плохо. Причин несколько: 1) специализированный ни с чем не совместимый XML, 2) следствие: разрабатывать возможно только в одной специализированной среде, у которой куча проблем с юзабилити и производительностью, 3) опять же, всякие диффы плохо работают с XML, 4) итд
* Исходники на DSL, хранимые вместе с метаинформацией в бинарном формате. Коротко: очень плохо. Причины те же что с предыдущим, только стандартные средства ещё хуже работают с бинарными файлами, а формат конечно же уникальный и ни с чем не совместимый.sshikov
31.05.2016 16:46Хм. Понимаете, автор всерьез уверен, что xml сравнивается диффом. Ну о чем тут можно говорить? Сравнивается — ну отлично, пусть пойдет, и попробует сравнить два документа word, где все содержимое в одной строке (вторая — xml заголовок).
Ну не понимает человек, что <a x=«a» y=«b»/> и <a y=«b» x=«a»></a> это семантически одинаковые документы, а дифф при этом будет весьма и весьма толстый.
Что можно поменять в UML (или BPMN) скажем стрелочку, «чтоб было красиво», семантически это останется тоже самое — а дифф мы снова поимеем при этом неизвестного размера. И самое главное — мы не сможем выделить из него то, что на самом деле важно, и то, что является украшательством.
Т.е. даже если формат не проприетарный, как BPMN, а вместо менеджеров диаграммами программируют бизнес-аналитики — это мало что меняет. Все равно на выходе из таких идей как правило получается один г****код.
dougrinch
31.05.2016 18:21Хм, вы про какого автора говорите? На сколько я понял, tangro как раз и предлагает чтобы код вместо простого текста был чем-то, имеющим внутреннюю структуру (AST). А вот конкретный формат этого аст — дело десятое. Хоть xml, хоть какая-нибудь бинарная штука. Как раз прелесть этого решения в том, что гораздо проще будет сделать семантический дифф.
sshikov
31.05.2016 20:58Я про этого самого автора, хоть и отвечал в данном случае не ему.
Понимаете, я бы лично для начала хотел бы поглядеть на этот самый семантический дифф. Исходя из того, что автор предлагает в комментах обычный дифф для xml, у него такого на самом деле нет. И я такого никогда не видел. Т.е. проблема (одна из главных) инструментов, которые чуть выше обсуждаются, для работы с UML, с BPMN, которого я нахлебался по самое немогу, и другими вполне читаемыми человеком форматами — типа SVG, ровно в том, что нет хорошо сформулированной семантики такого диффа.
Ну хоть какой-нибудь паршивенький семантический дифф для SVG картинок? Вы думаете я против? Я только за — но я никогда не видел ни одного хорошего примера подобного решения.ApeCoder
01.06.2016 04:47Вроде ж мы про код говорим? Простой поиск выводит на stackoverflow http://stackoverflow.com/questions/523307/semantic-diff-utilities (сам, правда, не пользовался)
sshikov
01.06.2016 07:39Мы говорим про код, который не являлся бы текстом. Вон чуть выше коммент от Portnov, с которым я вполне согласен — все известные мне попытки уйти от текстового представления практически сводятся примерно к перечисленным, и все они очень плохи на практике. В том числе потому, что практически работающего диффа нигде нет. То что вы показали, хотя бы для java, выглядит неплохо, но почему-то в реальной жизни все что встречается — это структурный поиск/замена у IDEA.
На самом деле у меня есть подозрение, почему это так. Текст это одномерная структура. Как только мы уходим от одномерности к многомерности, аналогичные алгоритмы на дереве или графе сразу становятся значительно более дорогими вычислительно. И значительно более сложными для понимания. Что косвенно подтверждается комментарием к 8 ответу по вашей ссылке — сложность O(n^2) это ни в какие ворота обычно.ApeCoder
01.06.2016 08:08Тут вопрос, это принципиальная сложность или мы просто не доросли в каком-то смысле для решения этой задачи. Я думаю, для любой работающей технологии можно найти предыдущие попытки сделать то же самое, но неудачно.
Можно переходить к хранению градуированно?
— сначала сделать запасной текстовый интерфейс (хоть даже файловую систему виртуальную)
— потом перетаскивать сценарии использования на AST или даже какой-нибдуь semantic tree
Сейчас у нас фактически двойное хранение — у IDE в кешах и в тексте, причем тектовое представление первично. Может быть можно как-то стандартизировать кеши сначала как базу данных с публичным API, потом запретить хранить текст который содержит какую-то информацию не содержащуюся в базе данных, потом в какой-то момент сделать базу данных первичной.sshikov
01.06.2016 09:01Прежде чем куда-то переходить, нужно для начала продемонстрировать, что семантический дифф реально удобнее обычного, а этого пока не видать. Даже для простого в целом xml я не видел реально работающей технологии. При этом совершенно понятно, что работать с AST внутри кода намного удобнее, чем с текстом. И скажем рефакторинг вряд ли кто-то делает в здравом уме на тексте. Но с показом человеку все хуже.
ApeCoder
01.06.2016 12:15В принципе, человеку показыают уже не только текст но и AST (цветом и сворачивалками) а кое где и графикой
vadimr
30.05.2016 22:57Ещё 15 лет назад у нас, по безальтернативности, была масса Java-кода в репозитории VisualAge, представляющем собой сервер с объектной базой данных. Ну и что сейчас можно сделать с этим репозиторием (огромным бинарным файлом dat)?
Не надо изобретать велосипед и ходить по давно известным граблям.Akon32
31.05.2016 11:27>что сейчас можно сделать
Конвертнуть в git скриптом.vadimr
31.05.2016 11:53Крайне сомневаюсь в наличии такого скрипта, который выдернет из репозитория VA что-то, кроме текстов программ. Особенно учитывая, что минимальной единицей версионности в git является файл целиком, а в VA версионируются в том числе методы и члены классов. А тогда возвращаемся к тому, с чего начали.
MonkAlex
31.05.2016 06:16+1>Посмотрите на нынешний интерес к книгам — существенно упал. Потому, что многие представление информации воспринимаются нами живее, быстрее. Тот же аудиовизуальный ряд. Или инфографика.
Вот из этой херни автор выводит то, что код текстом — неудачен? Автор неудачен скорее, текст — лучшее изобретение человечества и не устареет ещё долго.
Статья выглядит страшно, так и хочется сделать больно тому, кто делится такими мыслями с миром. Читать он не научился, зато писать, писать горазд.
Idot
31.05.2016 08:41+1Интересно, какой формат у файлов ДРАКОН, и у прочих полностью визуальных языков программирования?
4p4
31.05.2016 10:32Проблема будет решена сама-собой когда появится ОС без файлов. А это станет актуальным (и будет быстро реализовано) когда сотрётся грань между ОЗУ и «диском». Сам текст, конечно, никуда не денется, человек ДУМАЕТ текстом, это самое близкое представление напрямую связанное с мышлением, однако, обогащение текста «няшками» типа структурирования, визуализации, кликабельности, перехода по ссылками и проч., постепенно будет происходить. Но не революционно, а так, как добавляются новые фичи в языки, одну тут добавили, через 5 лет стало майнстримом, одну тут.
ApeCoder
31.05.2016 10:53+1> ДУМАЕТ текстом
Можно пруф в контексте программирования? Может я не такой, он я скорее думаю геометрически.Idot
31.05.2016 11:48«Математики делятся на алгебраистов и геометров. Первые „рассуждают“ формулами, вторые — образами.» © математический фольклор
ApeCoder
31.05.2016 11:51Я не знаю точного определения слова «текст» и мне лень смотреть. Но формула как графическое предстваление это не последовательность символов там символы вступают в некоторые геометрические отношения (над/под и т.д.)
Flammar
31.05.2016 13:33когда появится ОС без файлов
Уже были, минимум с 1993 года. Newton OS, Palm OS. Лет 13-14 назад это практически взорвало мой мозг, но потом как-то заглохло. С файлами, которые можно «сохранить», оно как-то надёжнее видится. Хотя файл иногда кажется искусственной промежуточной сущностью. Но древовидность файловой системы тоже позволяет много что моделировать и структурировать.
человек ДУМАЕТ текстом
Человек ГОВОРИТ текстом, думает — далеко не всегда.sshikov
31.05.2016 21:21А кто сказал, что PalmOS без файлов? У нее просто немного специфическая структура, там грубо говоря одна только база данных фиксированной структуры, и все. Если это база — то оно что-ли уже не файлы?
Flammar
01.06.2016 18:07«База данных» может быть и просто на диске или во флэш-памяти без такой промежуточной сущности, как файл. Вместо «смещения относительно начала файла» — абсолютный адрес c в памяти или смещение относительно начала диска.
sshikov
01.06.2016 22:08В базе данных роль файлов играют схемы и таблицы. Смещения и адреса лежат ниже уровня, доступного пользователю. Так что разницы в общем почти никакой и нет.
hdfan2
31.05.2016 14:47+1Вспомнилось. Когда-то давно у меня был интересный девайс — МК-85. Программируемый калькулятор с LCD-дисплеем и килобайтом памяти. В нём был единственный язык — Бейсик. Но поскольку памяти было ужасно мало, текст программ (они редактировались построчно) сразу после ввода парсились и сохранялись во внутреннем представлении. Все инструкции занимали один байт (использовались значения, не занятые латиницей и кириллицей). Пробелы вообще не сохранялись. Получалось довольно компактно. Адов был девайс. Я на нём тетрис писал. И даже с красивой заставкой! Славные были времена. Хорошо, что они кончились.
ZavlabFF
01.06.2016 13:21Здравствуйте. Мне статья очень понравилась. Мои ощущения можно выразить так: Накипело! Наконец-то пришло время ставить вопрос ребром! Мне очень понравились коментарии. Чего здесь не было далее ниже.
!) В кибернетике есть теорема суть которой в следующем: Сумма (модернизация) 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!!) Удобно сразу видеть структуру — методы, классы, переменные, области видимости. Я считаю, что компьютер программисту друг. Вот пусть и помогает. Помогает искать, менять, даже объяснять (для этого нужны метаданные (от программиста, конечно))
В общем, нужно нечто новое. Идею дал, а Вы реализуйте (сам не могу по объективным причинам). Спасибо за внимание. Жду комменты (для этого и пишу).MonkAlex
01.06.2016 13:49+2>MS Word 2003 имел бинарный файл (.doc), а MS Word 2007 тоже бинарный, но в 3 раза меньше.
docx — архив с пачкой xml внутри. Дальше не читал, пишете фигню.ZavlabFF
01.06.2016 15:23-2вот и редактируйте его в блокноте. Пофиг в чём хранится, главное редактор, а ещё лучше процессор. Ой, не читайте, умник.
MonkAlex
01.06.2016 17:47Так я оттуда и знаю — я тесты пишу на формирование docx именно с опорой на этот формат. Построить дифф на xml, особенно построчный — проще простого.
webkumo
01.06.2016 16:16+2Расширю ответ МонкАлекса:
1. xlsx/docx — архив с текстовыми и бинарными данными. Бинарные данные — картинки и прочее не представимое текстом. Риббоны в офисе 2007 на мой вкус ужасны (хотя некоторым нравятся) — добраться до нужного функционала стало почти нереально (раньше было просто долго). Математические формулы удобно видеть в виде сложно-форматированного текста. В картинке часть текста не выделишь. Диалоговые окна — было и есть давно уже (в Delphi, редакторы форм в Netbeans/прочих IDE). Применяется очень мало где, ибо польза сомнительная (слишком большой оверхед получается по сгенерированному коду).
2. для текста диф уже вполне функциональный. Обучить его контексту языков — мало пользы и много гемороя. В некоторых языках компиляция кода с неинициализированной переменной невозможна (например — в Java при попытке использовать неиницаилизированные локальные переменные будет выдана ошибка компиляции). Т.е. это возможно но не для всех языков (для JS есть различные линтеры для этой же цели).
3. Логи уже давно опциональны. В Java при некотором желании можно даже динамически управлять их детализацией. Комменты в IDE можно настроить на сокрытие (возможно не во всех).
4. Для этого есть разные view и модели пакетирования кода. В некоторых языках — архитектурно нереализуемо. Хотя можно обеспечить какой-нибудь суррогат.
5. Идите в лес, грибочки собирать. Текстовые файлы исходного кода для каждого языка — и есть единый открытый формат для данного языка.
6. Давно есть (не во всех языках). В Java можно даже в работающее приложение пропихнуть обновлённый класс. Но релизную сборку всегда делают на чистой копии.
7. В том или ином виде давно реализовано. Опять же не для всех языков.
Ну а по итогу «возьмите-ка свою идею и… куда нибудь её утилизируйте». Всё о чём вы сказали или бред, или давно реализовано, или нереализуемо для части языков (я сомневаюсь что программисты c/c++ все поголовно мазохисты… вполне могли бы многое уже адаптировать идеи из других языков… но почему-то делается это далеко не со всеми идеями).
И статья — такая же бредовая. Нет пока более эффективного инструмента дающего сравнимую производительность. Просто из-за ограничений интерфейсов взаимодействия компьютер-человек. Вот когда будут нейроинтерфейсы, дающие возможно «думать в компьютер» — тогда появится что-то более удобное.ZavlabFF
01.06.2016 23:46Спасибо за ответ и за внимание webkumo и MonkAlex. «Манит меня в небесах тот звёздный свет, но достать его нелегко, хоть цель близка» (из песни). Буду думать.
Горы этого кода!!! Как Вы не запутываетесь?!webkumo
02.06.2016 10:25За других не скажу, но мой опыт последних лет — это разработка Java-бекэндов и JS-фронтендов.
В JS появились практки, делающие его более-менее модульным, Java всегда был модульным (мавен артефакты — внешний модуль + пакеты — внутренний модуль). Именно модульность с изоляцией неймспейсов значительно снижает потребность помнить что и где лежит и позволяет сосредоточиться на конкретных участках.
Сейчас в Java хотят дать внешней модульности более глобальное определение (обещают в 9ой выпустить).
PS но в конечном счёте всё упирается в конкретный проект… даже модульность не спасёт от лапши и классов по 3к строчек, если не следить за отсутствием антипаттернов.
Flammar
01.06.2016 21:15Ну, так как код — вещь древовидная, то, да, неплохо было бы иметь поддержку этой древовидности то ли на уровне ОС то ли ещё где-то на уровне среды. Чтоб невозможно было бы случайно как-нибудь поломать «всё» из-за удаления закрывающей или открывающей скобки. С хранением времени модификации (и, возможно, истории) каждого узла. С механизмами диффов, патчей и матчинга для древовидных структур.
Возникает, правда, уточняющий вопрос — а как насчёт переменных и прочего data flow, ведь современной программирование — оно «не столько про код, сколько про структуры данных»? Для начала можно его, чисто «императивно», обойти, посчитав, что хватит и «встроенной древовидизации» кода.
Тут мы рано или поздно опять, скорее всего, упрёмся в «нам нужен пятнадцатый стандарт», а так как уже есть «стандарт номер ноль» в виде тёплого лампового текста, то и «предыдущие 14 стандартов» с 99% вероятностью рискуют так и остаться непридумаными…
Draku1a
09.06.2016 02:42Старая шутка:
Настоящий программист пишет программы так:
«copy con file_prog.exe»
Есть среды разработки, которые хранят код и метаданные в одном файле. Например, 1С Предприятие. И, если не ошибаюсь, Flash. Даже макросы в Word или Excel — вместе с формами хранятся в документе.
Почему удобнее хранить код в виде текста? Именно потому — что так его проще и удобнее читать, удобнее искать файл по содержимому.
Karroplan
есть замечательный посыл — «если критикуешь, предложи альтернативу». потрындели-потрындели, и что?
tangro
А там вначале есть ссылка — Kythe. Это ещё не «оно самое», но хотя бы шаг в направлении. Мне интересно мнение людей о нём.