Я ДЕЛАЮ САЙТЫ (c)

так это скорее недостаток,

подобного рода недостатки с огромной лихвой компенсируются десятками тысяч уже реализованных фич классов и алгоритмов. По крайней мере для JVM / .NET можно как минимум не делать 90% велосипедов, которые придется написать в ЯП с «преимуществом» «не-JVM».

Scala очень хороша, но почти все авторы библиотек городят на ней страшные вещи

Интересно почему? Скала привлекает фриков что-ли? Лисп-эффект типа?

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

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

Это так кажется, когда пишешь на C/C++ под окружение из сишных же библиотек и сишного ядра. А вот когда для какого-то вшивого xmonad нужно тянуть гигазы хаскеля, то нормальным это никак не назовешь. Это ничуть не лучше вкорячивания JVM.

прошу прощения - не скалу минимально юзабельной, а ФП-стиль программирования на скале сделать минимально юзабельным (и то еще вопрос). Улавливаете разницу?

В дотнете похожая ситуация сложилась с Nemerle, кстати.

scalatra

В принципе, годно, надо глянуть подробней, а то с play я уже затрахался.

circumflex

Как-то с документацией не густо. С асинхронностью/стримингом не ясно.

что в ООП-щине самая-самая лучшая Java

Совсем аноним измельчал.

nemerle - супер язык.

Да. Ибо ТС знаменитый местный некромант, только и делает что вбрасывает про скалу. Не знаю когда он наконец писать на ней станет.

Да под шиндуз.

Приводить такой аргумент - пошлятина. Фу, стыдитесь

Напиши на хаскелле браузер. Или стрелялку. И т.п. :)

Можно подумать на си написано меньше

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

лол, а на си, перле, питоне, руби этого всего нету штоле?

Вообще, мне надо только http с тред-пулом и поддержкой стриминга.

https://github.com/spray/spray не подойдет?

Кстати да, еще там всякие Unfiltered от твиттера, но я не пробовал

лол, а на си, перле, питоне, руби этого всего нету штоле?

школоло, никто не говорит о том, что «нету, штоле».

Си - наверняка даже больше чем на java накатано просто за счет возраста ЯП.

перле, питоне, руби - да уж поменьше и поговнистее будет. Sad but true.

так это скорее недостаток

кому и кобыла - невеста

обещания светлого будущего когда VM обгонят нативный код по производительности не сбылись

и не сбудутся, но это касается только си[++], хаскелю его нативность нифига не помогла по сравнению с жабкой. Остальные «вм-ные» если не громко причмокивают, то уж никак не обгоняют.

портабельность на уровне байткода нафиг никому не вперлась

пошёл за канделябром

в то время как нативно компилируемые ЯП нормально вписываются в остальное окружение ОС

ох уж эти сказочники... И если есть желание поупираться рогом в землю дальше - расшифруй «_нормально_ вписываются в остальное окружение ОС»

и не сбудутся, но это касается только си[++], хаскелю его нативность нифига не помогла по сравнению с жабкой.

раскрой мысль пожалуйста.

имелась в виду скорость работы программ

тогда мысль или цепочка выводов совсем непонятна.

Упрёк был в сторону [обещания] производительности jvm по сравнению с нативным кодом. Отвечая, хотел сказать, что только си[++] среди тех, что «гонят натив» (про паскаль и иже с ним - ни слова), генерит код производительнее jvm. Языки же (компиляторы/среды) с «богатым рантаймом» (gc и прочее), даже порождающие на выходе готовый натив (а-ля хаскель) в лучшем случае по производительности идут вровень с jvm, большинство же - нещадно тупит.

Все правильно сказал. Тред можно закрывать.

ну про вровень с jvm это под хорошим вопросом, сильно зависит от задачи о опыта программиста :)

И от опыта программиста на JVM

«вм-ные» если не громко причмокивают, то уж никак не обгоняют.

Посмотри на VM VisualWorks Smalltalk и уд(и/а)вись.

это естественно, правда с JVM, насколько мне хватает памяти и опыта (впрочем опыт был всякой дурной вебни, простенькой бизнес гуйни с малым кол-вом логики и универовских задач) особо на runtime не повлияешь, и максимум, что можно сделать это RTS опции и использование «современных» библиотек, в то время как в haskell можно залезать на очень низкий уровень вплоть до играния с raw памятью как в сях, и все потери будут только за счет модной RTS.

лучшем случае по производительности идут вровень с jvm

Это довольно смешно читать про Хаскель, учитывая то, насколько больше абстракции от ассемблера (в той или иной форме) он предлагает. Всего лишь вровень с jvm =(

Кстати, рано или поздно ребятки из MR уделают ваше С, сохранив возможность не писать это самое С в Хаскеле (что можно делать уже сегодня, если очень хочется)

рано или поздно ребятки из MR уделают ваше С

Ваше С кто только не уделывал -тот же PyPy. Только вот «уделывание» на одном микробенчмарке никого особо не интересует.

Посмотри на VM VisualWorks Smalltalk и уд(и/а)вись.

ну хоть пруфов накидай

Это довольно смешно читать про Хаскель, учитывая то, насколько больше абстракции от ассемблера (в той или иной форме) он предлагает.

А у вас негров линчуют!

ЁТМ, речь шла только о производительности «в чистом виде», а ты сюда сразу абстракции приплёл...

Кстати, рано или поздно ребятки из MR уделают ваше С

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

Я конечго отвечу, если ты этого хотел.

При мониторе 15' и разрешении 1900x1200 и следовательно dpi 146 все приложения будут выглядеть хорошо/одинаково (в firefox единственное надо один хак включить), кроме тех что написаны на java.

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

Есть горы инфы и десятки способов влиять на исполнения, оптимизировать сборку мусора, менять сборщики мусора, профили работы виртуальной машины и даже есть способы использовать unsafe код и off-heap хранилища

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

внутри из кода? или опциями запуска, про которые я говорил?

даже есть способы использовать unsafe код и off-heap хранилища

ну и что значит «даже», ты так говоришь, как будто это уникальная фишка, а у других нет..

внутри из кода? или опциями запуска, про которые я говорил?

Иногда внутри, иногда опциями. Смотря что

ну и что значит «даже», ты так говоришь, как будто это уникальная фишка, а у других нет..

Ну виртуальная машина достаточно safe. Есть возможность использовать unsafe как из Java кода, так и подключением библиотек. У других есть. Но часто если у других что-то есть, то у Java точно есть. Исключения редко бывают

При мониторе 15' и разрешении 1900x1200 и следовательно dpi 146 все приложения будут выглядеть хорошо/одинаково (в firefox единственное надо один хак включить), кроме тех что написаны на java.

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

На SWT смотрел? (Vuze, AnyLogic, но не последний Eclipse)

ну хоть пруфов накидай

Мой текущий development image с проектом:

Количество классов, количество обьектов, сожранная память в метрах:

Smalltalk allClasses size. -> 5142
ObjectMemory allObjects size. -> 3628944
(ObjectMemory actualSizes inject: 0 into: 
	[:size :current | current+size])/1024/1024 asFloat.  
-> 102.377

Что будет с памятью если просто запустить Eclipse я думаю рассказывать не надо.

Время на создание обьектов в милисекундах (Core2 2Mhz):

(Time millisecondsToRun: 
	[100000 timesRepeat: [Array new: 10; new: 10; new: 10;
            new: 10; new: 10; new: 10; 
            new: 10; new: 10; new: 10; new: 10].
	ObjectMemory doOrFinishIncrementalGC]). 

-> 372

Жабу сейчас поднимать лень, но интерфейс у VisualWorks реактивный, в отличии от.

О памяти вроде вопрос и не стоял. Но да ладно.

Создание кучи мелких объектов можно проверить можно, но не думаю, что JVM прямо таки умрёт на этой операции. Но и это сравнение весьма условное. Я думал, что может у тебя есть ссылки на хоть какое костыльное сравнение уже кем-то проведенное.

Интерфейс реактивный и переносимый? Хотя да - это не самый главный козырь jvm.

Вот благодаря тебе и посмотрел, давно пора уже, но то что мне было нужно, jdownloader, всякие uml, этого не юзали.

Там на каком то этапе, кажеться на этапе диалекта self, была скорость 1/2 от C.

Я думал, что может у тебя есть ссылки на хоть какое костыльное сравнение уже кем-то проведенное.

Все тесты что я видел тупо сравнивают численные методы, там да - Smalltalk сливает. Но вот когда дело доходит до всего остального - тестов я не видел, а по собственным ощущениям (с жабой и скалой я работал) жаба жручая и тормозная по сравнению с. Что в Eclipse что в IDEA работать невозможно если в фоне в три потока идёт сборка мира. VW этого даже не замечает.

Интерфейс реактивный и переносимый?

И то и то. Image переносим на Mac/Win/Linux и еще кучу юнихов с условием одинакой разрядности VM (32 или 64 bit).

ну вот твоё создание кучи мелких объектов

public class GenTest {

   public static void main(String[] args) {
      Object[] res;
      long t1 = System.currentTimeMillis();
      for (int j = 0; j<100000; ++j) {
         res = new Integer[] { new Integer(10), new Integer(10),
                 new Integer(10), new Integer(10),
                 new Integer(10), new Integer(10),
                 new Integer(10), new Integer(10),
                 new Integer(10), new Integer(10) };
      }
      long t2 = System.currentTimeMillis();
      System.out.println(t2-t1);
   }
}

сожранная память в метрах:

ObjectMemory allObjects size. -> 3628944

3.6 Терабайта?

у вот твоё создание кучи мелких объектов

Код некорректен. В Smalltalk'овском коде каждый 'new: 10' это создание массива из 10-ти элементов типа nil , а не боксированного целого .

3.6 Терабайта?

Это количество обьектов - ObjectMemoru allObjects - возвращает массив - size - его длинну.

у меня занимает 31ms, E750, 2.93ГГц

Там в цикле ещё GC принудительно дёргается.

Вот эквивалентный код:

import java.util.Vector;

public class GenTest {

   public static void main(String[] args) {
         Object res;
         long t1 = System.currentTimeMillis();
         for (int j = 0; j<100000; ++j) {
		          res = new Vector(10);
		          res = new Vector(10);
		          res = new Vector(10);
		          res = new Vector(10);
		          res = new Vector(10);
		          res = new Vector(10);
		          res = new Vector(10);
		          res = new Vector(10);
		          res = new Vector(10);
		          res = new Vector(10);
				  System.gc();
		       }
         long t2 = System.currentTimeMillis();
         System.out.println(t2-t1);
      }
}

Когда он закончит (!) работать я выдам результат на своей машине.

нафиг вектора

и вызов gc - «моветон» у жабки

вот этот код:

public class GenTest2 {

   public static void main(String[] args) {
      Object[] res;
      long t1 = System.currentTimeMillis();
      for (int j = 0; j<100000; ++j) {
         res = new Object[10];
         res = new Object[10];
         res = new Object[10];
         res = new Object[10];
         res = new Object[10];
         res = new Object[10];
         res = new Object[10];
         res = new Object[10];
         res = new Object[10];
         res = new Object[10];
      }
      long t2 = System.currentTimeMillis();
      System.out.println(t2-t1);
   }
}

Прошу прощения, GC там всё таки вне цикла. Поправил - запустил - 174 милисекунды. Вполне вполне.

Остаётся вопрос, что ж жаба поделки все такие тормозные.

ну у меня с gc вне цикла ~60-70 мс

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