По scalaz есть что-нибудь?
почему так долго компилируется?
Расскажите, как работает сборщик мусора? Нужно ли занулять ссылки? А если ссылки кольцевые?
>Расскажите, как работает сборщик мусора?
Как в JVM. Бери любое описание GC в JVM и читай.
>Нужно ли занулять ссылки?
Нет
>А если ссылки кольцевые?
Всё хорошо соберется.
Чем оно лучше Хаскеля/Лиспа/Эрланга?
> Нужно ли занулять ссылки?
Если пишешь код, который управляет временем жизни объектов, например, реализацию динамического массива, которую можно урезать, то нужно. К примеру, размер чанка вектора - это невидимая снаружи деталь реализации, если чанк 20 элементов, а пользователь урезал вектор до 10, и после 10го в ячейках остались ссылки на его объекты, это утечка памяти.
Ну или ещё пример: если есть метод, в котором на n-й строке var yoba = ... - очень дорогой ресурс, на строках от n+k до n+k+m - очень долгое вычисление, не использующее ресурс, имеет смысл занулить yoba перед этими строками, чтобы не ждать освобождения ресурса до конца метода.
О, капитан, мой капитан!
:3
Прошёл когда-то курс на курсере, забавный но довольно лёгкий. Нужно ли знать джаву чтобы найти работу? Есть ли вообще работа? Насколько хорошо надо знать джава/жвм и всю эту инфраструктуру чтобы что-то писать осмысленное?
Пишу всякое говно на 200 строк на питоне пока, есть смысл перекатиться в скала?
Пишу всякое говно на 200 строк на питоне пока, есть смысл перекатиться в скала?
Как курс, кстати? Хотел вкатиться но не могу никак закончить автоматы. Может попробую сейчас глянуть лекции и сдать домашку, хард дедлайн завтра лол.
Менее основательный, чем maththink, но зато больше тем затрагивается. Тесты пока что довольно простые и дается сколько угодно попыток, при этом неправильные ответы сразу же помечаются.
что за курс про автоматы?
Посоны, вопрос по курсере:
есть "((left union right) union that) incl elem", который пиздец как тормозит и "(left union (right union that)) incl elem", который значительно быстрее.
Как это понять? Хвостовая рекурсия?
есть "((left union right) union that) incl elem", который пиздец как тормозит и "(left union (right union that)) incl elem", который значительно быстрее.
Как это понять? Хвостовая рекурсия?
надо полагать, от размеров left и that зависит. потестируй отдельно с разными значениями
кстати, есть ещё третий вариант
(left.union(that)).union(right)
а вызов методов "через пробел" — это пиздецома, не надо так.
Спасибо, анон, "(left.union(that)).union(right)" работает быстрее всего. Осталось понять, почему (в общем случае).
подумай, как считается union, в смысле сложности в зависимости от размеров 2х множеств или что у тебя там
вообще, если уж говорить о скорости, то там полюбому весь код — говно ебаное… и суть курса не в оптимизации тоже. это ленивое программирование
>то там полюбому весь код — говно ебаное…
Я охуел, когда делал множества на функциях (вторая неделя). Над каждым маленьким заданием тупил по два часа.
Так, падажжи... Тесты не проходят. Как это вообще работает? "Incl elem" не вызывается, соответственно, это самая медленная операция.
не понял
Ты объединяешь только правую и левую ветки, а у узла есть еще собственно значение.
Короче, я подумал, и мне кажется, что если большее множество объединяется с меньшим, то возникают тормоза, надо делать наоборот. Только там нет способа понять, какое из них большее, а какое меньшее. Еще где-то видел, что, мол, надо использовать что-то похожее на merge sort, тогда объединение происходит за линейное время.
как ускорить компиляцию программ написанных на языке программирования сцяла?
заебало ждать по 5 секунд
заебало ждать по 5 секунд
Ты неправильно задаешь вопрос.
1. Писать без багов
2. Разбивать программу, чтобы компилировать только то что ты сейчас редактировал
3. Писать больше, а не через 10 написаных строк компилировать.
Как-то можно сделать глобальную функцию? А не объект с методом (аналог статического метода в яве, но без класса).
Можешь запихнуть ее в package object, тогда она будет доступна внутри модуля аки глобальная.
Лайк
Посмотрите что ваше ООП и mixin'и в месте с имплицитами наделали человеку:
Have a look at the hierarchy of the Plone Site class. Between square backets you can see the number of methods/attributes defined per class, except special attributes. The plot comes from a real Plone application I have in production. The total count is of 38 classes, 88 names overridden, 42 special names and 648 regular names: a monster.
To trace the origin of the methods and to keep in mind the hierarchy is practically impossible. Moreover, both autocompletion and the builtin help facility become unusable, and the self-generated class documentation becomes unreadable since it is too big.
…My hate for mixins comes from my experience with Zope/Plone. However the same abuses could be equally be done in other languages and object systems – with the notable exception of CLOS, where methods are defined outside of classes and therefore the problem of class namespace pollution does not exist – in the presence of huge frameworks.
A consequence of namespace pollution is that it is very easy to have name clashes. Since there are hundreds of methods and it is impossible to know all of them, and since method overriding is silent, this is a real problem: the very first time I subclassed a Plone class I ran into this issue: I overrode a pre-defined method inadvertently, causing hard-to-investigate problems in an unrelated part of the code.
Боль динамомакаки
Имплиситы не при чём, это чисто о миксинах, и это пиздёжь: в Scala, когда наследуешь T1 и T2, у которых есть одинаковые реализации foo, компилятор выдаст ошибку и скажет, что ты должен явно указать, какую выбирать:
def foo = super[T1].foo
А в случае, если наследуешь своим A трейт B, в котором есть реализация foo, и объявляешь свою реализацию foo, не зная, что уже есть в суперклассе, компилятор скажет, что ты провтыкал и либо переименовывай либо явно указывай override.
http://blog.joda.org/2011/11/real-life-scala-feedback-from-yammer.html
История из 2011 о том, как одна соцсеть переехала со скалы на джаву.
История из 2011 о том, как одна соцсеть переехала со скалы на джаву.
Finally some official words from Yammer. So Stephen would you show some integrity by prominently featuring this article on your blog as you did with that leaked email so people can see both side of the story?
http://eng.yammer.com/blog/2011/11/30/scala-at-yammer.html
Ну вот, только я собрался конвертировать жар от моего пукана в электроэнергию и продавать государству.
>2011
yasno, ponyatno
Пацаны, кто-то в последнее время компилировал компилятор под венду?
У меня такая херня, не знаю что делать: http://pastebin.com/2x9sPtUm
Погуглил - ничего нету. У меня:
Apache Ant(TM) version 1.9.4 compiled on April 29 2014
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
У меня такая херня, не знаю что делать: http://pastebin.com/2x9sPtUm
Погуглил - ничего нету. У меня:
Apache Ant(TM) version 1.9.4 compiled on April 29 2014
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Parallel-lazy Performance: Java 8 vs Scala vs GS Collections
http://www.infoq.com/presentations/java-streams-scala-parallel-collections
Специальная библиотечка для коллекций победила всех как неожиданно
И вопрос про байткод: как я понял, компилятор скалы пока не использует использует трюки с invokedynamic/invokeinterface из JDK8 при обработке кода с лямбдами?
http://www.infoq.com/presentations/java-streams-scala-parallel-collections
Специальная библиотечка для коллекций победила всех как неожиданно
И вопрос про байткод: как я понял, компилятор скалы пока не использует использует трюки с invokedynamic/invokeinterface из JDK8 при обработке кода с лямбдами?
> не использует использует трюки с invokedynamic/invokeinterface из JDK8 при обработке кода с лямбдами?
https://issues.scala-lang.org/browse/SI-8359
Сейчас 2.11., основной МАЙЛСТОУН всех 2.12. - хорошая интеграция с Java 8, как на физическом (байткод), так и на высоком уровне (чтобы скальные лямбды на уровне языка были тоже совместимы с функциональными интерфейсами безо всяких имплицит-конверсий).
https://issues.scala-lang.org/browse/SI-6476
Пиздец, почему не пофиксят до сих пор?
s"Yoba says \"$huy\""
Пиздец, почему не пофиксят до сих пор?
s"Yoba says \"$huy\""
Сап, посаны.
Хочу контрибьютить в скалу. Смотрел жиру - вроде есть баги, которые вполне по-силам.
Но эти уебки так и не могут ни в нормальную систему сборки - собирают антом, ни в нормальные руководства интеграции исходников в IDE.
Анон, помоги нормально импортировать проект в IDEA, чтобы все собиралось прямо в ней, чтобы можно было нормально запускать тесты по одному и т.д.
Хочу контрибьютить в скалу. Смотрел жиру - вроде есть баги, которые вполне по-силам.
Но эти уебки так и не могут ни в нормальную систему сборки - собирают антом, ни в нормальные руководства интеграции исходников в IDE.
Анон, помоги нормально импортировать проект в IDEA, чтобы все собиралось прямо в ней, чтобы можно было нормально запускать тесты по одному и т.д.
Если проект собирается антом, то по-нормальному в Идею ты его не импортируешь никак.
Че означает оператор "++"? Как вообще гуглить про операторы?
соединяет два списка наверное
Пасиб
Я пользуюсь Dash.
Какая ide для скалы на сегодняшний день норм?
Что бы типы показывала и навигация была по проекту и либам.
Что бы типы показывала и навигация была по проекту и либам.
vim
cat > Foo.scala
idea
Почему? Думаешь не получится разрулить все вручную?
IntelliJ IDEA
Купил его?
Я не он, но купил.
Too soon....
>Too soon....
YOU HAVE AWAKENED ME TOO SOON, EXECUTUS!
Хочу сделать скриптовый язык для игрушки, который компилируется в xml, на основе небольшого подмножества скалы. Что посоветуете? Писать самому с нуля все ast и парсер, конечно, интересно, но придется отдельно делать тайпчекер, плагин к иде и все такое. Интересует, как можно использовать уже существующую инфраструктуру скалы для моих задач, как это, например, сделано в scala-js.
Вот почти все, что нужно от языка
http://pastebin.com/7NA2UXzT
Вот почти все, что нужно от языка
http://pastebin.com/7NA2UXzT
>Хочу сделать скриптовый язык для игрушки, который компилируется в xml
Какой-то пиздец ты придумал.
Это не я придумал. Есть уебищная среда для создания ии ботов мышкой, на выходе - xml файл, повторяющий эту структуру. Таким образом разработчики решили "упростить" создание ии для игры, поскольку деревья ифов, по их мнению, некошерно бы смотрелись в виде кода. Поэтому они сделали некое подобие языка практически без модульности, статических переменных и с двумя типа глобальных переменных, которые могут быть объявлены где угодно в дереве. Я хочу исправить этот недостаток и сделать небольшой статически типизированный язык, который будет компилироваться в эту их ересь.
Алсо, может кто-то работал с xtext, jetbrains mps или kiama. Что из этого подойдет?
def IsIdle(idleState: Integer, threshold: Float) =
state == idleState && self.hasTarget && !self.isOnGround && self.skill == threshold
у тебя threshold Float, а ты сравниваешь его по == зачем так?
Да это просто я накидал бессмысленный код со всем тем, что может понадобиться от языка.
Когда следующая итерация на курсере?
Они не закрывают ассайменты, можешь хоть сейчас их проходить.
Я сертификатодрочер.
Сделай сейчас, а когда начнется следующая итерация всё сдашь.
Я нищестудент, если я сейчас буду писать на скале, я смогу потом устроиться жаба-джуниором? Просто я понимаю, что не бывает вакансии скала-джуниор, но на джаве за бесплатно писать не хочу. Мои соображения такие, что тулы там одни и те же, а в самой джаве ничего сложного нет, поэтому я смогу моментально вкатиться в джаву, когда мне это понадобится. Какие подводные камни?
Знание Java SE — ничто, в жабьих вакансиях оно само собой неявно подразумевается. Нужно осваивать фреймворки/SDK, хоть в Java EE, хоть в ведроиде, хоть в ололо-бигдате.
У меня вопрос. А как организовать акторы с общим состоянием? Например есть несколько акторов User и Room. Юзер может находиться либо в одной комнате, либо ни в одной. Комната знает, кто в ней находится.
Возможные проблемы такие:
Юзер пытается войти в несколько комнат.
Юзер пытается войти в несуществующую комнату.
На каком-то этапе теряется сообщение.
Спасибо!
Возможные проблемы такие:
Юзер пытается войти в несколько комнат.
Юзер пытается войти в несуществующую комнату.
На каком-то этапе теряется сообщение.
Спасибо!
Вопрос по akka.
Сделай промежуточный актор UserRoomManager, который будет хранить соответствие User -> Room и обрабатывать сообщения типа JoinRoom(id), LeaveRoom, MessageToRoom(msg) и т.п.
Хотя Message лучше слать напрямую комнате, тогда JoinRoom должен позвращать ActorRef комнаты.
Тогда состояние будет размазано по UserRoomManager и Room. Произойдет рассинхронизация при любой потере сообщения между ними.
Сделай сообщения с подтверждением, то есть реквесты. Например User шлет LeaveRoom к UserRoomManager, а тот шлет LeaveRoom(user) к Room. Если на какой-то из стадий не получено подтверждение, то запрос фейлится в самом начале и состояние остается прежним во всех звеньях цепочки.
Да, хорошая идея. Нативные реквесты есть в акка? Это не приведет к deadlock, если все акторы на одной jvm крутятся?
Пойду гуглить.
Гугли akka pattern ask. Не приведет, так как реализовано через Future, но есть свои подводные камни. Например, надо делать так
val client = sender()
for(reply <- room ? Leave) {
...
client ! OK // sender в этом случае будет Room, а не User
}
Потом есть некоторые неудобства с обработкой ошибок и других таймаутов. Подробнее http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/
> Если на какой-то из стадий не получено подтверждение, то запрос фейлится в самом начале и состояние остается прежним во всех звеньях цепочки.
Не понимаю, почему.
Да, не подумал, что в комнате состояние поменяется в этом случае. Хотя, если подумать, это не критично, так как URM вернет клиенту что-нибудь вроде RoomInaccessible, клиент должен попытаться повторить запрос еще раз позднее. В самой комнате этого юзера уже не будет и сообщения от комнаты не будут ему приходить. Сам факт того, что комната недоступна - уже нештатная ситуация, которая должна обрабатываться отдельно.
Словил сгуху.
http://pastebin.com/AT5gcKNH
Угадайте, что возвращает метод, если операция с БД успешна, что будет, если убрать явный return, и что будет, если перехватывать не Throwable, а его более узкий подтип. (В общем-то предсказуемо, но было майндфаком).
Код ужасный (затычка), и в продакшон не пойдет
http://pastebin.com/AT5gcKNH
Угадайте, что возвращает метод, если операция с БД успешна, что будет, если убрать явный return, и что будет, если перехватывать не Throwable, а его более узкий подтип. (В общем-то предсказуемо, но было майндфаком).
Код ужасный (затычка), и в продакшон не пойдет
false возвращает, потому что в анонимных функциях return бросает специальное исключение. Верно?
трай\катч нужно в блок внести
Нет, нельзя, блок DB.withTransaction должен быть внутри try/catch (или выполняет все, или вылетает с исключением, иначе закоммитится сфейлившаяся транзакция)
По-другому на JVM нелокальный goto (из объекта-лямбды), видимо, никак не сделать. Надо бы посмотреть, эквивалентны ли явный return и неявный (через последнее значение) в верхнем скоупе функции.
try\catch это не из скалы, так что выкидывай своё говно
>> 420398
> CCAHNHA, которая сворачивает голову JIT и выдает перлы вроде выбрасывания исключения при выполнении return из лямбды.
Тут, вобщем-то, претензий к сцале нет, кроме сбивающего с толку слова return, которое на самом деле не привычный return из C-языков, а longjmp для случая inner-лямбда-объектов. Это явно указано в Scala Language Specification. Обычные, через стек, возвраты из лямбд разумеется возможны через последнее значение блока лямбды. У меня же тот код опасен и с т.з. жавы - перехватываю Throwable.
> CCAHNHA, которая сворачивает голову JIT и выдает перлы вроде выбрасывания исключения при выполнении return из лямбды.
Тут, вобщем-то, претензий к сцале нет, кроме сбивающего с толку слова return, которое на самом деле не привычный return из C-языков, а longjmp для случая inner-лямбда-объектов. Это явно указано в Scala Language Specification. Обычные, через стек, возвраты из лямбд разумеется возможны через последнее значение блока лямбды. У меня же тот код опасен и с т.з. жавы - перехватываю Throwable.
Ведь обсуждалось уже много раз, что трайкетч для мудаков. Почему бы не врапнуть это в Try()? да так и вернуть, ну или recoverWith прям там
Это Play + anorm. anorm достаточно тонкая обертка над JDBC, я не был уверен, что он ничего не бросает и написал затычку.
Ну скорей всего бросает. Легко проверить, отключи бд перед запросом. Если бросает - обрабатывать жи надо, траем всяким или Either возвращать.
Господа, я тут собрался попробовать написать рекомендательную систему и заодно пощупать Скалу, расскажите, откуда повелось, что она хорошо подходит для работы с большими данными? Ну и заодно, вакансии по ней есть?
Проходил курс на корсере по скале, но уже маленько подзабыл фичи языка Хотя и в самом курсе думаю и половина фич не была рассмотрена
Есть ли смысл сейчас начинать писать на нём проект под ведроид? Какие профиты могут быть? Нашёл макроид но он кажется outdated потому-что последний коммит в гитхаб их 5 месяцев назад.
Тут без цитирования, фиксану.
ФП вообще часто хвалят за то что если на нём правильно писать - многопоточность красиво обеспечивается и масштабируемость. Т.е например отсутсвие сайд-еффектов в коде позволяет его распараллелить легко.
На базе чего рекомендатерьную систему пишешь? Стек принципов/базовых методов имею ввиду
https://github.com/pocorall/scaloid/
Давно слежу за проектом, он создает видимость постоянно поддерживаемого китайцем
Почему этого видео еще нет в треде?
Как же я опростоволосился с него.
Стоит как SCALA блять!
Говно какое-то, лучше бы ты что-нибудь полезное прнес.
Спасибо. Да пока ни на чём, изучаю теоретическую часть, поэтому ничего обнадёживающего. За последние года там ничего нового не придумали, с другой стороны, если не считать историю с Нетфликсом.
http://ideone.com/ZX4Tym почему оно вот так?
type erasure в действии
солюшн воркэраунда пикрелейтед
Понятненько.
- Одну минуту, - громко произнес Стасик, - прежде чем
продемонстрировать вам способ поедания борща, о котором все вы, как
будто, позабыли, я должен опорожнить свой кишечник.
Вот каким образом развратник приступил к омерзительной операции. Его
окружили четверо скала-ганимедов: один держал наготове большой ночной горшок,
второй взял зажженную свечу и подставил ее поближе к анусу, чтобы было лучше
видно происходящее, третий сосал ему член, четвертый, перекинув через руку
белоснежное полотенце, целовал Стасика в губы. Тот, опершись еще на двоих
педерастов, поднатужился, и как только появилось невероятное количество
дерьма, которое обыкновенно и регулярно выдавал хозяин замка, учитывая
страшное количество поглощаемой им пищи, тот юноша, что держал вазу,
принялся восхвалять экскременты. "Какое прекрасное скала-дерьмо! - восклицал он. -
Ах, господин мой, какое превосходное скала-говно! Как красиво вы испражняетесь".
Когда дифирамбы закончились, педераст, вооруженный салфеткой, языком очистил
преддверие ануса, а горшечник подставил содержимое горшка под нос Стасику и
опять громогласно восхвалял его. После этого мощная струя мочи ударила в рот
сосателю, который тут же проглотил всю жидкость, полотенце завершило то, что
не мог сделать язык, и четверо ганимедов, оставшись без дела, долго сосали
поочередно язык, фаллос и задний проход распутника.
продемонстрировать вам способ поедания борща, о котором все вы, как
будто, позабыли, я должен опорожнить свой кишечник.
Вот каким образом развратник приступил к омерзительной операции. Его
окружили четверо скала-ганимедов: один держал наготове большой ночной горшок,
второй взял зажженную свечу и подставил ее поближе к анусу, чтобы было лучше
видно происходящее, третий сосал ему член, четвертый, перекинув через руку
белоснежное полотенце, целовал Стасика в губы. Тот, опершись еще на двоих
педерастов, поднатужился, и как только появилось невероятное количество
дерьма, которое обыкновенно и регулярно выдавал хозяин замка, учитывая
страшное количество поглощаемой им пищи, тот юноша, что держал вазу,
принялся восхвалять экскременты. "Какое прекрасное скала-дерьмо! - восклицал он. -
Ах, господин мой, какое превосходное скала-говно! Как красиво вы испражняетесь".
Когда дифирамбы закончились, педераст, вооруженный салфеткой, языком очистил
преддверие ануса, а горшечник подставил содержимое горшка под нос Стасику и
опять громогласно восхвалял его. После этого мощная струя мочи ударила в рот
сосателю, который тут же проглотил всю жидкость, полотенце завершило то, что
не мог сделать язык, и четверо ганимедов, оставшись без дела, долго сосали
поочередно язык, фаллос и задний проход распутника.
Что это за такой уёбищный язык у вас?
Сблеванул с синтаксиса. А за использование case уже давно пора в ёбыч прописывать с ходу.
> за использование case уже давно пора в ёбыч прописывать с ходу.
Чтоу?
Он прав. Плохой стиль. Неуважение к людям, которые будут читать твоё говно. Исправляй.
Мимо_js_monkey
Категория: портвешковый делирий обезьяны
Но ведь синтаксис и вправду говно...
Что за хуйню ты несёшь, как по другому матчить?
Тот мамкин тралл имеет в виду case в структуре switch. Если бы здесь были умные люди, ему бы пояснили, что case без switch это ничто иное как сахар для PartialFunction, типизующий её область определения. Но тут только мамкины тралы и хеллоуворлдщики увы
Я ньюфаг в скале, только недавно решил обмазаться ей. Возник тут филосовский вопрос. Почему для каждой структуры данных своя конкатинация? Тут вам и ++, и ::, и, :::, и append, и ещё всякое разное. Как это запомнить и зачем это сделано?
Просто запомнить
так надо
>2015
>case
Предлагай альтернативу.
if instanceOf
Как это может заменить сопоставление с шаблоном? Там разбирается весь терм на любой уровень вложенности вместе с его типом и одновременно извлекаются и биндятся все желаемые значения, а у тебя что?
тоже самое
yasno))
понятно
Ну вот. А я то думал, что я бидла и фишки не просекаю
так и есть ты быдло
https://groups.google.com/forum/m/#!topic/scala-user/n-59nIEVAOI
Увидел сегодня в рассылке - most noob-friendly community ever.
Увидел сегодня в рассылке - most noob-friendly community ever.
Сильно ли, на текущий момент, Play уступает Spray в производительности? И уступает ли?
Оба упрутся в io.
Смотрите, какая хуйня
http://scala-lang.org/news/2015/02/05/scala-js-no-longer-experimental.html
Оказывается, можно компилять скалу в жс. Кто-нибудь уже пользовался?
http://scala-lang.org/news/2015/02/05/scala-js-no-longer-experimental.html
Оказывается, можно компилять скалу в жс. Кто-нибудь уже пользовался?
Даже твою мамку можно скомпилять в js, столько этих ёбаных трансляторов уже понаписали.
Ну мне просто очень печёт от того что приходится писать фронтенд на динамической параше и блевать от джяваскрипта. А теперь можно всё писать на йоба-функционал-статик-скале.
Привет. Перекатился с RoR на Scala. Язык очень нравится, для моих задач подходит идеально. Но хотел бы услышать объективный ответ на вопрос: когда лучше использовать Scala, а когда Java?
Scala - всегда
Java - никогда
двачую
Sup. Пишу в целях обучения проект на Play.
Есть ли среди нас, добродушный анон, который может ответить на возникшие вопросы и помочь разобраться c ReactiveMongo, Play и работой неблокирующих веб-серверов?
Если такой найдется, пиши в jabber [email protected]
Есть ли среди нас, добродушный анон, который может ответить на возникшие вопросы и помочь разобраться c ReactiveMongo, Play и работой неблокирующих веб-серверов?
Если такой найдется, пиши в jabber [email protected]
Привет, решил попробовать ваш еба-язык. Не знаю Java, но знаю Haskell. Какие подводные камни?
Подготовительную лоботомию уже прошёл?
najtiElementVMassive
Найди наименьший элемент в массиве, скотина.
najtiElementVMassive arr = foldl1 min arr
/0
Посаны, а можно под андроид разрабатывать на скале? Сам не планирую, так чисто из интереса спрашиваю.
Я анус твоей мамаши вчера хорошенько разработал.
Да, можно.
>Какие подводные камни?
>Не знаю Java, но знаю Haskell
Зависит от того, насколько ты "не знаешь" джаву и "знаешь" хаскель. Если ты на работе писал на шарпе, а про хаскель читал в интернетах и писал хелловорлды, как я в своё время, все будет ок, язык понравится.
Если же хаскель знаешь хорошо, а на С++-подобном говне не писал, то рискуешь проблеваться.
Вот что еще может быть интересно почти всем в этом треде:
http://tonymorris.github.io/blog/posts/what-kind-of-things-are-easy-in-haskell-and-hard-in-scala-and-vice-versa/index.html
Что означает твое высказывание в данном контексте?
Для чего нужен этот язык и что на нём пиздатого можно сделать? Ну и как по востребованности?
Хуёвый вывод типов, хуёвая производительность, хуёвая IDE, хуёвый синтаксис, хуеватые либы.
компилятор написан олимпиадниками
Если хочешь в ФП с монадками и scalaz готовься к зависшей на проверке имплиситов IDE и к SOE в рантайме
Такие дела
Норм будет, если одновременно с принципами ФП в Scala проходить? Или без пройденного курса по ФП я ничего не пойму?
У тебя есть еще полтора месяца, чтобы ознакомиться с курсом фп на скале. Этого будет достаточно. Алсо, да, если незнаком с ФП, то курс по фп обязателен.
> У тебя есть еще полтора месяца, чтобы ознакомиться с курсом фп на скале.
Так он только в апреле начнётся и чуть позже реактивного программирования. Или ты имеешь в виду просто посмотреть скалу и фп самому где-нибудь ещё?
Пиздец, всегда путаю, что идет следующим после февраля, апрель или март. Тогда не так много времени. Хотя за две недели все равно можно посмотреть большую часть лекций по фп (они должны быть в открытом доступе сейчас). Я в прошлом году так и сделал. Быстро пробежался по курсу фп и с опозданием начал реактивы. Пукан побаливал, но процентов 60 информации усвоил, все домашки сделал. Сертификат не получил, но знаний хватило, чтобы потом сделать скалу и акку своими основными инструментами. В этом году буду уже ради сертификата проходить, плюс они должны были пофиксить кучу багов, которые были в прошлом курсе.
Ты всё правильно написал сначала, до середины апреля полтора месяца.
Ну вообще охуеть.
А можно проходить курс по фп, но на окамле? Мне скалку ставить некуда, а окамлц пылится в углу.
поясните за тайпсейф активейтор, стоит ли его использовать?
нет
ну а что он вообще из себя представляет?
генерит готовые шаблоны под типичные приложения
Поцыки, расскажите ньюфане про SBT. Про сборку я немного понял, но как осуществлять деплой?
publish
Что за артефакты, репозитории, POM и прочее? Мне нужно развернуть приложение на удаленном сервере.
jvm стек для меня совсем в новинку.
sbt-native-packager жи есть
Будь няшей, объясни многоходовочку:
- собрали
- залили вместе со статикой (куча файлов) на удаленный сервер;
- запустили;
И заливать нужно быстро, т.е. не перезаливать неизменившиеся файлы (аля rsync).
блять берешь убанту 14.04 ставишь докер на него накатываешь докку, делаешь гит пуш сбт проекта и все само деплоится заебал
Оно хуже Хаскеля но работе есть выбор между Скалой и Джавой, а не между Скалкой и Хаскелем. На счет скобочного говна и телебейсика ты пошутил наверное.
>Нужно ли знать джаву чтобы найти работу?
В основном да. У нас есть люди, которые никогда раньше не программировали на Джаве, но это скорее исключение. Обычно Скалка - это игрушка для джавамирка и помимо проекта на Скале у тебя еще будет зоопарк систем на Джаве.
>Есть ли вообще работа?
Да.
>Насколько хорошо надо знать джава/жвм и всю эту инфраструктуру чтобы что-то писать осмысленное?
Чтобы что-то осмысленное писать хорошо её надо знать, другое дело что программисты на Скале частенько сами не до конца понимают, что такое хорошо, а что такое плохо, поэтому быдлокод в большинстве случаев прокатывает.
Наш проект под ОС ПИТУХ компилируерся почти в два раза быстрее, чем под нормальной операционной системой. Не знаю, поможет ли тебе это. А так используюй REPL и дижею, там получается без компиляции обходиться.
ООП - уебанство. Множественное наследование - уебанство в квадрате. А трейты - линеаризованное уебанство в степени уебанства. Щито поделать, десу?
Если ты про трейты, то выберет в зависимости от порядка, в котором трейты унаследованы (а именно реализацию из самого "правого" трейта, либо из тела класса, если там метод перегружен).
>На каком-то этапе теряется сообщение.
Это вся суть Акки. Акка написана петухами для петухов, не трать на неё время. По крайней мере не делай это бесплатно. Конечно, многие долбоёбы пихают её в прод и с ней приходится трахаться, но бесплатно-то зачем говно жрать?
Когда твой выбор ограничен сортами говн - выбирай Скалу. Во остальных случаях - язык программирования.
>Во остальных случаях - язык программирования.
Например?
Лексах
Хуже божественного Erlang, но лучше хачкеля.
Эрланг не предназначен для написания чего-либо надёжного.
В отличии от хачкеля то?
Не только хаскеля, но и большей части мейнстрима. Он на антрипаттерне построен. Конечно, некторые долбоёбы его и в джаву тащут, в результате приложение на джаве начинает работать так же дерьмово, как и на эрланге, но это уже проблема программиста, а не языка.
>Это вся суть Акки. Акка написана петухами для петухов, не трать на неё время. По крайней мере не делай это бесплатно. Конечно, многие долбоёбы пихают её в прод и с ней приходится трахаться, но бесплатно-то зачем говно жрать?
Посмотрим как ты закукарекаешь когда типизированных акторов допидорят
>хуже Хаскеля
>ООП - уебанство
>Акка написана петухами для петухов
>Когда твой выбор ограничен сортами говн - выбирай Скалу. Во остальных случаях - язык программирования.
Ммм, какой толстый петух.
Почему в языке нету параметризованных синглтонов?
хочется писать
object Foo[T] = ...
А в коде потом
Foo[Int].doStuff() или Foo.doStuff(intParam)
Инстанцировать, видимо, лениво. Вопрос в том, как синглтоны инстанцируются скалой сейчас (на старте приложения же?) и почему нельзя запилить генерики.
хочется писать
object Foo[T] = ...
А в коде потом
Foo[Int].doStuff() или Foo.doStuff(intParam)
Инстанцировать, видимо, лениво. Вопрос в том, как синглтоны инстанцируются скалой сейчас (на старте приложения же?) и почему нельзя запилить генерики.
Падажи, так синглтон у тебя один или по одному для каждого типа?
А когда они должны создаваться? При первом вызове? Или сразу для всех возможных типов?
sealed class Foo[T] {
def doStuff() = ???
}
object Foo {
def apply[T]() = new Foo[T]()
}
Держи http://ideone.com/m6CwNg
http://scalex.org/ - эта хуйня не работает?
Пусть у меня (условно в жаве) в синхронном коде есть последовательность вызовов, которые могут выбросить исключения. Тогда я использую finally для кода, который гарантированно выполнится, прервется цепочка или нет. Каков аналог finally для композиции Future через andThen (recover/recoverWith - это же подобие catch|catch-maybe-throw?)?
AHTUNG
AHTUNG
AHTUNG
AHTUNG
AHTUNG
Новая сессия Principles of Reactive Programming на Coursera стартует через 11 часов.
https://www.coursera.org/course/reactive
ГЕРОЯМ СЛАВА
А чем обычный onComplete не устраивает?
Стоит ли вкатываться в этот курс, если скалу ни разу не видел и Principles of Functional Programming не проходил? В ФП могу на уровне хаскеллепараши.
да, но придется поднадрочиться, тут тяжелее, чем в хаскеле, лепить карринг и партиал фанкшнс.
А ни у кого нет архива заданий с предыдущего курса?
А то я начал делать вперед, а они буквально неделю назад закрыли доступ к предыдущему курсу.
Пасаны поясните за web framework для scala хочу перекатиться с питона
play framework - если нужен честный веб фреймворк, где большинство фич из коробки
spray.io - есть есть желание клепать асинхронные rest сервисы.
Спасибо.
Даже сам Одерски не знает о багах в своей поделке:
https://class.coursera.org/reactive-002/forum/thread?thread_id=232
https://groups.google.com/forum/#!topic/scala-debate/je4vZbR3WbA
https://class.coursera.org/reactive-002/forum/thread?thread_id=232
https://groups.google.com/forum/#!topic/scala-debate/je4vZbR3WbA
Анон, когда в православной scala запилят нормальный websocket?
отстой. я за ним давно слежу
Следишь или используешь? В чем отстой-то? Все тесты автобана проходит.
не работала раньше с моей версией sbt. поэтому забил.
нет. прости
По-моему самая живая из статически-типизировавнных поделок - это микросовтовский TypeScript
То, что они написали, что больше не экспериментальный - это хуйня. Скала на джаве до сих пор экспериментальная, фактически, а они про жс
> Scala + Java - всегда
не благодари
Работаю в проекте, написанном с нуля на скале. Дико пригораю с имплиситов. Ни один разработчик, долгое время работающий на проекте, пока не смог объяснить, в чём космический эффект этого говна: что-то где-то откуда-то берёт параметры, причём чтобы найти место, откуда всё-таки это приходит - ты должен прошарить все скоупы, которые тебе доступны. Как бывшей джава-макаке мне не понятно: нахуя прятать от кодера информацию?
Объясните полезность, в общем.
Объясните полезность, в общем.
что бы можно было реализовать паттерн "тайпкласс"
Классика компьютерной науки http://isorecursive.livejournal.com/1622.html
Имплиситы это как раз та вещь, которой не нужно злоупотреблять.
Скала вообще специфический язык.
Чтобы нормально использовать его в промышленном программировании, нужно соблюдать ряд строгих ограничений на использование возможностей языка.
Например, скалаз идет нахуй сразу же.
И вообще любые нездоровые игрища с типами.
Про это много написано, гугол тебе в помощь.
И в первом же комменте - известный карго-культист - монадодрочер.
Что отлично характеризует целевую аудиторию подобной хуйни.
Моноид, блядь, пиздец вообще, хули там обсуждать? Так нет же, дрочат и дрочат, бессмысленно и беспощадно.
Конструкторы соломенных монад, блядь.
Удивительно, что ты автора поста не опознал. Да, мельчает анонимус.
Спасибо за ответы.
Почему работорговцы такие тупые хуесосы? Неужели вы думаете, что если человеку мозги выебать и запугать, он станет хорошим дружком-наблюдателем? Неужели вы думаете, что если шкуру "натренировать", выебав по кругу во все дыры, а потом ещё мозги прочистить, она не станет противна ТОВАРУ? Неужели непонятно, что все эти подсадные обиженки не могут воспринимать ТОВАР как друга, любовника, не могут быть с ним искренними, а следовательно, на одной волне? Неужели вы думаете, что ТОВАР этого не чувствует, не замечает в их взглядах, жестах, интонациях? Неужели вы считаете, что уточка-"фпшница", которая с умирающим видом зевает, когда ты рассказываешь ей про комбинаторы парсеров, а в следующий момент пиликает "о госпаде это всё так интересно" - это охуенно мотивирующий и жизнеутверждающий икспириенс? Вы хоть пробовали анализировать, как меняются отношения ТОВАРА и близких после того как вы обработали последних? Я уже давно боюсь знакомиться с новыми людьми, потому что я знаю, что их сломают, и меня они будут в худшем случае ненавидеть, а в лучшем - рассматривать как мешок с деньгами, из которого и им перепадёт, если хорошо потрусить. Кароче, пиздец, господа, не знаю какая у вас там статистика успешности вашей деятельности, но у меня складывается впечатление, что всё, чем у вас по факту получается быть - это ёбаными чекистами, разрушающими всё святое, что было у человека. Хуй знает, как вы это потом продавать собираетесь. Мой вам добрый совет: меняйте парадигму. Пришло время переписывать методички.
https://www.youtube.com/watch?v=Log4mbxgiaM
https://www.youtube.com/watch?v=Log4mbxgiaM
Изначально имплиситы были задуманы для "pimp my library" (по аналогии с pimp my ride) - добавления новых фишек в уже готовые чужие библиотеки (классы). В руби это называют monkey patching. Тайп-классы (на бытовом уровне) - примерно то же самое.
И плюсы и минусы тут очевидны. В руби-говне, например, разобраться бывает весьма затруднительно.
Также, имплиситы используются в самом языке - для рефлекшна, например. В этом случае без них было бы криво. Тем не менее, в последних версиях они считаются advanced feature, и должны быть явно разрешены.
Вообще, скала вызывает у меня двойственные чувства. Как и у большинства людей. Например, рекомендую прочесть вот это (там 3 части): http://zeroturnaround.com/rebellabs/scala-sink-or-swim-part-1/
Также, весьма рекомендую вот это:
http://twitter.github.io/scala_school/
Вот хорошее про функторы-монады-хуяды (хаскель, но тем не менее):
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
Вот функторы и функциональная композиция на джаваскрипте, тоже хорошо для понимания:
http://functionaljavascript.blogspot.ru/2013/07/functors.html
По чистой функциональщине есть очень хорошая книжка "Functional Programming in Scala". Вообще по языку, включая функциональщину - Scala in Action, Scala in Depth. Для быстрого старта - Scala for Impatient.
Я начинал со "Скала для нетерпеливых", в книжке всё выглядело классно и круто, опережающие определения, крутые коллекции, опции, кейс-классы и паттерн мэтчинг. Потом, когда я столкнулся с продуктивным кодом, я понял, что функциональный язык - это экзотично, но ни разу не newbie-friendly. Очень много неявных механизмов, которые скрывают детали реализации. По итогу, для функциональщика скала слишком императивна, для императивщика слишком функциональна. Чисто моё имхо после полугода работы на скале после Java EE: скала не подходит для индустриального программирования, если в команде есть хоть один функциональщик. Даже одного достаточно, чтобы в коде появилась куча ненужных абстракций, которые экономят строчки кода, но отнимают у остальных разработчиков чувство контроля над кодом.
Строго говоря, я ещё сам не понял, может ли моё мнение претендовать на объективность, или это очередной баттхёрт утёнка.
Это типичные ощущения человека, пытающегося писать на скале. Такой язык.
А функциональщину полезно изучать, экспериментировать, но в реале применять нужно весьма дозировано.
> Даже одного достаточно, чтобы в коде появилась куча нормальных абстракций, которые экономят строчки кода, но отнимают у умственно-отсталых императивных мартышек чувство контроля над кодом.
Обобщу то что написали челики выше. Имплиситы нужны для:
1) Pimp my library. Полезность очевидна, ничего нигде не скрывается.
2) Typeclasses (почему-то сразу все начинают выёбываться знаниями тривиальных вещей и кукарекать про монады с моноидами, и не говорият про TypeTag, всякие Reads/Writes из play-json и другие походие применения тайпклассов.
3) Dependency injection, без явного указания параметров по всей иерархии вызовов.
4) Неявные преобразования. Единственная спорная штука, чаще даже вредная, чем полезная. Обычно лучше использовать pimp my library и добавлять методы вроде asFoo/toBar. Это, кстати, одна из причин, по которой использование JavaConverters предпочтительнее JavaConversions.
5) Редко используемый приёмы вроде CanBuildFrom в коллекциях, для вызова различного кода в зависимости от типов.
>Очень много неявных механизмов, которые скрывают детали реализации.
И в чем проблема? Программирование и есть абстракция от деталей реализации.
>скала не подходит для индустриального программирования, если в команде есть хоть один функциональщик. Даже одного достаточно, чтобы в коде появилась куча ненужных абстракций, которые экономят строчки кода, но отнимают у остальных разработчиков чувство контроля над кодом.
Как будто ненужные абстракции только функциональщики плодят. Для скала-команды важно чтобы её члены стремились учиться и обсуждали язык, новые техники и технологии, чтобы не было очень отстающих. Стайл-гайд тоже нужен, хотя бы неформальный, или хотя бы чтобы можно было сказать: чувак, ты написал херню, или что-то непонятное, объясни почему ты сделал именно так или перепиши нормально.
>Вообще, скала вызывает у меня двойственные чувства. Как и у большинства людей.
>Это типичные ощущения человека, пытающегося писать на скале. Такой язык.
Я понимаю, откуда берутся такие ощущения. Скала как раз тем и сложна что нужно постоянно балансировать между ФП и ООП и вообще между разными фичами, для чего нужна самодисциплина чтоле. Новички, слабые программисты и просто середнячки часто скатываются в стороны, что приводит к запутанному коду. Поэтому скала подходит далеко не для каждой команды.
> Dependency injection
Это тоже спорно. В случае когда из 10 имплисит зависимостей тебе надо передать один параметр явно, остальные имплисит параметры тоже придется передавать явно.
Так это скорее разумно использовать как внедрение контекста, как например ExecutionContext у Future, или Request в Play.
А неявными преобразования и имлисит классы как раз очень годная вещь, позволяющая делать сахарные DSL.
Новички-середнячки тут ни при чём.
Скала - академический язык, и его только-только начали доводить до возможности нормального промышленного использования. И ещё хуй знает, что в итоге получится.
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
Да, но, к примеру, idris ограничивает их одним преобразованием за раз, чтобы код не превращался в магию.
_мимопроходил_
Компейлятор скалы тоже не сможет вывести через 2 имплисит преобразования насколько мне известно.
Да, подтверждаю
Ну ок тогда. Хотя, возможно, стоит как-то контролировать количество неявных преобразований в пределах одного выражения?
Я это в основном и имел в виду, не знал как коротко написать.
Годная, но имеет ограниченную область применения. ДСЛе писательство это вообще отдельная тема.
>Хотя, возможно, стоит как-то контролировать количество неявных преобразований в пределах одного выражения?
Это может очень замедлить компиляцию.
>he avoids clever tricks
Вопрос только в том что считать tricks. GoF выглядит как сборник tricks? Как по мне да.
>Скала - академический язык, и его только-только начали доводить до возможности нормального промышленного использования
А вот диванный иксперт закукарекал.
Ты неправильно понимаешь, что такое clever tricks.
Если хочешь пример - это функциональщина в ООП проекте ради экономии пары строк кода и ради того, что именно такой код тебе именно сегодня кажется красивым, хотя другим он кажется нечитаемой хуйнёй.
А ещё ради того, что ты сам себе при этом кажешься охуенно продвинутым, возвышающимся над серой массой как блестящая лиловая залупа, торчащая из пены в ванной.
Пассаж про диванного эксперта даже комментировать не хочу - это очевидная проекция.
Скала не только ООП язык, но и функциональный, так что мнение болезных мартышек, которым там что-то непонятно, всем похуй.
> clever tricks - это функциональщина в ООП проекте ради экономии пары строк кода
Любое усложнение кода ради эконимии пары строк кода это плохо.
Че ты доебался к какой-то функциональщине? Что это вообще такое?
>ты сам себе при этом кажешься охуенно продвинутым, возвышающимся над серой массой
Что бы такого не было, нужно, как я уже писал про отношения внутри команды,
>чтобы можно было сказать: чувак, ты написал херню, или что-то непонятное, объясни почему ты сделал именно так или перепиши нормально
>это очевидная проекция
Сорре, но нет. Я уже почти как два года на скале пишу, в команде есть люди с 3+ годами опыта.
И для меня очевидно что у тебя нет опыта использования функциональных или гибридных языков, но есть мнение о них, о разработке с их использованием, о мифических clever tricks и функциональщине.
Мне одному кажется что этот пост полон боли порванного императивного мартыхана?
Какой-то у вас тут странный спор.
Вообще, нормальные люди стараются писать код не столько для себя, сколько для команды. Аутисты, пишущие код, понятный только им самим, нахуй уже никому не нужны. Нормальные люди либо подстраиваются под команду, если она достаточно хороша, либо ищут такую, под которую или не надо подстраиваться вообще (настолько там все пиздаты и круты), или вообще можно всех подстроить под себя.
В связи с этим реально веселят функциональные мамкины илитисты, которые работают в толпе императивных макак, не находят понимания у коллег, а потом исходят на говно на анонимной борде, в попытках как-то оскорбить совершенно левых людей. Собственно как и императивные бибизяны, которые горят от необходимости адаптироваться под функциональную команду.
Вообще, нормальные люди стараются писать код не столько для себя, сколько для команды. Аутисты, пишущие код, понятный только им самим, нахуй уже никому не нужны. Нормальные люди либо подстраиваются под команду, если она достаточно хороша, либо ищут такую, под которую или не надо подстраиваться вообще (настолько там все пиздаты и круты), или вообще можно всех подстроить под себя.
В связи с этим реально веселят функциональные мамкины илитисты, которые работают в толпе императивных макак, не находят понимания у коллег, а потом исходят на говно на анонимной борде, в попытках как-то оскорбить совершенно левых людей. Собственно как и императивные бибизяны, которые горят от необходимости адаптироваться под функциональную команду.
Если я часть команды, то остальные должны подстраиваться и под меня тоже.
Вообще если команда полна мартышек, это не повод деградировать и писать дристню, а повод их обучить до уровня функциональных господ либо выкинуть на мороз.
Двачую этого господина.
Cкорее тебя выкинут на мороз, функцианальный господин ты наш
Тырпрайз команды переписывающие ява легаси на скалу в таком же императивном стиле чтобы было "ололо современно" считаю говноедством.
Пора свыкнуться с фактом, что функциональщина в скале - норма, ООП в ней нужен только как система модулей и для интеропа с явой.
Але бля! Посмотри на стандартный стек от Typesafe - Play Framework (Iteratee, ActionFuctions compositions), Slick, Akka Streams+Http. Не говоря уже о сторонних спарках, алгебердах (асбтрактная алгебра, ахуеть теперь), скалдингах.
ФП это не какие-то мифические "монады в хачкиле". В Spay используются typelevel свистелки на HListах из шейплеса, не верх ли мракобесия в продекшене.
Пора бы уже понять что динамический диспач виртуальных методов как единственная выразительная конструкция языка грубо говоря себя изжил.
Пора свыкнуться с фактом, что функциональщина в скале - норма, ООП в ней нужен только как система модулей и для интеропа с явой.
Але бля! Посмотри на стандартный стек от Typesafe - Play Framework (Iteratee, ActionFuctions compositions), Slick, Akka Streams+Http. Не говоря уже о сторонних спарках, алгебердах (асбтрактная алгебра, ахуеть теперь), скалдингах.
ФП это не какие-то мифические "монады в хачкиле". В Spay используются typelevel свистелки на HListах из шейплеса, не верх ли мракобесия в продекшене.
Пора бы уже понять что динамический диспач виртуальных методов как единственная выразительная конструкция языка грубо говоря себя изжил.
Ничего из перечисленной тобой хуеты не используется в энтерпрайзе.
Стандартный стек от тайпсейфа - для кого он стандартный?
Кстати, монады в хачкиле совершенно не мифические, а самые настоящие.
А вот фп в скале местами очень напоминает карго-культ.
А кто тебе сказал, что это я не понимаю скалу или функциональщину? У меня, как раз, с этим всё хорошо.
Просто я регулярно читаю, как весьма неглупые люди исходят на баттхёрт по поводу скалы.
И я их прекрасно понимаю.
Потому, что скала местами очень напоминает перл. Тоже, кстати, очень хороший язык.
А ещё я вижу, что типичный код на скале из интернетов состоит из clever tricks чуть более чем полностью.
Поэтому, я думаю, что до массового применения скалы в энтерпрайзе ещё очень далеко.
А ещё я хочу сказать, что я изрядно разочаровался в скале именно из-за того, что среди коммюнити и контрибьюторов очень много долбоёбов, которым похуй на практичность, зато очень хочется показать, какие они клёвые трюкачи, как они умеют в хаски-арт и т.д.
В итоге, язык остаётся академическим говном, а я вынужден писать на джаве.
Такие дела.
Мартыхану неприятно
> Ничего из перечисленной тобой хуеты не используется в энтерпрайзе.
> Стандартный стек от тайпсейфа - для кого он стандартный?
Охуительные истории
мудаку неприятно.
ну пойди прочти книжечку по spring или там hibernate и напиши еще один петстор.
ты хотя бы посмотрел, какие кастомеры у того же typesafe.
это тебе не хайбернейтовский маппинг настраивать.
>А кто тебе сказал, что это я не понимаю скалу или функциональщину? У меня, как раз, с этим всё хорошо.
Я говорил про опыт использования, а не про то, понимаешь ты что-то или нет. Студентики 2 курса тоже "понимают" ООП, а когда приходят в первый бодишоп, все оказывается немного по-другому.
>Потому, что скала местами очень напоминает перл.
1) Наговнокодить можно на любом языке.
2) Еще раз мой комментарий по этому поводу:
>Я понимаю, откуда берутся такие ощущения. Скала как раз тем и сложна что нужно постоянно балансировать между ФП и ООП и вообще между разными фичами, для чего нужна самодисциплина чтоле. Новички, слабые программисты и просто середнячки часто скатываются в стороны, что приводит к запутанному коду. Поэтому скала подходит далеко не для каждой команды.
3) Перл академический это просто пиздец.
>А ещё я вижу, что типичный код на скале из интернетов состоит из clever tricks чуть более чем полностью.
Может бы потому что он написан для их демонстрации? Хочешь нормальный код увидеть - читай код библиотек. Их обычно челики поумнее пишут.
>А ещё я хочу сказать, что я изрядно разочаровался в скале именно из-за того, что среди коммюнити и контрибьюторов очень много долбоёбов
Примеры, я за два года не заметил такой хуйни.
>Поэтому, я думаю, что до массового применения скалы в энтерпрайзе ещё очень далеко.
Не знаю, почему ты и даун выше доебались к слову "энтерпрайз", как будто это показатель чего-либо, но тут ты прав, по большому счету:
http://www.javacodegeeks.com/2011/09/yes-virginia-scala-is-hard.html
http://www.javacodegeeks.com/2011/09/scala-use-is-less-good-than-java-use.html
Правда, проблема не в том что это "академический язык" ты вообще знаешь что это такое?, а в том что большинство программистов - дауны уровня пту (см. выше), в лучшем случае середнячки.
Прав. Несколько раз подавлял желание добавить scalaz в проект. Пока доволен тем, что никто не пишет императивную дрысню и в планах есть курс по advanced scala & fp.
Так и знал, что тебе будет нерпиятно.
Что ты пишешь на скале?
"Опыт", "2 года" - это слишком общие слова.
Что именно?
Работаешь ли ты ин-хаус или в софтверной компании?
В каком городе/стране?
В общих чертах, деанон не нужен.
Также, правильно ли правильно ли я понял, что ты - тот самый жжист, который запостил пост про функторы ()?
Пост про моноиды, кончно же, просто забыл уже.
У Андрюши вроде сейчас другой прикол, думаю это не он.
Двачую этого, но scalaz таки импортнул не сдержался.
Почитал ваш срач по диагонали насчет Скала.
За десять лет так и не выяснили как правильно на нём писать - охуенный язык. Спасибо Мартину.
За десять лет так и не выяснили как правильно на нём писать - охуенный язык. Спасибо Мартину.
>как правильно на нём писать
Не писать на нем
Бро, спасибо, ты буквально в двух словах выразил всю ту гамму чувств, которую я по этому поводу испытываю, лол.
- кун.
Работаю в киевской компании. В общих чертах, пишем систему для обработки множества событий и генерации аналитики по ним. До этого еще всякие сервер-сайд штуки писал, не буду уточнять, т.к. круг скалистов небольшой, может деанон случится.
>правильно ли правильно ли я понял, что ты - тот самый жжист
Нет. Я подытожил ответы про имплиситы: .
Ну я так и делаю, кстати.
Скалисты, расскажите мне о полезных штуках в Скале, которые вы используете постоянно, но таких не в Джаве. Я не про общее удобство и не про то, что реализовано в сторонних библиотеках. Например, ООП в C++, которого нет в C, и которое в последнем без здоровенных костылей не замутить. Кейс-классы и паттерн матчинг, например.
> мам ну скажи ему что это он мартышка!
Это ты мартышка.
Мама того анона
типы алиасы
лямбды (до java 8), система типов, миксины
Паттерн матчинг раскрывается полностью только когда научишься писать кастомные экстракторы (unapply, unapplySeq).
С помощью них можно даже последовательность байтов разобрать на параметры одной строкой. Я так недавно socks-сервер написал.
Как-то не впечатлило, но пойдет.
Лямбды и до восьмерки реализовывались малой кровью.
Не понял что ты имеешь ввиду под системой типов.
Миксины - ок.
>научишься писать
На курсы-то ходить не надо чтоб научиться?
> На курсы-то ходить не надо чтоб научиться?
Суть не в том чтобы научиться писать, а в том чтобы научиться применять. Человеку который до этого писал только на императивных языках, обычно очень сложно понять, где использовать все эти функциональные фичи, т.к. он уже привык делать всё императивно, у него сам образ мышления императивен. Это усугубляется тем, что скала без проблем позволяет писать говнокод джява-стайл, и не приучает сама к хорошему стилю.
Поясните вообще в чём суть скалы в продакшене? Вижу вакансию вот на джуниора под скалу, но зачем? Смысл? Это же аутсорсерам заказывают такие проекты, смысл использовать такой язык? Порог вхождения высокий, я так смотрю на него и мне даже кресты в несколько раз проще кажутся, компилятор вон с багами, фич конечно полно. Но ведь вы понимаете что вы пишете на под компьютеры в которых возможно только императивное программирование? Ваш код так или иначе транслируется в императивный. Так зачем сопротивляться и писать на таких языках? Пишите на джаве, на крестах, всё-равно через 2 десятка лет и скала и все языки ныне существующие устареют и станут юзлесс.
> Порог вхождения высокий, я так смотрю на него и мне даже кресты в несколько раз проще кажутся, компилятор вон с багами, фич конечно полно.
Неправда, скала очень простой язык, по сравнению с крестами и джявой с её спрингами и гибернейтами.
> Но ведь вы понимаете что вы пишете на под компьютеры в которых возможно только императивное программирование? Ваш код так или иначе транслируется в императивный. Так зачем сопротивляться и писать на таких языках? Пишите на джаве, на крестах, всё-равно через 2 десятка лет и скала и все языки ныне существующие устареют и станут юзлесс.
То что ты ешь так или иначе транслируется в говно. Так зачем сопротивляться и есть человеческую еду? Жрите сразу говно за обе щеки.
Кстати про простоту скалы он без сарказма сказал. Многие вещи унифицированы и сделаны проще. Например выпилен специальный синтаксис массивов.
В твиттере, линкедине, нетфликсе тебе пояснят по хардкору.
>Например выпилен специальный синтаксис массивов.
Туда же можно добавить AnyVal|AnyRef вместо постоянных оговорок про элементарные типы. В 8-ой Яве пришлось делать несколько отдельных стримов для элементарных типов, в Скале все и так будет нормально приводится к элементарным типам.
а можешь раскидать по хардкору, как народ пишет эти ваши веб-приложения на скале? на java понятно - берешь спринг, сверху хибернейт, какой-нибудь шаблонизатор и вуаля!
со скалой это наверное какой-нибудь play framework или там scalatra (или вообще spray если у тебя там spa), а что народ использует для доступа к базе, как разруливает проблемы с секьюрити и вот это вот все?
Вбрось кусок кода.
Type inference, abstract types, existential types, path dependend types, type variance, ну и немного не в тему но и и имплиситы (context bound, view bound).
> для доступа к базе
Slick же
Play2(там и сервер и шаблонизатор и Аллах), slick для базоебли в функшионал-стайл, дальше по вкусу. Для секурности либы тоже есть. Опять же никто не мешает впердолить что нибудь джавовое.
Есть мнение что скалка просто инструмент дающий больше возможностей, но при этом более сложный. Ты же яму можешь и лопатой выкопать, а можешь сделать быстро экскаватором. Но им надо уметь управлять. А джуниор скалы просто для снижения bus-фактора. Врагу не пожелаешь потерять хорошего разработчика и потом пытаться выучить скале спрингомакакена.
Не понял зачем toBytes везде PartialFunction.
>case v @ SocksVersion.SocksV4 ⇒ // SOCKS4
Вот так было бы более идеоматично:
case SocksVersion.SocksV4(v) => ...
Но это константа же, а не экстрактор
А сделать её экстрактором тебе религия запрещает?
Плюс, вместо
case SocksVersion(SocksVersion.SocksV4) :: ...
можно было бы
case SocksVersion.SocksV4(v) :: ...
и потом (v, command, ...)
Да и SocksVersion можно было бы при таком подходе трейтом сделать, наверное.
В итоге всё стало бы несколько больше похожим на скалу. А в нынешнем виде - это, скорее, си.
Во всяком случае, там куча сишных идиом.
>его только-только начали доводить до возможности нормального промышленного использования
Скалу "только-только" начали подпирать костылями, чтобы она подходила хоть для какого-то использования. Достаточно взглянуть на её библиотеку коллекций, чтобы понять, насколько там всё плохо. При этом создатели Скалы находятся в очень неудобном положении вися между массивом стульев. С одной стороны, как в Джаве сделать нельзя, потому что работать с иммутабельными коллекциями без фильтров, мапов и тому подобным крайне неудобно. С другой, реализовать нормальные полиморфные функциии там тоже затруднительно (не в последнюю очередь из-за сабтайпинга). И наконец, отсутсвие ленивости, которое превращает списки и итераторы в принципиально разные вещи, и отсутсвие чистоты, которое делает фьюжн невозможным. Плюс заявка на индустриальный язык для серьёзного бизнеса, а в этом сообществе с большим подозрением относятся к сложно контролируемым оптимизациям вроде неявного фьюжена либо неявного форсирования ленивости (даже если это возможно). Как результат, появлятся всякие уродцы, вроде TraversableLike, TraversableOnce, GenTraversableLike, GenericTraversableTemplate, Iterable, IterableView, IterableViewLike, Iterator, GenIterable, SeqView, SeqViewLike, Seq, SeqLike, AbstractSeq, LinearSeq, LinearSeqOptimized, HasNewBuilder, CanBuildFrom, Patched, Prepended, Reversed, Zipped, ZippedAll, Sliced, Transormed с дополнительными параметрами типов, имплицитами, и прочей хуйнёй-молофьёй. Всё это можно освоить, но это ебанный пиздец по сложности ни с какими функторами-монадами не сопостовимый. Т.е. чтобы эффективно использовать банальную библиотеку коллекций в Скале, надо быть нихуёвым икспертом в области этой самой библиотеки.
Я думаю, половина местных скалаикспертов соснёт, если я попрошу написать эффективную полиморфную функцию над коллекциями. Потому что там слишком дохуя степеней свободы в выборе подходящих интерфейсов, маневрировании между общностью и эффективностью, выборе эффективного низкоуровневого доступа через билдер против более "функциональной" но менее эффективной реализациии через готовые функции, и просто в понимании тонкости сортов этого говна. В итоге, когда люди решают реальную задачу, они просто используют конкретный List, даже без полиморфизма по типу элемента, у них нет времени задрачивать скала-коллекции, им надо, чтобы работало. И вот тут происходит весьма интересная хуйня. Дело в том, что в Хаскеле тупо ебашить на листах и комбинировать готовые комбинаторы - это весьма правильно и идиоматично. Подразумевается, что комбинаторы заинлайнятся, промежуточные структуры дефорестнутся, что надо - зафорсится. В Хаскеле лист - тащем-то обычный ADT, ничем не отличающийся от остальных таких же. Т.е. человек, который тупо пишет на Хаскеле, как бы по дефолту прав и пишет правильный код. В нём большая часть библиотек так написана - тупое объявление базиса и дальше комбинирование базисных функций (подразумевается, что компилятор должен их оптимизировать, причем на это можно положиться, потому что в условиях отсутвия сайдэффектов правила перезаписи весьма тривиальны и доступны для понимания). В случае Скалы это не совсем так. Человек, который тупо использует List где ни попадя - не совсем прав. Потому что List в Скале - это весьма специализированная структура данных, оптимизированная для вполне определенных действий. Правильно в Скале писать именно так, как это сделано в её библиотеке коллекций. Срезать углы в Скале - неправильно. Поэтому человек, который тупо пишет на Скале, как бы по дефолту быдлокодит. А небыдлокодить на ней, как я уже писал, довольно сложно, в итоге большая часть кода, тупо написанная на этом "промышленном" языке, по умолчанию будет быдлокодом, в то время, код, написанный аналогично на Хаскеле - будет вполне идиоматичным.
Какая хорошая экспертиза. Я бы ещё добавил, что для идеального языка достаточно удобных литералов, переменных, циклов, массивов, хешей, контекстов (ооп или тайпклассо-трейто-имплиситы для состояния, try-catch для исключений, nullity-as-falsum для short-circuiting), ну и подможества континуаций в виде yield/yield-from, в которое все интересные монады вкладываются удобнее чем в сами монады. То есть, кофе/ноджс или петон.
Всё так.
Даже добавить нечего.
А зачем, Маня, если это сравнение уже извлеченной константы?
А SocksVersion это не трейт?
хуита,
в скале говно только колекции, потому что их писали студенты-дауны.
Как то ты сделал меня грустить. Только я думал что из жабомакакуса превращаюсь в функционалогосподина и ты так меня в говно мокнул. Скажи няша, а когда надо использовать лист а когда что то другое?
Лучше использовать Vector, если не добавляешь много элементов в конец/начало, или не разбираешь рекурсивно через head :: tail
мимо
> или не разбираешь рекурсивно через head :: tail
Срезы в скалку не завезли?
Давай пример "срезов"
Не только. Например, любой язык с иерархическими неймспейсами в любой их форме - говно, потому что способствует генерации безумной сложности на ровном месте. Одна библиотека - один ёбаный импорт - и заебись! Вот как живёт элита. Но это только один из секретов успеха. Общая парадигма такова: сложность можно побороть только простотой.
> один ёбаный импорт - и
... область видимости засрана 9000 ненужными классами
Ну хорошо, надо уточнить, что конечно же, должна быть возможность указать имена, импортируемые из либы "import Yoba, qux from liba", возможность переименовывания "import Yoba as Foo from liba", квалифицированного импорта "import gtk as GTK @ new GTK.YobaWidget".
Так и сейчас так, import liba.Yoba
К тому же достаточно просто использовать йобу, и IDE автоматом найдёт и импортнет её.
Сейчас так только в питоне и ноджс/ecmascript6. В хаскеле, сишарпе, жабе, скале, одна ссаная библиотека может распихивать свой свэг по нескольким десяткам различных неймспейсов в духе "com.petooshara.sosihui.ui.widgets", "com.petooshara.sosihui.ui.widgets.util", "com.petooshara.sosihui.business.model", "com.petooshara.sosihui.business.util" и так далее. В скале это говно усугубляется тем, что где-то там могут быть спрятаны нужные имплиситы, причём необязательно в пекедж-обжекте пакета, а например, в объекте-модуле, лежащем внутри объекта-модуля, лежащего внутри пакидж-объекта. И это ещё примитив, можно гораздо глубже. И проблема уже в самих этих иерархиях, в том что их надо осознавать, мейнтейнить, сёрфать, всякие поиски затерянных имплиситов - это вообще пиздец, до этого можно не доходить, проблема была намного раньше.
> одна ссаная библиотека может распихивать свой свэг по нескольким десяткам различных неймспейсов в духе
Ну это логично, что виджеты и бизнес-модели в разных пакетах, а не смешаны в одну кучу. Иначе бы просто размазывали это говно на десять библиотек.
> Сейчас так только в питоне и ноджс/ecmascript6.
Т.е. скриптозашквар и не нужно
Нихуя бы не размазывали. Бизнес-моделей в библиотеках не бывает, а подмодули текущего проекта могут работать как локальные библиотеки в духе import * from "/models".
> Сейчас так только в питоне и ноджс/ecmascript6
как так?
я вообще не понимаю, что за баттхерт? проблема найти нужный символ в библиотеке? да, я вижу, как с имплицитами это может превратиться в анальный цирк, но в языках без них нету твоей надуманной проблемы.
Например, в джаве все решается десятикратным тыканьем Alt-Enter
Да, это проблема. Просто многие уже к ней привыкли, и считают это нормой. С типами так было, с io/st/ref'ами в хаскеле так было, и с имплицитами так будет. Просто программисты влюбляются в бессмысленные материи, не имеющие никакого смысла и самоценности и делают ради делания, не ради результата. Именно потому среди программистов так много тяжелодушевнобольших людей. Где-то в глубине подсознания они чувствуют этот парадокс и он разрывает их на части. Здоровый же человек вообще не может любить программирование, потому что оно является неприятным, но иногда необходимым способом достижения по-настоящему желанной цели. Ценность имеет эта цель, не способ её достижения.
хуйня
>Т.е. скриптозашквар и не нужно
А - Аргумент
далее, большой проект на рутнопе 10^5 строк, большой на джаве 10^6, судя по бенчмаркгейму питон выразительнее в три раза, значит джава майнтабельнее в 3 раза.
> Просто программисты влюбляются в бессмысленные материи,
Б - бессмысленные материи)))
Да, где-то решается. Только вот видишь, сначала придумали вредную хуйню, потом придумывали способ как её побороть. И сейчас это даже не везде есть, а лишь в каком-нибудь эклипсе да жидее, может ещё и подглючивает иногда. И там люди работают на фуллтайме, пилят все эти синтаксические анализаторы и пакетные, которые позволят запилить автоматическое вычисление нужного импорта. Это смешно и грустно.
А, ясно, я думал это что-то из хачкиля, а оказывается ты обычный дебил.
> я думал это что-то из хачкиля
Зависимые типы не из хаскеля, но всё-таки вам не завезут ещё лет десять, можешь быть спокоен.
И какое у них практическое применение?
Доказательство корректности программы или по крайней мере каких-либо её частей. Ну и к тому же дополнительная выразительность для системы типов.
Вот, возьми: https://vimeo.com/117221082
Миморазбирающийся, а может ещё скажешь почему, в чем там подъебка и когда все таки стоит юзать тот же лист?
Потому что лист это связанный список, а вектор массив. Поэтому вектор эффективнее для всего, кроме того что я написал. А вообще пиздуй читать документацию.
Да ты, оказывается, просто дурачок.
Не стоило тратить на тебя время.
> предлагает извлекать из case object его же
> называет кого-то дурачком
Типичный /зк/-дебил
опять хуита, сьеби уже со своей экспертизой
Да ты даже ещё тупее, чем я думал.
Самое смешное в этой истории то, что выше ты пафосно рассказываешь об экстракторах, при этом не понимая, что это, и зачем это нужно.
И пишешь сишный код на скале в итоге.
Типичный жрец карго-культа, лол.
В каком месте он сишный?
>Я думаю, половина местных скалаикспертов соснёт, если я попрошу написать эффективную полиморфную функцию над коллекциями.
90% процентов разработчиков, приходивших к нам на собеседование соснули, когда их попросить написать на их языке программирования решение уравнение Ax^2 + Bx + C = 0
> В Хаскеле лист - тащем-то обычный ADT, ничем не отличающийся от остальных таких же. Т.е. человек, который тупо пишет на Хаскеле, по дефолту выдает ...
stack overflow на любом более менее крупном массиве данных. Большинство учебников Хаскеля для обработки данных содержат рекурсивные описания алгоритмов, которые в лучшем случае транслируются в обычной цикл (при этом выглядят как говно из-за хвостовой рекурсии), в худшем падают на паре миллионов элементов. И это при том, что fold сейчас не то что в Хаскеле, он в Яве есть.
> соснули, когда их попросить написать на их языке программирования решение уравнение Ax^2 + Bx + C = 0
Но ведь это МАТЕМАТИКА нужно знать формулу которая в жизни ненужна и соотвественно которую большинство людей забудет через год. Давать такие задачи на собеседовании тупо, если только вы не математика ищите.
Формула для уравнения второй степени при этом говорилась по требованию, там сыпались на проверке А=/=0, и отдельном случае для уравнения первой и нулевой степени. Проверка входных значений - это, блядь, основа программирования.
для второй степени нужно уметь выводить
это восьмой класс блядь
Решать надо было в общем случае для любого нелинейного уравнения? То есть все численные методы нужно помнить наизусть?
> Решать надо было в общем случае для любого нелинейного уравнения?
Нет. Но даже если и так, то не нужно помнить
> все
достаточно одного, дихотомий, например, но ты и его не помнишь
И что? Я вот даже таблицу умножения уже забыл, ибо всё это нинужно в реальной жизни.
ахаха ты меня затралел
Не поэтому. Если начинать разберать по частям всё там написанное, выяснится, что там большинство в общем-то по делу. Просто сделать лучше на Скале как-то не получается даже у недаунов.
>Только я думал что из жабомакакуса превращаюсь в функционалогосподина
Не со Скалой. Скала - это мультипарадигма, там своя особая атмосфера. Освоить ФП на Скале ИМХО тяжлее, чем на Хаскеле. Потому что многие вещи там реализуются посредством весьма хитрых трюков, помимо самой вещи надо еще понимать суть трюка. Скала - это инструмент для тех, кто уже знает ФП и ООП, а не для тех, кто собрался учить хотя на курсере есть курсы ФП на Скале, сам я их не смотрел, попробуй, может быть всё не так страшно, как я здесь написал
>Скажи няша, а когда надо использовать лист а когда что то другое?
В каждом случае лучше что-то свое. Проблема не в том, что сложно выбрать структуру для конкретного случая, а в том, что сложно написать полиморфную функцию. Да и вообще следовало бы начать с того, что в Скале в принципе сложно написать функцию. Там функции над коллекциями - на самом деле методы, поэтому в проектах появляется всякое говро вроде RichSeq, RichArray, RichMap и т.п. (примеры реальные, наследование иногда необходимо, чтобы добраться до какого-нибудь защищенного метода, вроде newBuilder)
>Одна библиотека - один ёбаный импорт - и заебись!
То что ты называешь библиотеками вообще не является элементами языка. В языке есть понятие модуля. Один модуль - один импорт, почти везде так. Библиотека (как compilation/distribution unit) может включать в себя несколько модулей, из которых тебе может понадобиться один. Иерархические пространства имён - говно. Но вот в Джаве, например, они не иерархические. Наличие точечки в имени там никак не влияет на результат импортирования. В C# они иерархические, да.
>stack overflow на любом более менее крупном массиве данных.
Давай проверим. Допустим у нас есть список интов, нужно прибавить к крайнему элементу единичку.
Хаскель: https://ideone.com/OHnLHn
Скала: https://ideone.com/5p7yyA - ой, а как же так, всего 4к элементов, а мы уже всё?
@tailrec напиши
>а как же так, всего 4к элементов, а мы уже всё?
Ты бы ещё на ноль, блядь, поделил бы там где-нибудь.
Лол, сначала выдал неебическую экспертизу (спижженую откуда-то, естественно), а потом спалился на такой хуйне.
Фу таким быть.
Тогда вообще не сконпелируется, потому что функия не хвосторекурсивная.
Что ты хочешь этим сказать? Что функцию можно к хвосторекурсивному привести? Я это и так знаю. Задача была показать человеку, знакомому с Хаскелем видимо из книжек, что его предубеждения о том, что самый тупой и прямолинейный код над ADT будет обязательно падать со stack overflow не верны. Скорее наоборот всё с полпинка запустится. Причем еще выдаст приличную производительность (0.17s 4596KB против 4.01s 322240KB, да).
Разумеется, в обоих языках можно сделоть правильно и это требует хорошего понимания принципов работы, разумеется, результаты оптимизаций будут примерно одинаковы и по времени и по памяти и по строкам кода (например: http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=ghc&lang2=scala), но ручная оптимизация - это не то, чем бы хотелось заниматься большую часть времени. И вот в Хаскеле самый тупой вариант скорее самый правильный, а в Скале - скорее нет.
Примечательно, что это свойство Хаскеля не совсем хорошо для серьёзных продукционных систем. Потому что достигается оно использованием ленивости (в Хаскеле нет call-стека, SO там вылетает на паттерн-матчинге при раскрытии санков, что может быть сложнее для понимания и отладки) и хитрожопого фьюжена. Но на продукционной системе нет требования "посчитать за 0.17s", там и 4 секунды норм (просто железо подбирается под задачу). Зато есть требование "недопустить 30% просадки производительности из-за того, что после докручивания новой фичи внезапно слетела какая-то автоматическая оптимизация и никто не знает, что именно". Это одна из причин, по которой для продакшена выбирают более тупые (в плане оптимизаций и модели исполнения), но более предсказуемые языки.
>спижженую откуда-то, естественно
Ха-ха!
>а потом спалился на такой хуйне
На какой хуйне? Просто написал код, а он не работает. Печалька же.
Вот!
Кстати, параметр list там лучше передавать by name.
Только вчера об этом читал:
http://blog.dmitryleskov.com/programming/scala/stream-hygiene-i-avoiding-memory-leaks/
Для скалы нужно пускануть JVM поэтому тут расход памяти такой конский, тут глупо сравнивать с рантаймом хачкиля.
>>stack overflow на любом более менее крупном массиве данных.
>Давай проверим. Допустим у нас есть список интов, нужно прибавить к крайнему элементу единичку.
Конкретно в твоем случае оптимизация сработала, дальше что?
https://ideone.com/rgf94x
https://ideone.com/vHZdqI
Быстрофикс.
Насчёт by name - в самой рекурсивной функции это не нужно. Это надо, если есть ещё внешняя функция, в которую передаётся стрим, и внутри которой выполняется рекурсивная функция.
>Ленивая скала, ай-ай.
Ай-ай. Я уже писал об этом здесь Слишком дохуя сложностей вникать во все тонкости и вибирать между List, Stream, Seq, Iterable и TraversableOnce, который может быть isTraversableAgain. Давай уж ты напишешь функцию по всем канонам Скалы, чтобы если я передаю ей List, то и получал бы на выходе List, а не обрезанный Stream.
Что есть такое очень нужное в рантайме JVM, чего нет в рантайме Хаскеля? Может быть охуенный мусоросборник, гринтреды и STM? Ой, нет, та же хуйня по сути.
>Конкретно в твоем случае оптимизация сработала
Конкретно в моём случае сработала WHNF, которая тащем-то детерминирована и не зависит от оптимизаций конпелтора.
> дальше что?
Дальше, например, укажем типы: https://ideone.com/58bSgu В Скалке же ты их указал, почему в Хаскеле не указываешь?
маладец. на лурке нашол?
https://vandreev.wordpress.com/2007/06/18/feistel-ciphers-and-des-in-haskell/
feistel :: (Bits a) => (a -> b -> a) -- Mixing function
-> (a -> k -> b) -- Round function
-> a -- Block to be encrypted
-> [k] -- Key schedule
-> (a, a) -- (L, R)
подобным каррингом в скале себя проще в жопу выебать/
feistel :: (Bits a) => (a -> b -> a) -- Mixing function
-> (a -> k -> b) -- Round function
-> a -- Block to be encrypted
-> [k] -- Key schedule
-> (a, a) -- (L, R)
подобным каррингом в скале себя проще в жопу выебать/
>Если начинать разберать по частям всё там написанное, выяснится, что там большинство в общем-то по делу. Просто сделать лучше на Скале как-то не получается даже у недаунов.
студент из лазаны закукарекал чтоли?
пизже студентов из лозанны только студенты из sbt
> Примечательно, что это свойство Хаскеля не совсем хорошо для серьёзных продукционных систем
Ой, бля, да хаскель банально неудобен, зачем в такие дебри залазить?
>В Скалке же ты их указал, почему в Хаскеле не указываешь?
Но ведь речь шла о поведении по умолчанию, вывод типов в рекурсивных функциях, теорема Хиндли-Милнера, вот это все. А оказывается все также нужно указывать тип. Печалька.
И да, главная проблема Хаскеля -
Я пишу о реальном опыте, а не о своей диванной икспертизе, диванных искпертов тут и так полно. Так вот, причин отказа по причине "Хаскель не удобный" я не встречал. Более того, у нас часто на Скалу жалуются, мол линзы там неудобные, не композятся нихрена и многое другое. А вот отказ по причине недоверия к ленивой семантике и автоматической оптимизации был. Люди в прод-системах очень серьезно относятся к производительности. Причем не к абсолютной производительности, а к гарантиям что она внезапно не изменится.
>Но ведь речь шла о поведении по умолчанию
А там отличное поведение по-умолчанию. Просто по-умолчанию Хаскель использует Integer, а не Int32. Integer немного медленнее, зато не переполняется, что по-умолчанию лучше для большинства задач, если тебе не нужно заниматься крохоборством. Например, твоя ёба на fib47 уже пизданётся https://ideone.com/p2huYW А Хаскель - нет https://ideone.com/99qcxQ
>И да, главная проблема Хаскеля -
Главная проблема /зк, что тут сидят диванные иксперты.
Поздравляю, вы осилили подсчёт числа Фибоначчи на Скале. Это прорыв.
>Я пишу о реальном опыте, а не о своей диванной икспертизе
А выглядит как диванная экспертиза, а учитывая, что тема посвящена Scala, а не Haskell, то еще и как довольно тупой троллинг.
Если хочешь, чтобы тебя считали человеком, то приводи примеры проектов, которые ты реализовал, с примерами кода. Примеры чисел фибоначи и проходов списков никого не ебут, они на чистом Си и выглядят нормально и работают быстро.
Покажи работу с асинхронными запросами, построение интерфейсов, ORM с нормальную, как раз работа для системы типов Haskell.
Пусть полный аналог Akka покажет.
>А выглядит как диванная экспертиза
Если это для тебя так выглядит, просто не читай. Кому надо - почитают.
>Если хочешь, чтобы тебя считали человеком, то приводи примеры проектов, которые ты реализовал
Какая-то идиотская просьба. Во-первых что значит "я реализовал"? Есть куча проектов, над которыми я работал в составе команды. В одиночку разве что Золотце Симту реализовал, но это хобби-проект, а не продукционная система со всеми вытекающими. Во-вторых - тема треда Скала, а не "хвастаюсь своими проектами", вот я и пишу о языке и сравниваю с ближайшими аналогами.
>Покажи работу с асинхронными запросами, построение интерфейсов, ORM с нормальную
С какими запросам? Каких интерфейсов?
Полный аналог всему идиотизму?
>пок-пок нинужна нинужна!!!
Что, простите?
Тебе полный аналог всему идиотизму, или разобрать по задачам и показать, как делать правильно?
Давай, сделай правильно распределённый кластер http://doc.akka.io/docs/akka/snapshot/scala/cluster-usage.html
Мне кажется ты пришел размахивать каким-то дерьмом, про которое вчера прочитал в интернете и начал им размахивать как красным флагом. Какой именно вопрос тебя интересует в реализации распределенных кластеров?
Так как ты реализуешь это без акторов, Маня?
> пишу о реальном опыте
> линзы
О да.
> линзы
О да.
Акторы не имеют прямого отношения к "распределенным кластерам" (что бы ты не имел ввиду под этим), и в интернете ты можешь нагуглить достаточно реализаций их без Акки. Чтобы убедиться в истинности мной сказанного достаточно посмотреть на дату первого релиза Акки (2009), а кластеры существовали до этого.
Теперь конкретно по акторам. Как я уже писал, я вижу смысл здесь обсуждать только свой реальный опыт, потому что нагуглить какую-нибудь хуйню и радостно ей размахивать может любой школьник, я тоже гуглить, мне это не интересно. Что касается реального опыта: у нас есть один сервис, использующий акторы из Акки как примитив синхронизации/элемент декомпозиции (да, первая проблема акторов в том, что они пытаются быть чем-то большим, чем примитив синхронизации, примерно как объект в ООП) и netty + finagle для реализации протокола коммуникации. По этой системе у меня следующие выводы:
netty - поделка для домашек и хелло-ворлдов. Для серьёзных систем противопоказана ввиду фундаментальных ошибок дизайна. Может быть хороша, чтобы экспериментировать с новыми протоколами, возможно для этого изначально и создавалась.
finagle - ничего против не имею, но и особых профитов от неё не заметил. Сейчас у нас связка netty+finagle выпиливается, в новой finagle скорее всего не будет. Ну можно было бы заюзать просто я не понимаю зачем и не настаиваю. Остальным тоже как-то пофиг.
Акторы в том виде, в котором они реализованы в Акке и actor model как подход к проектированию - фейл. Собственно поэтому я и говорю, что Акка - говно. Может там какой-нибудь очень классный коммуникационный протокол, может быть там есть какие-то классные тулзы для мониторинга нод, алгоритмы fault-detection и т.п. (мы не строили на Акке распределенных кластеров поэтому я не эксперт в этом вопросе). Но внутри Акки - акторы, т.е. дерьмо. Поэтому я и писал, что это идиотизм, по крайней мере на core level. Что там накидано сверху - я не знаю.
Ну у нас есть один любитель. Вообще проверил, использует мало, видимо потому что не удобно. Собственно он на них и жаловался. Я сам как-то обхожусь без линз в Скале. В Хаскеле использую. Тоже по-началу долго старался обходиться без них, но потом появились задачи, которые с линзами идеально декомпозируются, я не выдержал и переписал на линзах.
Хороши ли линзы где-либо, кроме задач по пересборке персистентных иммутабельных структур данных с изменившимся где-то в глубине значением? (у меня таких задач никогда не возникало, но могу представить, что раз в 10 лет что-то такое понадобится, если менять работу каждые полгода) Есть ли какие-то случаи линзо-геттеров, которые не было бы удобнее написать элементарными средствами js/петона/java/етц типа точечки, квадратных скобочек, функций/методов?
>а кластеры существовали до этого
И что теперь, это значит, что они были написаны лучше, чем могли бы быть с аккой?
>Акторы в том виде, в котором они реализованы в Акке и actor model как подход к проектированию - фейл кукареку я так сказал
Ясно
>Хороши ли линзы где-либо, кроме задач по пересборке персистентных иммутабельных структур данных с изменившимся где-то в глубине значением?
Собственно для этого они и нужны. Еще хороши для декомпозиции, когда меняющий что-то алгоритм лежит отдельно, а структуры данных - отдельно. Тогда в алгоритм передаётся набор линз, чтобы он мог что-то менять. В ООП для этих целей можно было бы добавить к структуре данных интерфейс, реализующий геттеры и сеттеры, или использовать паттерн адаптер.
Проблему свойств в ООП можно иллюстрировать следующим кодом: window.getPosition().setX(10). Что должна возвращать getPosition()? Если копию Position, то такой код работать не будет. Если ссылку, то:
Position position = window.getPosition();
position.setX(10);
работать будет, а:
Position position = window.getPosition();
window.setPosition(new Position());
position.setX(10);
уже нет. Т.е. объект position в некоторых случаях является аксессором, а в некоторых - самостоятельным объектом, статически чем он является не определить. Линза всегда является аксессором. Кроме того, существуют более слабые, чем линзы типы. Например, траверсалы, которые отбирают 0 значений, или одно, или несколько значений. Операция получения значения для них не валидна. Зато валидна, например, операция обновления всех значений, удовлетворяющих критерию.
>И что теперь, это значит, что они были написаны лучше, чем могли бы быть с аккой?
Нет, это значит, что кластеры могут быть написаны без Акки. И еще это не значит, что с Аккой можно написать что-то лучше, чем без неё.
>Акторы в том виде, в котором они реализованы в Акке и actor model как подход к проектированию - фейл кукареку я так сказал
Кукарекаешь здесь только ты, я могу подробно описать какие проблемы существуют в акторах, т.к. у меня продакшн-система, сделанная на акторах, а ты тут исходишь на говно и сыплешь оскорблениями. Вангую в тебе фанбоя и мамкиного тролля, а посему иди нахуй.
>Нет, это значит, что кластеры могут быть написаны без Акки.
Давай, рассказывай, как ты будешь писать кластер на хачкеле, кукаретик.
Ты хамишь и задаёшь дебильные вопросы. Почему я должен тебе что-то рассказывать?
Идейно, конечно, расписал, но проблема такая есть только в головах. На практике вне жабосишарпов всем похуй на все эти геттеры-сеттеры и в большинстве случаев есть просто поля, которые можно прочитать и записать. Если вдруг надо сделать какое-то составное вычисление, пишут сбоку функцию getYoba (или calcYoba) или метод в классе. В редком случае когда требуется составная логика не только гета, но и сета - тогда будет действительно пара getYoba, setYoba, а так как документацию надо читать в любом случае и везде (даже в скале, даже в хаскеле), это вообще ничего не меняет, ведь ты и так будешь смотреть в доке как этим пользоваться.
> добавить к структуре данных интерфейс
Номинативные статикопроблемки. В динамике вообще похуй, всё полиморфное ровно настолько, насколько оно полиморфное физически по своей природе.
>кукареку
Ясно, слился
Я и не говорил, что линзы решают какую-то мировую проблему. Я их долго и не использовал именно потому, что считаю проблему малозначимой, а полноценная их реализация напичкана матаном по самое небалуй. Но в итоге я всё равно пришел к выводу, что с линзами удобнее.
Что касается аргументов "проблема есть только в головах" и "всё равно читать документацию", советую дополнить их "всё дело в кривых руках", "всё равно корректность программы доказать невозможно", "нормальный программист может писать на чём угодно" и поехать к Амишам программировать на Коболе.
>В динамике вообще похуй, всё полиморфное ровно настолько, насколько оно полиморфное физически по своей природе.
Я не встречал ни одного серьёзного проекта, написанного на динамике.
Я не понял, в школах весенние каникулы что ли?
Спасибо, но кобол ещё более неудобный и избыточный чем хаскель и скала, хотя, конечно, они умудрились в этом обогнать большую часть мейнстримных языков.
> Я не встречал ни одного серьёзного проекта, написанного на динамике.
Ну ты серьёзно? Наоборот же, на жабках/сишарпах пишут только корпоративный аутсорсинг распил, к этой же тусовочке пытаются подмазать скалу и хаскель, потому что любят разработчиков, которые могут увлечься глубоким (и бессмысленным) инструментом и перестать обращать внимание на реальность. Весь реально полезный софт написан либо на байтоёбских языках, либо на динамике, либо вперемешку.
Акторы в akka изначально и задумывались как низкоуровневые примитивы синхронизации, просто из-за сходства с Active Object и обилию туторов (воркер <-> менеджер) мисюзается по полной.
На скала дейз 2014 (вроде) есть видео где авторы Акки, как раз сравнивают акторы с потоками и так далее.
В Akka-Stream например ты декларативно описываешь стримы, а потом "материализуешь" их в акторах, то есть обрабатывается это акторами, но сам ты об акторы на уровне апи не шкваришься.
По поводу класстеров в акке - стоит почитать раздел todo, очень много еще только в планах, на данный момент реализованы только базовые вещи, health, векторные часы, госсип.
Единственная интересная тема в Akka, это Persistance, позволяющая реализовать CQRS с евенторсингом на кластере. Но опять же кривовато и это мисюз акторов.
Общая императивность и антайпность делает использование акки довольно зашкварным делом.
Расскажи поподробнее про netty. Я так понимаю до недавнего времени особо выбора кроме netty под java/scala не было. Опять же play на netty.
>Ну ты серьёзно?
Я это говорю исходя из своего опыта. Типичная задача, которая возникает в достаточно сложном проекте - это понять, на что повлияют вносимые изменения. Статический анализ кода этому в некоторой степени помогает - можно хотя бы посмотреть, где используется твоя функция. Как это делать в динамике? Грепать по всему проекту функцию по имени? Динамика подходит либо для небольших тулзов, либо для чего-то вроде сайтов, генерирующих независимые друг от друга странички.
>на жабках/сишарпах пишут только корпоративный аутсорсинг распил
У тебя представления о корпоротивном софте на уровне какого-то школьника-тролля. Дохрена корпораций, которые неработоспособны без своего софта и у которых IT - чуть ли не основная статья расходов, а ты тут что-то про распилы, откаты.. /po/ обчитался что ли?
В манямирке весь тырпрайз на ноде и рельсах.
>Акторы в akka изначально и задумывались как низкоуровневые примитивы синхронизации
Как низкоуровневый примитив синхронизации им следовало бы ограничиться типизированным FIFO каналом, что собственно и есть в акторе от синхронизации. И это норм. Всё остальное - антипаттерны и шарлатанство. При этом я не отрицаю, что именно для распределенных кластеров метапарадигм в Акке могут быть какие-то годные тулзы, которых нет у остальных. Тогда, возможно, её имеет смысл использовать ради этих тулзов, но не ради акторов конечно же.
Дак акторы дуальны CSP. http://en.wikipedia.org/wiki/Actor_model_and_process_calculi
В акке экспериментально выпустили типизированные акторы http://doc.akka.io/docs/akka/snapshot/scala/typed.html может быть будут не такие зашкварные.
Реально полезные проекты - это сайты, десктопный и системный софт. У больших и сложных сайтов типа вконтакта, фейсбука, реддита, гитхаба, битбукета, бекенды пишут на всяких динамических языках. Десктопный софт написан по большей части на байтоёбских, но сперва туда начали потихоньку протаскивать скрипты для расширяемости, а сейчас уже не стесняются вообще целиком на динамике писать (я вот сириусли пользуюсь повседневно tagspaces, которая на ноде через node-webkit). В аутсорсинге обычно занимаются сайтами, но бекенд пишут на какой-то лютой хуйне чтоб денег побольше выбить на разработку и чтоб разработчики были помозгопромываемей. Те сложные проекты о которых ты говоришь - они вписываются в эти категории или нет? Они хоть как-то обозримо воздействуют на эту реальность или всё внутренняя хуйня в стол? Можно ли попросить примеров, хотя бы просто о чём этот софт? Я сколько в аутсорсинге чялился - почти везде хуйня в стол была. Типа: внутрення ирп-системка вместо одинэс или сяп или десятков других при этом чисто для себя, внутренняя консолька на жс чтоб вместо скл зделать велосипед поверх, внутренняя кококорасшияемая веб-ирп в которую можно вставлять расширения на жс (тоже чисто для внутреннего использования лучше было взять даже какое-то опенсорсное готовое решение), реальные форекс приложухи на жс для мобилок (но этот проект свернули когда люди попытались этим пользоваться а оно пиздец глючило в андроиде), и далее опять какие-то ёбаные внутренние админки для никого и ничего на жабе. Не знаю, может это просто мне так повезло, но складывается впечатление, что 99% аутсорсинга просто пишут в стол бессмысленную хуету на голимых технологиях для шизодопланктонин.
Ты втираешь нам какую-то ДИЧЬ.
Просто мне хватило любознательности задумываться, а что мы вообще делаем. Суть корпоративных разработчиков на пикрилейтед. Они обмазываются там своими архитектурами на языках максимально в это немогущих и фундаментальными проблемами бытия вроде насколько гибче будет вносить изменения если написать геттеры и сеттеры вместо полей, и оно им всё так свято и интересно, что понять что они ничего по сути не делают, просто времени не хватает.
> я тоже гуглить, мне это не интересно.
я тоже ебать, ее рука
> сайты
пишутся на статико говне
рука сестры?
ее рук
брат sbt скачал?
решил чем то занять руки пока пол мавен репозитория скачивается.
руки сестры)
Двачую этого Мне как-то даже осуждать это не хочется, потому что это относится не к программированию, а к твоему мировосприятию. Я, например, считаю, что реально полезные продукты - это айфоны и велосипеды. А трубопрокатные заводы строят, чтобы побольше денег выбить на строительство и чтобы инженеров было чем занять. Потому что трубы - это хуйня в стол, я за свою жизнь ни одной трубы не купил и ни один из моих знакомых тоже. И еще автомобилестроение не нужно. Потому что велосипеды экологичнее и полезнее для здоровья. Просто москвичи этого не понимают нихрена. Вот если бы они все пересели с автомобилей на велосипеды, на дорогу тратили бы те же 3 часа, но здоровее были бы. Сейчас я начну тут всем эту хуйню втирать, и пускай меня переубеждают, доводы мне всякие приводят.
Так ведь с этого надо начинать. А с таким подходом будет как в науке - тонны макулатуры, дроч ради дроча. При том, что область чисто инфраструктурная и должна обслуживать реальность, а не наоборот. С трубами пример неправильный, потому что их надобность очевидна, в корпоративной параше совсем не так - там реально хуйня в стол. Вот примеров чего полезного релевантного ты так и не привёл.
С автомобилями пример тоже неправильный. Очевидно, что так как запасы нефти на планете ограничены, нужно переходить на электромобили. Одними велосипедами не обойтись, потому что они медленее, намного менее удобны, на них затруднительно ездить в дождь и зимой, и не всем подходят по здоровью.
Ахахаха, местные скалаебы сломались как только им сказали, что 99% софта - ебаное говно и пишутся на таком же ебаном говне такими же ебаными говнюками, но только у этих петухов реальные задачи и сложные проекты, только как они называются и что они делают почему-то они не знают. Это, видать, слишком неведомая хуйня, недоступная простым смертным.
мимокрок
мимокрок
эталон шизофазии
>ебаное говно и пишутся на таком же ебаном говне такими же ебаными говнюками
Если софтом пользуются - он не говно, смирись и не визжи.
Так ведь с этого надо начинать. А с таким подходом будет как в науке - тонны макулатуры, дроч ради дроча. При том, что область чисто инфраструктурная и должна обслуживать реальность, а не наоборот. С трубами пример неправильный, потому что их надобность очевидна, в корпоративной параше совсем не так - там реально хуйня в стол. Вот примеров чего полезного релевантного ты так и не привёл. С автомобилями пример тоже неправильный. Очевидно, что так как запасы нефти на планете ограничены, нужно переходить на электромобили. Одними велосипедами не обойтись, потому что они медленее, намного менее удобны, на них затруднительно ездить в дождь и зимой, и не всем подходят по здоровью.
Андрюшу подглючивает
>Так ведь с этого надо начинать.
Нет, это путь в никуда и разговор ни о чем. Доказывать что-либо друг другу можно только при совпадении аксиоматических базисов. А у нас с тобой либо явный конфлитк аксиом - твоя аксиома в том, что корпоративное говно не нужно, а моя, в том, что нужно; либо неявный - ты говоришь, что трубы очевидно нужны (т.е. у тебя есть некий набор лемм, из которого необходимость труб является тривиальным следствием), а у меня такого набора нет, поэтому для меня это нихуя не очевидно.
Особенность человеского сознания в том, что человек превращает теоремы в аксиомы. Это логично - часто запоминанине полных импликаций гораздо более затратно, чем запоминание готовых фактов. Ты можешь проверить это на примере бурбакистов - они свели аксиоматику к минимуму. Но людям нихуя не удобно оперировать понятием единицы, состоящей из 2 409 875 496 393 137 472 149 767 527 877 436 912 979 508 338 752 092 897 символов, проще добавить теорем, создать теорию категорий, теорию графов, евклидову геометрию это всё.
Что мы можем сделать дальше? Раскручивать наши "синтетические" аксиомы до теорем, пытаясь найти общий базис. Но его нет. Я не думаю, что ты насколько туп, что смог сделать на каком-то тривиальном шаге нелогичные выводы. И я не на столько туп. Тем не менее наши конечные выводы противоречивы. А это значит, что в поисках общего базиса нам рано или поздно придётся дойти до предела. Предел - это единственный вопрос: в чем смысл человеческого бытия? Я думаю, что тебе очевидно, что ответа на этот вопрос нет. Попытка ответа на этот вопрос равнозначна попытке построения теории в условиях полного отсутсвия аксиом. Теория без аксиом невозможна. Собственно ппоэтому люди придумали Бога и Священное Писание, как некую терминальную аксиому, сведение которой к набору теорем или споры о писании приравниваются к ереси, т.е. запрещены. Но Бог у каждого совой, более того, поняние Бога внутренне противоричиво. Ты хочешь поговорить о Боге? Или ты хочешь съебать в другой тред, предоставив нам возможность обсуждать, как в Скале и Хаскеле решаются проблемы написания ненужного корпоративного софта?
Бог - есть абсолют, всеобемлющее понятие, включающее в себя все возможные аксиомы и правила вывода. В этом суть всемогущества Бога. Бог может всё, любое утверждение в аксиоматике Бога выводимо. А это означает её противоречивость. Это также означает бесконечность аксиоматического базиса Бога. Человеческий разум конечен (следует хотя бы из конечности нейронов и синаптических связей) Т.е. любая человеская религия - это лишь проекция бесконечного божественного замысла, выраженная в конечном наборе откровений. Что мы получим при попытке проецирования бесконечного множества на конечное? Некую сурьекцию, причем число возможных сурьекций бесконечно. Даже если принять число возможных религий счетным (что, очевидно, противоречит наблюдаемым фактам о конечности энергии Вселенной, но пусть будет счетным: больше - не меньше) речь пойдёт о проекции алеф-инфинума на алеф-нуль. Это означает, что любое Божественное Откровение истинно. И в то же время, что Откровений может быть сколь угодно много. И в то же время, что любая паста на дваче может являться и суть является Божественным Откровением. Но что же есть одно откровение по отношению к другим? Оно есть ересь, αἵρεσις. Ересь - означает "разночтение". Разночтение Божественного Замысла. Ересь неизбежна, ибо человек не спобен понять Божественного Замысла полностью, ересь отностиельна, ибо любой человек, понявший часть Бога посчитае еретиком иного, понявшего иную часть Его. Послание к Коринфянам первое гласит: "Ибо, во-первых, слышу, что, когда вы собираетесь в церковь, между вами бывают разделения, чему отчасти и верю. Ибо надлежит быть и разномыслиям между вами, дабы открылись между вами искусные." Значит ли это, что Церковь должна бороться с ересью? Нет, ни в коем случае, ересь лишь раскрывает наиболее искусных, и их трактовка Замысла Бога и будет новой Церковью.
>Доказывать что-либо друг другу можно только при совпадении аксиоматических базисов
Ты, анон, сейчас выразил мысль, которая вертелась около моей черепной коробки уже полгода как. Спасибо тебе, Анон.
Хорошо, не хотим о отсутствии полезных проектов на статике (кроме байтоёбства) - ладно, можно остановиться на присутствии большого количества полезных проектов на динамике. Только ты скажешь, что все эти сайты, игры, десктоп, системщина - это всё детский сад, а реально сложные проекты - это только внутренняя корпоративная хуйня под NDA. И уж там-то действительно всё надо писать на скале/хаскеле/жабе/сишарп а не на ноде/петоне/раби/пхп, иначе будет немайнтабельно и вообще надо будет всю папку с проектом грепать в поиске символов.
>можно остановиться на присутствии большого количества полезных проектов на динамике
На Коболе и C++ (мне кажется ты его ошибочно относишь к байтоёбству, хотя он часто успользуется как джава) написано в 100 раз больше кода и полезных проектов что на динамике, а на PHP в 10 раз больше кода чем на питоне. О чем это говорит? Да только о том что при должном старании можно из говна сделать конфекту говенную.
>на жабках/сишарпах пишут только корпоративный аутсорсинг распил
Idea, eclipse, hadoop, spark, lucene, android, twitter да иди нахуй короче, гугли сам.
>прочитать и записать
>записать
Отказано.
>Всё остальное - антипаттерны и шарлатанство
Например?
>Акторы в том виде, в котором они реализованы в Акке и actor model как подход к проектированию - фейл.
Из-за их динамической натуре чтоле?
> чтобы эффективно использовать банальную библиотеку коллекций в Скале, надо быть нихуёвым икспертом в области этой самой библиотеки.
Только если тебе нужно её расширить. Обычно это не требуется.
-
А вообще вы зря на хаскелиста накинулись, что динамико-питух, что скала-господа. Он по делу все пишет.
Кстати, если уж тут развели срач Scala vs Haskell, позволю себе процитировать свой старый пост, может кто-то не видел ссылку
>http://tonymorris.github.io/blog/posts/what-kind-of-things-are-easy-in-haskell-and-hard-in-scala-and-vice-versa/index.html
Не понимаю чего вы сюда бога и всю эту поебень притащили. Нужно было всего-то привести пример полезного внутреннего корпоративного продукта. Но, как и полагается представителю корпорации – вместо того чтобы честно признаться "да, мы тут занимаемся хуйней", представитель корпорации начинает нести отвлеченные беседы о боге, ереси, истине и абсолюте.
Видимо, нужно самому верить, что ты занимаешься чем-то полезным. Иначе внутреннего стержня не будет и деньги перестанут давать. И если задают конкретные вопросы – делай умный вид и начинай нести хуйню немедленно, иначе сам начнешь сомневаться.
Все как с богом, действительно.
Видимо, нужно самому верить, что ты занимаешься чем-то полезным. Иначе внутреннего стержня не будет и деньги перестанут давать. И если задают конкретные вопросы – делай умный вид и начинай нести хуйню немедленно, иначе сам начнешь сомневаться.
Все как с богом, действительно.
> пример полезного внутреннего корпоративного продукта
хуйня через которую я отпуск беру
До хаскелиста доебался какой то писатель фибонач. Все скала-господа и так понимают что сравнивать ерзац язык под JVM с хаскелем глупо. Скала удобнее явы + потешный ФП каргокульт, но до хаскеля в плане ФП ей далеко.
Но с другой стороны можно отмахиваться аргументом "но это же та же ява только на ололо односрочниках" можно применять скалу в продакшене. Убедить же кого-то не понимающего профит ФП использовать хаскель в продакшене довольно проблематично (невозможно).
Сколько абстрактных фабрик фасолин и человекочасов было потрачено? Какие технологии использованы?
да мне похуй
вопрос ведь о пользе был, а не о затратах
Хачкель говно без задач просто
Вопрос о пользе включал в себя контекст. То есть, если ты можешь просто отправить письмо эйчару и у тебя будет отпуск (и такая система не будет доставлять неудобств тебе и эйчару), но погромисты для этого полгода пишут абстрактные заводы – это не польза, это убыток для всех, кроме аутистов-погромистов, которым вообще похуй что писать; и их начальника, который на этом бюджеты компании пилит.
> То есть, если ты можешь просто отправить письмо эйчару и он выдумает причину, чтобы послать тебя нахуй, то с программой просто берёшь и получаешь отпуск
Ты, видимо, не понял сути того что я написал.
Да, ты написал "кукареку нинужно"
И с чего тогда лучше всего начинать знакомиться с ФП? На ум ничего не приходит, кроме sicp и scheme
схема
хаскель
shen (Есть книжка Functional programming in Qi)
да можно и со скалы по курсу одерского, но там уровень слабенький
сразу видно книжку эту не читал
Как ты пришел к такому выводу? Ты считаешь что она не подходит как вступление в ФП?
По мне дак learnyouhaskell + Real World Haskell достаточно быстрый старт в практическое ФП.
Конечно если ты хочешь годами долбиться в теорию категорий и лямбда счисление, то она тебе не пойдет.
Котаны, проходил мимо и прочитал дофига всякой критики и видяшек про говняность языка. Так ли все плохо? Не замечал такой критики того же шарпа, вот джавы да.
мимо полный нуфаг
мимо полный нуфаг
Шарп просто не сравнивают с теми языками, с которыми сравнивают скалу.
SICP, TAPL и PFDS. В качестве языка - scala. Это perl6, только на стероидах и можно использовать в продакшене.
Почему? Если сравнивать, то в чем он проигрывает?
1. это функциональный язык без ленивости
2. а тайп инференц просто пиздец, что приводит к невъебической сложности, см карринг и тд
3. от предыдущих двух пунктов у скалы случились пизданутейшие коллекции, см батхертнутого(дохуя ошибок, пизданутейшие зависимости)
но какой бы скала плохой не была, она все равно лучше ебаной джавы и шарпа
Тайп инференц пизданутый из-за присутсвия сабтайпинга.
А по поводу коллекций, такое ощущение что батхертнутый коллекции особо не использовал. Потому что все что он написал - детали имлементации, которые обычного кодера ебать не должны.
Посоветуйте какой-нибудь опен сорс проект для разбора полетов на практическом уровне. Прочел скала ин экшн, хочу теперь глянуть реалити.
Akka
Не сильно ли круто сразу исходники акки? Или это поможет лучше понять как с ними работать?
Можешь ещё библиотеки отсюда поковырять https://github.com/lauris/awesome-scala
Как так scala утонула? Нужно поднять!
в ньюфаг треде полно ребят, которые спрашивают как сделать сортировку на крестах, ты знаешь, что нужно делать.
Аноны, мне тут предлагают на scala-у свалить - стоит оно того? Достигну ли просветления или это просто java с сахарком?
Конечно стоит
Меня терзают сомнения - неужели смена языка может сильно сказаться на производительности/эффективности ?
Да
Народ, а есть же какие нибудь проекты, которые пытаются сделать компилятор для scala-ы не таким тормознутым? Киньте линков плз
Естественно. Если бы это было не так все бы остановились на С и не было бы даже твой лоботомированный java.
Собирай проекты на sbt, инкрементная компейляция же.
Ну и на том же sbt можно компилировать на кластере (хотя в прочем не знаю впилен ли этот функционал в стабильные ветки).
>Достигну ли просветления или это просто java с сахарком?
Это не просто джава с сахарком. Хотя её можноно не нужно и так использовать.
>неужели смена языка может сильно сказаться на производительности
На производительности написания кода - да. Могу точно сказать, что
1) я практически не борюсь с языком при написании кода, по сравнению с С#, на котором я писал до раньше,
2) больший процент багов связан с неправильным/неполным пониманием требований, а не с некорректным кодом,
3) намного легче менять код, тоесть фиксить баги и прикручивать фичи, рефакторить и т.д.
4) легче читать код, он более dense не знаю как это на русском сказать, лаконичный немного не то, намного меньше синтаксического и смыслового мусора, не столько из-за сахара, а чтоле из-за способа мышления, к которому подталкивает язык,
5) очень мало изменяемого состояния, что тоже помогает и в ловле багов и в понимании чужого кода,
6) дело вкуса конечно, но я просто получаю удовольствие, когда использую скалу, если бы я писал на джаве, я бы в рот уже всю эту работу ебал, что очевидно имело бы негативное вляние на производительность.
>предлагают на scala-у свалить - стоит оно того
Стоит, не попробовав все равно не узнаешь. Так и будешь скетпически задаваться вопросом про джаву с сахарком. Если не понравится, чего исключать нельзя, сменить работы на джаву не проблема, возможно даже в той же компании куда ты пойдешь работать.
Спасибо анон, придал уверенности. Просто вроде и книжки по scala-е почитал и тестоваое задание сделал, а все таки до ощущения перестройки рабочего процесса не дошел.
Т.е ощущения вида - ну да, круто, но выстрелит ли это все вместе при написании боевого кода не понятно.
В чем пишешь?
ИДЕ ведь намного хуже, чем студия для си-шарпа
> dense
плотный, так и говори
IntelliJ IDEA же
Как будто есть другие IDE для jvm-based языков...
Мне постоянно говорят, что Scala IDE лучше чем плугин для идеи. Сам я в идее пишу на джаве, а на скале писал в ней полхеллоуворлда. А Scala IDE пиздец
Вообще склоняюсь к просторедактору.
>выстрелит ли это все вместе при написании боевого кода не понятно.
Важно в какую команду попадешь, я об этом выше писал. Может и не выстрелить, в смысле не будет сильно отличаться от джавы, но тебе-то что с этого?
Компактный - самое подходящее слово наверное.
Пишу в IDEA.
>ИДЕ ведь намного хуже, чем студия для си-шарпа
IDEA для джавы примерно как студия + решарпер. Поддержка скалы похуже, но я лично от недостатка фич не страдаю. Разве что иногда подсветка хромает и один раз, при использовании очень громоздких хитровыебаных типов, редактирование кода в некоторых файлах вешало идею намертво. Приходилось в текстовом редакторе эти файлы править, лол.
Что там со Scala IDE не знаю, два года наза она мне меньше понравилась чем IDEA, да и сам eclipse бесит.
>просторедактору
Это ты так о имаксе?
о виме
Плагин заебись, батя грит хорошо сделали
Не дерзи!
Indexing...
SSD + i7
Можно ли как нибудь (может с помощью макросов) автоматически добавлять в case классы методы, например я хочу что бы в каждом case классе появился метод storeToDB()?
Сделай имплисит-класс для Serializable
AKKA не нужна http://proseand.co.nz/2015/05/17/akka-honeymoon/
Автор очередной неосилятор просто.
Ну почему, там есть здравая критика, например то что меняется состояние, и нет статической типизации.
> I wish I just had a bunch of functions which return a Future composed together to build our application
Лол. Ему RxJava/Scala нужна была, а не akka
Акторы и нужны для инкапсуляции стейта. Если код внутри акторов превращается в спагетти значит херово провели декомпозицию либо абузят акторы для высокоурвневых задач.
Отличный пример использования акки - Akka Streams, стримы состоят из Stages, каждый стейдж материализуется в актор, но для потребитель API этого не видит.
Вообще в таких историях успеха можно спокойно заменять слова Actor на Thread. Если бы обосрались на голых тредах, скорее всего обосрутся и на акторах.
У акторов динамическая природа. Попытка прикрутить к ним типы знатно эту систему типов усложняет. Есть конкурентне модели на статической типизации, например join-calculus, но они на мой взгляд громоздкие и сложны в использовании, поэтому за пределы всяких экспериментальных языков и либ не выходят. Можешь попробовать ScalaJoins, мож понравится.
Что такое линзы в скале (в самых общих чертах, для быдла)?
Геттеры и сеттеры
Линзы нужны чтобы менять значения полей во вложенных иммутабельных структурах
Пример плз. Как понимаю должно быть что то вроде такого по функционалу:
case class Person(name: String, lastName: String)
val p1: Person = Person("Jon", "Smith")
val p2: Person = p1.set("name", "Suze")
p2 == Person("Suze", "Smith")
?
Кто-то недавно спрашивал про годные примеры использования экстракторов. В Play Framework можно найти много годных примеров:
https://www.playframework.com/documentation/2.4.x/ScalaTestingWithGuice
https://www.playframework.com/documentation/2.4.x/ScalaContentNegotiation
https://www.playframework.com/documentation/2.4.x/ScalaTestingWithGuice
https://www.playframework.com/documentation/2.4.x/ScalaContentNegotiation
Первый линк неверный. Правильный линк
https://www.playframework.com/documentation/2.4.x/ScalaSirdRouter
let (|>) g f = f g
?
?
f(g)
в scalaz есть этот символ, но он неособо работоспособен, вот, например, какой-то дед реализовал его
блять, ебаная макак СЛОВО ИЗ СПАМ-ЛИСТА
хететепе://stevegilham.блогспот.ком/2009/01/pipe-operator-in-scala.html
Хм.
Я пару лет назад присматривался к скале.
И я написал пайп оператор, но помню, что пришлось тайп-сигнатуру нифига не интуитивно понятную расписать.
То, что написал этот Стив Гилам работать не будет
Подмогите, пожалуйста.
Как передать в
def fun[T](xs : java.util.List[T], comparer : (T, T) => Boolean)) ....
из джавы второй параметр? Лямбду мою не берёт.
Как передать в
def fun[T](xs : java.util.List[T], comparer : (T, T) => Boolean)) ....
из джавы второй параметр? Лямбду мою не берёт.
Попробуй заинстанциировать Function2
Не получается конвертнуть boolean в scala.Boolean
import collection.JavaConversions._
— попробуй импортировать эту библиотеку
Кто нить хотел бы совместно куклопроект пилить простенький? ради знакомства с языком или просто начальной практики. я кое-что пилю уровня джуниора, мне был бы кстати компаньон, ибо сложно самого себя пинать и заставлять что-то делать.
что ты делаешь?
небольшую говнину на playframework. сбор некоторой околоспортивной статистики с data mining в перспективе и кое чем еще.
ненавижу спорт, есть бэклог подробное объяснение?
мне было бы удобнее через чатик на вопросы ответить. вот асечка 695594342, скайпик quilted.jacket
https://github.com/flatlizard/blog/blob/master/app/views/newPost.scala.html
https://github.com/flatlizard/blog/blob/master/app/controllers/Application.scala
есть проект на 2.4(спасибо деду за победу и за депенденси инъекшн) и есть вот такая охуительная ошибка(см внизу), погуглил но нихуя не понял, там, где она возникала она была связанна с интернационализацией страницы,
вот например https://blog.sourcy.io/2015/05/27/porting-scala-play-2-3-application-with-slick-2-1-0-to-play-2-4-slick-3-0-0/ , но мне это толком нихуя не помогает, может подскажете что?
Error:(5, 19) Play 2 Compiler:
C:\Users\Pain\Play\activator-1.3.2-minimal\blog\app\views\newPost.scala.html:5: could not find implicit value for parameter messages: play.api.i18n.Messages
@inputDate(postForm("date"))
^
вьюха: [code lang='scala']
@import helper._
@(postForm: Form[Post])
@form(routes.Application.createPost) {
@inputDate(postForm("date"))
@textarea(postForm("title"))
@textarea(postForm("content"))
<button id="submit" type="submit" value="Submit" class="btn btn-primary">Submit</button>
}
[/code]
https://github.com/flatlizard/blog/blob/master/app/controllers/Application.scala
есть проект на 2.4(спасибо деду за победу и за депенденси инъекшн) и есть вот такая охуительная ошибка(см внизу), погуглил но нихуя не понял, там, где она возникала она была связанна с интернационализацией страницы,
вот например https://blog.sourcy.io/2015/05/27/porting-scala-play-2-3-application-with-slick-2-1-0-to-play-2-4-slick-3-0-0/ , но мне это толком нихуя не помогает, может подскажете что?
Error:(5, 19) Play 2 Compiler:
C:\Users\Pain\Play\activator-1.3.2-minimal\blog\app\views\newPost.scala.html:5: could not find implicit value for parameter messages: play.api.i18n.Messages
@inputDate(postForm("date"))
^
вьюха: [code lang='scala']
@import helper._
@(postForm: Form[Post])
@form(routes.Application.createPost) {
@inputDate(postForm("date"))
@textarea(postForm("title"))
@textarea(postForm("content"))
<button id="submit" type="submit" value="Submit" class="btn btn-primary">Submit</button>
}
[/code]
could not find implicit value for parameter messages: play.api.i18n.Messages
почему от меня требуют эту ебучую хуйню? пизда
почему от меня требуют эту ебучую хуйню? пизда
Ты в гугле искал текст ошибки или сразу сюда пришел?
Искал, сука, спросил на стек оверфлоу, ничего толкового нету, на со какой-то тип из цюриха что-то подсказал, но это не помогает, уже пиздец как заебало. Глупо спрашивать здесь какие-то вопросы синтетического характера, когда все можно нагуглить оперируяю ключевыи словами, связывая их примитивным английским, но я ничего не нашел и застрял, а спросить нет у кого, я в отчаянии, поэтому и написал здесь.
http://stackoverflow.com/questions/9733082/i18n-error-controller-and-templates-uses-different-implicit-languages
Может локаль не та из заголовка запроса или переменной окружения берется?
Не знаю, я вообще не понимаю, нахуй она здесь нужна, у меня в конф по дефолту английский стоит и менять мне ничего не нужно.
https://github.com/flatlizard/blog/blob/master/app/views/newPost.scala.html
@(postForm: Form[Post])(implicit messages: Messages)
Не пробовал?
Не пробовал?
Ну и соответсвенно в контроллер нужно применшать I18nSupport, в экшен объявить вида = Action { implicit request => ... }
Ну и I18nSupport потребует инъекцию messagesApi: MessagesApi в конструкторе контроллера.
В 2.4 имплисит Lang заменили на Messages и соотвественно имплисит преобразования на RequestHeaders=>Messages. Это нужно чтобы узнать Accepts-Language входящего реквеста, скорее всего его требует какой нить стандартный темплейт хелпер который ты используешь.
https://www.playframework.com/documentation/2.4.x/api/scala/index.html#views.html.helper.inputDate$
apply метод требует имплисит messages: Messages как я и говорил.
https://www.playframework.com/documentation/2.4.x/Migration24#I18n
спасибо всем, решил проблему следующим образом:
import play.api.i18n.Messages.Implicits._
import play.api.Play.current
спасибо всем, решил проблему следующим образом:
import play.api.i18n.Messages.Implicits._
import play.api.Play.current
Но так ты используешь global app (Play.current), который скоро будет депрекейтед. Более чистый вариант с инъекцией нужных зависимостей.
спасибо, почитал уже, изменил
Курс по fp на скале для слоупоков: https://www.coursera.org/course/progfun
Список годноты: https://github.com/lauris/awesome-scala
PWNScala начнется через месяц: http://pnwscala.org/2014/index.html
Презентации летнего ScalaDays: https://www.parleys.com/channel/53a7d269e4b0543940d9e535/presentations?sort=views&state=public
Прошлый тред: http://arhivach.org/thread/21250/
Два недавних форка компилятора, один от тайплевела и второй от баттхертнутого:
https://github.com/typelevel/scala (https://github.com/typelevel/scala/wiki/Differences)
https://github.com/paulp/policy
Специальные ссылки для тех, кто хочет потроллить ИТТ, но не хочет прослыть дауном:
http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu
http://www.youtube.com/watch?v=TS1lpKBMkgg
http://www.infoq.com/presentations/scala-idris