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

"Релиз компилятора Rakudo 2022.02 для языка программирования Raku (бывший Perl 6)"	+/–
Сообщение от opennews (??), 13-Фев-22, 10:34
Представлен выпуск Rakudo 2022.02, компилятора для языка программирования Raku (бывший Perl 6). Проект был переименован из Perl 6 так как не стал продолжением Perl 5, как ожидалось изначально, а превратился в отдельный язык программирования, не совместимый с Perl 5 на уровне исходных текстов и развиваемый отдельным сообществом разработчиков. Одновременно доступен  выпуск виртуальной машины MoarVM 2022.02, формирующей среду для запуска скомпилированного в Rakudo байт-кода. В Rakudo компиляция также поддерживается для JVM и некоторых виртуальных машин для JavaScript... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56690
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 13-Фев-22, 10:34	+3 +/–
>(бывший Perl 6). А когда там уже седьмой перл выйдет?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от Аноним (2), 13-Фев-22, 10:46	–5 +/–
а смысл? язык полностью сдал свои позиции даже в тех областях, где он когда-то N-дцать лет назад был популярен. Сабж - просто попытки выкопать труп инвалида от рождения и сделать ему искусственное дыхание, хотя там и легких-то уже нет, все сожрала Мать Природа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3, #8, #9

3. Сообщение от Аноним (3), 13-Фев-22, 11:12	+2 +/–
Сабж - новый язык, спеку начали писать ещё в 20хх, но релиз как это бывает несколько затянулся. Так что нет, это не попытка выкопать труп, это другой язык от тех же авторов. perl 7 уже есть https://gist.github.com/Grinnz/be5db6b1d54b22d8e21c975d68d7a54f
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #4, #5

4. Сообщение от Аноним (4), 13-Фев-22, 11:37	+3 +/–
>другой язык от тех же авторов. Много языков хороших и разных
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #15

5. Сообщение от Аноним (2), 13-Фев-22, 11:40	–1 +/–
> другой язык от тех же авторов Какая разница, кто как его величает, сабж - "развитие" перла, о чем намекает даже официальный сайт, где в куче мест вместо "раку" пишут "перл 6".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #7

6. Сообщение от Skif (ok), 13-Фев-22, 12:04	–1 +/–
Раками кто-то пользуется? Под пивко небось? Ps: ностальгически вздохнул по пятой жемчужине и нулевых...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #14

7. Сообщение от Аноним (7), 13-Фев-22, 12:05	+/–
Какая разница, как язык величает аноним с опеннета. Сабж — новый язык, сильно отличающийся от перал, но перенявший у него некоторые концепции. Где написано "перл 6" — значит, не успели исправить. Раньше язык носил это имя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Онаним (?), 13-Фев-22, 15:03	+/–
> Сабж - просто попытки ... сделать ему искусственное дыхание Причём рот-в-рот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

9. Сообщение от Аноним (9), 13-Фев-22, 15:51	+7 +/–
Пишет клоун, который вообще не умеет ни в какой код :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10

10. Сообщение от Аноним (2), 13-Фев-22, 17:06	–1 +/–
так научись и прекрати им быть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

11. Сообщение от mos87 (ok), 13-Фев-22, 17:32	+1 +/–
Нужно.
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от Аноним (-), 13-Фев-22, 17:37	+1 +/–
>Ps: ностальгически вздохнул по пятой жемчужине и нулевых... А чего вздыхать ностальгически? Уж 5я перловка в любом линухе есть. Идёт жешь в комплекте ко всяким бубунтам и иже с ними. Бери да пиши.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #13

13. Сообщение от Аноним (13), 13-Фев-22, 17:53	–4 +/–
Да какая-то дичь, какие-то аутисты из копрошляпы в иксы напихали перла последние пару лет. Видимо, чтобы окончательно иксы закопать, а то пользователям что-то очень нравится когда у них всё работает -- так хоть перл утянет их на дно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

14. Сообщение от Самокатофил (?), 13-Фев-22, 18:05	+2 +/–
Пока перлхакеры пилили джастфофан новый язык, мир изменился. Они сделали перл с блекджеком и бабочками, а "продакшн" вовсю гнал стадо в го и петончег. Рыночек порешал, тут ничё не поделаешь. > Ps: ностальгически вздохнул по пятой жемчужине и нулевых... Хех, до сих пор мой рабочий инструмент. Я не так суперстар, и начинал учить его школотой, когда жемчужина уже теряла позиции. Просто это были всё еще времена, когда на лоре о опеннете тусовалось не так много уставших сеньёров с макбуком, и пинали школоту не в "успешный успех", а в "кр@сно глазие и пердоленг". А когда уже раскурил перловку, там уже не до другой скриптоты. Вот до сих пор и пишу. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #17

15. Сообщение от YetAnotherOnanym (ok), 13-Фев-22, 18:33	+/–
Рэймонд Куни, залогиньтесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

16. Сообщение от Аноним (16), 13-Фев-22, 19:04	+/–
>Проект был переименован из Perl 6 так как не стал продолжением Perl 5 Стал, просто перловики-утята это не приняли. >не совместимый с Perl 5 на уровне исходных текстов Будто перл 4 совместим с 5м на уровне исходных кодов
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

17. Сообщение от alexander lunev (?), 13-Фев-22, 19:15	+6 +/–
Отличный язык, пишу на нём до сей поры, под виндой и под никсами. При этом спокойно и на питоне могу. И вообще, на чем надо - на том и могу. Раньше нас так учили, что язык программирования учится за две недели, а основы и парадигмы программирования - они всегда и везде одинаковые (ок, не везде, есть еще LISP). Поэтому холивары про язык программирования мне непонятны - удобно вам на питоне писать - вперёд, кривые ноги. Очень неудобный язык, по сравнению с перлом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

18. Сообщение от Аноним (16), 13-Фев-22, 19:16	+/–
Кстати, отличный язык. Всё тот же хакерский швейцарский нож, но круче и современнее.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20

19. Сообщение от Аноним (-), 13-Фев-22, 20:13	+/–
>перловики-утята это не приняли. Как-то слышал от одного перловика, что Raku тормозной по сравнению с Perl-5. Кто пишет на Raku? Raku стал быстрее исполнять программы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #45

20. Сообщение от Аноним (13), 14-Фев-22, 00:36	–1 +/–
ps aux | grep python | wc -l 65 ps aux | grep perl | wc -l 1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #21

21. Сообщение от Аноним (16), 14-Фев-22, 03:09	+3 +/–
Посочувствовать тебе что ли? >ps aux | grep python | wc -l >1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #22, #24

22. Сообщение от Аноним (13), 14-Фев-22, 03:36	–2 +/–
Толку-то переживать когда $  memorycount.sh firefox Total RSS (ps): 3.639 gb Total (smaps-rss): 3.705 gb Total (smaps-pss): 2.940 gb $ memorycount.sh python Total RSS (ps): 0.673 gb Total (smaps-rss): 0.696 gb Total (smaps-pss): 0.492 gb
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

23. Сообщение от Аноним (23), 14-Фев-22, 04:16	–3 +/–
Perl - отстойный язык: * Нечитабельный, особенно когда количество кода возрастает. Язык поощряет написание нечитабельного кода. * Ужасные $, @ и % префиксы переменных. * Невозможность описать параметры функции в заголовке функции. Надо смотреть в тело функции чтоб узнать, какие аргументы есть и как они используются. Или верить на слово документации, если она есть и не устарела. Удачной отладки. * Чтение аргументов функции из массива @_. Какое-то тяжёлое наследие шелл-программирования походу, где аргументы в $@ хранятся. * Нет типизации скаляров. Одна переменная - это тебе и строка, и число. Можно запросто сложить число со строкой, "и тебе за это ничего не будет". Тоже похоже на тяжёлое наследие шеллов. * Ужасно реализованное ООП. * Практически не реализованное ФП. Никаких тебе filter, map или flatmap. Только указатели на функции. * Сложность рефакторинга, обусловленная вышепереречисленными трудностями. В 90-х, когда не было выбора, Perl был хорошим выбором, на безрыбье. Но сейчас Python и особенно Ruby на голову удобнее. Ты всё ещё скрипишь над скриптами на Перле? Это же Дум 2.0 - ад на земле!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #26, #27, #28, #35

24. Сообщение от Аноним (-), 14-Фев-22, 07:13	+1 +/–
Не надо. Он имел ввиду функционал языка, ты же показал то, что Python здорово плодит процессы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29

25. Сообщение от Аноним (-), 14-Фев-22, 07:21	+/–
>Нечитабельный, особенно когда количество кода возрастает. Язык поощряет написание нечитабельного кода. Ты имеешь ввиду скрипты-однострочники. Или типичное состояние кода на перле?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #46

26. Сообщение от m (??), 14-Фев-22, 09:20	+1 +/–
Попробуй Rust прочитай или go.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #60

27. Сообщение от m (??), 14-Фев-22, 09:23	+/–
Чтобы прочитать текст нужно знать язык, возмущаться бесполезно. Оформление можно автоматически поправить, для этого существует perltidy.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

28. Сообщение от Самокатофил (?), 14-Фев-22, 10:24	+2 +/–
Список претензий похож на  копипасту из нулевых про 4 перл от начинающих питонщиков. > Нечитабельный Раст нечитабельный. > Ужасные $, @ и % префиксы переменных. Чем же они ужасны? Они указывают на тип. > Невозможность описать параметры функции в заголовке функции man perlsubs С разморозкой. > Нет типизации скаляров. Как это нет? Вы точно знаете перл? Походу нет. Типизация есть, и происходит неявное приведение типов при помощи контекстозависимых операторов. Это то, за что я обожаю просто перл. Мудохаться с ручным приведением -- без меня. Нужна будет строгая типизация, возьму статику. > Ужасно реализованное ООП. В языке нет ООП, если только вы не считаете bless за "реализацию ООП". Опять же, вы точно знаете перл? Bless() это то, что с помощью package дает каркас для построения любых ООП систем. Так в перле есть не одна ООП система на выбор. Слооожна, плак-плак. Ну так перл и не для новичков. > Практически не реализованное ФП. "Ужасно" реализованное ооп. "Практически" не реализованное ФП. Сквирти, это ты чтоль гуманитаришь? > filter Grep > map Map > flatmap Зачем, когда есть map/grep и контекстуальное приведение типов? > Сложность рефакторинга, обусловленная вышепереречисленными трудностями. Вышеперечисленных трудностей нет. А когда у кого-нибудь из скриптовых появится профайлер на уровне nytprof, тогда можно будет серьезно говорить о рефакторинге, а не этот детский сад поо сигилы, чтоивы написали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #31, #33, #36, #37, #49

29. Сообщение от Самокатофил (?), 14-Фев-22, 10:30	+/–
:-D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

30. Сообщение от Аноним (31), 14-Фев-22, 12:58	–2 +/–
Ещё не запустили обсуждение нового названия для языка? А то с таким названием он не летун (не летец).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47

31. Сообщение от Аноним (31), 14-Фев-22, 12:59	+1 +/–
>>Ужасные $, @ и % префиксы переменных. >Чем же они ужасны? Они указывают на тип. На тип должен указывать Тип.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #32

32. Сообщение от Самокатофил (?), 14-Фев-22, 13:05	–1 +/–
> На тип должен указывать Тип. Сигил и есть Тип.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

33. Сообщение от fi (ok), 14-Фев-22, 14:58	+/–
>> Нечитабельный >Раст нечитабельный. Это он еще C не видел - пусть попробует из 10 стр. портянки понять что делает функция. Впрочем C++ даст 100 очков вперед по непонятности из-за косвенных вызовов функционала ))))))))))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #34

34. Сообщение от Самокатофил (?), 14-Фев-22, 15:10	–1 +/–
>>> Нечитабельный >>Раст нечитабельный. > Это он еще 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ообщить модератору
Родитель: #33 Ответы: #41

35. Сообщение от freehck (ok), 14-Фев-22, 15:38	+1 +/–
Блин, я не являюсь перл-программистом, а просто мимо этого языка проходил когда-то, но даже я смогу легко размазать подобный вброс. =) > * Нечитабельный, особенно когда количество кода возрастает. Язык поощряет написание нечитабельного кода. Докажите. Когда я последний раз взаимодействовал с Perl в CPAN был довольно-таки читаемый код. Сомневаюсь, что что-то изменилось. Вот то ли дело стандартные библиотеки Python. Вот уж где хочется пройтись асфальтоукладчиком. =) > * Ужасные $, @ и % префиксы переменных. Ужаааасные, ну конеееечно. Ведь это так плохо, по имени символа понять, что он относится к скаляру, списку или хэшу. Суффиксные нотации в стиле Microsoft куда лучше, конечно же. =) > * Невозможность описать параметры функции в заголовке функции. Когда я в последний раз писал на перле (а это было целую вечность тому назад), вроде бы уже было можно. Нафиг надо, конечно, но можно. > Надо смотреть в тело функции чтоб узнать, какие аргументы есть и как они используются. Или верить на слово документации, если она есть и не устарела. Удачной отладки. Ё-моё, надо читать документацию. В топку такой язык! В топку! =) > * Чтение аргументов функции из массива @_. Какое-то тяжёлое наследие шелл-программирования походу, где аргументы в $@ хранятся. О ужас, функции по умолчанию принимают массив, который потом надо разбирать. Во многих языках это -- отдельный элемент синтаксиса, имеющий специальную нотацию. А тут -- из коробки, ну как же так-то. =) > * Нет типизации скаляров. Одна переменная - это тебе и строка, и число. Можно запросто сложить число со строкой, "и тебе за это ничего не будет". Тоже похоже на тяжёлое наследие шеллов. Ну вообще-то есть. Это тебе не шелл, где всё обращается в строку. Другое дело, в перле присутствует элемент тяжёлого наследия от Си, с этим его неявным преобразованием типов. > * Ужасно реализованное ООП. Перевожу на человеческий язык: "Модель ООП в языке Perl отличается от той, к которой привык автор в любом другом языке". Что собственно не мудрено: каждый ООП-ориентированный язык создаёт какую-то свою модель ООП, отличную от предыдущих. Этих моделей уже целый вагон, и каждая несёт в себе свои достоинства и недостатки. Эталонной модели нет. Смысла спорить о том, какая из моделей лучше -- тоже. Я вот скажу, что лучшая модель ООП представлена в языке OCaml, а вы продолжите дальше мучаться со Scala, но то, что у ООП есть проблемы с теоретической базой, и что это уже давно религиозный культ -- к языку Perl никак не относится. > * Практически не реализованное ФП. Никаких тебе filter, map или flatmap. Лол. Вы уверены? =) > * Сложность рефакторинга, обусловленная вышепереречисленными трудностями. Вот тут ничего не смогу сказать. Я не занимался рефакторингом на перле. Но при прочих равных, я спокойно читал чужой код, и он вызывал куда меньше вопросов, чем, к примеру, код на си, на крестах, на яве или скале. > В 90-х, когда не было выбора, Perl был хорошим выбором, на безрыбье. Но сейчас Python и особенно Ruby на голову удобнее. Я не хочу представлять себе ментальное состояние людей, на полном серьёзе утверждающих, что между Perl 5 и Python 3 -- они сделают выбор в пользу Python 3. Больные ублюдки. =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #40

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

37. Сообщение от freehck (ok), 14-Фев-22, 15:51	–1 +/–
>> flatmap Кстати, никогда не понимал любви некоторых языков к этой странной функции. Все же понимают, что это map с последующим flatten-ом. Так зачем огород городить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #39, #50

38. Сообщение от Самокатофил (?), 14-Фев-22, 16:05	–1 +/–
> как вас интересно читать. вы явно разбираетесь. Сарказм бро, имеет смысл когда ссылается на фейл. Я ссылался на утверждения демонстрирующие незнания языка. А ты? > вот тогда скажите пожалуйста - > на сколько актуальна "дичь"\информация которая описана здесь - https://www.opennet.ru/base/dev/perl_memory.txt.html Ни насколько. Смесь правды и заблуждений и неактуальностей ввиду perl 5.4. Ориентироваться не стоит. > поясню - всё что там описано - череда дичайших НЕочевидностей (которые бабахали > когда размер обрабатываемых данных приближался к реальным, боевым размерам). Ох уж эти смузибои с своими "ниачивидна"! В одном языке тебе говорят: а = b -- ссылка. В другом тебе говорят: $a = $b -- копия, $a = $$b ссылка. Что здесь неочевидно? Перл -- "низкоуровневая" скриптота, с timtowdy и возможностью лезть в кишки бэкенда (B::) на лету. Делай что хочешь, следи за руками. > я вот как-то не встречал где бы это рекомендовали сразу писать "чистенько" на > перл, чтобы потом не случалось то что описано по ссылке, а > вы? А я сразу начал с camel book, где заложили основы, и до таких "мануалов" даже дело не дошло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

39. Сообщение от Самокатофил (?), 14-Фев-22, 16:21	–1 +/–
>>> flatmap > Кстати, никогда не понимал любви некоторых языков к этой странной функции. Все > же понимают, что это map с последующим flatten-ом. Так зачем огород > городить? Ну функциональщики любят алиасы :-D Но притензию к Perl'y я не понял. Учитывая контекст-зависимую природу map/grep'a в Perl, это же вообще ненужная сущность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #42

40. Сообщение от Самокатофил (?), 14-Фев-22, 16:50	–1 +/–
>> * Сложность рефакторинга, обусловленная вышепереречисленными трудностями. > Вот тут ничего не смогу сказать. Есть их у меня :-P Вот если под рефакторингом тот "программист" понимает рестайлинг, то конечно, новичку timtowdy даст по щам. И чем зелёней новичок -- тем смачнее. Но ведь с таким рефакторингом справится и perltidy + perlcritic + Абу. Зачем называть рефакторингом то что отдалённо является им, а мерять его удобство по плачу обезьяны по сигилам. Для рефакторинга понадобятся: профайлер, дебаггер, дебаггер регулярок, тесты, и профессиональное сообщество хакеров, которое восполнит недостаток знания perl internals при "неожиданном поведении". По моему скромному мнению, с этим у перла лучше чем у многой скриптоты. Не говорю "всей" только из душевной скромности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #52

41. Сообщение от 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ообщить модератору
Родитель: #34 Ответы: #44

42. Сообщение от freehck (ok), 14-Фев-22, 20:08	+1 +/–
> Ну функциональщики любят алиасы :-D Как функциональщик, я данным тезисом озадачен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #43

43. Сообщение от Самокатофил (?), 14-Фев-22, 20:22	+/–
>> Ну функциональщики любят алиасы :-D > Как функциональщик, я данным тезисом озадачен. Я попытался спетросянить, что ввиду того, что функциональщики не любят присваивание, они будут плодить одинаковые/похожие функции. Просто я это... не могу, сделав фокус, уйти не обосравшись после этого. :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

44. Сообщение от Самокатофил (?), 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ообщить модератору
Родитель: #41

45. Сообщение от Аноним (16), 14-Фев-22, 23:17	+/–
>Как-то слышал от одного перловика, что Raku тормозной по сравнению с Perl-5. Это было во времена альфы, сейчас по тормознутости на уровне перла5, если не расставлять типы вручную.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

46. Сообщение от Аноним (23), 14-Фев-22, 23:21	+/–
Типичное состояние кода на перле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

47. Сообщение от Аноним (-), 15-Фев-22, 07:31	+/–
Для рускаго языка не летун. Для английского языка летун.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

48. Сообщение от AskerTV (ok), 15-Фев-22, 18:06	+/–
Что то нигде нет про PHP, а ведь именно PHP и заменил Perl. PHP, давно уже предвещают конец, но он себя не плохо чувствует, развивается. Вот и Perl с его наследием, живёт. Много legacy-кода на нём, смысл его переписывать на PHP, или Python/Ruby/NodeJS/Go, если во время переписывания, будут опять появляться "новые самые лучшие языки программирования"? Уже и на Kotlin, пытаются делать веб-приложения/сайты.
Ответить | Правка | Наверх | Cообщить модератору

49. Сообщение от Аноним (23), 16-Фев-22, 02:29	+/–
> Раст нечитабельный. Это правда. И Перл тоже. > Чем же они ужасны? Тем, что ужасно замусоривают код. >> Невозможность описать параметры функции в заголовке функции > man perlsubs Вы про прототипы? Типа "sub func($$$$)" для описания 4 параметров? Но это же фигня какая-то. Даже на костыль не тянет. Неудивительно, что прототипами этими никто не пользуюся. Никогда не видел их в реальном коде. Людям нужны нормальные параметры с нормальными именами. width, height, timeout, filename и т.п., а не "$". Это как в Кин-Дза-Дза всё что угодно называли "ку". А в перле всё что угодно называют "$". >> Нет типизации скаляров. > Типизация есть, и происходит неявное приведение типов при помощи контекстозависимых операторов. Неа. Любая документация по Перлу рассказывает, что есть всего 3 типа - скаляр, массив и хэш. Так что у скаляра только один тип - скаляр. >> Можно запросто сложить число со строкой, "и тебе за это ничего не будет". > происходит неявное приведение типов при помощи контекстозависимых операторов. Это то, за что я обожаю просто перл. Мудохаться с ручным приведением -- без меня. Вы правда не видите проблемы со сложением цисла и строки? Неужели программирование на Перле так портит людей? Для вас выбор - это приведение вручную или автоматически? А для меня такая ситуация - ошибка программиста, на которую интерпретатор должен ругаться. Желательно бы на стадии компиляции, но раз в динамических языках такая роскошь недоступна - то хоть в рантайме. > В языке нет ООП > Bless() это то, что с помощью package дает каркас для построения любых ООП систем Программист должен сам себе делать ООП? И каждый своё несовместимое? Простите, но это дно, а не сервис языка. > Слооожна, плак-плак. Ну так перл и не для новичков. Сильное заявление. А я наоборот слышал восхваления, что Перл простой. А теперь получается, программист ещё и усилия должен прилагать, чтобы выучить такой плохой язык? Я не вижу, чем эти усилия окупятся. Уж лучше вложить силы в Питон или Руби. > Grep, Map Спасибо, принимается. Подзабыл о них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #53

50. Сообщение от Аноним (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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #56, #57, #62

52. Сообщение от Аноним (23), 16-Фев-22, 03:57	+/–
> Вот если под рефакторингом тот "программист" понимает рестайлинг > Зачем называть рефакторингом то что отдалённо является им, а мерять его удобство по плачу обезьяны по сигилам. Сам обозвал рефакторинг рестайлингом (зачем???), сам удивился, а обезьяной почему-то обозвал кого-то другого. :) Под рефакторингом понимается переработка кода для лучшей читабельности и поддерживаемости. То есть код переносится в другие функции, в другие модули, изменяются взаимосвязи между частями кода, а также АПИ. Функции сливаются или наоборот разбиваются на несколько, переименовываются, переносятся в другие модули. Модули тоже могут сливаться, разбиваться, переименовываться. По сути, рефакторинг - это один из способов снижения технического долга. Рефакторинг в динамических языках - вообще неблагодарное занятие, по сравнению со статическими. Но в Перл в этом деле сливает даже другим динамическим языкам. Очень трудно что-то прорефакторить и не внести ошибок. Вот, самое простое, поменять количество параметров в функции или поменять параметры местами. И чтобы код продолжил работать. В Перле это будет сделать труднее, чем в Питоне и Руби. Потому что вместо списка внятно именованных параметров в Перле @_. А прототипы, которые не сильно бы и помогли, никто не использует, ибо убоги.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #54, #70

53. Сообщение от Самокатофил (?), 16-Фев-22, 04:00	+/–
О чем с тобой говорить, если я тебе говорю "man perlsubs" а ты спрашиваешь: > Вы про прототипы? И следом же > Но это же фигня какая-то. Даже на костыль не тянет. Ты думаешь что соломенное чучело помноженое на обосрамс со старта располагает к разговору? Вертел я весь ваш последующий текст, сударь, разрешите откланяться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #64

54. Сообщение от Самокатофил (?), 16-Фев-22, 04:04	+/–
>[оверквотинг удален] > могут сливаться, разбиваться, переименовываться. По сути, рефакторинг - это один из > способов снижения технического долга. > Рефакторинг в динамических языках - вообще неблагодарное занятие, по сравнению со статическими. > Но в Перл в этом деле сливает даже другим динамическим языкам. > Очень трудно что-то прорефакторить и не внести ошибок. > Вот, самое простое, поменять количество параметров в функции или поменять параметры местами. > И чтобы код продолжил работать. В Перле это будет сделать труднее, > чем в Питоне и Руби. Потому что вместо списка внятно именованных > параметров в Перле @_. А прототипы, которые не сильно бы и > помогли, никто не использует, ибо убоги. Нагенеренный AI инфошум. man perlsubs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

56. Сообщение от Самокатофил (?), 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ообщить модератору
Родитель: #50

57. Сообщение от freehck (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: Если моё недоверие тебя задевает, я конечно извиняюсь, но пойми меня и ты -- я сходу этого не нагуглил, плюс к тому мы на опеннете: тут чего только за истину в последней инстанции выдать ни пытаются. То, что ты пишешь, выглядит очень похоже на правду. Но мне нужен пруфлинк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #61

59. Сообщение от nich (ok), 16-Фев-22, 11:53	+/–
Признавайтесь, кто с раку игрался?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #69

60. Сообщение от DD (??), 16-Фев-22, 17:48	+/–
Вот про GO не надо гнать. Читается на ура любой код. Но с дженериками да, попортят это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

61. Сообщение от Аноним (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ообщить модератору
Родитель: #57 Ответы: #63, #65

62. Сообщение от Аноним (23), 16-Фев-22, 23:11	+/–
Вместо > Если бы function1..function4 возвращали бы просто Result1..Result4 без ошибок - хорошо > подошёл бы простой map. конечно же имелось в виду: Если бы function1..function4 возвращали бы просто Type2..Type5 без ошибок - хорошо подошёл бы простой map.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

63. Сообщение от freehck (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ообщить модератору
Родитель: #61 Ответы: #71

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

65. Сообщение от freehck (ok), 17-Фев-22, 11:26	+/–
> Для Скалы можешь попробовать Дорогой, я кстати только что понял, что ты тот же самый Аноним, что и исходный пост треда написал. =) Есть к тебе вопрос в таком случае... То есть Perl ты не любишь, а Scala ты любишь...  Но как же так? Их ведь так роднит обилие синтактического сахара! =)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #76

66. Сообщение от Самокатофил (?), 17-Фев-22, 13:37	+/–
> Я вообще-то тоже думал, что ты про прототипы. Так бывает если не читать документацию. Именно поэтому, я сослался на неё и не агрился в первый раз. > И "man perlsubs" -- > плохо гуглится, а самого перла у меня нету под рукой. Может > ты прояснишь мысль? Это ман. https://perldoc.perl.org/perlsub#Signatures Насколько оно нужно перловикам в реальной жизни -- видно по статусу. Нет, если прям охота -- всегда пожалуйста. Фичу даже если удалят, её можно будет включить прагмой use. Просто... когда у тебя есть возможность из функции создавать какие угодно сложные структуры данных, инкорпорирующие переданные в функцию параметры, то использовать эти сигнатуры нууууу... плюсов нет, обратная совместимость пострадает. В качестве документирующего код средства может? Ну есть perldoc с бородатых лет, все хорошие программисты им пользуются, а от плохих и сигнатуры не спасут. Нет, если нужно прям -- то вот оно, пожалуйста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #67

67. Сообщение от freehck (ok), 17-Фев-22, 16:21	+/–
>> И "man perlsubs" -- плохо гуглится, а самого перла у меня нету под рукой. Может ты прояснишь мысль? > Это ман. Да, да. И я тебе гарантирую, что людям, у которых нету перла на машине, натурально лень искать, откуда ставится эта ман-страница. > https://perldoc.perl.org/perlsub#Signatures Понял. Ну, здорово. Впрочем, я не сильно понимаю, зачем скриптовому языку такие финты ушами: я как бы никогда не слышал, чтобы кто-то на шелл ругался за то, что там параметры нельзя в шапке указать. Так и тут, я не понимаю, почему вдруг это для человека проблема: область применения данного инструмента располагает к тому, чтобы это не было проблемой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #68

68. Сообщение от Самокатофил (?), 17-Фев-22, 17:09	+/–
>>> И "man perlsubs" -- плохо гуглится, а самого перла у меня нету под рукой. Может ты прояснишь мысль? >> Это ман. > Да, да. И я тебе гарантирую, что людям, у которых нету перла > на машине, натурально лень искать, откуда ставится эта ман-страница. Когда ссылаются на ман -- ссылаются на ман. Тут уж какие претензии? Лень искать, лень читать, зато вбрасывать не лень? Мээээн. >> https://perldoc.perl.org/perlsub#Signatures > Понял. Ну, здорово. Впрочем, я не сильно понимаю, зачем скриптовому языку такие > финты ушами: я как бы никогда не слышал, чтобы кто-то на > шелл ругался за то, что там параметры нельзя в шапке указать. "Фиче" 8 лет. С таким анабиозом чуваку вбрасывать про жемчужину, и хуцповать в ответ на ман... :-D > Так и тут, я не понимаю, почему вдруг это для человека > проблема: область применения данного инструмента располагает к тому, чтобы это не > было проблемой. И я хз. Учитывая природу Perl, ты видел какие финты ушами можно делать в сигнатурах. В отличие от прототипов, в компайл-тайм это не засунешь. А в рантайм, где это важно, всё равно нужно засовывать контракты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #73

69. Сообщение от Самокатофил (?), 17-Фев-22, 17:11	+/–
> Признавайтесь, кто с раку игрался? Признавайтесь, кто баловался с раку?! :3
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

70. Сообщение от Самокатофил (?), 17-Фев-22, 17:22	+/–
Ты не понимаешь что такое прототипы, сигнатуры, и для чего они нужны. При изменении порядка аргументов функции нужно апдейтить документацию, потому что смотрят документацию, а не порядок аргументов функции в исходном коде. В общем, читни манца, дуде, и не пори чушь здесь про "рефакторинг".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #72

71. Сообщение от Аноним (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ообщить модератору
Родитель: #63 Ответы: #85

72. Сообщение от Аноним (23), 18-Фев-22, 17:47	+/–
> При изменении порядка аргументов функции нужно апдейтить документацию, потому что смотрят документацию, а не порядок аргументов функции в исходном коде. Я ж уже писал про это. Во многих реальных проектах документация на функции часто бывает устаревшей или вообще отсутствует. Особенно для внутренних функций модуля, не для API-функций. В идеале, конечно документация всегда должна быть и должна апдейтиться. Но увы, далеко не всегда так бывает. > смотрят документацию, а не порядок аргументов функции в исходном коде Это правда для API-функций популярных библиотек. И почти всегда неправда для внутренних функций. Чтобы далеко за примером не ходить, вот исходник, на который выше ссылку кидали: https://github.com/uutils/coreutils/blob/main/src/uu/mktemp/... В файле определено несколько функций, у скольких из них есть документация? Спойлер: ни у одной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #74

73. Сообщение от Аноним (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ообщить модератору
Родитель: #68

74. Сообщение от Самокатофил (?), 18-Фев-22, 18:17	+/–
>> При изменении порядка аргументов функции нужно апдейтить документацию, потому что смотрят документацию, а не порядок аргументов функции в исходном коде. > Я ж уже писал про это. Во многих реальных проектах документация на > функции часто бывает устаревшей или вообще отсутствует. Особенно для внутренних функций > модуля, не для API-функций. В идеале, конечно документация всегда должна быть > и должна апдейтиться. Но увы, далеко не всегда так бывает. В Perl принято писать POD. А документацию ради документации конечно, никто не пишет. >> смотрят документацию, а не порядок аргументов функции в исходном коде > Это правда для API-функций популярных библиотек. И почти всегда неправда для внутренних > функций. Ну дали тебе сигнатуры. Твой аргумент устарел лет на 8. > Чтобы далеко за примером не ходить, вот исходник, на который выше ссылку > кидали: > https://github.com/uutils/coreutils/blob/main/src/uu/mktemp/... > В файле определено несколько функций, у скольких из них есть документация? Спойлер: > ни у одной. И чем им поможет в данном случае параметры? Ты высасываешь из пальца аргументы к своему синдрому утёнка. Перловщикам не нужны сигнатуры en masse. Это подтверждается практикой, и я, как перловщик, говорю тебе об этом прямо, face to face. Что нужно для рефакторинга я тебе написал выше. Твои аргументы -- детский сад. Прости, не б обиду, дружище, но реально, это такая мелочь, что я просто не знаю как сказать это так, чтобы тебя не обидеть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #77

76. Сообщение от Аноним (23), 18-Фев-22, 18:57	+/–
Хм, какой-то дурацкий вопрос, содержащий как минимум 3 сомнительных утверждения: 1. В Перле много синтаксического сахара. 2. В Скале много синтаксического сахара. 3. Количество синтасического сахара - главный критерий выбора языка. Перл и Скала относятся к разным языковым классам, их вообще не имеет большого смысла сравнивать. В классе Перла гораздо больше синтаксического сахара у Руби, который ещё и гораздо мощнее. В классе Скалы есть Груви и Котлин. Они может чуть слаще, но Скала однозначно мощнее. Не люблю Перл, потому что он намного хуже в своём классе, чем Питон и особенно Руби. Ну зачем использовать Перл, если есть Руби? Я затрудняюсь найти, в чём Перл лучше Руби. Именно как язык, а не реализация интерпретатора, популярность в рейтингах или там количество вакансий на рынке труда. Люблю Скалу, потому что она самая мощная в своём классе. В классе Ява-подобных языков для Ява-машины. Ну, то есть например Clojure в эту категорию не попадает, ибо не Ява-подобный. В Скале отличное сочетание ООП и ФП. А также привычный синтаксис, ну, кроме использования квадратных скобок. И про companion object я не уверен, что это хорошая идея. Но эти недостатки малы, их запросто можно простить за достоинства Скалы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #83, #84

77. Сообщение от Аноним (23), 18-Фев-22, 19:14	+/–
> Ну дали тебе сигнатуры. Твой аргумент устарел лет на 8. Принимаю, что этот аргумент устарел. Спасибо, что рассказал. Можно было и без такой драмы. Куча остальных аргументов никуда не делись, кстати. >> https://github.com/uutils/coreutils/blob/main/src/uu/mktemp/... > И чем им поможет в данном случае параметры? Тем, что становится понятней, как вызываются функции. > Перловщикам не нужны сигнатуры en masse. А мне нужны. Имею я право покритиковать их отсутствие в реальном коде?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

83. Сообщение от Самокатофил (?), 18-Фев-22, 20:24	+/–
> Хм, какой-то дурацкий вопрос, содержащий как минимум 3 сомнительных утверждения: > 1. В Перле много синтаксического сахара. > 2. В Скале много синтаксического сахара. > 3. Количество синтасического сахара - главный критерий выбора языка. > Перл и Скала относятся к разным языковым классам, их вообще не имеет > большого смысла сравнивать. В классе Перла гораздо больше синтаксического сахара у > Руби, который ещё и гораздо мощнее. Мощщщя! Мощнота! Мощщщность! > В классе Скалы есть Груви > и Котлин. Они может чуть слаще, но Скала однозначно мощнее. Однозначно: мощщщя! Мощнота! Мощщщность! > Не люблю Перл, потому что он намного хуже в своём классе, чем > Питон и особенно Руби. Ну зачем использовать Перл, если есть Руби? > Я затрудняюсь найти, в чём Перл лучше Руби. А зачем руби если есть перл? Ну серьёзно, зачем? Даже переписывать не надо ничего. :-D > Именно как язык, > а не реализация интерпретатора, популярность в рейтингах или там количество вакансий > на рынке труда. Может минимализм? Ну еще мощщщя! мощнота! мощщщность! > Люблю Скалу, потому что она самая мощная в своём классе. Мощщщя! Мощнота! Мощщщность! Чувак, тебе самому не смешно? xD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

84. Сообщение от freehck (ok), 19-Фев-22, 00:50	+/–
> Хм, какой-то дурацкий вопрос, содержащий как минимум 3 сомнительных утверждения: > 1. В Перле много синтаксического сахара. > 2. В Скале много синтаксического сахара. > 3. Количество синтасического сахара - главный критерий выбора языка. Ну, первые два есть, и спорить с этими утверждениями вряд ли вряд ли кто в здравом уме станет. А вот утверждения 3 в данном вопросе не содержится вовсе. Это ты соломенное чучелко сделал, чтобы с ним бороться. =) > Перл и Скала относятся к разным языковым классам, их вообще не имеет большого смысла сравнивать. А я и не сравниваю. Я лишь отметил, что языки очень похожи тем, что засахарены настолько, что аж тошнит. =) Ну и к тому же я решительно протестую против понятия "языкового класса". Сравнивать языки в языковом классе тоже смысла не много. Классы надо нарезать по задачам, которые язык, как инстумент, помогает решать. Причём смотреть не на один лишь синтаксис, а также на стандартные библиотеки, на сообщство, на количество и качество дополнительных пакетов... Потому что если будем смотреть лишь на синтаксис aka выразительную силу языка... Что ж, тогда победили лиспы, а вся история развития языков программирования не имела смысла, можем расходиться. =) > Не люблю Перл, потому что он намного хуже в своём классе, чем Питон и особенно Руби. Я ничего не скажу за руби, я не знаю руби. Но в питоне такое качество стандартных библиотек, что при решении, на чём заскриптовать что-либо между питоном и перлом я безусловно бы отдал голос за перл. Есть конечно прикладные области типа того же ML, где из сишных либ понаделали массу обвязок для питона, и так уж исторически сложилось, что там питон превалирует -- что ж, там лучше использовать питон. > Люблю Скалу, потому что она самая мощная в своём классе. В классе Ява-подобных языков для Ява-машины. О, вот с этим я спорить не буду. Я вполне согласен, что в экосистеме JVM это хороший выбор. Но отдельно отмечу, что в наших далеко не дремучих кругах превалирует мнение, что "Scala -- это такой Perl для функциональщиков". Не я его автор. Но это очень меткое определение. =) > В Скале отличное сочетание ООП и ФП. Ну да, блин, решили проблему ромба, убрав множественное наследование и разрешив подмешивание. А я вот склонен считать, что явное решение проблемы ромба в том же SBCL было куда более разумным шагом. Однако я не хочу об этом спорить. Будем честными: ООП -- это религия. А религия -- она как маяк в море: надо смотреть издалека. Ты же в ней, судя по всему, варишься. И я выражаю тебе по этому поводу сочувствие. > И про companion object я не уверен, что это хорошая идея. Это потому что ты чувствуешь немного Perl-а в данном аспекте вашего ООП. ;) Понимаешь, есть модели ООП, основанные на классах, а есть основанные на прототипах. А это как раз немного прототипов в вашей сугубо классовой модели. =) > Но эти недостатки малы, их запросто можно простить за достоинства Скалы. Для меня Scala имеет существенный недостаток: она для JVM, а я писать под эту платформу не хочу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #86

85. Сообщение от freehck (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ообщить модератору
Родитель: #71

86. Сообщение от Аноним (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ообщить модератору
Родитель: #84 Ответы: #87

87. Сообщение от freehck (ok), 19-Фев-22, 02:52	+/–
Хорошо. Не будем играть в психологов. Я тебе прямо и без намёков всё скажу. Как показала наша беседа, ты не воспринимаешь ни сарказма, ни шуток, даже лёгкие подъёбки воспринимаешь в штыки. Я хз, как ты вообще живёшь в таком состоянии. Я понимаю, что обосрать что-либо -- естественное желание в данном случае, и поэтому ты выбрал Perl. Ну что ж, хорошо, Бога ради. Перл говно. Ты победил. Но серьёзно, парень, у меня -- просто перл говно, а вот у тебя -- есть проблемы, с которыми тебе придётся разобраться. Я тут не помощник, ты ж меня не послушаешь. Но имей в виду, что они есть. Просто чтобы ты помнил об этом тезисе, когда получишь второе подтверждающее мнение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #88

88. Сообщение от Аноним (23), 19-Фев-22, 04:14	+/–
> Хорошо. Не будем играть в психологов. ...И продолжил играть в психолога. Я тебе ещё одну вещь расскажу, надеюсь опять будет полезно, как с флэтмэпом и монадами. Люди любят придумывать истории про других людей. Особенно, про тех людей, которые с ними не согласны. Каждый человек думает, что он прав. А если кто-то с ним не согласен - то тот другой конечно же неправ. Но как же так, почему тот другой выбирает быть неправым, очевидно же, что он не прав? Нормальный же человек выберет то же мнение что и я, потому что оно, очевидно, правильное, и будет прав! Значит с ним что-то не так. И вот человек начинает придумывать историю про другого человека, что с тем другим не так. Наверное он тупой. Или ему злость глаза затмила, сам не понимает, что говорит. Или его в детстве обидели и он озлобился вообше навсегда. Или он из такой-то социальной группы, а они там все неправы и вообще маргиналы. Или ещё что-то. Вот и придумана история про того другого. И нарисована картина. Я прав и на белом коне, а тот другой - неправ и этому найдена удобная причина. Естественно, такая выдуманная история про другого человека - полная чушь, основанная на догадках или вообще на придумках. Но она подогревают самолюбие. Такая вот защитная психологическая функция. Я раньше тоже придумывал истории про тех, кто со мной не согласен. А потом мне кто-то рассказал про такое вот придумывание историй. И я понял, что это бессмысленное занятие. И перестал это делать. Теперь я просто позволяю другому человеку иметь собственное мнение. И мне пофиг, почему он неправ. Я не придумываю этому обоснование. Стало как-то легче что ли. И тебе советую поступить так же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #89

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

90. Сообщение от Аноним (23), 19-Фев-22, 20:58	+/–
Ты что, не понял ничего? Ты же про меня только что историю придумал. Про себя подумай, а не про меня, психоаналитик форумный. Открытым текстом рекомендую тебе: перестань эти истории придумывать. Это бессмыссленное занятие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #91

91. Сообщение от freehck (ok), 20-Фев-22, 10:23	+/–
Хорошо-хорошо, перестану.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

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

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