Здравствуйте, Algebroid, Вы писали:
F>>а в чём претензия? F>>паскалевская нотация ж более неудобная. A>Паскаль очень удобный. Учебный язык. Вирт создавал его, чтобы учить студентов программированию.
Настолько удобный что в нём долгое время не было встроенного динамического массива, только struct-хаки а-ля getmem.
(в современных диалектах уже конечно есть)
Здравствуйте, alex_public, Вы писали:
_>Что за ересь процветает в этой темке? )
Опровергни.
_>Какой ещё интерпретатор Java? )))
JVM умеет интерпретировать байт-код.
_>Вы вообще про какое столетие пишете? )
Ржака, правда? По делу есть что сказать?
_>Какой ещё "ранний JIT"? Это вообще что такое? )
Это такой JIT из-за которого запуск приложения "тормозит" потому что ресурсы заняты перекомпиляцией байткода в нативный код.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Настолько удобный что в нём долгое время не было встроенного динамического массива, только struct-хаки а-ля getmem. EP>(в современных диалектах уже конечно есть)
В Дельфи 4 появилось. А списки были и в первом Дельфи.
Здравствуйте, Algebroid, Вы писали:
A>Здравствуйте, neFormal, Вы писали:
F>>а в чём претензия? F>>паскалевская нотация ж более неудобная.
A>Паскаль очень удобный. Учебный язык. Вирт создавал его, чтобы учить студентов программированию.
Паскаль сам по себе очень плохой язык. Сам же Вирт переделал его сначала в Modula-{1,2,3}, а потом довёл до Оберона. Ляпы Паскаля колоссальны, а в мир он пошёл по известному принципу — успех получает не лучшее, а первое из минимально приемлемых.
Но если речь именно о нотации записи типов и определения переменных, то вся линии Паскаль-Модула-Оберон лучше линии Фортран-Алгол-Си-Java/C#/etc.
Здравствуйте, Ночной Смотрящий, Вы писали:
A>>>Паскаль очень удобный. Учебный язык. Вирт создавал его, чтобы учить студентов программированию. EP>>Настолько удобный что в нём долгое время не было встроенного динамического массива, только struct-хаки а-ля getmem. EP>>(в современных диалектах уже конечно есть) НС>В Дельфи 4 появилось. А списки были и в первом Дельфи.
Ну да, это и есть один из современных диалектов Pascal'я.
Здравствуйте, neFormal, Вы писали:
N>>>>Алголоподобная декларация типов должна умереть. Только ML/Pascal. F>>>а в чём претензия? F>>>паскалевская нотация ж более неудобная. N>>Чем неудобная? F>печатать неудобно, объёмней больше.
Ну вот Go сократил эту печать до объёма, как C, но мне некоторая многословность тут больше нравится.
N>>Одно только преимущество понимания конструкций сложных типов по сравнению с кошмаром в C (где всё надо читать справа налево) уже на пользу. F>вообще, это зависит от того, как ты читаешь: по типам или по именам переменных.
Единственный правильный вариант читать — по именам переменных, потому что именно объявление переменной — то, что тут нужно, а не игры вокруг типа. Поэтому "x *int", а не "int *x".
N>>Вон положительная сторона Go F>у него их нет.
Есть. И это одна из самых заметных.
N>>понимаешь, что это N>>var x: array[0..99] of integer;
F>а если бы int x[0..99]; то получилось намного проще.
var x [0..99]int, вполне нормально. Если таки вводить тут диапазоны.
Здравствуйте, bisoft, Вы писали:
D>>Но мой случай другой — у меня заказчики — компании, и вот они хотят версии ПО под Андроид. Ну вот потому что они там у себя решили что андроидный планшет для их работников подойдёт.
B>Это как раз понятно, компаниям действительно дешевле купить более дешевые планшеты под Android.
Полноценный Samsung Galaxy Tab вполне сравним с iPad по стоимости.
Экономия тут не очень роляет, как показывает практика.
Здравствуйте, Algebroid, Вы писали:
_>>Что за ересь процветает в этой темке? ) Какой ещё интерпретатор Java? ))) Вы вообще про какое столетие пишете? ) A>интерпретатор пи-кода джава-виртуальной-машины
Ну так и какое отношение он имеет в 21-ом веке к теме про производительность? )
Здравствуйте, Blazkowicz, Вы писали:
_>>Какой ещё интерпретатор Java? ))) B>JVM умеет интерпретировать байт-код. _>>Вы вообще про какое столетие пишете? ) B>Ржака, правда? По делу есть что сказать?
О чём можно говорить по делу с обсуждающими производительность Java интерпретатора? )))
_>>Какой ещё "ранний JIT"? Это вообще что такое? ) B>Это такой JIT из-за которого запуск приложения "тормозит" потому что ресурсы заняты перекомпиляцией байткода в нативный код.
Здравствуйте, alex_public, Вы писали:
_>О чём можно говорить по делу с обсуждающими производительность Java интерпретатора? )))
И о чём же?
_>А бывает JIT с каким-то иным поведением? )
Прикинь. Бывает JVM компилирует байткод не сразу.
Пара добавлений для новичков, кто пока дальше кода не видит.
Про более развитые языки, на которых "быстрее писать". Большинство ресурсов в длительных проектах уходит не на то чтобы написать, а на то чтобы разобраться с тем что уже написано и внести изменения. И тут у более простых языков есть небольшое преимущество. Простой язык — простой код — простые решения. Меньше не очевидных абстракций, которые скрывают в себе неисправимые реализации. Дешевле найти и замеменить разработчиков, так же как и обучить. По этим причинам, например, бум Scala прошел. Вытеснить древний и топорный язык Java с постамента никак не удаётся даже языкам опережающим по возможностям и C#.
Про производительность. Об этом твердят уже более десятка лет. Производительность в подавляющем большинстве систем на много менее критична чем масштабируемость. Стоимость времени квалифицированного разработчика соизмерима с самым топовым железом. Кому нужны недели оптимизаций, когда за те же деньги, можно купить железяку и решить проблему, а драгоценный ресурс — время потратить на более полезную для бизнеса задачу? Даже на самых топорных тестах .NET опережает Java, ну раза в два. При том что, если привести тесты в порядок, разница существенно сократится.
Вот и выходит что ни развитость языка, ни производительность вообще никак на выбор платформы не влияют. Доступность, надежность, инструментарий и экономическя эффективность — вот что важно.
Здравствуйте, alex_public, Вы писали:
_>Ну так и какое отношение он имеет в 21-ом веке к теме про производительность? )
Спроси у того кто делает подобные тесты.
Здравствуйте, Dair, Вы писали:
D>Полноценный Samsung Galaxy Tab вполне сравним с iPad по стоимости.
Сравним только Tab S, у которого OLED экран. А аналоги с обычным IPS раза в два дешевле. Если же брать не самс, цена на который тоже задрана, а что нибудь типа ASUS, то разница в цене с ipad будет очень большой.
Здравствуйте, Blazkowicz, Вы писали:
B> Про производительность. Об этом твердят уже более десятка лет. Производительность в подавляющем большинстве систем на много менее критична чем масштабируемость. Стоимость времени квалифицированного разработчика соизмерима с самым топовым железом. Кому нужны недели оптимизаций, когда за те же деньги, можно купить железяку и решить проблему, а драгоценный ресурс — время потратить на более полезную для бизнеса задачу? Даже на самых топорных тестах .NET опережает Java, ну раза в два. При том что, если привести тесты в порядок, разница существенно сократится.
Кстати говоря, с тех пор ситуация весьма изменилась. Осталась в соответствие с вышеописанным она только для тех случаев, которые допускают масштабирование задачи на несколько компьютеров. Если же задача предназначена для выполнения на одном устройстве, то расклады серьёзно изменились в связи с окончанием периода роста производительности ядер процессоров. Теперь при добавление каждой новой функции в своё ПО придётся дважды подумать, а то и переписать его на чём-то более быстродействующем. )
Здравствуйте, alex_public, Вы писали:
_>А когда? ) Давай уже определимся: некий упомянутый тут термин (хыхы) "ранний JIT" — он что конкретно означает и где можно увидеть его определение?
Бугагашечки. Мусье простыми словами не понимать? Только термины?
Вот тут разжевано http://stackoverflow.com/a/35614237
Здравствуйте, alex_public, Вы писали:
_> в связи с окончанием периода роста производительности ядер процессоров.
И никто не заметил что период роста производительности ядер плавно перетёк в период роста количества ядер? Или в C# не знают про векторизацию?
