C vs. JVM's benchmark

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

И в чём получается отличие рефакторизационного тула от редактирования в текстовом редакторе, если и там и там приходится одинаково напрягать мозги над своими действиями?

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

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

Я в этих морях не плавал, посему не смогу сказать "невозможно" так же уверенно, как в случае с тиклем.

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

Не сошёлся, это всего лишь пример. Пример языка, который достаточно гибок и без костылей с сервоприводом.

>И в чём получается отличие рефакторизационного тула от редактирования в текстовом редакторе, если и там и там приходится одинаково напрягать мозги над своими действиями?

Не это имеется ввиду. Если человек написал некий "eval" который в итоге породит новую переменную или что-либо - это не причина не давать ему вобзможности к символьному переименованию. Я еще раз повторяю - экивалентность преобразования - это желательное условие а не необходимое. У меня жмбские программы изобилуют выражениями которые интерпретируются на лету - это не причина не давать мне переименовывать части которые не являются этими выражениями - я знаю что делаю. РЕфакторинг тулл понимает часть которую может разобрать лексическосинтаксически, строя модель со связями и анализом датафлова - но никто не ждет от него чудес что оно догадается что на уме у программиста - это просто лопата которая помогает копать а не делает за тебя всю работу - и чем лучше лопата это делает - тем луше. Но лопата не способдна заменить программиста - однако это не причина от нее отказываться.

>Не сошёлся, это всего лишь пример.

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

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

> Если человек написал некий "eval" который в итоге породит новую переменную или что-либо - это не причина не давать ему вобзможности к символьному переименованию. Я еще раз повторяю - экивалентность преобразования - это желательное условие а не необходимое.

Это может быть заюзанная библиотечная функция(например, из пакета control), либо какой-нибудь sqlite, который тоже uplevel-ит переданный ему скрипт. _Слишком_ за многим придётся следить, особенно если программа использует хоть одну бублиотеку :)

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

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

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

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

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

>_Слишком_ за многим придётся следить, особенно если программа использует хоть одну бублиотеку :)

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

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

Причина есть - это разджаражющая работа которую надо делать. По навигации вверх, прописывании там и т.д. Раздражающую работу можно не делать если на имени декларации в месте где она описывается иде предлагает "засунем в неймспейс?"

>Да, если писать на тикле, пользуясб только возможностями, которые есть в яве, то большинство кода таким и окажется

Нет. Много ли аплевелов внутри tk по сравнению с размером кода? 20 аплевелов в 6ти файлах - при чем все в глобале. Это значит что остальной код относительно сейф. Все сводится к тому надо ли отказываться от продвинутых инструментов ради 20 мест в коде. При чем отказываться ни от чего не надо - просто не надо рефакторить то что мутно взаимодействует с контекстом не вдумыавясь - так это нельзя делать и без мегатулов.

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

Да.

> Если человек производит данное переименование - мегатул может в этом помочь.

Русский народ такую помощь называет "медвежья услуга".

> По навигации вверх, прописывании там и т.д. Раздражающую работу можно не делать если на имени декларации в месте где она описывается иде предлагает "засунем в неймспейс?"

Убедил. Можно было, конечно, повозбухать, что namespace export можно написать и по-извращённому, но я этого нигде не видел.

> Нет. Много ли аплевелов внутри tk по сравнению с размером кода?

Имеловь в виду "внутри кода на tk", т.е. внутри описания гуя? Я не видел в подобном аплевелов, зато foreach там применяют широко и беспощадно.

> Все сводится к тому надо ли отказываться от продвинутых инструментов ради 20 мест в коде

Да. И к тому, насколько "продвинутый инструмент" будет продвинутее текстового редактора. По мне так они окажутся в одинаковом положении(разумеется, тестовый редактор у нас не ed).

>Имеловь в виду "внутри кода на tk", т.е. внутри описания гуя?

Здесь рассматривать tk как законченную библиотеку которую кто-то пишет.

>Я не видел в подобном аплевелов, зато foreach там применяют широко и беспощадно.

Злобный форич кто-то предлагает заменить на нормальный mset или модифицировать set для мультивалюэс. Интересно сделают?

>И к тому, насколько "продвинутый инструмент" будет продвинутее текстового редактора

Он будет его дополнять:) К стати я не вижу принципиальных проблем для появления такого функционала для емакс - как никак там тоже не на С писать надо.

Вот тут http://benchqueens.narod.ru человек написал программу, которая ищет все возможные перестановки ферзей.

16 ферзей расставляет за 2,5сек

Вот к чему стремиться надо!

Мои привествия. К сожалению не было возможности, отслеживать тему. to gaa: >>Скорость исполнения кода средой меня несильно волнует, предпочитаю выигрывать на правильном алгоритме(решении). ...

>Весьма показательный пример целевой аудитории языка Java.

>Кстати, поинтересуйтесь зарплатами на другие специальности, прежде чем идти работать программистом. .... Кстати, там всё кроссплатформенно, так что знания и из WIndows и из Linux пригодятся.

Спасибо за инфо конечно, она мне пригодиться также как и инфа о средней температуре в отдельной точки антарктиды на неделю. Мне очень жаль если Я кому то, чем то не угодил, в силу личных предпочтений и здравого смысла. Но для меня результат первичен, а инструмент (путь) достижения результат вторичен.

Мое почтение.

> Злобный форич кто-то предлагает заменить на нормальный mset или модифицировать set для мультивалюэс. Интересно сделают?

Он не злобный, просто его иногда используют и для множественного присваивания :) А как только сделают, так народ ещё пару версий будет писать по-старому, дабы совместимость не потерять.

>> И к тому, насколько "продвинутый инструмент" будет продвинутее текстового редактора

> Он будет его дополнять:)

Я так подозреваю, что это будет лишь copy-n-paste с добавлением дополнительных символов, не более.

> К стати я не вижу принципиальных проблем для появления такого функционала для емакс - как никак там тоже не на С писать надо.

Там есть обновлялка proc-ов "на лету" для отладки tk-шных приложений. И я подозреваю, что это обновление происходит сильно за-stub-ированным тиклевский скриптом, а не путём синтакситечкого/семантического разбора

Фи, там повороты и отражения не учитываются. Так и я могу.

Дополню свой ответ , по идее утро ночи мудрее.

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

На тему языков: - Сравнение Джава и Си мягко говоря неудачное, Си даже не ООП яп. Не понимаю Я этих "ярых" стронников Си, ведь это старый как комп. мир язык. Есть куча других современных языков которые компилируют так любимый небыдлокодерами нативный код. - По моему для тех кто хочешь вникнуть в суть работы машины на низком уровне, следует изучать ассемблер, это для поборников крепких мозгов.

Ручное управление памятью в Си: ну и что оно дает? то самое, это дает преимущество в скорости на джава подобным языком? Я в Сях не ногой признаться, но не думаю что процесс выделения и высвобождения памяти чем то принципиально отличается от других яп. Удовольствие от ручного управления довольно сомнительное: 1) Есть куча других дел помимо выделения памяти, такие как размышления схемой, структурой, основным алгоритмом проекта, реализация планов и деталей, написание доп. классов, тестирование. А если ты все в одном и менеджер проекта и программист, и кодер, и художник, и менеждер продукта, -) то Си просто зло. 2) с точки зрения производ-ти особых преимуществ перед авто. методом нет, скорее недостатки не думаю что в Сях есть инструмент аналогичный работе типа Стринг в Дельфи. Для тех к то в танке процесс выделения памяти считается ресурсоемким, впрочем как и копирование байтов, в любом случае при сложении строк приходиться выделять память + копировать в новую выделенную область памяти содержимое слагаемых строк. При активной работе со строками Я использую самодельный StringBuilder, не знаю тонкостей реализации его в C# и Java, я сделал для себя то что мне надо, удобно и быстро, его использование снижает кол-во перевыделения памяти, как при добавлении так и при удалении строк. От копирования байтов к сожалению никуда не уйти. Что в Сях что в Джаве, что в Асме.Да и быстрее выделения памяти в стеке по моему нет, однако для задач сложения огромных строк это не подойдет, так что лучше StringBuilder`a ничего нет имхо.

3) Да тут любителям производительности, рекомендовали последовательно, Асм, Машинные коды, и аналоговую схему -), от себя добавлю избегайте использования, файлов данных в текстовом формате (XML, HTML), используйте только!!! быстрые бинарные данные, а остальное "быдло" пусть парсирует текст и наслаждается ламерским удобством и красотой.

В общем: Я не ярый сторонник джава, Я даже кодить на ней пока не умею, впрочем как и не противник Си, и риспект всем кто кодит и на том и на другом, вот только шире надо думать что ли, у каждого есть свои плюсы и минусы, по моему здесь просто надо знать четко какой инструмент необходимо использовать для определенной ниши. Повторюсь для меня важен результат, а инструмент достижения вторичен, будет завтра новый язык с революционными наработками, я буду с удовольствием использовать его.

Для бревен: Эт тем товарищам что орут что такой то инструмент овно а кодящие на нем быдло кодеры, к сожалению ничего кроме жалости не вызывают, здесь явно наличие проблем личного характера, быть может отдельные из них и сильные программисты (кодеры), но для меня это не показатель.

Для сложения больших строк лучше использовать структуру данных "Rope".

> тем товарищам что орут что такой то инструмент овно а кодящие на нем быдло кодеры

большинство орущих просто троллят :) не нужно принимать это близко к сердцу, это такой стиль общения на ЛОРе.

> Для сложения больших строк лучше использовать структуру данных "Rope".

Спасибо уже читаю, >http://www.linux.org.ru/view-message.jsp?msgid=2929835&lastmod=1216153837... >В 2007 году на ICFPC была интересная задача. Реализация на хаскеле с ропами работала на несколько порядков быстрее, чем заоптимизированная вусмерть реализация на сях. гм гм кто бы сомневался, прогресс не стоит на месте, имхо за счет правильного алгоритма предпочтительнее выигрыша за счет обезьяньего труда (ручного выделения памяти).

>Фи, там повороты и отражения не учитываются. Так и я могу.

А сколько времени будет работать такая прога на жабе? Тем более посчитать количество расстановок без учета поворотов и отражений для 18-20 ферзей - хватит ли памяти? И, кажется, его прога на асме использует бинарные структуры, а не хранение расстановок в массивах байтов, больно уж мало его прога памяти использует.

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

real 2m9.257s
user 2m8.181s
sys 0m0.134s

это просто тупо расставить 20 ферзей .... памяти сожрало 5 мегов.

Это как ? плохой или хороший результат ?