Обсуждение

к вопросу о формате файла - я рассматриваю вариант встраивания кода в текстовый файл - аналогично тому, как PHP встраивается в HTML:

meta source="text" name="example_text"
Здравствуй, мир!
/meta

meta source="pl2" name="example3"
    {
         Console.write_line(source["example_text"].text);
    }
/meta

варианты значений source: solution - сложное программное решение из нескольких пакетов или файлов, package - проект из нескольких исходных файлов, text - многострочный текст, form - описание формы XAML, menu - описание меню, scene - сцена LUA, table - таблицы - перечисление однообразных данных, tree - иерархические деревья, sql, html, xml, vrml, pl2, ... https://github.com/palexisru/pl2_rus/wiki/file-source , https://github.com/palexisru/pl2_rus/wiki/source-meta

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

Я это понимаю. Всё, что я пишу, выходит за рамки IDE, поэтому в плане окупаемости ещё хуже: стоимость разработки инструментария много превышает стоимость разработки прикладных продуктов на этом инструментарии. На том же Западе такие работы делаются в виде крупных opensource проектов со многими источниками финансирования (например, экосистема Eclipse так была сделана -- вокруг большого вклада IBM, но он там явно был не единственным). В России такого сорта проекты вообще непонятно как разворачивать: нет культуры промышленных консорциумов (когда конкуренты сбрасываются по чуть-чуть на что-то полезное в плане инфраструктуры и инструментария).

Окупается в разных нишах. Например, каждый полноценный движок в геймдеве содержит в своём составе IDE. А на IDE для программистов зарабатывают те же JetBrains. Это если не брать закрытые (т.е. без пользовательских плагинов) решения по "интеграции с говном и торфом" для разных энтерпрайзных бизнес-кейсов, коих немеряно. Или там IDE для писателей (Scrivener). Или... В общем, как и с другими продуктами, деньги надо считать, грамотных спецов искать. Иначе да, ничего и никак.

Но как от опытного в разработке IDE человека был бы благодарен за содержательную критику (хотя я понимаю, что критиковать на данной стадии ещё практически нечего). Ибо полностью согласен с аргументом, что для разработки Editor, IDE, Studio и даже простых компиляторов, для всего этого "системного программирования" нужна высокая квалификация и с ней нужно сделать очень много работы.

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

Эмм.. Почти весь Eclipse был когда-то частью WebSphere -- коммерческой IDE от IBM, которую для пиара отдали на open source, а продавали за $1000 корпоративным пользователям с J2EE. Дальше IBM на ней зарабатывала написанием разных модулей для корпоративных заказчиков (собственно, это основной способ заработка IBM -- где-то за $200/час). Ну и другие тоже зарабатывали, собственно. Например, IBM написали для PHP новую версию Zend IDE (а одну из прошлых версий наша контора писала). Понимаете теперь, как на IDE зарабатывать и кто зарабатывает? Кто-нибудь с деньгами хочет IDE для пиара своего языка программирования или для увеличения продуктивности своих сотрудников (бюджет простой: повышение эффективности 10 сотрудников на 10% за год при ЗП в $100k обойдётся в $100k, которые можно потратить на IDE). Вот основной способ заработка и основная причина разработки IDE. А Open Source тут вообще не при чём, это просто вишенка на торте. Бюджет разработки IDE -- от $500k. Кстати, неплохая аналогия для высококачественной IDE, чтобы ощутить сложность задачи -- офисные приложения (всякие Word, Excel, Powerpoint). Сколько не-MSFT-овских вордов сделали за последние три десятилетия?

Про бюджет я ответил выше. А про разработку -- квалификация нужна по причине сложности продукта. В Eclipse порядка миллиона строк кода. Несколько месяцев уйдёт только чтобы в этом прилично разобраться! А потом нужно ещё писать десятки тысяч строк, чтобы реализовать сотни фич типа "комментарий", "форматирование текста", "синтаксический анализ языка Z", "статический анализ языка Z". И каждая такая фича -- это недели или даже месяцы работы. Сто фич по неделе на фичу -- это уже два человеко-года. А ещё столько же надо заложить на тестирование и багфиксинг, и в 3 раза больше, чем программирование+багфиксинг вместе, если вы хотите делать из этого продукт, а не поделку (ибо сбор требований, продажи, маркетинг, документация). Это вообще rule of thumb в разработке продуктов: 1/6 программирование, 1/6 тестирование, 2/3 -- всё остальное. Но если вы возьмёте готовый компонент редактора, готовый компонент графического редактора, готовый статический анализ, и не захотите делать кастомные(улучшенные) версии этих компонент -- то, конечно, можно существенно снизить объём программистской работы. Процентов на 80. Но: вспомним про вашу связь "многие-ко-многим" между представлениями данных в разных views. Сколько у вас уйдёт лет, чтобы отловить все баги в вашей реализации (которая к тому же будет постоянно изменяться-улучшаться)? (Именно поэтому такие большие бюджеты. $500k -- это всего 5 лет одного хорошего программиста в Америке. Если набирать программистов со всего мира -- можно снизить почасовую ставку раза в три. Ну, будет $150k за 5 человеко-лет.) Так что прикиньте свои фичи, посчитайте человеко-годы, вздохните, и займитесь чем-нибудь ещё :) До тех пор, пока у нас нет компьютера, чтобы он за нас программировал и делал индивидуальные динамические интерфейсы на заказ (начиная с чего-то типа описанного в "Ишкушштвенный интеллект", и заканчивая интерфейсом из "Харизмы" Каганова), делать IDE -- пустая трата времени.

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

Очень хороший у вас пример с office! В VPRI как раз сделали такой проект ровно чтобы показать избыточность кодирования в подобных проектах (хотя там они всё-таки решили пооптимизировать в какой-то момент, что снизило значимость происходящего). Вот тут: http://www.vpri.org/pdf/tr2012001_steps.pdf (там задача была -- показать, что принципиально можно утрамбовать сложность приложения для personal computing, т.е. оффиса, в 20тыс. строк. Это последний отчёт, предыдущие были не менее интересны, как и многие работы на http://vpri.org/html/writings.php). Ещё интересное направление, которое появилось в связи с IDE, так это приходящие со стороны node.js фреймворки. То есть мысль не стоит на месте. Но что бюджет для значимых на уровне глобуса исследований в направлении IDE от $500K, я с этим спорить даже не буду: там нужно будет сделать systems framework, на нём наваять плагины для предметной области, а на получившемся моделере продемонстрировать моделирование в какой-то предметной области, т.е. три проекта в одном. Деньги же обычно дают только за моделирование в предметной области, даже не за написание моделеров. Хотя в предпринимательстве и бывают и другие примеры, весьма неожиданные для всех (кроме команд, тяжело работающих для их получения) успехи.

Ну, даже многие редакторы не обновляются. TextMate загнулся, например, и про Komodo давно не слышно, уж не говоря про питоновские поделки типа SPE.

Конечно можно утрамбовать, если 90% фич зарезать. Даже если отвлечься от растущей стоимости поддержания кодобазы, стоимость разработки в IDE -- по сути, квадрат от количества фич, потому что фичи можно сочетать с любыми другими фичами, а значит, взаимодействия между фичами, которые нужно программировать, растут квадратично. Так что зря вы мне тут увлечённо рассказываете, что можно сделать IDE с одной фичей за неделю. Ну можно, кто же спорит, вот даже пример: https://github.com/antirez/kilo Но я хоть убей не понимаю, что в подобном минимализме интересного. Ведь ценность новой IDE выше старых, только когда у новой IDE больше фич, чем у старой! Ценность в IDE -- интеграторская работа.

Ну, кроме полного согласия с вами написанным, у меня два контраргумента: 1. Архитектурно уже довольно много известно про IDE строительство, можно не повторять громоздкость Eclipse в полном объеме. Есть линия node.js и тамошних последователей (в принципе, это необязательно даже на JavaScript повторять, тамошние идеи начали развиваться и на разных других языках), есть уже приводимый мной пример работы VPRI, где отрабатывается идея "вычислений/моделирования/редактирования общего вида" и малости кода для такой работы. 2. Совершенно верно, у меня там прописана intellect-studio, так что вполне возможен какой-то bootstrapping через повышение уровня intellisence, вплоть до помощи в генерации каких-то кусков кода и помощи в отладке. Это может совсем не помогать в начале разработки, но неожиданно может давать эффекты в конце разработки. И да, отношение затрат, нервов и времени "треть к двум третям" работ от состояния "программа, наконец, работает" до стадии "продукт" я знаю. Пока об этом не говорим. Говорим о постановке задачи: осмысленна ли она, или нет? Забыл ли я какие-то важные части системы, или нет? Принципиально возможно ли такое создавать, или не получится по каким-то теоретическим (не бизнес) причинам? Опять же, можно ничего не делать -- и наблюдать, как лет за десять все эти JetBrains и Eclipse Foundations доползут примерно в ту точку, о которой я говорю. Можно посчитать инвестиции в попкорн, гарантированно меньше, чем на какую-то работу )))

Тут можно заметить, что много редакторов и не нужно, особенно если появляются удачные. Atom, например, свеж -- и многие на него переходят, несмотря на расцвет Sublime. А до этого удачка была у Notepad++. У IPython, наоборот, расцвет в виде Jupyter. Сам факт загибания одних продуктов и прихода новых других ещё ни о чём не говорит. Это и есть "прогресс" )))

Я рад, что вы поддерживаете мой аргумент, что все эти systems frameworks -- операционные системы, ибо наблюдение про размер кода для операционных систем в зависимости от фич (не любых, конечно, а ровно тех, о которых мы тут говорим -- многозадачность, многопользовательскость и т.д. из этой крупной серии) было впервые сделано в отношении операционных систем, ну и ещё дополнительно сложность в системном программировании увеличивается от того, что есть программирование поверх них: Word and Excel and PowerPoint and other Microsoft programs have intimate — one might say promiscuous — knowledge of each others' internals. In Unix, one tries to design programs to operate not specifically with each other, but with programs as yet unthought of (Doug McIlroy, 2003). Тем не менее, и с таким потихоньку научаются бороться. Все эти микросервисы, RESTful стили, учёт CAP-теорем и NoSQL и т.д.. Мир не стоит на месте. Опять же, можно понимать, с какого места начинать: сразу брать что-то типа http://electron.atom.io/ и идти дальше по накатанной линии JavaScript (зная, какая стена ждёт тебя через буквально пару месяцев такого пути), или пойти по линии решающего похожие проблемы https://github.com/shashi/Escher.jl с выбором расширяемого Julia в качестве системного языка, и писать многое почти с нуля и не зная, какая именно стена ждёт тебя через буквально пару месяцев такого пути (она тоже будет ждать, конечно, но другая). И таких решений, конечно, при старте проекта будет пара десятков. Когда мы начинали делать онтологический редактор (там ведь тоже вполне себе IDE, "проект" поддерживается), то выкинули на помойку семь codebases, до финиша дошла только восьмая версия написанного с нуля кода. Менялось всё, даже библиотека GUI. Вот: https://github.com/TechInvestLab/dot15926

Не доползут. Всё рассыпается под собственной тяжестью. Пока принципиально подход -- способ борьбы со сложностью -- не поменяется, все будут наступать на одни и те же грабли. В Ace и cloud 9 нет ничего особенного -- просто браузер берет часть фич на себя. Но тормозить от этого всё начинает жутко, потому что вместо молотка используют микроволновку.

Тормозит этот atom просто ужасно. Большая задержка при печати, на больших файлах вообще не работает. Большая часть горячих клавиш недоступна. И это редактор, а не ide. Фич мало.

Jupyter -- это редактор. Внутри -- codemirror, подсветка 20 строк в секунду, чтобы не тормозило работу, и жуткие костыли во многих местах. Фич мало опять же. Ну, я бы аналог jupyter за неделю-две собрал из готовых компонент. Но дальше-то что?

Вот, это правильно: нужно принципиально менять способ борьбы со сложностью. Интересно было бы узнать, какие вы предлагаете для этого варианты.

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