JAVA среда

Вверх ↑

Форумы Между деломJAVA среда ← Ctrl1 2 3 4 567 8 9 10...20 21 22 23 24Ctrl →

Этот топик читают: Гость

Ответов: 171

Рейтинг: 19

#76: 2011-12-27 00:31:29 ЛС | профиль | цитата

Ну тоесть я хотел спросить если java

Dilma писал(а):

не предназначен для разработки GUI приложений

то как у groovy с этим?

[offtop]Как раз сейчас вникаю в groovy, очень нравиться простой синтаксис, ооп, замыкания, то чего нехватает яве[/offtop]

карма: 0

Ответов: 1528

Рейтинг: 57

#77: 2011-12-27 06:26:59 ЛС | профиль | цитата

iarspider писал(а):

ЛПП

Простите, а причем здесь латвия(Латвийская первая партия) ?

iarspider писал(а):

вычислять можно

вот и я о том, что МОЖНО, это гораздо лучше чем когда не МОЖНО.
МОЖНО БД написать на CUDA, вот это МОЖНО, а твоё МОЖНО не МОЖНО совсем.

Dilma, опять вы CUDA вычисления и GUI в кучу мешаете

Главный плюс Java в том что там действительно масса вариантов решения одной задачи, у нас такого никогда не было и не будет (один в поле не воин).
Возможно Java и менее производительна, но она во много раз быстрее того что есть у нас сейчас (если FTCG в расчёт не брать, т.к. используется он крайне редко).
Ещё один немаловажный плюс, писал я както программу, а потом в ТЗ добавился пунктик "должно работать в Linux" и всё, все труды на смарку.
Java очень хорошо страхует от таких вот, неожиданностей.

Насчёт GUI. Вы только разрабам NetBeans или Eclipse эту тайну не раскройте, а то мужики то не знают..

Насчёт Android. Разработка пакета уже идёт, чуть позже и до него доберусь, боюсь только что этот пакет уже в скором будущем не будет уступать пакету windows по возможностям, и может вскоре превзойти по функционалу

Сейчас HiAsm(пакет Windows) находится на стадии когда он может быть просто прекраснейшим учебником ООП для непосвящённых, но конкретно по назначению его использовать не получится, хотя может и видеться псевдо-перспектива, а если взять конкретно и начать разбираться, то всплывёт, что он даже ZIP архив нормально создать не в состоянии (почему? а вы у разрабов bszip.dll спросите, библиотеку которых даже просто заменить нечем, а взять bass.dll есть чем заменить ? тоже нет.).

Java тормозит ? Видя огромнейшие перспективы, можно и смириться с тем что программы, будут работать чуть быстрее чем те что мы пишем сейчас

Но зато там есть реальные аналоги и главное выбор, из чего вытекают возможности.

карма: 0

Голосовали:

ser_davkin

Администрация

Ответов: 15295

Рейтинг: 1519

#78: 2011-12-27 14:35:02 ЛС | профиль | цитата

hitman249 писал(а):

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

это сравнение java программ и программ из пакета Windows?

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

карма: 27

https://hiasm.com

Ответов: 5446

Рейтинг: 323

#79: 2011-12-27 14:37:01 ЛС | профиль | цитата

hitman249, ЛПП к Латвии никакого отношения не имеет.

карма: 1

Ответов: 1528

Рейтинг: 57

#80: 2011-12-27 16:10:00 ЛС | профиль | цитата

моё дело предложить ©

[flood]или показать, что если идти дальше тем-же курсом, то будет больнее осознавать что остановка "остались у разбитого корыта ©" была в свое время проигнорирована, а все усилия были успешно перенаправлены на изобретение второго такого-же "корыта".
По вашему Google выбрал Java как основу просто так, случайно? То что за столь короткий срок программисты осилили написать несколько сотен тысяч программ также чистая случайность?

А если подумать о HiAsm, каковы причины почему у нас каждый новый придуманный компонент на вес золота? Ну старожилы и сами всё знают, а новичкам сразу скажу:
первое - малодокументированный KOL,
второе - почти полное отсутствие каких либо delphi исходников, которые можно воткнуть без обработки под KOL,
третье - малое количество вообще каких либо delphi исходников, которые можно использовать, а из тех которые всё-же есть, сразу выбрасываются сложные исходники заточенные под VCL (читай почти всё).
из этого следует что почти всё что придумано из компонент написано с чистого листа, со всеми вытекающими багами, глюками и смачно засмакованно KOL-ом и далее его багами. И спрашивается ради чего это всё ? Ради того чтобы exe файлик весил не 800кб, а 30кб ? А теперь с QT этот файлик будет весить вообще 20+мб. Мне одному кажется что гдето чтото не правильно в выбранном направлении будущего на текущий момент развития?

Ну вообщем я попытался, моя совесть чиста

[/flood]

карма: 0

Разработчик

Ответов: 26209

Рейтинг: 2137

#81: 2011-12-27 16:32:06 ЛС | профиль | цитата

hitman249 писал(а):

А если подумать о HiAsm, каковы причины почему у нас каждый новый придуманный компонент на вес золота? Ну старожилы и сами всё знают, а новичкам сразу скажу

А причем тут вообще Windows пакет, который был первым и котрый написан на Delphi

Что, только этим пакетом ограничен HiAsm

Я никак в толк не могу взять -- ну кто тебе мешает создать свой пакет Java, кто

Ведь для этого есть все, бери и делай. Сделаешь отличный пакет, и он может попасть в инсталляцию

карма: 22

Администрация

Ответов: 15295

Рейтинг: 1519

#82: 2011-12-27 17:16:44 ЛС | профиль | цитата

hitman249 писал(а):

А теперь с QT этот файлик будет весить вообще 20+мб

чего?

карма: 27

https://hiasm.com

Ответов: 1528

Рейтинг: 57

#83: 2011-12-27 17:34:40 ЛС | профиль | цитата

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

карма: 0

Администрация

Ответов: 15295

Рейтинг: 1519

#84: 2011-12-27 22:52:41 ЛС | профиль | цитата

hitman249 писал(а):

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

1) о какой ОС идет речь?
2) а java программы с каких пор стали запускаться без JVM?

Или я пропустил момент, с которого мы для QT учитываем необходимые для работы библиотеки, а для java нет?

карма: 27

https://hiasm.com

Ответов: 1731

Рейтинг: 68

#85: 2011-12-27 23:12:05 ЛС | профиль | цитата

Ну допустим для QT 20+ МБ
Но для Java это 80+ МБ

карма: 1

Ответов: 1429

Рейтинг: 50

#86: 2011-12-27 23:55:13 ЛС | профиль | цитата

В свое время я работал на программе SPSS, это для, статистических, рассчетов. И когда ее, однажды, полностью перевели на Java, для кроссплатформенности. Она стала работать в три раза медленнее. С тех- пор остался нехороший осадок про Java.

карма: 0

Администрация

Ответов: 15295

Рейтинг: 1519

#87: 2011-12-28 00:46:03 ЛС | профиль | цитата

Она стала работать в три раза медленнее. С тех- пор остался нехороший осадок про Java.

на Java (как впрочем и на любом managed языке) производительную и быструю программу можно написать только в том случае, если хорошо знать особенности реализации архитектуры VM и встроенных библиотек. Канонический пример в крайней степени не оптимального и медленного кода:


#cpp
String s = "";
for(int i = 0; i < 10000; i++)
  s += "*";

В тоже время на Delphi, к примеру, такая конструкция работает хорошо и быстро.

карма: 27

https://hiasm.com

Ответов: 1528

Рейтинг: 57

#88: 2011-12-28 11:01:46 ЛС | профиль | цитата

Dilma, можно этот же скрипт под IC? Для сравнения.
------------ Дoбавленo в 06.51:
Dilma, в Java так с текстом никогда не работают!
вот правильно

#cppStringBuffer s = new StringBuffer("*"); 
	for(int i = 0; i < 10000; i++)
        s.append("*").toString();

------------ Дoбавленo в 14.57:

#cpp
String st = "Маша";
st += "Саша"+"и"+st;

Опишу работу такого скрипта

Сначало создаётся слово

Маша
Саша
Саша и
Саша и Маша

Все эти слова одновременно будут находиться в памяти, пока неиспользуемые фрагменты соберёт сборщик мусора.
------------ Дoбавленo в 14.59:
Что будет если так вот поступать в цикле хорошо показано в цикле от Dilma.
------------ Дoбавленo в 15.04:
И ещё быстрее можно ускорить используя StringBuilder вместо StringBuffer
------------ Дoбавленo в 08.07:
Бенчмарки C#, C++, Java, Delphi
------------ Дoбавленo в 10.20:
Ещё вариант на StringBuilder, очень быстрый с 1 000 000 интераций.

#cpp
        StringBuilder sb = new StringBuilder();
        for (int i=0; i<1000000; i++)
        {   sb.append("*"); }
        String s = sb.toString();

------------ Дoбавленo в 18.44:
Тесты в ms на 10000 итераций
Скрипт от Dilma - 291
Мой вариант на StringBuffer - 88
Второй вариант на StringBuilder - 4

Тесты в ms на 100000 итераций
Скрипт от Dilma - 34645
Мой вариант на StringBuffer - 8857
Второй вариант на StringBuilder - 9
Второй вариант на StringBuilder на 1000000 итераций - 54

------------ Дoбавленo в 10.52:
хм, в StringBuffer ошибку сделал, так правильно

#cpp
StringBuffer s = new StringBuffer(); 
 for(int i = 0; i < 10000; i++)
s.append("*");

------------ Дoбавленo в 11.01:
Из этого видим что если использовать самый быстрый метод, разрыв с производительностью пакета Windows без использования FTCG возможностей будет всего-то в ~611 раз.
Нужно ещё сделать замеры на чистом IC.

карма: 0

Ответов: 16884

Рейтинг: 1239

#89: 2011-12-28 11:26:13 ЛС | профиль | цитата

На "чистый" IC

code_26351.txt
60 ms на 1 000 000

hitman249 писал(а):

будет всего-то в ~611 раз

Конкретные цифры пож-ста.

карма: 25

Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!

файлы: 1

code_26351.txt [435B] [238]

Разработчик

Ответов: 26209

Рейтинг: 2137

#90: 2011-12-28 11:29:49 ЛС | профиль | цитата

карма: 22

файлы: 1

code_26352.txt [952B] [230]

Форумы Между деломJAVA среда ← Ctrl1 2 3 4 567 8 9 10...20 21 22 23 24Ctrl →


Сообщение ...
Прикрепленные файлы (файлы не залиты)