Оно вообще было и раньше. Это мы сразу тогда пошли на шаг дальше Eclipse. Но оставили запуск object типа для совместимости с Eclipse. А сейчас решили, что эта совместимость только путает да и от нас требует тучу непонятного кода иметь (ибо надо решить в каких случаях запускать внутренности объекта, а в каких все).
Убрали необходимость писать object снаражи, так как это приводило к большому количеству недопониманий. Просто код надо писать без object, прямо на top level.
Все верно. Цель была изначально неправильной, а именно рассказать как можно больше, сколько только возможно успеть. Цель достигнута, но ответ неоднозначный, насколько эффективным это окажется в итоге (зависит лишь от того, продолжат ли люди изучение Scala или нет).
Думаю, что если проведем что-то такое еще раз, то все переделаю, и расскажу в три раза меньше, но с введением в функциональное программирование.
Мне кажется, что второе сделать, скорее всего, можно только грязными хаками, свой хайлайтинг запустить после джаваскриптового и удалить в нужных местах ненужный красный код (звучит просто, а на самом деле не так, скорее всего, если такой возможности таки нет, лучше обратиться к разработчикам, чтобы они добавили подобное API).
Первое и третье сделать можно, причем, я полагаю, что малой кровью (но по первости, скорее всего, какое-то время это отнимет).
Другой разговор, что если затронуть не openapi (особенно с грязными хаками), то вероятность, что надо будет постоянно, что-то чинить от версии IDEA к версии, довольно высока.
Предлагаю статью (полный текст недоступен, так как статья января) www.popmech.ru/article/6385-milliard-pikseley/
Суть в том, что можно получать снимки до 17 гигапикселей. Причем технология гораздо дешевле.
Но это верно, лишь для обычных, земных снимков. Для тех целей, для которых была сделана эта камера, увеличение количества пикселей вполне оправдано, хотя я все равно не уверен, что разрешающую способность ну уж никак не увеличить другими способами.
Скорость работы такая же, или быстрее, в случае если не переборщить с ФП и не вляпаться в несколько не очевидных моментов.
1. boxing происходит еще более незаметно, чем в Java. Это происходит в силу того, что примитивные типы теперь дозволено видеть в качестве параметров дженериков.
2. Return использованный внутри анонимных методов или for (что на самом деле тот же анонимный метод). Проблема в этом случае происходит в силу бросания эксепшина NonLocalReturnException (с названием могу и напутать), что происходит довольно долго (а на деле скажем этот код совсем простой и должен был в итоге выполниться в три раза быстрее).
3. ФП позволяет сократить количество кода, но за счет скорости выполнения. Скажем иногда удобно много раз итерироваться по массиву выполняя вещи, которые можно было сделать в одну итерацию. Происходит подобное просто из-за удобств функционального стиля.
Думаю, что если проведем что-то такое еще раз, то все переделаю, и расскажу в три раза меньше, но с введением в функциональное программирование.
Спасибо за замечание!
Первое и третье сделать можно, причем, я полагаю, что малой кровью (но по первости, скорее всего, какое-то время это отнимет).
Другой разговор, что если затронуть не openapi (особенно с грязными хаками), то вероятность, что надо будет постоянно, что-то чинить от версии IDEA к версии, довольно высока.
Суть в том, что можно получать снимки до 17 гигапикселей. Причем технология гораздо дешевле.
Но это верно, лишь для обычных, земных снимков. Для тех целей, для которых была сделана эта камера, увеличение количества пикселей вполне оправдано, хотя я все равно не уверен, что разрешающую способность ну уж никак не увеличить другими способами.
1. boxing происходит еще более незаметно, чем в Java. Это происходит в силу того, что примитивные типы теперь дозволено видеть в качестве параметров дженериков.
2. Return использованный внутри анонимных методов или for (что на самом деле тот же анонимный метод). Проблема в этом случае происходит в силу бросания эксепшина NonLocalReturnException (с названием могу и напутать), что происходит довольно долго (а на деле скажем этот код совсем простой и должен был в итоге выполниться в три раза быстрее).
3. ФП позволяет сократить количество кода, но за счет скорости выполнения. Скажем иногда удобно много раз итерироваться по массиву выполняя вещи, которые можно было сделать в одну итерацию. Происходит подобное просто из-за удобств функционального стиля.