А как жаву по памяти анализировали? Там же GC хитрожопый, занятая JVM память != занятая память, она может быть освобождена в любой момент.

Что я пропускаю?

Полное отсутствие SDK для этих недоязычков.

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

про интерпретируемые языки для мобильных платформ - почти ничего

Как вы умудрились проспать моровое поветрие мертворождённых мобильных платформ на JS?

про интерпретируемые языки для мобильных платформ - почти ничего

У меня firefox OS, там вполне себе JS.

В чём такая принципиальная разница между Java и интерпретируемыми языками? Платформонезависимость есть и у тех, и у других (а интерпретируемые ещё и удобнее, поскольку это plain text - привет, unixway). Скорость исполнения тоже соизмерима. Удобство написания - ну ладно Perl, но есть же вполне читаемый Python и даже Ruby/JS, на худой конец, даже их приятнее читать и писать.

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

при этом относительно большие приложения могут ворочаться на 32Мб

До первого OOM :)

Вопрос не про энтерпрайз, я же подчеркнул. Для больших энтерпрайзных - важно. Для читалок новостей и флаппи бёрдов - как-то не очень.

PHP на втором месте, годно

Полное отсутствие SDK для этих недоязычков.

Я же и спрашиваю, почему SDK нет.

В букмарках! Спасибо

а уж по использованию памяти Perl обгоняет её на порядки вообще

Не совсем верно. При росте программы, при росте используемых типов (хэши хэшей/массивов или массивы хэшей/массивов) возрастает использование памяти (практически экспоненциально). Если заглянуть под gdb, что делает перл с данными, то увидим, что из-за динамической типизации при одном лишь использовании функций сравнений (eq/==) перл начинает копировать значение в сишной структуре с другим типом. Допустим если задать переменную с цифровым значением в виде строки $value = "123";, а затем сделать сравнение if ($value > 10), очевидно, что значение надо сконвертировать в int (gdb это покажет, что в структуре для переменной $value находится два значения двух типов: строковое и числовое). И это сконвертированное новое значение никуда из структуры переменной далее не денется. Более того, удаление всей переменной не приведет к возврату выделенной памяти в ОС. Это так называемая оптимистичная работа с памятью.

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

Что касается скорости работы Perl также есть замечания. В отличие от PHP Perl содержит куда больше внутренних виртуалных функций. В то время, как PHP более строг и использует куда меньше функций для совершения тех же действий. В тесте же видно, что тестировали насколько круто работает регепс...

Ты думаешь, птички это проект на 100 строк? Там тоже есть баги и тоже надо поддерживать код. Я набросил на питоне относительно небольшой (год неспешной разработки в одиночку) проектик и уже начинаю жалеть, что не писал на джаве. Потому что из-за динамической типизации без не зная (или не помня) конкретных кусков кода там не разберёшься.

потому-что нет желания писать 5 версий СДК? написали на Java - дали SDK на Java, написали на Objective-C - дали SDK на Objective-C, а писать еще к этому отдельное сдк со способом трансляции из одного языка в другой задача сравнимая по сложности с написанием самой платформы - спасибо, нет

Только наркоман будет использовать Жаву в интерпретаторе. Компилируй - всё будет нормально.

Я так понимаю, можно на каком-нибудь Jython под андроид писать. Мб на IronPython под винфон. Это касательно удобства.

Насчёт скорости - честно говоря, не понимаю, откуда такая разница в скорости, мб автор что-то не так делал?

Насчёт скорости - честно говоря, не понимаю, откуда такая разница в скорости, мб автор что-то не так делал?

        while(pos=strstr(pos,"efgh")){
            memcpy(pos,"____",4);
        }

vs

$gstr=~s/efgh/____/g;

Регепс в перле делает внутреннюю оптимизацию, не смотря на то, что нет флага /o (once). Строка же постоянно растет до размеров 4 мб и тогда strstr() сильно тормозит.

Автор статьи - упоротый даун, ну какая нафиг интерпретируемая джава?

почему в энтерпрайз она отлично вписывается - вопрос другой

Этот вопрос меня очень давно и мучительно мучает. Почему?

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

Можно же вручную проверить типы перед проблемным местом, не? Конечно, это лишнее действие, но ничего архисложного не вижу.

Не понял, что ты имеешь в виду. Можно пример?

Как будто для жабы он есть.

Не понял, что ты имеешь в виду. Можно пример?

Я вам должен пример бага в вашей программе показать, так, что ли?

Первый состав мобильных платформ на JS уже проследовал с фабрики прямо на кладбище без остановок.

Ну вот у меня есть стек вызовов с ошибкой. На 300-м уровне стека что-то падает. Причина в том, что не 127-м уровне в переменную передали не тот тип. Как это обнаруживать?

Причина в том, что не 127-м уровне в переменную передали не тот тип. Как это обнаруживать?

А что тут сложного-то? У вас в стрейсе написано, что ошибка вызвана неверным типом какой-то переменной. Ищете последнее место, где ей присваивается значение, и проверяете что там не так.

В целом, понятно. Спасибо.

То есть, всё упирается в низкий уровень разработчиков. Я понял, хорошо.

У вас в стрейсе написано, что ошибка вызвана неверным типом какой-то переменной.

А вот и нет. Я недавно долго искал, как в маркдауне экранировать html-теги. У меня было в параметр «экранировать» записано True, и оно их заменяло на «HTML_REMOVED». Оказалось, кроме True туда можно передавать строку «экранировать» (не помню как оно называется точно). Вот и догадывайся, где какой тип совать.

Упоротый? Всё упирается в размер проекта и команды. Если >1 разрабочика, то в проекте на скриптовом языке ты уже не разберёшься.

А вот и нет.

А вот и да.

Я недавно долго искал, как в маркдауне экранировать html-теги. У меня было в параметр «экранировать» записано True, и оно их заменяло на «HTML_REMOVED». Оказалось, кроме True туда можно передавать строку «экранировать» (не помню как оно называется точно). Вот и догадывайся, где какой тип совать.

Если параметр принимает как bool, так и string, то ошибки не будет. В чём проблема-то?

Вот и догадывайся, где какой тип совать.

А чего гадать, если всё в документации написано?

Если параметр принимает как bool, так и string, то ошибки не будет. В чём проблема-то?

В том, что в таком апи нифига не разберёшься.

А чего гадать, если всё в документации написано?

Представь себе, в большинстве проектов документация околонулевая. Особенно в больших.

Этот вопрос меня очень давно и мучительно мучает. Почему?

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

Если >1 разрабочика, то в проекте на скриптовом языке ты уже не разберёшься.

Ну 4.2 же. Я разбирался в легаси-перл-коде, не зная перла, а я ещё зелёный совсем. Чем другие хуже?

В том, что в таком апи нифига не разберёшься.

Что мешает разобраться? Не вижу никаких сложностей.

Представь себе, в большинстве проектов документация околонулевая. Особенно в больших.

Если вы написали эту функцию, сделали так, что она принимает разные типы значений определённого парметра, и не задокументировали это, то вы ССЗБ, и никакия типизация эту проблему не решит. Если же эта функция библиотечная, то проблема опять в библиотеке, а не в типизации.

Зачем её выбрали для мобильных разработок изначально

Потому что ихняя система образования глюкнула и явщиков стало реально много.

(ещё как JavaME)?

В те древние времена подразумевалось что каждая недожелезка будет иметь «железный» JIT. В этом суть существования стадартизированого байткода.

Что мешает разобраться? Не вижу никаких сложностей.

То, что тебе вместо «посмотреть тип аргумента и угадать что поставить» надо смотреть исходники метода и искать, какие варианты он принимает.

Если вы написали эту функцию, сделали так, что она принимает разные типы значений определённого парметра, и не задокументировали это, то вы ССЗБ, и никакия типизация эту проблему не решит.

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

Разобраться-то можно во всём, разница во времени. Такой код быстрее переписать, чем разбираться.

Perl, за ним Python/Ruby/JS/Tcl...Lua

Какой из этих языков по-Вашему, кроме тикля, выполняется без промежуточной компиляции?

В чём такая принципиальная разница между Java и интерпретируемыми языками?

Принципиалная разница между интерпретируемыми и компилируемыми языками заключается в том, что интерпретатор транслирует текст языка A в текст языка А, а компилятор текст языка А в текст языка В.

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

FIXED

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

Ох, лол.

У Python и Ruby очень плохо с многопоточностью, поэтому на должность языковой платформы на мобильные девайсы это плохие варианты. Плюс к этому, из-за их динамичности, сложно сделать нормальные инструменты разработки.

надо посмотреть документацию к методу и узнать, какие варианты он принимает

Ещё раз. Документация — это роскошь, которая бывает в реальных проектах очень редко. Да, можно жаловаться и говорить, что это плохо и так нельзя. Но такова жизнь.

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

В первом случае ошибка возникнет в момент присвоения значения, а не в момент использования переменной. И что, от этого легче?

Ошибки не возникнет. Я сразу в IDE увижу, какой тип нужен функции и дальше буду от этого разбираться.

Во втором случае сама функция написана криво и не документирована.

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

разделяй понятия java как языка и java как платформа. Видим,о как у тебя, так и у афтора нет представлений о java memory model и о java virtual machine в частности.

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

Про ущербный бюрократический синтаксис я даже не говорю.

Поэтому и выбрали. Это один их законов Паркинсона. Бюрократы плодят бюрократов. В результате штат бюрократов растет, а полезные функции, выполняемые ими, стремятся к нулю.

Есть тут один такой на ЛОРе. В легаси-проекте на Python разбирается. Не надо таких.

ты говоришь о маленьких проектах с хорошим кодом.

более реальная ситуация такова: заказчик дает 10 мегабайт кода, который команда из 15 упоротых индусов с рейтом 2$ час писала предыдущиие 6 лет. Индусы отказались от проекта, потому что софтина не работает, не компилируется, и они не хотят и не могут ее чинить. Заказ отдается дорогим зажравшимся профессионалам-русским за 15$ в час, задача - хотя бы запустить софтину.

Java под такие задачи заточена идеально. А что ты будешь делать с той же задачей, будь она написана на Ruby, я даже боюсь представить

Такой код быстрее переписать, чем разбираться.

а теперь, если этот код писали в течение 6 лет, за сколько часов управишься с переписыванием?

быстрее туда как-нибудь вхачить костыли и подпорки (естественно даже близко не понимая, как это работает), лишь бы оно не падало в большинстве случаев, о которых знает клиент :))

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