Папа Карло и инкрементальные компиляторы

[vanxant]

Забавно, что большинство выбирают тот же Sublime, а не какой-нибудь Eclipse, именно за то, что это текстовый редактор, а не IDE, и не подвисает в непредсказуемые моменты времени из-за попыток разбора.

[impwx]

Смотря на каком языке писать. Если язык со слабой динамической типизацией, то да, на нем реально проще писать в текстовом редакторе, потому что IDE все равно едва может подсказать что-то вменяемое. Если же брать языки вроде C# или Java, уверен что практически все разработчики пользуются инструментами типа Visual Studio + R# или Idea.

[VolCh]

потому что IDE все равно едва может подсказать что-то вменяемое

Посмотрите IDE от JetBrains для PHP, Python и Ruby.

[impwx]

Как раз сейчас по воле судьбы пришлось написать кое-что на PHP. Воспользовался PhpStorm 7.

AutoComplete работает только там, где данные можно считать из PhpDoc-комментариев. Кроме того, даже если комментарий есть, но указан тип mixed — тоже ничего не определишь, и очень много стандартных функций используют такой тип полиморфизма.

В некоторых случаях можно использовать явное указание типов в определении функции, но PHP как всегда отличился. Указания типов работают только для некоторых встроенных типов.

Проблема не в том, что ребята из JetBrains не постарались — даже наоборот, они проделали титаническую работу. Visual Studio 2012 примерно так же с трудом переваривает код на JS. Проблема в самой динамической типизации — за свободу действий приходится платить сложностью статического анализа.

[VolCh]

Ещё семёрку не ставил, но шестёрка вполне корректно выводит типы сама.

Сомневаюсь, что в семёрке это сломали :) Вкупе с phpdoc решает процентов 90 если не больше проблем с автодополнением, если динамической типизацией не злоупотреблять, переменные повторно не использовать и т. п. В общем использовать PHP примерно как, емнип, Scala.

[Maccimo]

Сравнивать code completion для PHP и для JS не совсем корректно.
Сделать приличный code completion для JS намного труднее, чем для PHP.
Хотя бы потому, что в PHP способы декларации полей и методов класса жёстко заданы, а в JS этих способов +∞ и какой-нибудь

jQuery.each(
  someMember.split(" "), 
  function(index, value) {
    jQuery.fn[value] = function(x) {};
  }
);

внезапно может понадобавлять кучу методов непонятно куда.

[impwx]

Совсем не обязательно. Объекты в JS — то же самое, что массивы в PHP. Ни одна среда разработки не подскажет вам, какие ключи следует ожидать массиве. И в PHP тоже можно намусорить в глобальную область видимости, например так:

<?php
if(mt_rand(1, 1000) < 500)
{
    function A($a) { echo 'A = ' . $a; }
}
else
{
    function B($a) { echo 'B = ' . $a; }
}

А еще можно вообще сделать eval, как и в JS. Повторюсь — если понимать под фразой «приличный code completion» качество подсказок, которое дают R# или Idea, то как для PHP, так и для JS это априори невозможно. Поэтому все среды разработки на динамических языках работают примерно одинаково: дают контекстные подсказки только локально, а для остального выдают полный список найденных в проекте идентификаторов.

[VolCh]

Та же Idea с PHP плагином показывает довольно адекватно подсказки, когда может автоматически вывести тип (грубо — во всем проекте только одно присваивание данной переменной, тип которого не вызывает сомнения) или есть актуальные phpdoc комментарии (плюс выявление заметной части противоречий между кодами и phpdoc).

[bigfatbrowncat]

Учитывая, что у eclipse есть только один аналог сходный по возможностям — IDEA — и тот платный и закрытый, вернее было бы говорить «не eclipse, а какой-нибудь sublime». А вообще говоря, не знаю, как у вас, а у меня в eclipse на сегодняшний день проблемы только с кособокой и недоделанной ADT. С CDT и тем более с JDT никаких проблем нет.

[Kirhgoff]

Я не знаю, про какой язык вы говорите, но в Scala я долго с муками цеплялся за любимый много лет Eclipse, а потом в какой то момент сел на IDEA и весьма ей доволен. Только шорткаты переделал на эклипсовские. И ничего она не платная, Community Edition ничем меня не ограничивает.

[eliah_lakhin]

А как на ваш взгляд с поддержкой Scala в NetBeans по сравнению с Idea? С NetBeans я работал совсем мало, слышал, что там тоже есть плагин для Scala, но пощупать не приходилось.

Если что, я вас не минусовал. И мне действительно интересен вопрос.

[spacediver]

Кастую монографию Мартина Фаулера «Domain Specific Languages».

[lorus]

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

[eliah_lakhin]

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

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

[kosiakk]

Jetbrains Nitra примерно про то же?

[eliah_lakhin]

Достаточно разные вещи. Nitra по большому счету — это еще один инструмент для разработки плагинов для IntelliJ Idea, путем расширения синтаксиса существующих языков в некоторых заданных рамках.

Если все же сравнивать:

* Nitra больше про расширение существующих языков. Papa Carlo — вполне традиционный парсер-комбинатор.
* Подход Nitra — все из коробки. Papa Carlo — отдельная библиотека для бесшовного связывания с другими компонентами компилятора.
* У Nitra свой синтаксис, свой отдельный язык. Papa Carlo — API для Scala или Java.
* Nitra скорее всего будет завязан на разработку языковых плагинов/расширений именно под продукты JetBrains. Papa Carlo не привязан ни к каким конкретным продуктам. Его можно использовать и для Eclipse, и для Sublime Text или даже для Vim и Emacs.

Надо сказать, Nitra не первая попытка JetBrains сделать систему для построения DSL поверх существующих языков. До этого еще был MPS. А еще у Eclipse есть похожий проект — Xtet

[worker4food]

Не такие уж и разные. Nitra — развитие вот этой библиотеки за деньги JetBrains. И с первого взгляда, разницы между PapaCarlo и Nemerle.PEG особой и нет, кроме того что там не java, а .net. Хотя это, конечно не отменяет того факта, что разработчики упорно Нитру называет «фреймворком для создания языков».

[eliah_lakhin]

Интересно, спасибо за ссылку. Надо будет изучить поподробнее.

А как там, в PegGrammar-Macro, с инкрементальным разбором? Это в общем-то ключевой момент. PEG парсеров довольно много, и не только на Nemerle со Scala, конечно. Но почти все они не поддерживают инкрементальный парсинг.