Отношение к Java

Да, а java-быдлокодеры думают, что других ресурсов кроме памяти больше нет и что програмы на жаве не текут, потому, что не текут )))

Потому, что оно умеет и делает в разы больше?

То есть, имитирует бурную деятельность?
Вот, у меня, например, есть SQuirrel. Это клиент для бд. Там можно прицепить любые данные если для них есть jdbc драйвер. Я могу немного поковыряться с разными базами данных - таблицу загрузить/выгрузить/скопировать, что-нибудь отредактировать, перенести несколько таблицу с одного сервера на другой и т.д. Но это единичные задачи и я никогда не буду использовать яву для пакетного переноса данных. Да и зачем это делать, если можно сделать проще и быстрее на bash/grep/sed? Я писал на ней парсеры логов, потому что я не умел в регекспы, у меня есть пара клиентов с гуём, потому что мне лень учить что-то еще, да и меня они в принципе устраивают.
Практика же показывает, что все написанное на яве, что выполняет какие-нибудь более-менее большие вычисления тормозит. Но, я думаю, это не потому что ява такая тормозная, а потому что она выполняет много неявных для программиста преобразований. Так класс Color например проверяет каждый раз для входных данных цветовую модель, если делать set. Это не критично для небольшого количества данных, но если делать setColor для кучи пикселей, то это будет намного медленнее, чем простое присваивание трёх байт. Да, можно абстрагироваться от того, как данные хранятся и думать об классной архитектуре, но за это придётся платить. Но это пол беды, потому что когда хочешь, чтобы код работал побыстрее, то начинаются проблемы, ковыряние в исходниках библиотек, привязывание нативных библиотек и прочее. Если речь идёт о структурах сложнее int то явакод оптимизировать на порядок сложнее чем то же с/с++.

жлобское отношение к жабе сложилось исторически
причиной тому - жлобская же позиция оракла

C/C++ быдлокодеры думают, что они никогда не допустят ошибку при работе с памятью и не парятся. Если уметь, то вполне можно написать что-то более-менее безопасное. Но все равно это будет дольше, чем Java-код.

Само собой. Или дольше писать+больше уметь = быстрая, или быстрее написать + меньше уметь = медленная и более-менее безопасная работа. Для ынтерпрайза подходит второе, но если нужен, например, браузер, то лучше - первое.

Да, а java-быдлокодеры думают, что других ресурсов кроме памяти больше нет и что програмы на жаве не текут, потому, что не текут )))

Люди вообще зря замыкаются в чём-то одном.

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

Я больше про Heartbleed.

О чем эта стена текста? Ну кажется тебе - пусть кажется. Хочется присваивать три байта - это спокойно реализуется на Java. Критичные места, которых в программах не более 1%, при помощи JNI / JNA спокойно пишутся на православной Си, а все остальное на нормальном высокоуровневом языке.

Хочется присваивать три байта - это спокойно реализуется на Java.

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

которых в программах не более 1%, при помощи JNI / JNA спокойно пишутся на православной Си

И если мне нужны строки побыстрее или регулярки/коннекторы к бд/sdl, то мне нужно линковать нативные либы? Это и на с++ можно делать. Плюс встаёт вопрос простоты переносимости, т.к. я уже не могу просто всять и перекинуть jar мне еще надо тащить и либы.
Кстати вот например FreeCol у меня на ноуте и интелом безбожно тормозит, а battle for weston работает на ура. FreeCol не использует sdl, явакодером это зачем?

на джаве так не принято. Надо обязательно сделать фабрику фабрик для развесистой иерархии наследования.

Т.е. проблема, как всегда, в конкретном слесаре, а не в разводном ключе? :)

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

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

И речь не идёт о трёх байтах, а о классе Color. Я пробовал на яве писать что-то типа экранной маски для игры на поиск предметов. Эта программа делала снимок экрана, сравнивала его с пустой комнатой и искала отличия. Все отрисовывалось на JFrame и там даже не было разговора о realtime. Отчасти это работало, но когда пришло время оптимизировать конец был закономерен. Какой смысл в такой ситуации линковать и разбираться в нативных либах, если видно, что ява это не тот инструмент.

Т.е. проблема, как всегда, в конкретном слесаре, а не в разводном ключе? :)

Отчасти и в них тоже. Часто яву используют не там где нужно.

Intellij IDEA весьма шустрая

О да.

Ты просто использовал неправильное API. На Java легко делается обработка графики. Я недавно делал распознавание текста, сложные алгоритмы на огромном (600 dpi) изображении. Не в реалтайме, конечно, но вполне шустро всё летало. Тупо наложить маску на экранное разрешение это раз плюнуть.

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

Тупо наложить маску на экранное разрешение это раз плюнуть.

Расплюнь, да скинь ссылку на код в тред.

Только надо не только наложить маску, а еще вывести её на экран, обработать клики мышки и не потерять фокус окна браузера.

Да, забыл. Еще скрины экрана надо периодически делать.

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

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

Так-то у меня тоже не было проблем посчитать маску. Ява не такая тормозная, чтобы складывать 3М байт полсекунды. Проблемы - вывести это потом на экран. У меня тыкалка для cookieclicker'а на яве не плохо работала, и коллеге я её скидывал - все отлично было, но походу ява не для экранных сканеров.

Тут же не только маску считать/выводить надо. Еще и с фокусом окон надо колдовать, чтобы приложение не замечало ничего, а awt/swing слишком грубые для этого.

Ну не знаю. У меня в Debian для C/C++ есть библиотеки для всего, а для Java хоть ncurses, хоть примитивный librpm либо через JNI цеплять либо в интернете искать (к слову, librpm вообще не нашёл).

ööö... ваще хз что на это ответить.. попытаюсь.

У меня в Debian для C/C++ есть библиотеки для всего

Пдыжьдыжьдыыжьь разбомбило мозг кровища гроб гитлер!

ncurses

Что это? 80ый год? Но зачем?

librpm

Что это? Дистропроблемы, о которых ява программист не знает.

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

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

Как-то раз я написал свой wget на яве. Потом узнал, собственно, про wget. Обработка бд тут не ахти какая быстрая, но для не очень крупных операций подходит. Главное, что с переносимостью мучатся не надо. Закинул jar'ку поставил jvm и забыл. Но если надо делать что-нибудь по интереснее клиента для бд, то все упрётся в специфичные фичи платформы, которые легче и удобнее дёргать через с/с++, а ява для такого не предназначена by desing.

Как-то раз я написал свой wget на яве. Потом узнал, собственно, про wget.

Хахаха. Нормально чо, так все пацаны делают)

Обработка бд тут не ахти какая быстрая, но для не очень крупных операций подходит.

В крупных и очень крупных делах на «обработку бд» (кстати, что это?) всем пофиг. Главное в таких делах - это оптимизация деревьев запросов, нормализация баз.

Главное, что с переносимостью мучатся не надо.

В этом и смысл явы.

Но если надо делать что-нибудь по интереснее клиента для бд, то все упрётся в специфичные фичи платформы, которые легче и удобнее дёргать через с/с++, а ява для такого не предназначена by desing.

Опять же, стремные сторонние библиотеки для c/c++ и нифига не удобнее. А в задачах «по интереснее» всегда найдется с чем потрахаться. У явы такой design, чтоб трахаться меньше, делать больше. Сравнимо с движением по шассе на автомобиле (c/c++) и над шоссе на самолете (java). Сверху видно всю ситуацию, а не 20 метров вперед.

«обработку бд» (кстати, что это?)

Массовый дамп/миграция например. Её можно конечно сделать, но проще - mysqldump | grep | sed | awk | mysql

У явы такой design, чтоб трахаться меньше, делать больше.

С другой стороны то, что с явой нормально не потрахаешься это минус, если нужно именно трахание.

Сравнимо с движением по шассе на автомобиле (c/c++) и над шоссе на самолете (java). Сверху видно всю ситуацию, а не 20 метров вперед.

Неплохой пример. Но за грибами/на рыбалку, например не летают на самолётах. Хорошо для этого дела иметь какой-нибудь вездеход-амфибию, ну или хотя бы УАЗ.

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

Кстати, почему ОП считает, что сообщество «воротит нос от Java». У апача полно всяких вещей есть для DOM, а также компонентов для чтения/записи xls/otd/rft/doc(x) и прочего добра.

Неужели дело в повышенном потреблении оперативной памяти, мегабайт которой сегодня стоит меньше 30 копеек?

Дело в сложности настройки. Нельзя просто взять и запустить. Надо прописать -Xms, -Xmx. К тому же оно не умеет в десктопный гуй.

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

Что там за косяки вылезут? Я писал на яве (awt/swt/swing) десктопные графические приложения, рисующие динамический контент, но весь экран не трогал. Единственная проблема была с прозрачностью, но это скорее всего от моей тогдашней анскильности, решил в итоге.

Что там за косяки вылезут?

Сам подумай, GC даст о себе знать, будет тормозить и выжирать память как не в себя.

К тому же оно не умеет в десктопный гуй.

Кто бы что не говорил, а swing живее всех живых. Хоть и не разрабатывается уже. А в макоси еще и выглядит нормально :)

Он не интегрируется в систему. Конечно оно рабочее и для энтерпрайза сойдёт (им главное чтоб работало, даже если там motif будет), а для десктопа более нативные и красивые гуи заруливают.

Сам подумай, GC даст о себе знать, будет тормозить и выжирать память как не в себя.

Так это с данной задачей никак не связано. Оно итак будет :D

Не очень быстрая динамическая отрисовка/перемещение окон и нужны специфичные приёмы для работы с окнами/экраном, чтобы фокусироваться на линзе, когда щелкаешь по браузеру. Тут нужна та часть нативного кода, которая выводит курсор мыши. По сути нужен просто еще один курсор. Я не знаю, есть ли вообще возможность на яве такое сделать. (Хотя, возможно, курсор мыши - это просо окно, которое всегда вверху)
Я решал эту задачу так: сперва сделал окно, с свойством «всегда сверху». Делал скрин, писал его на окно. Когда щелкал по окну - прятал его и передавал щелчок на браузер. Потом игру сделали хитрее и если браузер терял фокус, то она ставилась на паузу и счёт обнулялся. Тогда я сделал 4 окна и окружил ими курсор. Но беда была в том, что они очень не быстро меняли размер, да и реализация, была откровенно говоря, костыльная. Вообщем я плюнул и перешел на кликалки.

В KWin это кажись на Js сделано.
Вывод: даже JavaScript производительнее Java.

Нативный SWT и красивый JavaFX тебе в помощь.

SWT я насмотрелся на примере эклипсы. Тормозит адово, местами выглядит вырвиглазно (но возможно это проблемы GTK, а не самого SWT).

Кликалки кстати говоря не плохо на ней получаются. Она достаточно шустро по экрану ищет что надо + нет заморочек с переносимостью на радость виднофагам.

В KWin это кажись на Js сделано.
Вывод: даже JavaScript производительнее Java.

Так вроде бы он в нативный компилится, не?

Ты о скорости и маневренности автомобилей не по БелАЗ'ам судишь, надеюсь?

Я не видел ни одного другого приложения на SWT. Ткни в популярный пример.

Да я пошутил. Там кресты: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/mast...

Внизу.
http://www.eclipse.org/swt/community.php

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

В Лиспе, если охота аспектно-ориентированного программирования, нужно лишь настругать немного макрокоманд, и готово. В Java, нужен Грегор Кичалес, создающий новую фирму, и месяцы и годы попыток заставить всё работать. - Петер Норвиг.

Да вбросил он. Только фанатики хотят все переписать на свой язык. Адекватные люди знают, что каждый инструмент хорош для своей задачи. Но самое плохое, что находятся люди, которые пишут на яве все, что можно: эмуляторы/лиспы/велосипеды/grep'ы/браузеры...И все бы ничего, но если это пропихивают как единственно верный путь и лишают всяческой альтернативы, то это весьма и весьма скверно пахнет дерьмом, господа.

Также минус явы и всяких пистонов в том, что разработчиков там считают криворукими идиотами. Это может быть и не плохо, если ты только начал во всем разбираться, но считать серьёзно, что все должны на этом писать - это маразм.

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