The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз компилятора Rakudo 2022.02 для языка программирования Raku (бывший Perl 6), opennews (??), 13-Фев-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


28. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +2 +/
Сообщение от Самокатофил (?), 14-Фев-22, 10:24 
Список претензий похож на  копипасту из нулевых про 4 перл от начинающих питонщиков.

> Нечитабельный

Раст нечитабельный.

> Ужасные $, @ и % префиксы переменных.

Чем же они ужасны? Они указывают на тип.

> Невозможность описать параметры функции в заголовке функции

man perlsubs
С разморозкой.

> Нет типизации скаляров.

Как это нет? Вы точно знаете перл? Походу нет. Типизация есть, и происходит неявное приведение типов при помощи контекстозависимых операторов. Это то, за что я обожаю просто перл. Мудохаться с ручным приведением -- без меня. Нужна будет строгая типизация, возьму статику.

> Ужасно реализованное ООП.

В языке нет ООП, если только вы не считаете bless за "реализацию ООП". Опять же, вы точно знаете перл? Bless() это то, что с помощью package дает каркас для построения любых ООП систем. Так в перле есть не одна ООП система на выбор.

Слооожна, плак-плак. Ну так перл и не для новичков.

> Практически не реализованное ФП.

"Ужасно" реализованное ооп. "Практически" не реализованное ФП. Сквирти, это ты чтоль гуманитаришь?

> filter

Grep

> map

Map

> flatmap

Зачем, когда есть map/grep и контекстуальное приведение типов?

> Сложность рефакторинга, обусловленная вышепереречисленными трудностями.

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

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

31. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +1 +/
Сообщение от Аноним (31), 14-Фев-22, 12:59 
>>Ужасные $, @ и % префиксы переменных.
>Чем же они ужасны? Они указывают на тип.

На тип должен указывать Тип.

Ответить | Правка | Наверх | Cообщить модератору

32. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  –1 +/
Сообщение от Самокатофил (?), 14-Фев-22, 13:05 
> На тип должен указывать Тип.

Сигил и есть Тип.

Ответить | Правка | Наверх | Cообщить модератору

33. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от fi (ok), 14-Фев-22, 14:58 
>> Нечитабельный
>Раст нечитабельный.

Это он еще C не видел - пусть попробует из 10 стр. портянки понять что делает функция.

Впрочем C++ даст 100 очков вперед по непонятности из-за косвенных вызовов функционала ))))))))))))

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

34. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  –1 +/
Сообщение от Самокатофил (?), 14-Фев-22, 15:10 
>>> Нечитабельный
>>Раст нечитабельный.
> Это он еще C не видел - пусть попробует из 10 стр.
> портянки понять что делает функция.

как тут сказали, практика критерий истины.

rust: https://github.com/uutils/coreutils/blob/main/src/uu/mktemp/...

c: https://git.suckless.org/sbase/file/mktemp.c.html

функционал 1 в 1.

> Впрочем C++ даст 100 очков вперед по непонятности из-за косвенных вызовов функционала
> ))))))))))))

впрочем даже он чище раста. :)

Ответить | Правка | Наверх | Cообщить модератору

41. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от man man (?), 14-Фев-22, 19:05 
> rust: https://github.com/uutils/coreutils/blob/main/src/uu/mktemp/...
> c: https://git.suckless.org/sbase/file/mktemp.c.html

исправят в шестом патче в ведро. или шестьдесят шестом. или шестьсот шетьдесят... вы поняли тенденцию?

Ответить | Правка | Наверх | Cообщить модератору

44. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Самокатофил (?), 14-Фев-22, 20:52 
>> rust: https://github.com/uutils/coreutils/blob/main/src/uu/mktemp/...
>> c: https://git.suckless.org/sbase/file/mktemp.c.html
> исправят в шестом патче в ведро. или шестьдесят шестом. или шестьсот шетьдесят...
> вы поняли тенденцию?

неистово доставляют ваши намёки :-D

Ответить | Правка | Наверх | Cообщить модератору

36. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (-), 14-Фев-22, 15:43 
как вас интересно читать. вы явно разбираетесь. вот тогда скажите пожалуйста - на сколько актуальна "дичь"\информация которая описана здесь - https://www.opennet.ru/base/dev/perl_memory.txt.html
поясню - всё что там описано - череда дичайших НЕочевидностей (которые бабахали когда размер обрабатываемых данных приближался к реальным, боевым размерам). я вот как-то не встречал где бы это рекомендовали сразу писать "чистенько" на перл, чтобы потом не случалось то что описано по ссылке, а вы?
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

38. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  –1 +/
Сообщение от Самокатофил (?), 14-Фев-22, 16:05 
> как вас интересно читать. вы явно разбираетесь.

Сарказм бро, имеет смысл когда ссылается на фейл. Я ссылался на утверждения демонстрирующие незнания языка. А ты?

> вот тогда скажите пожалуйста -
> на сколько актуальна "дичь"\информация которая описана здесь - https://www.opennet.ru/base/dev/perl_memory.txt.html

Ни насколько. Смесь правды и заблуждений и неактуальностей ввиду perl 5.4. Ориентироваться не стоит.

> поясню - всё что там описано - череда дичайших НЕочевидностей (которые бабахали
> когда размер обрабатываемых данных приближался к реальным, боевым размерам).

Ох уж эти смузибои с своими "ниачивидна"! В одном языке тебе говорят: а = b -- ссылка. В другом тебе говорят: $a = $b -- копия, $a = $$b ссылка. Что здесь неочевидно? Перл -- "низкоуровневая" скриптота, с timtowdy и возможностью лезть в кишки бэкенда (B::) на лету. Делай что хочешь, следи за руками.

> я вот как-то не встречал где бы это рекомендовали сразу писать "чистенько" на
> перл, чтобы потом не случалось то что описано по ссылке, а
> вы?

А я сразу начал с camel book, где заложили основы, и до таких "мануалов" даже дело не дошло.

Ответить | Правка | Наверх | Cообщить модератору

37. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  –1 +/
Сообщение от freehckemail (ok), 14-Фев-22, 15:51 

>> flatmap

Кстати, никогда не понимал любви некоторых языков к этой странной функции. Все же понимают, что это map с последующим flatten-ом. Так зачем огород городить?

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

39. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  –1 +/
Сообщение от Самокатофил (?), 14-Фев-22, 16:21 
>>> flatmap
> Кстати, никогда не понимал любви некоторых языков к этой странной функции. Все
> же понимают, что это map с последующим flatten-ом. Так зачем огород
> городить?

Ну функциональщики любят алиасы :-D Но притензию к Perl'y я не понял. Учитывая контекст-зависимую природу map/grep'a в Perl, это же вообще ненужная сущность.

Ответить | Правка | Наверх | Cообщить модератору

42. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +1 +/
Сообщение от freehckemail (ok), 14-Фев-22, 20:08 
> Ну функциональщики любят алиасы :-D

Как функциональщик, я данным тезисом озадачен.


Ответить | Правка | Наверх | Cообщить модератору

43. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Самокатофил (?), 14-Фев-22, 20:22 
>> Ну функциональщики любят алиасы :-D
> Как функциональщик, я данным тезисом озадачен.

Я попытался спетросянить, что ввиду того, что функциональщики не любят присваивание, они будут плодить одинаковые/похожие функции. Просто я это... не могу, сделав фокус, уйти не обосравшись после этого. :D

Ответить | Правка | Наверх | Cообщить модератору

50. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 16-Фев-22, 03:01 
Как в этой ветке модно спрашивать, вы точно функциональщик? :)

Давайте попробую объяснить, надеюсь будет полезно.

Если использовать flatten для "уплощения" вложенных списков - смысла жёстко связывать его с map действительно немного.

Но вот представьте такую ситуацию. У вас есть цепочка обработки данных из функций которые возвращают right-biased Either<Error, TypeN> (псевдоязык, похожий на Яву):

Either<Error, Type2> function1(Type1 data);
Either<Error, Type3> function2(Type2 data);
Either<Error, Type4> function3(Type3 data);
Either<Error, Type5> function4(Type4 data);

Вместо Either подойдёт и Optional<TypeN>, но с Either всё-таки лучше. Так вот, надо обработать данные по цепочке и прерваться на первой же ошибке, если она возникнет. Тогда можно всю цепочку написать следующим образом:

Either<Error, Type1> initialMonad = Right<Type1>(initialData)
Either<Error, Type5> resultMonad = initialMonad
  .flatMap(function1)
  .flatMap(function2)
  .flatMap(function3)
  .flatMap(function4)

Если бы function1..function4 возвращали бы просто Result1..Result4 без ошибок - хорошо подошёл бы простой map. Но так как каждая функция возвращает Either - то нужно этот Either автоматически распаковывать, что flatMap и делает. В этом случае flatMap - логически одна операция, поэтому и сделали flatMap, совмещающий map и flatten.

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

56. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Самокатофил (?), 16-Фев-22, 04:34 
>[оверквотинг удален]
> Either<Error, Type5> resultMonad = initialMonad
>   .flatMap(function1)
>   .flatMap(function2)
>   .flatMap(function3)
>   .flatMap(function4)
> Если бы function1..function4 возвращали бы просто Result1..Result4 без ошибок - хорошо
> подошёл бы простой map. Но так как каждая функция возвращает Either
> - то нужно этот Either автоматически распаковывать, что flatMap и делает.
> В этом случае flatMap - логически одна операция, поэтому и сделали
> flatMap, совмещающий map и flatten.

какая-то теоретизированная др04ка вприсядку для строготипизированной скриптоты. Чем map не угодил?

Ответить | Правка | Наверх | Cообщить модератору

57. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 16-Фев-22, 10:48 
> Давайте попробую объяснить, надеюсь будет полезно.

Слушай, да, это как минимум интересно. По факту мне стало понятно вот что: если я мыслил обо flatten исключительно как о типе 'a list list -> 'a list, то ты мыслишь о нём, как о 'a t t -> 'a t для произвольного t. В этом контексте flatmap уже видится в другом свете. Но меня не покидает дежавю. Я постоянно пользовался тем же Option.bind, и он очень похож на flatmap, описанный тобой: 'a option -> ('a -> 'b option) -> 'b option. И по типу, и по смыслу. Похоже, что это другое название той же самой сущности, с которым я просто чаще сталкивался по жизни.

Но если ты правду говоришь, и flatmap действительно трактуется так широко, то мне всё же не понятно, почему оно называется flatmap. Ну как бы с 'a list всё понятно. Там мы реально строим отображение и сглаживаем его. В случае, если вместо list-а был бы какой-нибудь условный set -- тоже было бы понятно. Но в случаях с 'a option или ('e, 'a) result -- ну как это можно называть map-ом... Это уже аналог apply, а не map-а. В общем, мне сдаётся, что называть эту функцию банальным bind-ом разумнее, нежели flatmap-ом.

Насколько распространено использование flatmap-а в обозначенном тобой контексте? В смысле, когда flatmap и flatten суть синонимы bind и join. Я хотел бы увидеть, что flatmap действительно рассматривается так широко, как ты это сейчас описал. Может быть, у тебя найдётся ссылка на соответствущую литературу?

PS: Если моё недоверие тебя задевает, я конечно извиняюсь, но пойми меня и ты -- я сходу этого не нагуглил, плюс к тому мы на опеннете: тут чего только за истину в последней инстанции выдать ни пытаются. То, что ты пишешь, выглядит очень похоже на правду. Но мне нужен пруфлинк.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

61. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 16-Фев-22, 23:00 
> Я постоянно пользовался тем же Option.bind, и он очень
> похож на flatmap, описанный тобой

Да, flatMap это и есть bind.


> Но если ты правду говоришь, и flatmap действительно трактуется так широко, то
> мне всё же не понятно, почему оно называется flatmap.

Даже с Option и Either flatMap можно разбить на map и flatten. Лучше конечно не надо, но можно.

То есть сначала map делает

    Option[ A ] -> Option[ Option [ B ] ]

а потом flatten делает

    Option[ Option[ B ] ] -> Option[ B ]


> В общем, мне сдаётся, что называть эту функцию банальным bind-ом разумнее, нежели flatmap-ом.

Может, разумнее а может и нет. Споры про именование - вообще неблагодарное занятие. По мне так слово bind может означать очень много чего, в том числе и то, что делает flatMap.


> Насколько распространено использование flatmap-а в обозначенном тобой контексте? В смысле,
> когда flatmap и flatten суть синонимы bind и join. Я хотел
> бы увидеть, что flatmap действительно рассматривается так широко, как ты это
> сейчас описал. Может быть, у тебя найдётся ссылка на соответствущую литературу?

Для Окамла твоего не знаю литературы. Для Скалы можешь попробовать "Functional Programming in Scala" или "Get Programming with Scala", вот статья по мотивам текста оттуда:
https://freecontent.manning.com/using-option-in-scala-part-2.../

Вот ещё про то же самое, очень коротко:
https://alvinalexander.com/scala/handling-nested-options-wit.../

Вот наоборот подлиннее, в том числе явно упоминается, что flatMap это bind:
https://medium.com/free-code-camp/demystifying-the-monad-in-...

Вот про Яву:
https://stackabuse.com/java-8-streams-definitive-guide-to-fl.../

Везде даются примеры с Option/Optional вместо Either, наверное для простоты понимания. Но я и Option/Optional, и Either совместно с flatMap видел в коде реальных проектов. Уж сам решай, верить или нет.

Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 17-Фев-22, 00:36 
>> Я постоянно пользовался тем же Option.bind, и он очень
>> похож на flatmap, описанный тобой
> Да, flatMap это и есть bind.

Да, я уже и сам нашёл. Причём именно на примере OCaml / Haskell: https://web.archive.org/web/20190918044550/https://typeslogi...

(увы только web archive, ребята удалили страницу, но оно того стоит)

> По мне так слово bind может означать очень много чего, в том числе и то, что делает flatMap.

Я соглашусь, что bind штука перегруженная, но и flatmap тут этимологию имеет только ту, что он образован генерализацией классических списковых map и flatten. Всё-таки более корректно тут говорить про monadic bind, насколько я понимаю, это исходное название. А вот flatmap -- уже производное название. Ну да ладно. В любом случае придётся говорить на том языке, на котором говорят все.

> Для Окамла твоего не знаю литературы. Для Скалы можешь попробовать "Functional Programming
> in Scala" или "Get Programming with Scala", вот статья по мотивам
> текста оттуда

Спасибо, конечно, но я всё-таки про литературу ж спрашивал, а не про статьи на медиуме и ему подобным ресурсам. Хочется чего-нибудь более академического, чтобы понять, откуда у терминологии ноги растут. Ну а так-то я вижу, что люди походу пользуются данной терминологией весьма активно.

PS: Я внезапно осознал, что монада -- это просто тип, для которого определен monadic bind с условиями ассоциативности и тождественности. Ну вот почему никто не даёт монаде простого определения? Сразу бы определяли нормально, глядишь, в ФП было бы больше народу. А то развели, мол, монада есть эндофунктор с парой естественных преобразований... Оно-то может и то же самое, но должна же быть золотая середина между академиками и практиками...

PPS: ну в общем, этот небольшой разговор привёл меня внезапно к пониманию, что такое монада, чего я избегал последние несколько лет, так что -- спасибо. =)

Ответить | Правка | Наверх | Cообщить модератору

71. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 18-Фев-22, 17:17 
>> Для Окамла твоего не знаю литературы. Для Скалы можешь попробовать "Functional Programming
>> in Scala" или "Get Programming with Scala", вот статья по мотивам
>> текста оттуда
> Спасибо, конечно, но я всё-таки про литературу ж спрашивал, а не про
> статьи на медиуме и ему подобным ресурсам.

"Functional Programming in Scala" и "Get Programming with Scala" - это как раз книги. В "Functional Programming in Scala" много пишется именно про философию ФП.

Ответить | Правка | Наверх | Cообщить модератору

85. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 19-Фев-22, 00:56 
>>> Для Скалы можешь попробовать "Functional Programming
>>> in Scala" или "Get Programming with Scala", вот статья по мотивам
>>> текста оттуда
>> Спасибо, конечно, но я всё-таки про литературу ж спрашивал, а не про
>> статьи на медиуме и ему подобным ресурсам.
> "Functional Programming in Scala" и "Get Programming with Scala" - это как
> раз книги. В "Functional Programming in Scala" много пишется именно про
> философию ФП.

Я знаю.

Дорогой, не принимай близко к сердцу, но что-то до тебя туго доходит. =)

Ответить | Правка | Наверх | Cообщить модератору

65. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 17-Фев-22, 11:26 
> Для Скалы можешь попробовать

Дорогой, я кстати только что понял, что ты тот же самый Аноним, что и исходный пост треда написал. =)

Есть к тебе вопрос в таком случае... То есть Perl ты не любишь, а Scala ты любишь...  Но как же так? Их ведь так роднит обилие синтактического сахара! =)))

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

76. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 18-Фев-22, 18:57 
Хм, какой-то дурацкий вопрос, содержащий как минимум 3 сомнительных утверждения:

1. В Перле много синтаксического сахара.
2. В Скале много синтаксического сахара.
3. Количество синтасического сахара - главный критерий выбора языка.

Перл и Скала относятся к разным языковым классам, их вообще не имеет большого смысла сравнивать. В классе Перла гораздо больше синтаксического сахара у Руби, который ещё и гораздо мощнее. В классе Скалы есть Груви и Котлин. Они может чуть слаще, но Скала однозначно мощнее.

Не люблю Перл, потому что он намного хуже в своём классе, чем Питон и особенно Руби. Ну зачем использовать Перл, если есть Руби? Я затрудняюсь найти, в чём Перл лучше Руби. Именно как язык, а не реализация интерпретатора, популярность в рейтингах или там количество вакансий на рынке труда.

Люблю Скалу, потому что она самая мощная в своём классе. В классе Ява-подобных языков для Ява-машины. Ну, то есть например Clojure в эту категорию не попадает, ибо не Ява-подобный. В Скале отличное сочетание ООП и ФП. А также привычный синтаксис, ну, кроме использования квадратных скобок. И про companion object я не уверен, что это хорошая идея. Но эти недостатки малы, их запросто можно простить за достоинства Скалы.

Ответить | Правка | Наверх | Cообщить модератору

83. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Самокатофил (?), 18-Фев-22, 20:24 
> Хм, какой-то дурацкий вопрос, содержащий как минимум 3 сомнительных утверждения:
> 1. В Перле много синтаксического сахара.
> 2. В Скале много синтаксического сахара.
> 3. Количество синтасического сахара - главный критерий выбора языка.
> Перл и Скала относятся к разным языковым классам, их вообще не имеет
> большого смысла сравнивать. В классе Перла гораздо больше синтаксического сахара у
> Руби, который ещё и гораздо мощнее.

Мощщщя! Мощнота! Мощщщность!

> В классе Скалы есть Груви
> и Котлин. Они может чуть слаще, но Скала однозначно мощнее.

Однозначно: мощщщя! Мощнота! Мощщщность!

> Не люблю Перл, потому что он намного хуже в своём классе, чем
> Питон и особенно Руби. Ну зачем использовать Перл, если есть Руби?
> Я затрудняюсь найти, в чём Перл лучше Руби.

А зачем руби если есть перл? Ну серьёзно, зачем? Даже переписывать не надо ничего. :-D

> Именно как язык,
> а не реализация интерпретатора, популярность в рейтингах или там количество вакансий
> на рынке труда.

Может минимализм? Ну еще мощщщя! мощнота! мощщщность!

> Люблю Скалу, потому что она самая мощная в своём классе.

Мощщщя! Мощнота! Мощщщность!

Чувак, тебе самому не смешно? xD

Ответить | Правка | Наверх | Cообщить модератору

84. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 19-Фев-22, 00:50 
> Хм, какой-то дурацкий вопрос, содержащий как минимум 3 сомнительных утверждения:
> 1. В Перле много синтаксического сахара.
> 2. В Скале много синтаксического сахара.
> 3. Количество синтасического сахара - главный критерий выбора языка.

Ну, первые два есть, и спорить с этими утверждениями вряд ли вряд ли кто в здравом уме станет. А вот утверждения 3 в данном вопросе не содержится вовсе. Это ты соломенное чучелко сделал, чтобы с ним бороться. =)

> Перл и Скала относятся к разным языковым классам, их вообще не имеет большого смысла сравнивать.

А я и не сравниваю. Я лишь отметил, что языки очень похожи тем, что засахарены настолько, что аж тошнит. =)

Ну и к тому же я решительно протестую против понятия "языкового класса". Сравнивать языки в языковом классе тоже смысла не много. Классы надо нарезать по задачам, которые язык, как инстумент, помогает решать. Причём смотреть не на один лишь синтаксис, а также на стандартные библиотеки, на сообщство, на количество и качество дополнительных пакетов... Потому что если будем смотреть лишь на синтаксис aka выразительную силу языка... Что ж, тогда победили лиспы, а вся история развития языков программирования не имела смысла, можем расходиться. =)

> Не люблю Перл, потому что он намного хуже в своём классе, чем Питон и особенно Руби.

Я ничего не скажу за руби, я не знаю руби. Но в питоне такое качество стандартных библиотек, что при решении, на чём заскриптовать что-либо между питоном и перлом я безусловно бы отдал голос за перл. Есть конечно прикладные области типа того же ML, где из сишных либ понаделали массу обвязок для питона, и так уж исторически сложилось, что там питон превалирует -- что ж, там лучше использовать питон.

> Люблю Скалу, потому что она самая мощная в своём классе. В классе Ява-подобных языков для Ява-машины.

О, вот с этим я спорить не буду. Я вполне согласен, что в экосистеме JVM это хороший выбор. Но отдельно отмечу, что в наших далеко не дремучих кругах превалирует мнение, что "Scala -- это такой Perl для функциональщиков". Не я его автор. Но это очень меткое определение. =)

> В Скале отличное сочетание ООП и ФП.

Ну да, блин, решили проблему ромба, убрав множественное наследование и разрешив подмешивание. А я вот склонен считать, что явное решение проблемы ромба в том же SBCL было куда более разумным шагом. Однако я не хочу об этом спорить. Будем честными: ООП -- это религия. А религия -- она как маяк в море: надо смотреть издалека. Ты же в ней, судя по всему, варишься. И я выражаю тебе по этому поводу сочувствие.

> И про companion object я не уверен, что это хорошая идея.

Это потому что ты чувствуешь немного Perl-а в данном аспекте вашего ООП. ;)

Понимаешь, есть модели ООП, основанные на классах, а есть основанные на прототипах. А это как раз немного прототипов в вашей сугубо классовой модели. =)

> Но эти недостатки малы, их запросто можно простить за достоинства Скалы.

Для меня Scala имеет существенный недостаток: она для JVM, а я писать под эту платформу не хочу.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

86. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 19-Фев-22, 02:14 
>> Хм, какой-то дурацкий вопрос, содержащий как минимум 3 сомнительных утверждения:
>> 1. В Перле много синтаксического сахара.
>> 2. В Скале много синтаксического сахара.
>> 3. Количество синтасического сахара - главный критерий выбора языка.
> Ну, первые два есть, и спорить с этими утверждениями вряд ли вряд
> ли кто в здравом уме станет.

Ну, у нас с тобой наверное разные представления о том, сколько сахара много, а сколько немного.

> А вот утверждения 3 в
> данном вопросе не содержится вовсе.

А по-моему содержится: "То есть Perl ты не любишь, а Scala ты любишь...  Но как же так? Их ведь так роднит обилие синтактического сахара!" Я это понимаю так, что я якобы должен любить языки за синтаксический сахар, а всё остальное как бы и не важно. Но если ты имел в виду не это, то что?

> Это ты соломенное чучелко сделал, чтобы с ним бороться. =)

Это ты какую-то свою стандартную фразу для споров использовал? Как-то мимо. Я именно с этим утверждением и не боролся. Просто упомянул. Прошу, избегай таких клише. А то почитаешь тут форум, так  вместо своих мыслей люди то соломенное чучелко приплетут, то стокгольмский синдром утёнка-самозванца-Даннинга-Крюгера, то аксиому Эскобара. Утомляет.

> Я лишь отметил, что языки очень похожи
> тем, что засахарены настолько, что аж тошнит. =)

Как я и сказал, у нас с тобой наверное разные представления о том, сколько сахара много, а сколько немного. Тут могла бы быть шутка про морковку, но я специально её не пишу, жду подобного и от тебя.

> Ну и к тому же я решительно протестую против понятия "языкового класса".
> Сравнивать языки в языковом классе тоже смысла не много. Классы надо
> нарезать по задачам, которые язык, как инстумент, помогает решать. Причём смотреть
> не на один лишь синтаксис, а также на стандартные библиотеки, на
> сообщство, на количество и качество дополнительных пакетов...

Нарезать по задачам имеет смысл. И по синтаксису тоже имеет смысл.

> Потому что если будем
> смотреть лишь на синтаксис aka выразительную силу языка... Что ж, тогда
> победили лиспы, а вся история развития языков программирования не имела смысла,
> можем расходиться. =)

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

> в наших далеко не дремучих кругах превалирует мнение, что "Scala -- это
> такой Perl для функциональщиков". Не я его автор. Но это очень
> меткое определение. =)

А как по мне, дурацкое определение, и уж тем более не меткое. Это как один товарищ определил Перл как "язык для написания навороченных батников". Ну, потому что и то и то скрипты же.

>> В Скале отличное сочетание ООП и ФП.
> Будем честными: ООП -- это религия.

Ну, это кто как воспринимает. А ФП для некоторых - религия ещё похлеще ООП. :)

> А религия -- она как маяк в море: надо смотреть издалека. Ты
> же в ней, судя по всему, варишься. И я выражаю тебе
> по этому поводу сочувствие.
> Это потому что ты чувствуешь немного Perl-а в данном аспекте вашего ООП.

Давай мы не будем говорить обо мне или о тебе, а также не будем играть в психологов. И использовать приём https://lurkmore.to/%D0%9C%D0%BD%D0... тоже. Ты меня не знаешь и я тебя тоже. Я и про ЯП говорить утомился, а ты пытаешься ещё и на личности переходить. Был тут один, с ником Скоморох или типа того, допереходился уже, обещал откланяться, да всё никак.

Ответить | Правка | Наверх | Cообщить модератору

87. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 19-Фев-22, 02:52 
Хорошо. Не будем играть в психологов. Я тебе прямо и без намёков всё скажу. Как показала наша беседа, ты не воспринимаешь ни сарказма, ни шуток, даже лёгкие подъёбки воспринимаешь в штыки. Я хз, как ты вообще живёшь в таком состоянии.

Я понимаю, что обосрать что-либо -- естественное желание в данном случае, и поэтому ты выбрал Perl. Ну что ж, хорошо, Бога ради. Перл говно. Ты победил. Но серьёзно, парень, у меня -- просто перл говно, а вот у тебя -- есть проблемы, с которыми тебе придётся разобраться. Я тут не помощник, ты ж меня не послушаешь. Но имей в виду, что они есть. Просто чтобы ты помнил об этом тезисе, когда получишь второе подтверждающее мнение.

Ответить | Правка | Наверх | Cообщить модератору

88. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 19-Фев-22, 04:14 
> Хорошо. Не будем играть в психологов.

...И продолжил играть в психолога.

Я тебе ещё одну вещь расскажу, надеюсь опять будет полезно, как с флэтмэпом и монадами.

Люди любят придумывать истории про других людей. Особенно, про тех людей, которые с ними не согласны. Каждый человек думает, что он прав. А если кто-то с ним не согласен - то тот другой конечно же неправ. Но как же так, почему тот другой выбирает быть неправым, очевидно же, что он не прав? Нормальный же человек выберет то же мнение что и я, потому что оно, очевидно, правильное, и будет прав! Значит с ним что-то не так. И вот человек начинает придумывать историю про другого человека, что с тем другим не так. Наверное он тупой. Или ему злость глаза затмила, сам не понимает, что говорит. Или его в детстве обидели и он озлобился вообше навсегда. Или он из такой-то социальной группы, а они там все неправы и вообще маргиналы. Или ещё что-то. Вот и придумана история про того другого. И нарисована картина. Я прав и на белом коне, а тот другой - неправ и этому найдена удобная причина.

Естественно, такая выдуманная история про другого человека - полная чушь, основанная на догадках или вообще на придумках. Но она подогревают самолюбие. Такая вот защитная психологическая функция.

Я раньше тоже придумывал истории про тех, кто со мной не согласен. А потом мне кто-то рассказал про такое вот придумывание историй. И я понял, что это бессмысленное занятие. И перестал это делать. Теперь я просто позволяю другому человеку иметь собственное мнение. И мне пофиг, почему он неправ. Я не придумываю этому обоснование. Стало как-то легче что ли. И тебе советую поступить так же.

Ответить | Правка | Наверх | Cообщить модератору

89. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 19-Фев-22, 12:04 
Да, да. Просто помни об этом тезисе, когда получишь второе подтверждающее мнение.
Ответить | Правка | Наверх | Cообщить модератору

90. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 19-Фев-22, 20:58 
Ты что, не понял ничего?

Ты же про меня только что историю придумал. Про себя подумай, а не про меня, психоаналитик форумный.

Открытым текстом рекомендую тебе: перестань эти истории придумывать. Это бессмыссленное занятие.

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

91. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 20-Фев-22, 10:23 
Хорошо-хорошо, перестану.
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

62. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 16-Фев-22, 23:11 
Вместо

> Если бы function1..function4 возвращали бы просто Result1..Result4 без ошибок - хорошо
> подошёл бы простой map.

конечно же имелось в виду:

Если бы function1..function4 возвращали бы просто Type2..Type5 без ошибок - хорошо
подошёл бы простой map.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

49. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 16-Фев-22, 02:29 
> Раст нечитабельный.

Это правда. И Перл тоже.

> Чем же они ужасны?

Тем, что ужасно замусоривают код.

>> Невозможность описать параметры функции в заголовке функции
> man perlsubs

Вы про прототипы? Типа "sub func($$$$)" для описания 4 параметров? Но это же фигня какая-то. Даже на костыль не тянет. Неудивительно, что прототипами этими никто не пользуюся. Никогда не видел их в реальном коде. Людям нужны нормальные параметры с нормальными именами. width, height, timeout, filename и т.п., а не "$". Это как в Кин-Дза-Дза всё что угодно называли "ку". А в перле всё что угодно называют "$".

>> Нет типизации скаляров.
> Типизация есть, и происходит неявное приведение типов при помощи контекстозависимых операторов.

Неа. Любая документация по Перлу рассказывает, что есть всего 3 типа - скаляр, массив и хэш. Так что у скаляра только один тип - скаляр.

>> Можно запросто сложить число со строкой, "и тебе за это ничего не будет".
> происходит неявное приведение типов при помощи контекстозависимых операторов. Это то, за что я обожаю просто перл. Мудохаться с ручным приведением -- без меня.

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

> В языке нет ООП
> Bless() это то, что с помощью package дает каркас для построения любых ООП систем

Программист должен сам себе делать ООП? И каждый своё несовместимое? Простите, но это дно, а не сервис языка.

> Слооожна, плак-плак. Ну так перл и не для новичков.

Сильное заявление. А я наоборот слышал восхваления, что Перл простой. А теперь получается, программист ещё и усилия должен прилагать, чтобы выучить такой плохой язык? Я не вижу, чем эти усилия окупятся. Уж лучше вложить силы в Питон или Руби.

> Grep, Map

Спасибо, принимается. Подзабыл о них.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

53. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Самокатофил (?), 16-Фев-22, 04:00 
О чем с тобой говорить, если я тебе говорю "man perlsubs" а ты спрашиваешь:

> Вы про прототипы?

И следом же

> Но это же фигня какая-то. Даже на костыль не тянет.

Ты думаешь что соломенное чучело помноженое на обосрамс со старта располагает к разговору? Вертел я весь ваш последующий текст, сударь, разрешите откланяться.

Ответить | Правка | Наверх | Cообщить модератору

64. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 17-Фев-22, 11:17 
Я вообще-то тоже думал, что ты про прототипы. И "man perlsubs" -- плохо гуглится, а самого перла у меня нету под рукой. Может ты прояснишь мысль?
Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Самокатофил (?), 17-Фев-22, 13:37 
> Я вообще-то тоже думал, что ты про прототипы.

Так бывает если не читать документацию. Именно поэтому, я сослался на неё и не агрился в первый раз.

> И "man perlsubs" --
> плохо гуглится, а самого перла у меня нету под рукой. Может
> ты прояснишь мысль?

Это ман.

https://perldoc.perl.org/perlsub#Signatures

Насколько оно нужно перловикам в реальной жизни -- видно по статусу. Нет, если прям охота -- всегда пожалуйста. Фичу даже если удалят, её можно будет включить прагмой use. Просто... когда у тебя есть возможность из функции создавать какие угодно сложные структуры данных, инкорпорирующие переданные в функцию параметры, то использовать эти сигнатуры нууууу... плюсов нет, обратная совместимость пострадает. В качестве документирующего код средства может? Ну есть perldoc с бородатых лет, все хорошие программисты им пользуются, а от плохих и сигнатуры не спасут. Нет, если нужно прям -- то вот оно, пожалуйста.

Ответить | Правка | Наверх | Cообщить модератору

67. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от freehckemail (ok), 17-Фев-22, 16:21 
>> И "man perlsubs" -- плохо гуглится, а самого перла у меня нету под рукой. Может ты прояснишь мысль?
> Это ман.

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

> https://perldoc.perl.org/perlsub#Signatures

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

Ответить | Правка | Наверх | Cообщить модератору

68. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Самокатофил (?), 17-Фев-22, 17:09 
>>> И "man perlsubs" -- плохо гуглится, а самого перла у меня нету под рукой. Может ты прояснишь мысль?
>> Это ман.
> Да, да. И я тебе гарантирую, что людям, у которых нету перла
> на машине, натурально лень искать, откуда ставится эта ман-страница.

Когда ссылаются на ман -- ссылаются на ман. Тут уж какие претензии? Лень искать, лень читать, зато вбрасывать не лень? Мээээн.

>> https://perldoc.perl.org/perlsub#Signatures
> Понял. Ну, здорово. Впрочем, я не сильно понимаю, зачем скриптовому языку такие
> финты ушами: я как бы никогда не слышал, чтобы кто-то на
> шелл ругался за то, что там параметры нельзя в шапке указать.

"Фиче" 8 лет. С таким анабиозом чуваку вбрасывать про жемчужину, и хуцповать в ответ на ман... :-D

> Так и тут, я не понимаю, почему вдруг это для человека
> проблема: область применения данного инструмента располагает к тому, чтобы это не
> было проблемой.

И я хз. Учитывая природу Perl, ты видел какие финты ушами можно делать в сигнатурах. В отличие от прототипов, в компайл-тайм это не засунешь. А в рантайм, где это важно, всё равно нужно засовывать контракты.

Ответить | Правка | Наверх | Cообщить модератору

73. "Релиз компилятора Rakudo 2022.02 для языка программирования ..."  +/
Сообщение от Аноним (23), 18-Фев-22, 18:11 
Про "man persubs". Который на самом деле perlsub.

Захотел я почитать сию ман-страничку. Поискал в гугле "man perlsubs". Выдал мне гугл первую ссылку https://linux.die.net/man/1/perlsub . Я почитал, нашёл про прототипы. Про сигнатуры там ни слуху, ни духу. А ссылки https://perldoc.perl.org/perlsub даже на первой странице гуглопоиска нету.

Спросил потом тебя, ты про прототипы? Вместо того, чтобы объяснить, что ты про сигнатуры - ты стал в позу и ничего не объяснил. Наверное гордыней своей упивался по поводу того, что лучше знаешь Перл. Вот был бы менее гордым и объяснил бы - мы бы поняли друг друга лучше. Добрее надо быть к форумчанам, даже если не согласен с ними. :)

> "Фиче" 8 лет

Ты уверен? Фича помечена как экспериментальная. Она уже 8 лет как экспериментальная? Какой-то очень долгий эксперимент... На linux.die.net тоже ман 8-летней давности лежит что ли?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру