Но зато не будет лишнего копирования! Да и распаковки не будет, если локальная переменная имеет ссылочный тип (насколько я понимаю, такое теперь тоже должно стать возможным).
И снова вы пытаетесь высказывать какие-то, простите, маргинальные идеи: «функционального прошлого», «мучится со скобками». Риторический вопрос: а зачем мучиться с C-подобными фигурными скобками и стилем оформления, унаследованным от императивного прошлого?
Если конструктивно, то я пытаюсь сказать, что вы почему-то решили, что кому-то из пишуших на лиспе это не нравится, и они вынуждены превозмогать сложности ужасного функционального прошлого, чтоб написать что-то полезное и работающее.
Так вот, это неверно. CL — вполне современный язык программирования, а функциональное прошлое (я, честно говоря, не понимаю, где вы его в посте и примерах увидели, потому как CL — это императивный по большей части язык) — это скорее плюс, и я бы даже предпочёл побольше функциональных возможностей как в стандартной библиотеке CL, так и в языках, на которых я пишу каждый день.
Ну и, да, программисты на CL пишут на лиспе именно потому, что он им нравится. Нет тут никаких «мучений» и «изменения стиля программирования на околофункциональный».
Если под «прототипным программированием» вы имеете в виду модель ООП наподобие той, которая используется в JS — то нет, CLOS такое не поддерживает напрямую (конечно же, можно что-то эдакое кастомное изобрести, но мне не видится практического смысла в подобных экзерсисах).
Полиморфизм и наследование делается напрямую с использованием соответствующих возможностей CLOS. Вот, гляньте хотя бы статью на Википедии — может, часть вопросов у вас отпадёт.
Да, объектно-ориентированный код на CL не отличается радикально (на мой взгляд) от других языков, поддерживаемых множественное наследование — например, от Clojure или Scala. Но никаких сложностей с реализацией, например, двойной диспетчеризации вы не испытаете — а в то же время в мейнстримных компилируемых языках это целая проблема.
А почему вы называете Common Lisp функциональным языком? Мне вот это не кажется верным — скорее уж Scheme с более функциональным уклоном, а CL как раз с более императивным.
Помимо прочего, «стандартная» ООП-система без множественного наследования не очень хорошо позволяет описывать сущности во многих играх, и поэтому в частности OpenRA использует систему из паттерна «поведение» и композиции этих «поведений» в игровых объектах. На функциональном языке это также прекрасно можно смоделировать без какого-либо онтологического кризиса.
Пожалуйста, пишите ещё статьи про Пролог. Язык этот очень интересный (и нестандартный для программиста, который в работе чаще сталкивается с мейнстримными языками), и с этим связано неоднозначное отношение сообщества к вашим публикациям (и — особенно — комментариям).
Или это программа на каком-то очень хитром языке типа whitespace или malbolge (которую некто решил замаскировать под код на… Swift, если не ошибаюсь?), а подсветка на самом деле указывает на его настоящую семантику.
Простите за небольшой оффтоп, но на Windows рекомендую PSReadline (есть в репозиториях PSGet и Chocolatey) для автодополнения и ConEmu для эмуляции терминала.
И для операционных систем есть кое-какие наработки: Pash, приглашаю всех желающих и заинтересованных постить баги и фичреквесты :)
(может, и под Reactos наши наработки пригодятся, т.к. обычный PowerShell напрочь весь с закрытыми исходниками, и M$ его просто так раздавать под сторонние ОС не будет)
Хотели ли они блокировать отдельные страницы? Из-за HSTS ли оно «не сработало»? Вообще, «они» — это кто? Сертификат на домене подменял мой провайдер; сертификат блокировался браузером даже не из-за HSTS, а из-за того, что тупо выписан на домены провайдера, а не на ru.wikipedia.org.
К сожалению, ни слова о том, что будет какое-то исправление или ручная редактура этих сломанных статей :(
Если конструктивно, то я пытаюсь сказать, что вы почему-то решили, что кому-то из пишуших на лиспе это не нравится, и они вынуждены превозмогать сложности ужасного функционального прошлого, чтоб написать что-то полезное и работающее.
Так вот, это неверно. CL — вполне современный язык программирования, а функциональное прошлое (я, честно говоря, не понимаю, где вы его в посте и примерах увидели, потому как CL — это императивный по большей части язык) — это скорее плюс, и я бы даже предпочёл побольше функциональных возможностей как в стандартной библиотеке CL, так и в языках, на которых я пишу каждый день.
Ну и, да, программисты на CL пишут на лиспе именно потому, что он им нравится. Нет тут никаких «мучений» и «изменения стиля программирования на околофункциональный».
Полиморфизм и наследование делается напрямую с использованием соответствующих возможностей CLOS. Вот, гляньте хотя бы статью на Википедии — может, часть вопросов у вас отпадёт.
Да, объектно-ориентированный код на CL не отличается радикально (на мой взгляд) от других языков, поддерживаемых множественное наследование — например, от Clojure или Scala. Но никаких сложностей с реализацией, например, двойной диспетчеризации вы не испытаете — а в то же время в мейнстримных компилируемых языках это целая проблема.
Помимо прочего, «стандартная» ООП-система без множественного наследования не очень хорошо позволяет описывать сущности во многих играх, и поэтому в частности OpenRA использует систему из паттерна «поведение» и композиции этих «поведений» в игровых объектах. На функциональном языке это также прекрасно можно смоделировать без какого-либо онтологического кризиса.
Пишите ещё, многим такие вещи очень интересны!
И для операционных систем есть кое-какие наработки: Pash, приглашаю всех желающих и заинтересованных постить баги и фичреквесты :)
(может, и под Reactos наши наработки пригодятся, т.к. обычный PowerShell напрочь весь с закрытыми исходниками, и M$ его просто так раздавать под сторонние ОС не будет)