Comments 22
Забавно, что большинство выбирают тот же Sublime, а не какой-нибудь Eclipse, именно за то, что это текстовый редактор, а не IDE, и не подвисает в непредсказуемые моменты времени из-за попыток разбора.
Смотря на каком языке писать. Если язык со слабой динамической типизацией, то да, на нем реально проще писать в текстовом редакторе, потому что IDE все равно едва может подсказать что-то вменяемое. Если же брать языки вроде C# или Java, уверен что практически все разработчики пользуются инструментами типа Visual Studio + R# или Idea.
потому что IDE все равно едва может подсказать что-то вменяемое
Посмотрите IDE от JetBrains для PHP, Python и Ruby.
Как раз сейчас по воле судьбы пришлось написать кое-что на PHP. Воспользовался PhpStorm 7.
AutoComplete работает только там, где данные можно считать из PhpDoc-комментариев. Кроме того, даже если комментарий есть, но указан тип mixed — тоже ничего не определишь, и очень много стандартных функций используют такой тип полиморфизма.
В некоторых случаях можно использовать явное указание типов в определении функции, но PHP как всегда отличился. Указания типов работают только для некоторых встроенных типов.
Проблема не в том, что ребята из JetBrains не постарались — даже наоборот, они проделали титаническую работу. Visual Studio 2012 примерно так же с трудом переваривает код на JS. Проблема в самой динамической типизации — за свободу действий приходится платить сложностью статического анализа.
AutoComplete работает только там, где данные можно считать из PhpDoc-комментариев. Кроме того, даже если комментарий есть, но указан тип mixed — тоже ничего не определишь, и очень много стандартных функций используют такой тип полиморфизма.
В некоторых случаях можно использовать явное указание типов в определении функции, но PHP как всегда отличился. Указания типов работают только для некоторых встроенных типов.
Проблема не в том, что ребята из JetBrains не постарались — даже наоборот, они проделали титаническую работу. Visual Studio 2012 примерно так же с трудом переваривает код на JS. Проблема в самой динамической типизации — за свободу действий приходится платить сложностью статического анализа.
Ещё семёрку не ставил, но шестёрка вполне корректно выводит типы сама.
Сомневаюсь, что в семёрке это сломали :) Вкупе с phpdoc решает процентов 90 если не больше проблем с автодополнением, если динамической типизацией не злоупотреблять, переменные повторно не использовать и т. п. В общем использовать PHP примерно как, емнип, Scala.
Сомневаюсь, что в семёрке это сломали :) Вкупе с phpdoc решает процентов 90 если не больше проблем с автодополнением, если динамической типизацией не злоупотреблять, переменные повторно не использовать и т. п. В общем использовать PHP примерно как, емнип, Scala.
Сравнивать code completion для PHP и для JS не совсем корректно.
Сделать приличный code completion для JS намного труднее, чем для PHP.
Хотя бы потому, что в PHP способы декларации полей и методов класса жёстко заданы, а в JS этих способов +∞ и какой-нибудь
внезапно может понадобавлять кучу методов непонятно куда.
Сделать приличный code completion для JS намного труднее, чем для PHP.
Хотя бы потому, что в PHP способы декларации полей и методов класса жёстко заданы, а в JS этих способов +∞ и какой-нибудь
jQuery.each(
someMember.split(" "),
function(index, value) {
jQuery.fn[value] = function(x) {};
}
);
внезапно может понадобавлять кучу методов непонятно куда.
Совсем не обязательно. Объекты в 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 это априори невозможно. Поэтому все среды разработки на динамических языках работают примерно одинаково: дают контекстные подсказки только локально, а для остального выдают полный список найденных в проекте идентификаторов.Та же Idea с PHP плагином показывает довольно адекватно подсказки, когда может автоматически вывести тип (грубо — во всем проекте только одно присваивание данной переменной, тип которого не вызывает сомнения) или есть актуальные phpdoc комментарии (плюс выявление заметной части противоречий между кодами и phpdoc).
Учитывая, что у eclipse есть только один аналог сходный по возможностям — IDEA — и тот платный и закрытый, вернее было бы говорить «не eclipse, а какой-нибудь sublime». А вообще говоря, не знаю, как у вас, а у меня в eclipse на сегодняшний день проблемы только с кособокой и недоделанной ADT. С CDT и тем более с JDT никаких проблем нет.
Я не знаю, про какой язык вы говорите, но в Scala я долго с муками цеплялся за любимый много лет Eclipse, а потом в какой то момент сел на IDEA и весьма ей доволен. Только шорткаты переделал на эклипсовские. И ничего она не платная, Community Edition ничем меня не ограничивает.
UFO just landed and posted this here
UFO just landed and posted this here
Кастую монографию Мартина Фаулера «Domain Specific Languages».
Так а что в этом проекте помогает инкрементальной компиляции? Парсер — это тривиальная задача по сравнению с собственно компилятором.
Папа Карло не только инкрементально разбирает исходный код, но и сохраняет незатронутые куски AST инввариантными(каждый узел имеет свой идентификатор — уникальный на все время работы компилятора). Таким образом, любые сущности, которые вы нацепите на AST в следующих фазах компиляции, включая семантические связи и байт-код, будут также сохранены и могут быть переиспользованы.
Согласен, что при ряде ограничений разработка бэкэнда инкрементального компилятора может тоже оказаться весьма нетривиальной проблемой, но я не стал бы вот так легко списывать со счетов фронтэнд.
Согласен, что при ряде ограничений разработка бэкэнда инкрементального компилятора может тоже оказаться весьма нетривиальной проблемой, но я не стал бы вот так легко списывать со счетов фронтэнд.
Jetbrains Nitra примерно про то же?
Достаточно разные вещи. 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
Если все же сравнивать:
* 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
Не такие уж и разные. Nitra — развитие вот этой библиотеки за деньги JetBrains. И с первого взгляда, разницы между PapaCarlo и Nemerle.PEG особой и нет, кроме того что там не java, а .net. Хотя это, конечно не отменяет того факта, что разработчики упорно Нитру называет «фреймворком для создания языков».
Sign up to leave a comment.
Папа Карло и инкрементальные компиляторы