C vs. JVM's benchmark

>Да, это их проблема, ибо они пишут неполноценные плугины.

Это что за ярлык "неполноценные"? Для кого неполноценные? Я на руби работал - нормально. На жаваскрипте пользую - замечательно. Скоро доберусь до скалы. Чето мне кажется и это будет нормально. Ant - прерасно. XML шикарно. HTML - вплоть до укзания неправильных размеров картинки. ЧЯДНТ?

"Неполноценные" плугины - астрономически большще умеют чем "sed + awk".

>Компиляторы значит на C пишутся, семантику понимают, анализаторы синтаксиса тоже есть, а вот внезапно сделать из этого анализатор кода становится невозможно. Интересное кино.

Подтверждено жизнью.

>Сюрприз -- рефакторизаторы не нужны. Грепа выше крыши.

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

> Это что за ярлык "неполноценные"? Для кого неполноценные?

Неполноценные потому что не покрывают весь язык.

Говорю не голословно, потому что в своё время занимался дописыванием tcl debugger-а для работы с конструкциями ensemble из [incr]tcl, потому что он их не знал и воспринимал как текст.

> "Неполноценные" плугины - астрономически большще умеют чем "sed + awk".

Есть у меня модуль, который на 20-30% состоит из самописных конструкций языка. И я знаю, что любой неполноценный плугин мне в нем в лучшем случаеоткажется работать. Потому что идеи, как выделять подобные структуры нет даже на словах, не то что в коде.

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

Это вызов на пиписькомеряние? :) Проект не сильно большой, всего 10 человек(идею-то меньшей толпой писали).

Но постоянные фиксы ошибок, полученных с помощью "умных" плагинов("отсохшие" функции в jsp, старые имена классов в гибернейтовских запросах, закешированные данные, ставшие невалидными после общения с веб-частью...), уже достали.

>Неполноценные потому что не покрывают весь язык.

Критерий покрытия всего языка - ты сам придумал,

>Это вызов на пиписькомеряние?

Нет, на применимость замечаний типа "у меня есть модуль", "зараннее продумать" и прочую подобную фигню к реальной жизни.

> Нет, на применимость замечаний типа "у меня есть модуль", "зараннее продумать" и прочую подобную фигню к реальной жизни.

В _гибком_ языке подобное проблем не вызывает. А для правки негибкого человеческих сил не хватает, приходится использовать костыли с сервоприводом.

>> Неполноценные потому что не покрывают весь язык.

> Критерий покрытия всего языка - ты сам придумал

Не я. Пословица "назвался груздем -- полезай в кузов" была придумана задолго до меня. Назвался супермегатулой для работы с кодом -- изволь покрыть все случаи.

>В _гибком_ языке подобное проблем не вызывает. А для правки негибкого человеческих сил не хватает, приходится использовать костыли с сервоприводом.

В гибком символы ренеймятся по всей кучу исходников как-то подругому или что? В гибком функции экстрактятся с поиском дубликатов как-то подругому или что? Пример можно такого "гибкого" языка? И что обозначает гибкого - гнется хорошо?

> Назвался супермегатулой для работы с кодом -- изволь покрыть все случаи.

То есть возвращаясь к экскаватору и лапате - эксковатор вещь в археологии впринципе не применимая - равно как и лопата, а как же назвался груздем - изволь откопать черепки не повреждая - не можешь - бери кисточку и снимай первые 8 метров слоя почвы кисточкой - правильно?

> В гибком символы ренеймятся по всей кучу исходников как-то подругому или что? В гибком функции экстрактятся с поиском дубликатов как-то подругому или что?

Гибкий язык позволяет не заострять внимание на вышеперечисленном. А в сочетании с наличием вменяемого стиля(в частности, запрещающего называть глобальные переменные i или j) и продуманной архитектурой, отражающей задачу, а не притянутой к какой-то объектной модели, переименовывать символы, выделять интерфейсы или экстрактить функции становится редкой задачей.

> Пример можно такого "гибкого" языка?

tcl

> И что обозначает гибкого - гнется хорошо?

ГИБКИЙ, гибкая, гибкое; гибок, гибка, гибко.

1. Легко сгибаемый, упругий. Гибкая ветка. Гибкий хлыстик. Гибкий стан.

2. перен. Успешно разрешающий разнообразные, частые затруднения (книжн.). Гибкая политика. Гибкое законодательство. Гибкий ум.

Толковый словарь Ушакова

>> Назвался супермегатулой для работы с кодом -- изволь покрыть все случаи.

> То есть возвращаясь к экскаватору и лапате - эксковатор вещь в археологии впринципе не применимая - равно как и лопата, а как же назвался груздем - изволь откопать черепки не повреждая - не можешь - бери кисточку и снимай первые 8 метров слоя почвы кисточкой - правильно?

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

Опять же возникает вопрос, к какому языку применяется мегатул. К бейсику или турбо паскалю(без ifdef-ов) он применим на 100%, к яве -- пусть на 99. При дальнейшем движении к большей гибкости языка получаем асимптотическое сближение возможностей МегаТула и sed/grep.

>Гибкий язык позволяет не заострять внимание на вышеперечисленном

То есть не заниматься разработкой на оном - да?

>А в сочетании с наличием вменяемого стиля(в частности, запрещающего называть глобальные переменные i или j)

А так же поля структур одинаковыми именами с другими структурами.

>продуманной архитектурой,

Которая естественно может быть продумана вплоть до имен функций и их структуры для 5летнего проекта с изменяющимися требованиями методом применения телепатических способностей.

Фантастика.

>tcl

Пользуюсь. Хочу иметь extractы и ренеймы.

>При дальнейшем движении к большей гибкости языка получаем асимптотическое сближение возможностей МегаТула и sed/grep.

Ты сейчас говоришь о том что я не должен верить своим глазам видя языковые плугины в идее и эклипсе. Извини - но я им верю. _Работает_.

>> продуманной архитектурой,

> Которая естественно может быть продумана вплоть до имен функций и их структуры для 5летнего проекта с изменяющимися требованиями методом применения телепатических способностей.

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

>> tcl

> Пользуюсь. Хочу иметь extractы и ренеймы.

В силу свойств языка подобное автоматически сделать невозможно. Да и если писать на тикле, а не на яве с синтаксосом тикля(ну помнишь шутку про программистов на фортране), то сложно написать код, в котором это будет часто надобиться.

> Ты сейчас говоришь о том что я не должен верить своим глазам видя языковые плугины в идее и эклипсе. Извини - но я им верю. _Работает_.

Я уже показывал, что эти плугины вызывают грабли.

Кстати, сходил на страничку dltk. Судя по увиденному, они для каждой тиклевской языковой конструкции городят дополнительный обработчик. Интересно вот, теперь каждый разработчик более-менее приличной либы для tcl должен снабжать её плагином к эклипсу?

>В силу свойств языка подобное автоматически сделать невозможно.

Серьезно? Невеозможно взять выделенный кусок кода, определить передаваемые внешние символы и и символы выходящие за пределы выделенного участка и первые сделать параметроами нового прока а последние возвращаемым значением?

Я удивляюсь как компилятор такое хендлит.

>Я уже показывал, что эти плугины вызывают грабли.

Количество граблей - ничтожно мало пос сравнению с количеством полезных функций. У меня жаба с текстовм эвалом и кучка проектов по 5 лет возрастом - грабли наступаются раз в год.

>Интересно вот, теперь каждый разработчик более-менее приличной либы для tcl должен снабжать её плагином к эклипсу?

Он может это делать, это может делать коммунити, автор плугина может поставлять станжартные билиотеки.

Ты сейчас задаешь вопрос аналогичны "а что каждый разработчик либы на С должен предоставлять биндинги к жабе, пыху, питону, руби,.... "нужное подчеркнуть"?

Нет не должен - кому понадобиться сделают.

Для zsh же написано комплишенов? Пример:

~> chmod <tab>
a -- all
g -- group
o -- others
u -- user
\= - +

<tab>

~> chmod a
a -- all
g -- group
o -- others
u -- user
\= - +

<+>

~> chmod a+
X -- execute only if executable to another
g -- group's current permissions
o -- other's current permissions
r -- read
s -- set uid/gid
t -- sticky
u -- owner's current permissions
w -- write
x -- execute

<x><tab>

~> chmod a+x
X -- execute only if executable to another
g -- group's current permissions
o -- other's current permissions
r -- read
s -- set uid/gid
t -- sticky
u -- owner's current permissions
w -- write


и т.д. Работает? Вот - живой пример комплишена аналогичного для тикля.

> Серьезно?

Да.

> Невеозможно взять выделенный кусок кода, определить передаваемые внешние символы и и символы выходящие за пределы выделенного участка и первые сделать параметроами нового прока а последние возвращаемым значением?

Невозможно уже отделить код от данных, потому и невозможно указанное. Да и как быть с uplevel, upvar, которые ссылаются на другой фрейм стека?

> Я удивляюсь как компилятор такое хендлит.

У тикля нет компилятора. Это всё и объясняет.

> Количество граблей - ничтожно мало пос сравнению с количеством полезных функций. У меня жаба с текстовм эвалом и кучка проектов по 5 лет возрастом - грабли наступаются раз в год.

Ключевое слово "жаба". В других местах(в тикле в частности) при условии существования столь же мощных по количеству фич плагинов, грабли будут расти.

>> Интересно вот, теперь каждый разработчик более-менее приличной либы для tcl должен снабжать её плагином к эклипсу?

> Он может это делать, это может делать коммунити, автор плугина может поставлять станжартные билиотеки.

Дело в том, что без этого код получится незнакомым для МегаТула, как у меня было с конструкцией ensemble. В яве такого случиться не может.

> Для zsh же написано комплишенов? Пример: ... и т.д. Работает? Вот - живой пример комплишена аналогичного для тикля.

Да понятно что для proc/namespace/if/switch/for можно написать МегаТул. И они уже написаны не раз. А там уже зависит от того, на сколько тиклевских библиотек хватило терпения у плагинописателя в определении шаблонов для разбора. А библиотек, использующих хотя бы замыкания -- уже дохренищи. И для каждой придётся прописывать шаблоны.

>Невозможно уже отделить код от данных, потому и невозможно указанное.

Я удивляюсь как его кто-то может интерпретировать если невозможно выделить символы.

>Да и как быть с uplevel, upvar, которые ссылаются на другой фрейм стека?

Точно также. инкрементируются при экстракте - декрементируются при инлайне.

>У тикля нет компилятора. Это всё и объясняет.

http://www.tcl.tk/software/tclpro/compiler.html

>Ключевое слово "жаба". В других местах(в тикле в частности) при условии существования столь же мощных по количеству фич плагинов, грабли будут расти.

Жаваскрипт и руби - тоже клиючевые слова. Как иссылки их нежабских файлов на жабские символы.

>Дело в том, что без этого код получится незнакомым для МегаТула, как у меня было с конструкцией ensemble. В яве такого случиться не может.

Это слдучается в любом динамическом языке. И вот подиж ты - есть мегатулы.

>Да понятно что для proc/namespace/if/switch/for можно написать МегаТул

Уже немало.

>А там уже зависит от того, на сколько тиклевских библиотек хватило терпения у плагинописателя в определении шаблонов для разбора.

Еще больше.

>А библиотек, использующих хотя бы замыкания -- уже дохренищи. И для каждой придётся прописывать шаблоны.

Да жить вообще страшно - софт какой-то разрабатывать.

> Замечательно. Теперь сделайте очевидный вывод - шарп по скорости та же жаба. По потрохам - та же жаба. ТАк в чем проблема? А в культуре - и все. MS пересадил своих программистов с делфи и С++ на С# - вот и появились прикладки на C#. НА жабу никто не пересаживал десктопных программистов. Но это ничего не говорит о подходимости и неподходимости жабы.

Результат один - битва за декстоп проиграна. Остались сервера где важна безопасность, простой язык, куча либ. Может питон?

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

Джетбрейнс говорит что у них ушло 8-10 человек лета на разработку синтаксического анализатора для C#. Грамматика и семантика плюсов существенно сложнее, в рамках опен соурс поднять такую штуку сложно, тем более что плюсы это не горячая тема.

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

Еще одна сложность - моделирование. Для плюсов реверс-инжениринг сложнее и нетакой очевидный как для Java/C#.

>Результат один - битва за декстоп проиграна.

Как вы вообще с таким подходом за сосущий на десктопе линукс сели то?

> Как вы вообще с таким подходом за сосущий на десктопе линукс сели то?

Да неплохой конструктор.

>> Невозможно уже отделить код от данных, потому и невозможно указанное.

> Я удивляюсь как его кто-то может интерпретировать если невозможно выделить символы.

Логично. Но у меня есть другой пример: почти все стандартные функции имеют побочные эффекты, будь то if, switch или for. Переменные, установленные внутри них существуют и после завершения их выполнения.

>> У тикля нет компилятора. Это всё и объясняет.

> http://www.tcl.tk/software/tclpro/compiler.html

Слово "байткод" что-нибудь говорит? Это недокомпилятор, который (упрощённо) делит содержимое предопределённых конструкций(proc, if, for и т.д.) на list<pair<command,list<string>>. На большее он не способен.

>> Да понятно что для proc/namespace/if/switch/for можно написать МегаТул

> Уже немало.

Зависит от широты использования самодельных конструкций. Если они почти не используются, то ничего страшного. А чем дальше с лес, тем меньше пользы от мегатула.

>> А библиотек, использующих хотя бы замыкания -- уже дохренищи. И для каждой придётся прописывать шаблоны.

> Да жить вообще страшно - софт какой-то разрабатывать.

Не понимаю юмора. Фактически, для того, чтобы получить нормально функционирующий рефакторизатор, я буду вынужден к каждой конструкции своего кода дописывать ещё какую-то дополнительную информацию. Фактически, получается, что я начинаю писать уже не на tcl, а на tcl+refactordata. Причём ещё неизвестно, насколько много придётся писать этой дополнительной инфы и не получится ли её раз в 20 больше кода.

>Слово "байткод" что-нибудь говорит?

От этого он перестает быть компилятором? А жаба во что компилиться в астрал?

>Это недокомпилятор, который (упрощённо) делит содержимое предопределённых конструкций(proc, if, for и т.д.) на list<pair<command,list<string>>.

То есть он таки способен найти символы и что-то с ними сделать?

>Фактически, для того, чтобы получить нормально функционирующий рефакторизатор, я буду вынужден к каждой конструкции своего кода дописывать ещё какую-то дополнительную информацию.

Это только в том случае если ты хочешь чтобы он понимал твою конструкцию как некую высокоуровневую штуку, а не как набор проков.

Опять же если взять либы типа tk - большие популярные библиотеки - для них раз написанное будет помогать многим. А если у тебя маленький скриптец - то конечно его можно и в vi набросать.

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

>> Это недокомпилятор, который (упрощённо) делит содержимое предопределённых конструкций(proc, if, for и т.д.) на list<pair<command,list<string>>.

> То есть он таки способен найти символы и что-то с ними сделать?

В общем случае нет. Он способен выделить лексемы(надеюсь, я не ошибся с термином). Остальное возможно в вырожденных частных случаях.

Пример "нехорошего" кода: set s set; $s a puts; $s $a hello; $a [ $s $a ]

>> Фактически, для того, чтобы получить нормально функционирующий рефакторизатор, я буду вынужден к каждой конструкции своего кода дописывать ещё какую-то дополнительную информацию.

> Это только в том случае если ты хочешь чтобы он понимал твою конструкцию как некую высокоуровневую штуку, а не как набор проков.

Вернее, набор строк. В этом случае МегаТул оказывается бесполезен, а то и вреден. (Пусть я заюзал неизвестную ему библиотечную конструкцию try-catch-finally и заставил заэкстрактить часть кода в отдельную процедуру)

> Опять же если взять либы типа tk - большие популярные библиотеки - для них раз написанное будет помогать многим. А если у тебя маленький скриптец - то конечно его можно и в vi набросать.

В tk и запутаться-то нельзя, там всё и ез того прозрачно. Да, можно для всех десяти виджетов и всех пяти команд прописать, за каким ключом идёт замыкание, за каким -- текст, а за каким -- имя переменной.

Но это бесполезно, потому что сразу же будет сломано циклом foreach для постройки виджетов или чем-нибудь подобным. Или вступит в конфликт со сложившимся стилем: например, параметр -command у scrollbar принято давать в кавычках, а не фигурных скобках, чтобы единожды подставить путь к скроллируемому виджету и не таскать глобальную переменную.

Да, я не спорю, можно найти подмножество языка, на котором всё это будет работать эффективно. Но это будет кастрированный tcl.

> В любом случае - наличие такой тулзы будет помогать, а в случае отсутствия "метаинформации" для тулзы ты получишь просто для определенных бибьлиотек отсуствие таких возможностей -

Медвежью услугу оно будет делать. Будет вроде как уметь узнавать переменные, модифицировать код, но код после работы робота надо будет долго и тщательно перепроверять. Теряется преимущество автоматической работы.

> так ты и сейчас в таком положении - только для _всех_ библиотек.

И не страдаю, потому что язык предоставляет достаточно гибкости для того, чтобы излагать мысль именно в натуральном виде, не встраиваясь в рамки, установленные дядей Гослингом.

>set s set; $s a puts; $s $a hello; $a [ $s $a ]

И что в нем нехорошего?

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

Та с чего бы это?

>Будет вроде как уметь узнавать переменные, модифицировать код, но код после работы робота надо будет долго и тщательно перепроверять

С какой стати - покажи пример кода и пример рефакторинга который на нем загнется.

>> set s set; $s a puts; $s $a hello; $a [ $s $a ]

> И что в нем нехорошего?

Нельзя понять, что во второй и третьей инструкции будут объявлены новые переменные. А если развернуть их значения, нельзя понять что переменная puts и функция puts -- это не одно и то же.

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

> Та с чего бы это?

foreach w {label button} {pack [ $w .$w ]} . Хочу автодополнение параметра -text

>> Будет вроде как уметь узнавать переменные, модифицировать код, но код после работы робота надо будет долго и тщательно перепроверять

> С какой стати - покажи пример кода и пример рефакторинга который на нем загнется.

proc setd {val} {
uplevel 1 [ list set d $val ]
}

proc test {var arg} {
foreach $var $arg {break}
setd 4
puts "$a $b $c $d"
}

test {a b c} {1 2 3}

Хочу заэкстрактить в test первые две строки в отдельную функцию.

>Нельзя понять, что во второй и третьей инструкции будут объявлены новые переменные.

А это не надо понимать. Зачем это понимать?

>Хочу заэкстрактить в test первые две строки в отдельную функцию.

Ладно убедил - экстракт делать иза аплевелов апваров и сетов внутри блока - нереально в тикле. Но есть много других полезных вещей.

>> Нельзя понять, что во второй и третьей инструкции будут объявлены новые переменные.

> А это не надо понимать. Зачем это понимать?

Чтобы отслеживать переменные.

> Но есть много других полезных вещей.

Я подозреваю, что эти вещи тоже окажутся труднореализуемыми.

>Чтобы отслеживать переменные.

Зачем?

>> Чтобы отслеживать переменные.

> Зачем?

Ну так для ренейма, отслеживания области видимости и т.д....

И всё же мы подощли к тому, что в более иных языках, нежели java, крутые фичи рефакторизации либо не реализуемы(экстракты), либо не нужны(смена наследования на аггрегирование). Принимается?

>Ну так для ренейма, отслеживания области видимости и т.д....

Какой символ в твоем коде нельзя переименовать?

>И всё же мы подощли к тому, что в более иных языках, нежели java, крутые фичи рефакторизации либо не реализуемы(экстракты), либо не нужны(смена наследования на аггрегирование). Принимается?

Нет. Тикль динамический язык - естественно там все сложнее. Поэтому олграниченное подмножество. А в статических таких проблем нет.

Python: http://peptic.ifs.hsr.ch/trac/wiki/RefactoringSpecification http://rope.sourceforge.net/

Ruby: http://r2.ifs.hsr.ch/trac/wiki/TheRefactoringList

....

> Какой символ в твоем коде нельзя переименовать?

Ни один нельзя. Опять же из-за upvar/uplevel.

>> И всё же мы подощли к тому, что в более иных языках, нежели java, крутые фичи рефакторизации либо не реализуемы(экстракты), либо не нужны(смена наследования на аггрегирование). Принимается?

> Нет. Тикль динамический язык - естественно там все сложнее. Поэтому олграниченное подмножество.

Посморел по ссылкам это ограниченное подмножество. К тиклю не применишь ни одно из них.

> А в статических таких проблем нет.

Да! Потому для явы рефакторизаторы и рулят. А в том же тикле они либо не работают, либо не нужны.

>Ни один нельзя. Опять же из-за upvar/uplevel.

Это не причина - человек который делает это знает что делает.

>Потому для явы рефакторизаторы и рулят

Статические языки это и хаскел и Ф# и окамл и скала и .....

На тикле свет клином не сошелся.