XionDE.fm - Файловый менеджер на Java

забавно, но почему-то программы написанные с широким использованием питона работают шустрее чем написанные на джаве. пример: rhythmox и gajim.

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

>Нет.

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

>>без открытых проектов занимает ровно 20 секунд

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

20 секунд запуск повторный запуск без открытых проектов - "жаба не тормозит"?

>>Ну ладно, в среднем раза в три,

>Здесь, наверное, я должен как уважающий себя LOR-овец сказать "бугага". Если Вы не понимаете разницы между синтетическими тестами и РЕАЛЬНЫМИ GUI приложениями, то мне тут нечего сказать. Тем более тесты, мягко говоря не вызывают доверия, особенно startup - уже миллион раз обсуждалось почему так сравнивать нельзя.

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

>>зато памяти раз в десять:

>На гигабайт памяти среднестатистический программист зарабатывает меньше чем за день работы. Еще вопросы есть?

Гигабайт памяти стоит $100. Среднестатистический (особенно с учетом студентов) программист зарабатывает больше $2000? Даже у вас в Москве такого нет, что уж говорить об остальном постсоветском пространстве.

Во-вторых, кроме корпоративных поделок на жабе есть программы, которые должны использоваться на миллионах компьютеров. То есть из-за какой-то жабы каждый должен потратить по $100, т. е. общие потери населения от использования программы - сотни миллионов долларов, так?

>почему-то программы написанные с широким использованием питона работают шустрее чем написанные на джаве. пример: rhythmox

А разве оно не на С/С++ ?

насколько я знаю, там очень много питона

А можно скриншот хоть какой-нибудь в студию?.. Что за зверь?

> Как это нет? Срочно читать как используется память в линуксе.

Вот так нет. И я знаю как используется память в Linux.

> 20 секунд запуск повторный запуск без открытых проектов - "жаба не тормозит"?

Нет.

> Гигабайт памяти стоит $100.

В среднем. Можно купить и за 70.

> Среднестатистический (особенно с учетом студентов) программист зарабатывает больше $2000?

См. выше.

> которые должны использоваться на миллионах компьютеров. То есть из-за какой-то жабы каждый должен потратить по $100, т. е. общие потери населения от использования программы - сотни миллионов долларов, так?

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

> использованием питона работают шустрее

Визуально шустрее. Это разные вещи.

> И вообще, сейчас модно писать GUI на питоне, без малейшего намека на хот-кеи и шорткаты.

Вообще-то, accelerators позволяет задавать даже tkinter. Просто те долбодятлы, которые обычно пишут на питоне всякую херню, не знают это и знать не хотят.

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

Используются. Но вот Вы забыли что пользователь не считает программу медленной если ее скорость реакции на его действия менее 700 мс. Ну а если Вы прочитаете Джефа Раскина http://raskin-interface.narod.ru/interface/index.htm, то поймете как сделать так, что и более медленные операции будут казаться быстрыми.

> Визуально шустрее. Это разные вещи.

мне от десктоп приложений именно это и требуется, а на жабе они (десктоп приложения) подтормаживают

>Вот так нет. И я знаю как используется память в Linux.

Я внимательно слушаю, как же она используется на самом деле. :) У меня почему-то повторное чтение файла происходит без участия диска.

>В среднем. Можно купить и за 70.

Только предприятиям по оптовому договору.

>Но вот Вы забыли что пользователь не считает программу медленной если ее скорость реакции на его действия менее 700 мс. Ну а если Вы прочитаете Джефа Раскина http://raskin-interface.narod.ru/interface/index.htm, то поймете как сделать так, что и более медленные операции будут казаться быстрыми.

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

> У меня почему-то повторное чтение файла происходит без участия диска.

А при чем тут IDEA?

> Только предприятиям по оптовому договору.

Ну, например: http://retail.usn.ru/catalog/price/5000000/5703000/ Я что, куда-то не туда смотрю?

> Ключевые слова - "не считает", "казаться".

Наверное здесь стоит сказать что я не спорю с тем что Java быстрей C++.

> тормозит жаба от этого не меньше.

А вот "тормоза" определяются как раз пользователем.

> А прогрессбары рисовать и дурак может,

Что и все? :\

s/быстрей/медленней

>А при чем тут IDEA?

При том, что при повторном запуске бинарники JRE, бинарники IDEA, всевозможные библиотеки и конфиги считываются из памяти, а не с диска.

>Ну, например: http://retail.usn.ru/catalog/price/5000000/5703000/ Я что, куда-то не туда смотрю?

Не знаю. В моем краю везде 95-110. И то это подешевело только после выхода свисты.

> При том, что при повторном запуске бинарники JRE, бинарники IDEA, всевозможные библиотеки и конфиги считываются из памяти, а не с диска.

Предполагаю, что считывание тут не самое главное.

> Не знаю. В моем краю везде 95-110. И то это подешевело только после выхода свисты.

Отмаза не катит. Мы про Москву разговаривали.

>> На жабе пишут в основном безальтернативный софт

> Разный софт пишут, и новость это еще раз подтверждает

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

>> Не знаю. В моем краю везде 95-110. И то это подешевело только после выхода свисты.

>Отмаза не катит. Мы про Москву разговаривали.

В наших краях гиг стоит 59.40...

> Так вот этот самый проект только под 2.95.3 и собирается --- нынешние gcc это глотать не хотят. Принципиально.

А разбираться с причиной, само собой, не стал. Ну правильно, гораздо интереснее обидеться на весь мир и прогнать по поводу плохого gcc и всеобщей несправедливости. А я вот могу сказать, в чём обычно бывает причина. Ну, например, в функции, возвращающей значение, отсутствует return. Старая версия gcc глотает, новая упирается. И правильно упирается, я считаю. Проги, написанные через задницу, должны вымереть вместе с аффтарами. Дай мне реальный пример нормальной проги, которая собирается в gcc 2.95 и не собирается в более поздней (ядро не предлагать, надо нечто обозримое).

>Отмаза не катит. Мы про Москву разговаривали.

Вы - может быть, мы - нет.

>Предполагаю, что считывание тут не самое главное.

А это чтобы не было отмаз, что половину времени идея свои компоненты с диска читает.

> Это что вообще за хрень??? Ну ладно там muCommander, но ЭТО! Ну написал студент поделку - на новость ниразу не тянет.

Выложите кто-нибудь на ftp или ещё куда, а? А то у этого лузера bandwidth exceeded. Писец :)

> Разный софт пишут, и новость это еще раз подтверждает. Бывают и Tommy-like случаи, но в целом жаба хороша.

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

> А "быдлософт для контор" как писали, так и пишут по-прежнему на Delphi, и все еще кое-где насилуют труп FoxPro.

Чё, жабу даже туда не пустили?

>> Ну да, на индусов спрос большой...

> Хорошие программисты, кстати...

По висте заметно :)

> По висте заметно :)

Виста мне известна только по скриншотам. :)

Bandwidth Exceeded :(

> нам, дятлам, нужен консольный менеджер, перделки под ыкс засуньте себе в /dev/ass плашмя (желательно что бы они были написаны на жабе, так будет гламурнее)

А чё, этот, на жабе, в консоли работает, что ли?

>Виста мне известна только по скриншотам. :)

Скриншоты тоже тормозят? :)

Прочитал все... (все мнения). Народ, наверно, пришло время програмисткий труд разделять на какие-то части (Линусу (его команде) - ядро, другим - другое... Упертости в железо уже нет (практически), конечным юзерам нужны программы, удовлетворяющие их спрос. Их пока нет... Дешевле прикупить железа на быдлокодерскую программулину, чем заказывать написание оной. Разделение труда, однако... Т.е. IT сфера - это точно такая же часть нашей экономической жизни. Но пока все очень дорого и недоступно простому обывателю...

> Упертости в железо уже нет (практически)

Вот за это мне и хочется кастрировать быдлокодеров. Есть. Не надо забывать про ноуты, ok? И особенно - про аккумуляторы на них, которые имеют гадкое свойство - разряжаться.

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

Вам нужен очередной велосипед-недофайломенегер? А если нужен специальный софт, все равно платить будете за написание. Хотите - платите индусам за жабу, деньги-то ваши.

Писал я как-то быдлософтину на Qt и с++. Она компилилась как под офтоп, так и под Linux. Причём без изменения исходного кода. О каких таких больших затратах можно говорить? Я понимаю, конечно, если программа требует какие-либо ОС специфичные штуки. Только в этом случае и java не выход. Данный проект этому пример.

>Упертости в железо уже нет (практически

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

>Вам нужен очередной велосипед-недофайломенегер?

Мне он сто лет не нужен... Меня вполне устраивает mc... Речь не об этом...

Предлагаю задуматься об исторических аналогах... Сейчас IT сфера - это полностью ручной труд. (конец XVII века в промышленности). Эпоха начала внедрения паровых машин... И мы сейчас как раз стоим на пороге внедрения этих паровых машин. Просто ждем - кто первый внедрит эту паровую машину...

> Писал я как-то быдлософтину на Qt и с++. Она компилилась как под офтоп, так и под Linux. Причём без изменения исходного кода. О каких таких больших затратах можно говорить? Я понимаю, конечно, если программа требует какие-либо ОС специфичные штуки. Только в этом случае и java не выход. Данный проект этому пример.

О том и речь, собственно. Вся разница в трудоёмкости между Qt/C++ и жабой заключается в том, что для c++ придётся запустить компилятор под каждую платформу отдельно (что при использовании mingw и кросскомпиляции даже не требует перезагрузки из линукса в винду). Так что всё это - ХЕРНЯ. РЕАЛЬНАЯ причина проста до безобразия: при разработке на жабе не надо платить за средство разработки, в отличие от закрытого софта на Qt. Вот лузеры на жабу и ломятся. Всё просто :)

>А разбираться с причиной, само собой, не стал. Ну правильно, гораздо интереснее обидеться на весь мир и прогнать по поводу плохого gcc и всеобщей несправедливости. А я вот могу сказать, в чём обычно бывает причина. Ну, например, в функции, возвращающей значение, отсутствует return. Старая версия gcc глотает, новая упирается. И правильно упирается, я считаю. Проги, написанные через задницу, должны вымереть вместе с аффтарами. Дай мне реальный пример нормальной проги, которая собирается в gcc 2.95 и не собирается в более поздней (ядро не предлагать, надо нечто обозримое).

После озвучивания таких чисто сишных проблем... Мне смешны ваши нападки на Java. =) Если уж сделали продукт, в котором прогать в разы удобнее, чем в сях, так и нужно его юзать.

Вопрос тут не про программки, которые моделируют 3d, ядерные взрывы и прочую лабуду, не про те, где требуется RT. Обычные GUI-приложения можно и нужно писать на языках как можно более высокого уровня. У меня система загружена большую часть времени на примерно 1%. Если я юзаю какую-то прогу, мне не столь страшно, сколько она еще отнимет проца, 10% или 15%.

>Если я юзаю какую-то прогу, мне не столь страшно, сколько она еще отнимет проца, 10% или 15%.

Пока не так... Обычно хреновая программа кушает 100% (почти) проца...

> После озвучивания таких чисто сишных проблем... Мне смешны ваши нападки на Java. =) Если уж сделали продукт, в котором прогать в разы удобнее, чем в сях, так и нужно его юзать.

Ты, как я понимаю, висту себе уже поставил?

> Если я юзаю какую-то прогу, мне не столь страшно, сколько она еще отнимет проца, 10% или 15%.

А мне принципиально, у меня ноут. Там начинает греться проц, включается вентиль, садится акку и пр. Зачем это мне?

> Ещё один дятел, не знающий про XNC и прочие альтернативы?

Поставил XNC, русские надписи в меню, а так же имена файлов на русском отображаются кракозябрами.

Ubuntu 6.10, локаль utf-8

>Поставил XNC, русские надписи в меню

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

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

Удобство разработчика - это ещё не всё. Есть ещё ПОТРЕБИТЕЛЬСКИЕ качества, и они часто важнее.

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

Правильно, надо разработать Матрицу, которая сама будет клепать всё более тормозные и требовательные к железу проги. Мечта M$ просто. Они пока на полпути. Братья наши меньшие - индусы и шимпанзе - уже осваивают vb.net :)

>Предлагаю задуматься об исторических аналогах... Сейчас IT сфера - это полностью ручной труд. (конец XVII века в промышленности). Эпоха начала внедрения паровых машин... И мы сейчас как раз стоим на пороге внедрения этих паровых машин. Просто ждем - кто первый внедрит эту паровую машину...

Угу, автоматическая генерация кода, автоматические решатели задач, искусственный интеллект... Слава Роботам! Знаем, проходили. Вот только такая х%рня получается...

Что, по-вашему, может претендовать на роль "паровой машины" в жабе? Кросплатформенность в ущерб производительности? Нет уж, спасибо.

> Пока не так... Обычно хреновая программа кушает 100% (почти) проца...

Ээээ... Это на жабе такое пишут, да? По моим меркам (пишу на C++) хреновая программа на современном железе жрёт в среднем более 10..20%. Пики для нормальных прог допустимы, но короткие.

>Есть ещё ПОТРЕБИТЕЛЬСКИЕ качества, и они часто важнее

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

> "паровой машины" в жабе

Автоматический сборщик мусора.

> Кросплатформенность в ущерб производительности?

Хм. Мобильные телефоны, наверное, очень мощные устройства раз используют Java для самых требовательных приложений - игр. :)

>Что, по-вашему, может претендовать на роль "паровой машины" в жабе?

Я не собираюсь никого защищать... Лично я вижу кризис в IT сфере. Здесь много умных людей бывает... :)

> Хм. Мобильные телефоны, наверное, очень мощные устройства раз используют Java для самых требовательных приложений - игр. :)

Игры не определяют ОСНОВНУЮ функциональность телефона. Я, например, телефоном обычно звоню и шлю sms (и надеюсь, я не один такой). А игры запускал только пору раз, просто посмотреть. Ну неинтересно мне играть на телефоне, убого это :)