Молодцы. Наконец-то что-то нормальное от «экологов». И местного производителя наверняка это будет защищать перед китайцами.
> Однако, члены её партии выразили сомнение — каким образом можно будет доказать, что устройство сломалось именно потому, что производитель «так задумал»?
Статистически, конечно. Этим должен заниматься орган типа ФАС, а не потребители.
> Одной из причин этого называют антитеррористические меры, предпринятые после расстрела редакции сатирического журнала «Шарли Эбдо».
O_o
В ПДД приняли изменение, что «Помимо этого, в целях повышения видимости пешеходов в тёмное время суток, с 1 июля 2015 года устанавливается требование об обязательном применении пешеходами световозвращающих элементов при движении по проезжей части вне населённых пунктов в указанный период времени.»
Светоотражающие материалы давно используют в дорожной одежде. У меня в детстве была куртка с полосками, фотографии в ней не получались.
В общем, в с свете фар такой чел-елочная игрушка вполне сможет ослепить водителя
>То есть, вам приходится головой крутить?
Зачем? Действие происходит в центре, левый глаз видит немного левой части экрана, правый — правой. Если сидеть на близких к экрану рядах, так будет. Если же хочется смотреть одним ведущим глазом, можно слегка развернуть голову.
>Мне кажется, проще будет тогда использовать вогнутые гибкие экраны
Я вроде видел на форуме DIY-систему с такой штукой и плоской линзой Френеля.
Выход есть — асферические линзы, может даже склейки, удешевление за счет эффекта масштаба и т. п.; просто я хотел донести то, что высокое разрешение и угловое поле сейчас не ставят не потому что с экранами проблема, проблемы именно с оптикой — сделать высококачественный окуляр с угловым полем в 120 градусов и разрешением в угловую минуту непросто (для телескопа, например 30 градусов поля зрения — норма, приборы ночного видения по качеству вряд ли выше первого oculus rift и т. д.), а если окуляр дает разрешение в 3-5 минут, то и смысла в четких экранах нет — линза все равно замылит. По центру еще нормально рассчитают оптику, а вот по краям будет мыло.
Алиасинг следует из теоремы Котельникова, а не предельного разрешения глаза. Если требуется рендерить нечто четкое на устройстве с ограниченным разрешением, все высокие частоты нужно отфильтровать.
>Т.е., вы фильм когда в кино смотрите — делите пополам, и левую половину смотрите левым глазом, а правую — правым?
Если смотрю именно в кино, а не фильм на экране смартфона, то есть крайние области, которые видит только левый глаз или только правый. Поэтому суммировать разрешение нельзя, но и говорить, что суммарное разрешение для двух глаз такое же, как для одного, тоже нельзя. Суммарное разрешение не в 2 раза больше, конечно, но 80 лишних пикселей (~10% раздельного поля зрения) там будет. Хотя с учетом дисторсии и оптики в целом, это не суть — с учетом компенсации дистросии пиксель в пиксель на HD можно получить только имея >4К экран на каждый глаз. Зачем это нужно — не понятно.
>Правда, я думал, что описанное разрешение — это уже после потерь на дисторсию.
Нет, причем на самом деле технологические проблемы возникают из-за оптики. Идеальная оптика должна делать так, чтобы глазу не приходилось перефокусироваться при перемещении зрачка с центра на периферию — тогда изображение будет как настоящее и проблем вызывать не будет. Если же оптическая сила линзы переменная в зависимости от положения зрачка, то глазу приходится это перефокусироваться, что создает неприятные ощущения противоестественного изображения и утомляет. И трудно сделать дешевую оптику, дающую четкость HD с помощью одной пластиковой линзы, и не требующую перефокусировки глаза во всем поля зрения. Мне, например, выкатили ценник в $300 за штуку. В промышленных масштабах будет, понятное дело, сильно дешевле, — но лично мне вообще не понятно, как сделать что-то выше, чем 1000х1000х120 градусов, чтобы при этом оптика не весила полкило.
Потому что
1. На два глаза суммарное разрешение больше.
2. Поле зрения у глаз перекрывается
3. Изображения на экране изначально сильно искривлено, чтобы скомпенсировать дисторсию линзы. Посмотрите скриншоты Oculus Rift — там два бочкообразно искаженных квадрата, а не один единый прямоугольник. Иными словами, мыло по краям все равно будет.
Но вообще смотреть от просмотра кино через окуляры по-моему вытекут глаза, это как с биноклем ТВ смотреть.
>Конечно, бывают случаи несоблюдения этого режима самими фермерами, но разве это проблема ГМ как технологии?
Это проблема потребителя. Веришь ли ты медовым речам лоббистов, или нет, веришь ли ты в добросовестность фермеров (российских, например), или нет. Но не суть, какой смысл начинать обсуждать, кто каким лоббистам верит. Не всегда же они врут. Но мои претензии не в этом.
Дайте нормальные ГМО, разумных огурцов-терминаторов, которые электричество вырабатывают, а не это монопольное уныние. А то реально, в я детстве читал эти статьи, думал, воу, скоро будет будущее, помидоры в вечной мерзлоте! яблоки с ЛСД! бактерии будут нефть делать!
А в итоге вместо будущего какие-то патентованные семена, устойчивые к раундапу ® (тм), и куча проплаченных исследований о том, как это вкусно и полезно, ну и графики экспоненциального роста потребления глифосата и супер-сорняков, к нему устойчивых. А содержимое статей не изменилось — те же сладкие клубники, вот-вот на рынке будут (hint: не будут)
Причем я вполне понимаю, почему — это гербицид-устойчивые-ГМО крайне выгоды фирмам, которые одновременно продают одноразовые ГМО-семена и гербициды, я понимаю, почему в ЕС дрючат ГМО, натравливая зеленых, — не из-за самого ГМО, а из-за того, что защищают своего производителя перед американским, как всегда прикрываясь «европейскими стандартами», чтобы дяди из ВТО не пришли. Но мне-то какой профит от этого. Без вырабатывающих самогон бананов в розничной продаже это все так же интересно, как выпуски журнала Сад и огород.
Как ГМО-хейтер, скажу дипломатически, что много хороших сортов ГМО (пацаны, не бейте), но «Из применяемых ГМ-культур подавляющее большинство площадей занимают культуры, устойчивые к гербицидам и насекомым (часто к обеим сразу)»
А что-что, а жрать залитую глифосатом по самые помидоры кукурузу ради экономии трех копеек продавцу мне не хочется — мне вообще кажется, что по мере естественного отбора среди сорняков эффект сойдет на нет еще при моем поколении. А все эти «нетемнеющие яблоки» никому не нужны, нет там массового продукта, поэтому их лоббировать никто не будет. Будут лоббировать статьи о таких яблоках, а сами продавать ту же самую устойчивую к гербицидам кукурузу, кушайте на здоровье.
>Эта разработка не такая легкомысленная, как может показаться. Универсальная самообучаемая система когда-нибудь может найти применение, например, в автономных автомобилях и других проектах, где нужно анализировать состояние окружающих объектов и принимать решения.
В автомобилях нет индикатора заработанных очков, чтобы легко написать целевую функцию. А где ее легко написать, подобрать соответствующий оптимизатор не проблема.
Это неуловимое называется дисторсией, но мозг легко умеет ее игнорировать, потому что глаз сам по себе выдает очень кривое изображение с сильным мылом по краям. Большую часть мира мозг рисует
В том-то и дело, что система типов в хаскеле требует определенный стиль разработки — сначала семь раз отмерить, какие тебе типы нужны (ADT или кортежей достаточно? а тут у нас список или словарь нужен? или два словаря?), а потом отрезать код. А я предпочитаю скульптуры не из каменя высекать, а из пластилина лепить. Вылепил, а дальше прибил гвоздями типы с помощью аннотаций. В этом плане мне больше всего нравится язык Clay, в котором я даже поучаствовал немного, ныне застывший.
>Про unsafe_string тут опять не понятно, при чем тут типизация
При том, что в статике тебе не нужно тестов, чтобы проверять эти случаи. Вообще. Если забыл где-то — оно не скомпилируется. И так как это бесплатно (что в плане производительности, что в плане затрат времени), этим можно пользоваться. Потратил время, а потом забыл.
>Вот смотри если ты не используешь TDD то программа у тебя упадет в любом случае, и тут никакая статическая типизация не поможет
Да нет, поможет. Хардкорное TDD вообще редко используют в статических языках, потому что не нужно. Тесты пишут уже после кода. Дилемма простая, в статике ты описываешь типы и пишешь мало тестов, а в динамике ты пишешь много тестов, очень много тестов, нужно больше тестов. И в чем профит, в экономии времени? Так в динамике время реально экономится, когда тестов не пишешь вообще :) А если их писать, то времени приходится тратить больше, чем на типы… Это хорошо видно по распределению проектов — динамика в основном используется как CRUD примочка к базе, которой упасть в принципе не страшно, для скриптов автоматизации, для прототипов и расчетов… А статика — когда куча умных перцев готовит проект на годы. И первоначальные затраты времени окупаются сторицей. Я ничего не проповедую, говорю как есть просто. У меня специфика такая, что я за динамическими языками провожу больше времени, мне холиварить вообще не о чем.
>На деле таких ошибок почти никогда не происходит.
Ну это легко проверить, посмотрев на багтрек любого проекта.
>Зато я постаянно вижу стэктрэйсы от всяких API на Яве, в том числе в досаточно серьзеных проектах.
Я написал выше, ява очень часто вынуждает динамически кастить типы, этот язык не совсем показатель.
>Почему-то не спасает их статическая типизация.
Но это и не панацея, но вопрос же не стоит «зачем мучиться со статикой, когда есть такая хорошая динамика». Патчить зрелый статический проект, в котором все типы давно написаны, намного приятнее, чем ковыряться в динамическом проекте в 10 раз меньше. Писать с нуля проще и быстрее скриптами…
>Забавно, вы в предпоследней реплике, например, пишете чуть не дословно то, что в последней реплике обзываете «языкосрачем».
Я не против языкосрача, я против унылых аргументов. Когда идет аргумент, что на php можно сделать, ну да — вот github.com/ircmaxell/monad-php, но кто в здравом уме будет это использовать.
use MonadPHP\Identity;
$monad = new Identity(1);
$monad->bind(function($value) {
return 2 * $value;
})->bind(function($value) {
var_dump($value);
});
Функциональное программирование, это же не просто комбинаторы комбинировать а-ля linq to objects, как во времена SICP, в функциональной среде постоянно рождается что-то новое, что переходит в мейнстрим, сейчас это куча дополнительных фич и принципиально другой способ кодирования, который на императивных языках выльется в кашу из лямбд и тернарных if'ов вместо паттернматчинга.
>Не знаю, как вы, а я ни разу не сталкивался с проблемой «все сломалось из-за ошибочного типа».
А это не всегда видно, что типы могут помочь. Например, от всего пласта XSS ошибок и sql-инъекций в статическом коде можно избежать парой классов, но если рассуждать, что все строки одинаково полезны — уже не получится. От пласта ошибок единиц измерения, от которых ракеты падают, между прочим, тоже можно типами.
Но здесь дилемма статика/динамика непринципиальна (любые статические типы можно проверять и в динамике, и падать в рантайме), а вот сам факт падения при компиляции штука очень нужная и полезная.
Могу более жизненный пример дать, от Джоэля. Два типа unsafe_string, и safe_string, первый всегда получается от юзера, и может потенциально содержать XSS, инъекцию или что-то подобное, а safe_string — безопасная строка. safe_string неявно конвертится в unsafe_string, а unsafe_string в safe_string нет, только методом escape. Все функции, работающие с пользовательским вводом, возвращают unsafe_string. Все функции, кладующие что-то в базу или выводящие принимают safe_string. В итоге компилятор сам следит за тем, чтобы не было вредного кода в пользовательском коде, программист забыть не может.
И в принципе, как и в случае со списками, подобное можно написать и на динамическом языке, но есть один момент. Точнее два. Первый момент заключается в том, что человек без опыта статических языков вряд ли вообще о таком додумается — что строки могут иметь разные типы для помощи в проверках. Но это ерунда. _Принципиальная_ разница в том, когда упадет, если что-то написано не так. В статическом языке упадет при компиляции, в динамическом — во время теста (если повезет), или во время показа заказчику (если не повезет и ты как все забиваешь на тесты). И чем мощнее система типов, тем больший процент ошибок можно перенести на время компиляции. В Java, например, из-за ее фатальных недостатков, многие вещи проще делать через даункасты из Object — это та же динамическая типизация по сути. Все эти NullPointerException, ClassCastException — это вовсе не обязательно, чтобы в рантайме падало.
>Какая разница, упадет в рантайме, или при компиляции?
Огромная. При компиляции оно упадет при мне, а когда падает в рантайме — ну, если повезет, выловит тест, но раз в год и палка стреляет, а реальные люди почему-то отличаются от отличников из книжек по TDD, особенно когда сдача проекта вчера.
>А с изменяемым состоянием трубу не написать, что ли?
Я пишу «Читать код удобно», а вы мне что? Можно зделоть? Не понятно, о чем разговор, любовь к неизменяемости вообще с функциональностью слабо связана. const везде писать и в C++ рекомендуют, и у Макконнелла что-то подобное есть.
>В оригинальном тексте автор боится, что между map и reduce какая-то злая инопланетная тварь ему коллекцию испоганит. Это надуманная ерунда.
В оригинальном тексте много надуманной ерунды, да. Но это больше из-за вводного формата статьи. Сейчас из функциональщины взято все, что может быть легко перенесено в императивные языки, и поэтому особо такие статьи не впечатляют. Ну лямбды, ну вывод типов, а у нас вон linq и var есть. А на Rust если посмотреть, там и тайпклассы, и паттерн матчинг. Теперь впечатлять могут только вещи, которые уже так просто в императивный язык не перенесешь, потому что там все завязано на особенности этих языков. Типа vector fusion в хаскеле. А Scala лучше Java прежде всего как императивный язык, многие ее хотя бы из-за этого выбирают.
>На простом php можно запросто писать используя только функциональный подход.
Совсем унылые аргументы языкосрача пошли. Ну делойте, раз можно зделоть, вас кто-то насильно скалкой кормит что ли.
> Однако, члены её партии выразили сомнение — каким образом можно будет доказать, что устройство сломалось именно потому, что производитель «так задумал»?
Статистически, конечно. Этим должен заниматься орган типа ФАС, а не потребители.
> Одной из причин этого называют антитеррористические меры, предпринятые после расстрела редакции сатирического журнала «Шарли Эбдо».
O_o
В общем, в с свете фар такой чел-елочная игрушка вполне сможет ослепить водителя
Зачем? Действие происходит в центре, левый глаз видит немного левой части экрана, правый — правой. Если сидеть на близких к экрану рядах, так будет. Если же хочется смотреть одним ведущим глазом, можно слегка развернуть голову.
>Мне кажется, проще будет тогда использовать вогнутые гибкие экраны
Я вроде видел на форуме DIY-систему с такой штукой и плоской линзой Френеля.
Выход есть — асферические линзы, может даже склейки, удешевление за счет эффекта масштаба и т. п.; просто я хотел донести то, что высокое разрешение и угловое поле сейчас не ставят не потому что с экранами проблема, проблемы именно с оптикой — сделать высококачественный окуляр с угловым полем в 120 градусов и разрешением в угловую минуту непросто (для телескопа, например 30 градусов поля зрения — норма, приборы ночного видения по качеству вряд ли выше первого oculus rift и т. д.), а если окуляр дает разрешение в 3-5 минут, то и смысла в четких экранах нет — линза все равно замылит. По центру еще нормально рассчитают оптику, а вот по краям будет мыло.
Если смотрю именно в кино, а не фильм на экране смартфона, то есть крайние области, которые видит только левый глаз или только правый. Поэтому суммировать разрешение нельзя, но и говорить, что суммарное разрешение для двух глаз такое же, как для одного, тоже нельзя. Суммарное разрешение не в 2 раза больше, конечно, но 80 лишних пикселей (~10% раздельного поля зрения) там будет. Хотя с учетом дисторсии и оптики в целом, это не суть — с учетом компенсации дистросии пиксель в пиксель на HD можно получить только имея >4К экран на каждый глаз. Зачем это нужно — не понятно.
>Правда, я думал, что описанное разрешение — это уже после потерь на дисторсию.
Нет, причем на самом деле технологические проблемы возникают из-за оптики. Идеальная оптика должна делать так, чтобы глазу не приходилось перефокусироваться при перемещении зрачка с центра на периферию — тогда изображение будет как настоящее и проблем вызывать не будет. Если же оптическая сила линзы переменная в зависимости от положения зрачка, то глазу приходится это перефокусироваться, что создает неприятные ощущения противоестественного изображения и утомляет. И трудно сделать дешевую оптику, дающую четкость HD с помощью одной пластиковой линзы, и не требующую перефокусировки глаза во всем поля зрения. Мне, например, выкатили ценник в $300 за штуку. В промышленных масштабах будет, понятное дело, сильно дешевле, — но лично мне вообще не понятно, как сделать что-то выше, чем 1000х1000х120 градусов, чтобы при этом оптика не весила полкило.
1. На два глаза суммарное разрешение больше.
2. Поле зрения у глаз перекрывается
3. Изображения на экране изначально сильно искривлено, чтобы скомпенсировать дисторсию линзы. Посмотрите скриншоты Oculus Rift — там два бочкообразно искаженных квадрата, а не один единый прямоугольник. Иными словами, мыло по краям все равно будет.
Но вообще смотреть от просмотра кино через окуляры по-моему вытекут глаза, это как с биноклем ТВ смотреть.
Это проблема потребителя. Веришь ли ты медовым речам лоббистов, или нет, веришь ли ты в добросовестность фермеров (российских, например), или нет. Но не суть, какой смысл начинать обсуждать, кто каким лоббистам верит. Не всегда же они врут. Но мои претензии не в этом.
Дайте нормальные ГМО, разумных огурцов-терминаторов, которые электричество вырабатывают, а не это монопольное уныние. А то реально, в я детстве читал эти статьи, думал, воу, скоро будет будущее, помидоры в вечной мерзлоте! яблоки с ЛСД! бактерии будут нефть делать!
А в итоге вместо будущего какие-то патентованные семена, устойчивые к раундапу ® (тм), и куча проплаченных исследований о том, как это вкусно и полезно, ну и графики экспоненциального роста потребления глифосата и супер-сорняков, к нему устойчивых. А содержимое статей не изменилось — те же сладкие клубники, вот-вот на рынке будут (hint: не будут)
Причем я вполне понимаю, почему — это гербицид-устойчивые-ГМО крайне выгоды фирмам, которые одновременно продают одноразовые ГМО-семена и гербициды, я понимаю, почему в ЕС дрючат ГМО, натравливая зеленых, — не из-за самого ГМО, а из-за того, что защищают своего производителя перед американским, как всегда прикрываясь «европейскими стандартами», чтобы дяди из ВТО не пришли. Но мне-то какой профит от этого. Без вырабатывающих самогон бананов в розничной продаже это все так же интересно, как выпуски журнала Сад и огород.
А что-что, а жрать залитую глифосатом по самые помидоры кукурузу ради экономии трех копеек продавцу мне не хочется — мне вообще кажется, что по мере естественного отбора среди сорняков эффект сойдет на нет еще при моем поколении. А все эти «нетемнеющие яблоки» никому не нужны, нет там массового продукта, поэтому их лоббировать никто не будет. Будут лоббировать статьи о таких яблоках, а сами продавать ту же самую устойчивую к гербицидам кукурузу, кушайте на здоровье.
В автомобилях нет индикатора заработанных очков, чтобы легко написать целевую функцию. А где ее легко написать, подобрать соответствующий оптимизатор не проблема.
Как только моторные функции восстановились, ощущение перевернутости прошло.
При том, что в статике тебе не нужно тестов, чтобы проверять эти случаи. Вообще. Если забыл где-то — оно не скомпилируется. И так как это бесплатно (что в плане производительности, что в плане затрат времени), этим можно пользоваться. Потратил время, а потом забыл.
>Вот смотри если ты не используешь TDD то программа у тебя упадет в любом случае, и тут никакая статическая типизация не поможет
Да нет, поможет. Хардкорное TDD вообще редко используют в статических языках, потому что не нужно. Тесты пишут уже после кода. Дилемма простая, в статике ты описываешь типы и пишешь мало тестов, а в динамике ты пишешь много тестов, очень много тестов, нужно больше тестов. И в чем профит, в экономии времени? Так в динамике время реально экономится, когда тестов не пишешь вообще :) А если их писать, то времени приходится тратить больше, чем на типы… Это хорошо видно по распределению проектов — динамика в основном используется как CRUD примочка к базе, которой упасть в принципе не страшно, для скриптов автоматизации, для прототипов и расчетов… А статика — когда куча умных перцев готовит проект на годы. И первоначальные затраты времени окупаются сторицей. Я ничего не проповедую, говорю как есть просто. У меня специфика такая, что я за динамическими языками провожу больше времени, мне холиварить вообще не о чем.
>На деле таких ошибок почти никогда не происходит.
Ну это легко проверить, посмотрев на багтрек любого проекта.
>Зато я постаянно вижу стэктрэйсы от всяких API на Яве, в том числе в досаточно серьзеных проектах.
Я написал выше, ява очень часто вынуждает динамически кастить типы, этот язык не совсем показатель.
>Почему-то не спасает их статическая типизация.
Но это и не панацея, но вопрос же не стоит «зачем мучиться со статикой, когда есть такая хорошая динамика». Патчить зрелый статический проект, в котором все типы давно написаны, намного приятнее, чем ковыряться в динамическом проекте в 10 раз меньше. Писать с нуля проще и быстрее скриптами…
Я не против языкосрача, я против унылых аргументов. Когда идет аргумент, что на php можно сделать, ну да — вот github.com/ircmaxell/monad-php, но кто в здравом уме будет это использовать.
use MonadPHP\Identity;
$monad = new Identity(1);
$monad->bind(function($value) {
return 2 * $value;
})->bind(function($value) {
var_dump($value);
});
Функциональное программирование, это же не просто комбинаторы комбинировать а-ля linq to objects, как во времена SICP, в функциональной среде постоянно рождается что-то новое, что переходит в мейнстрим, сейчас это куча дополнительных фич и принципиально другой способ кодирования, который на императивных языках выльется в кашу из лямбд и тернарных if'ов вместо паттернматчинга.
>Не знаю, как вы, а я ни разу не сталкивался с проблемой «все сломалось из-за ошибочного типа».
А это не всегда видно, что типы могут помочь. Например, от всего пласта XSS ошибок и sql-инъекций в статическом коде можно избежать парой классов, но если рассуждать, что все строки одинаково полезны — уже не получится. От пласта ошибок единиц измерения, от которых ракеты падают, между прочим, тоже можно типами.
Но здесь дилемма статика/динамика непринципиальна (любые статические типы можно проверять и в динамике, и падать в рантайме), а вот сам факт падения при компиляции штука очень нужная и полезная.
И в принципе, как и в случае со списками, подобное можно написать и на динамическом языке, но есть один момент. Точнее два. Первый момент заключается в том, что человек без опыта статических языков вряд ли вообще о таком додумается — что строки могут иметь разные типы для помощи в проверках. Но это ерунда. _Принципиальная_ разница в том, когда упадет, если что-то написано не так. В статическом языке упадет при компиляции, в динамическом — во время теста (если повезет), или во время показа заказчику (если не повезет и ты как все забиваешь на тесты). И чем мощнее система типов, тем больший процент ошибок можно перенести на время компиляции. В Java, например, из-за ее фатальных недостатков, многие вещи проще делать через даункасты из Object — это та же динамическая типизация по сути. Все эти NullPointerException, ClassCastException — это вовсе не обязательно, чтобы в рантайме падало.
Вот чтиво про тесты в статических языках:
spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/
spin.atomicobject.com/2014/12/10/typed-language-tdd-part2/
Огромная. При компиляции оно упадет при мне, а когда падает в рантайме — ну, если повезет, выловит тест, но раз в год и палка стреляет, а реальные люди почему-то отличаются от отличников из книжек по TDD, особенно когда сдача проекта вчера.
>А с изменяемым состоянием трубу не написать, что ли?
Я пишу «Читать код удобно», а вы мне что? Можно зделоть? Не понятно, о чем разговор, любовь к неизменяемости вообще с функциональностью слабо связана. const везде писать и в C++ рекомендуют, и у Макконнелла что-то подобное есть.
>В оригинальном тексте автор боится, что между map и reduce какая-то злая инопланетная тварь ему коллекцию испоганит. Это надуманная ерунда.
В оригинальном тексте много надуманной ерунды, да. Но это больше из-за вводного формата статьи. Сейчас из функциональщины взято все, что может быть легко перенесено в императивные языки, и поэтому особо такие статьи не впечатляют. Ну лямбды, ну вывод типов, а у нас вон linq и var есть. А на Rust если посмотреть, там и тайпклассы, и паттерн матчинг. Теперь впечатлять могут только вещи, которые уже так просто в императивный язык не перенесешь, потому что там все завязано на особенности этих языков. Типа vector fusion в хаскеле. А Scala лучше Java прежде всего как императивный язык, многие ее хотя бы из-за этого выбирают.
>На простом php можно запросто писать используя только функциональный подход.
Совсем унылые аргументы языкосрача пошли. Ну делойте, раз можно зделоть, вас кто-то насильно скалкой кормит что ли.