Почему Kotlin достоен внимания и чем он интересен.

https://medium.com/@octskyward/why-kotlin-is-my-next-programming-language-c25c001e26e3

Kotlin язык практический и прагматичный, не академический, выросший из потребностей индустрии разработки на JVM и компании JetBrains, накопившей в этой индустрии огромную экспертизу.

Kotlin comes from industry, not academia. It solves problems faced by working programmers today.

Now there is Kotlin, and with it the last traditional pain associated with the Java ecosystem is gone. You can write code that’s more expressive and more concise than even a scripting language, but with way fewer bugs and with way better performance.

https://try.kotlinlang.org

http://kotlinlang.org/docs/resources.html

http://blog.paralleluniverse.co/2015/06/04/quasar-kotlin/

Как неверный выбор технологий для задачи приводит к значительным финансовым потерям.

О некорректной реализации библиотечных функций в языках программирования для работы с генераторами случайных чисел и к чему приводит слабая система типов языков и слабая проверка типов данных в динамических языках в разработках для финансовой индустрии и криптовалют.

https://medium.com/@octskyward/type-safety-and-rngs-40e3ec71ab3a

Крис Лэттнер покинул подразделение Tesla Autopilot Software.

В своём аккаунте в Твиттер Крис пишет, что работа ему не зашла по интересам. 😁😂

https://twitter.com/clattner_llvm/status/877341760812232704

http://nondot.org/sabre/Resume.html

Для ОС Redox, написанной на языке Rust, удалось произвести bootstrapping - скомпилировать всю ОС и ядро под самой ОС Redox.

Для этого под ОС были портированы компиляторы GCC toolchain и LLVM Compiler Toolchain, для портирования компилятора языка Rust - rustc.

https://www.redox-os.org/news/gsoc-self-hosting-1/

Разработчики компилятора OCaml Compiler Toolchain при оптимизации циклов в генерируемом компилятором коде программ на практике нашли баги при исполнении процессорами Intel блоков инструкций в коротких циклах в многопоточном режиме Hyper-Threading. Проблема касается процессоров Intel последних поколений, Skylake и KabyLake.
Обновления микрокода для некоторых моделей процессоров уже готовы для дистрибутива Debian.

https://lists.debian.org/debian-devel/2017/06/msg00308.html

http://www.opennet.ru/opennews/art.shtml?num=46762

Линус Торвальдс и Дирк Хоундл (VP, VMWare) - беседа на открытии первой ежегодной конференции LC3 China (LinuxCon + ContainerCon + CloudOpen) в Пекине.

https://www.youtube.com/watch?v=0rsx65_wjoE

https://www.lfasiallc.com/linuxcon-containercon-cloudopen-china

https://www.linuxfoundation.org/announcements/linuxcon-containercon-cloudopen-comes-to-china-for-first-time-2017

https://www.linux.com/blog/event/LC3-China/2017/linux-foundation-brings-3-new-open-source-events-china

Состоялся релиз языка и компилятора Crystal 0.23.0.

Появилась поддержка CSP многопоточности (как в Go, но со вкусом Ruby 😉) на базе сопрограмм, каналов и тред-пулов для маппинга программных потоков (нитей, fibers, green threads) на системные потоки в thread-pool'е процесса программы.
Для сборки компилятора требуется LLVM 3.8.

https://github.com/crystal-lang/crystal/releases/tag/0.23.0

Иерархическая классификация типизированного лямбда-исчисления, на базе лямбда куба Барендрегта, и его поддержка в языках функционального программирования:
https://gist.github.com/andrcmdr/7121c3d9eb83f06785d8055a5c3604a3


PS:
В январе-феврале этого года я прошёл курс Ерика Мейера по Haskell на EDX:
https://www.edx.org/course/introduction-functional-programming-delftx-fp101x-0

А после прослушал дополнительно курс практических лекций по Haskell:
https://www.youtube.com/watch?v=02_H3LjqMr8

https://www.youtube.com/playlist?list=PLwwk4BHih4fj2fxUuHEfvwNN84LALr5R3

Всем, кто интересуется и изучает концепции функционального программирования - очень рекомендую! 👍

Дискуссия с Крисом Лэттнером по дальнейшему развитию языка Swift на конференции WWDC 2017.

https://youtu.be/4qX1o-4W0HM

https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/

Видеозапись дискуссии можно также найти здесь:
https://news.realm.io/news/wwdc-2017-swift-panel/

Языку Swift и его компилятору сейчас действительно не хватает безопасной и внятной модели работы с потоками и их памятью, для удобного создания многопоточных приложений, т.к. на уровне языка нет поддержки работы с потоками (на базе сопрограмм или акторов) и асинхронным неблокирующим вводом-выводом (futures and promises, async/await, event-based async). Есть только фреймворк Grand Central Dispatch (GCD), который использует thread-pool pattern и мьютексную блокировку доступа к памяти потоков для управления критическими секциями. При использовании GCD код превращается в бесконечную пирамиду вызовов ("handler pyramid of doom", "call-back/closures hell").
Таким образом Swift не обеспечивает thread safety и код использует общую память для потоков (критические секции, shared mutable memory, shared mutable state), а без обеспечения thread safety про Server API (https://swift.org/server-apis/) и применение Swift в разработке ПО для серверных облачных инфраструктур можно забыть.

Ксавьер Лерой, разработчик группы проекта Gallium из института INRIA в Париже, во Франции, один из авторов языка OCaml и основных разработчиков его компилятора и виртуальной машины, рассказал подробности об обнаруженном им баге в процессорах Intel, при отладке оптимизации циклов компилятором OCaml для исполнения генерируемого компилятором кода в многопоточном режиме Hyper-Threading на архитектурах процессоров Intel последних поколений (Skylake и KabyLake).

http://gallium.inria.fr/blog/intel-skylake-bug

http://ocamllabs.io/general/2017/06/26/IntelHyperThreadBug.html

Перевод на русский язык:
https://habrahabr.ru/post/332552/

Oracle создали открытый run-time для контейнеризации в Linux на Rust - проект RailCar.

Проект RailCar создаётся на Rust на базе спецификации OCI (Open Container Initiative Runtime Specification, https://www.opencontainers.org) и претендует на положение серьёзной альтернативы и конкурента Docker, другой реализации спецификации OCI на Golang, от очень серьёзного поставщика облачных систем и решений - Oracle.


https://blogs.oracle.com/developers/building-a-container-runtime-in-rust

https://blogs.oracle.com/developers/three-new-open-source-container-utilities

https://thenewstack.io/oracle-opens-oci-container-runtime


https://github.com/oracle/railcar - run-time для управления контейнерами

https://github.com/oracle/crashcart - инструмент для отладки контейнеров с возможностями загрузки (sideload) в контейнер сторонних образов с исполняемыми файлами

https://github.com/oracle/smith - сборщик образов контейнеров на базе образов OCI или RPM пакетов


https://github.com/opencontainers/runtime-spec - спецификация OCI run-time

https://github.com/opencontainers/image-spec - спецификация образов OCI

https://github.com/opencontainers/runc - реализация OCI, базовый run-time для порождения процессов контейнеров


Причины создания RailCar и почему Go не так хорош для создания run-time для систем конейнеризации:

https://blogs.oracle.com/developers/the-microcontainer-manifesto

https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix


Links:
https://t.me/technologique/971

OOP versus FP - почему противопоставление парадигм программирования является некорректным.

Аргументы FP.

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

http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

Одна из тех статей к которой всегда интересно вернуться, перечитать её и переосмыслить ещё раз:
http://blogerator.org/page/oop_why-objects-have-failed

Плюс более прагматичный практический взгляд на данный вопрос в статье на русском языке:
http://eax.me/adt-and-traits/

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

Вот по большому счету и все, что нужно знать об АТД и классах типов. Если вы загляните на Hackage, то обнаружите, что с их помощью на практике можно реализовать что угодно. А зачем нам дополнительная сложность? Фактически, мы можем избавиться от иерархии классов (интерфейсы не считаются). В этом случае нам не нужно никакой там ковариации и контрвариации, восходящего и нисходящего преобразования, абстрактных классов, protected методов и так далее (за редкими исключениями, в основном связанными с наследием Java, см. определение MyMaybe выше). В общем, все плоско, как в... Go! Плоские абстракции only - плоское лучше чем вложенное (из манифеста Python).

Недаром в современных языках программирования, взять хотя бы Rust и Go, нет никакого наследования. Потому что наследование это полиморфизм подтипов и он не нужен, потому что сам по себе решается композицией типов! 😆😂👍

А теперь попробуйте угадать, что мы получим, если оставить в ООП только инкапсуляцию и полиморфизм.

Останутся интерфейсы/трейты/тайпклассы (классы типов), что в принципе одно и то же по концепциям, но называется по разному, их имплементации/имплементоры и параметризованные типы (generics, параметрический импредикативный полиморфизм) - это то же самое модульное структурное программирование! Никаких классов и наследования! Ещё в Модула-2 были модули с интерфейсами и их имплементациями. Потом эти же концепции перекочевали в Оберон, а далее в Go и Rust.
Нужны только интерфейсы, структуры, перечисления, как в Go, Rust и Виртовских языках. Через нетипизированные интерфейсы в Go можно реализовать поведение параметризованных типов, тех самых дженериков, которых якобы в Go нет.

А вообще хорошо, что сейчас постепенно приходит прозрение и осознание у многих профессиональных умудрённых опытом программистов, что наследование и классы, специальный ad-hoc полиморфизм включения (полиморфизм подтипов - однако, сколько же терминов в русской литературе обозначающих одно понятие!), всё то, что составляет парадигму ООП, оно уже не нужно - эти концепции себя давно изжили и само дальнейшее развитие технологий и концепций программирования уже идёт дальше, постепенно смещаясь в сторону парадигмы функционального программирования алгебраических типов данных, классов типов, полиморфизма высших порядков, лямбда исчисления и теории категорий.

Мне понравилось как этот процесс смещения акцентов в программировании объяснил Саймон Пейтон Джонс, большой спец по Haskell и автор его основного компилятора GHC:
https://youtu.be/iSmkqocn0oQ


Контраргументы OOP.

Сегодня на конференции услышал мнение одного из разработчиков, программиста с многолетним опытом на Haskell (но в компании он пишет на Rust и OCaml), что лингвистическим дизайнерам ФП языков приходится в них встраивать инкапуляцию из ООП (для type class'ов, функций и данных в OCaml и Haskell например) как дополнительный инструмент структурирования программ и проектов, потому что ФП парадигма в чистом виде (основанная на видах типизированного лямбда-исчисления) не имеет достаточных средств для структурирования очень крупных проектов (кроме функций различных порядков) и не позволяет этого делать, хотя в OCaml и Haskell помимо type class'ов, есть функторы (функции как объекты), монады (эндофункторы, для последовательного стуктурирования кода программ, например ST монада в Haskell для придания коду императивного вида и поведения) и конечно модули, но они опять же были привнесены в языки из структурного имеративного программирования, для структурирования очень крупных проектов.

Я решил проверить эту мысль и провести небольшое практическое исследование - отыскать очень крупные проекты на функциональных языках по объёму кода в количестве SLoC и посмотреть на используемые в этих проектах средства структурирования, используя https://openhub.net (бывший https://ohloh.net) - и по результатам исследования был несколько удивлён тому факту, что все проекты c кодовой базой более 1M SLoC использующие ФП языки (в основном OCaml, Haskell и Erlang) прибегают к императивным средствам структурирования программ.

Мартин Одерски об этом говорил в одном интервью на YouTube в котором он рассказывал об истоках Scala. Он рассматривал ООП для Scala как раз как средство модульности и средство структурного программирования для ФП, да и вообще Мартин в целом рассматривает объекты как модули, но более локального действия, в пределах обычных модулей/пакетов.

Все забыли, что ООП было создано для улучшения структурного программирования и привнесения в него большей модульности, компонентного подхода к проектированию программ, очень крупных проектов.
Были забыты и извращены идеи и концепции положенные в основу ООП и изначально возникшие в языках Simula, Smalltalk, Self - эти идеи были прекрасны!
Сейчас они живы в языках Objective-C и Ruby - это самые близкие к концепциям Smalltalk языки - и отчасти в Python и Swift.

ООП концепции которые были в версии Xerox Smalltalk изначально, бывшие инженеры Apple, выкупив их ранее у Xerox и будучи уже в команде Стива Джобса в Next, привнесли в Си и создали Objective-C, объектный Си, для разработки ОС NextStep, системных библиотек и графического интерфейса.

В Ruby Matz сам говорил что многое взял из Smalltalk - гомоиконность системы типов, интроспекцию типов, run-time рефлексивность языка и его системы типов.

Поэтому в Ruby и Objective-C очень сильно ощущается наследие Smalltalk.

Интересная видео лекция об истоках чистого ООП, языках Smalltalk и Objective-C:
https://youtu.be/mdhl0iiv478

Алана Кэя, автора Smalltalk, также всегда интересно послушать:

https://youtu.be/NdSD07U5uBs

https://youtu.be/KVUGkuUj28o

https://youtu.be/M6ZHxUwqPVw

На пути к Go 2.0 - Расс Кокс о дальнейшей эволюции Golang на конференции GopherCon 2017

https://blog.golang.org/toward-go2

На русском:
https://habrahabr.ru/post/333346/

Грядущие изменения в Go 1.9:
https://beta.golang.org/doc/go1.9


#Go
#Golang

Интересное обсуждение у нас возникло сегодня по теории компиляции, автоматному программированию, системам типов и применению типизированного лямбда исчисления для систем типов и строгого контроля типов, для статического анализа программ (и side-effect'ов в частности), математического доказательства безопасности систем типов, безопасности программ и их завершённости.
Язык OCaml уже давно доказал свою эффективность в этой области computer science и практическую применимость для создания компиляторов, статических анализаторов кода, парсеров, а также для создания системного программного обеспечения в целом (проекты Unikernel, MirageOS и ClickOS, которые ныне являются частью компании Docker и на базе которых создаются проекты Moby и Linux Kit [1] ).

По этом поводу и теме есть замечательная книга - Real World OCaml.

https://realworldocaml.org/v1/en/html/index.html

Часть вторая - parsing, tooling:
https://realworldocaml.org/v1/en/html/pt02.html

Часть третья - теория компиляции и автоматное программирование:
https://realworldocaml.org/v1/en/html/pt03.html

https://realworldocaml.org/v1/en/html/the-compiler-frontend-parsing-and-type-checking.html

https://realworldocaml.org/v1/en/html/the-compiler-backend-byte-code-and-native-code.html

Есть также книга Ксавье Лероя, автора OCaml - Unix system programming in OCaml:
http://ocaml.github.io/ocamlunix/

http://ocaml.github.io/ocamlunix/ocamlunix.pdf

https://github.com/xavierleroy

И ещё пара книг Ксавье Лероя, правда на французском:
http://caml.inria.fr/pub/distrib/books/manuel-cl.pdf

http://caml.inria.fr/pub/distrib/books/llc.pdf


Links:
[1] - https://t.me/technologique/960

Второй трейлер киберпанк триллера "Blade Runner 2049".

https://www.youtube.com/watch?v=dZOaI_Fn5o4

Трейлер о процессе съёмок фильма, с мнением актёров и съёмочной группы:
https://www.youtube.com/watch?v=BBsjZgu7T2U

Продолжение спустя 35 лет обещает быть очень интересным! 👍

Выпуск "Синего Фила" с Дмитрием Пучковым про фильм Blade Runner (1982) с весьма грубоким анализом сценария от Клима Жукова:
https://www.youtube.com/watch?v=BCgcPZHiZms&t=7m56s

О некоторых моментах фильма я даже не догадывался, он также полон библейских мотивов, как и другие фильмы Ридли Скотта, например "Прометей" и "Чужой: Завет", и даже имеет с ними общую киновселенную!
https://www.youtube.com/watch?v=BN5jZLf1AaM


#киберпанк
#cyberpunk

Шикарный спич на недавней конференции C++Now 2017, прошедшей в мае, от Нико Матсакиса, одного из основных разработчиков Rust!

Нико очень простым языком на примерах объясняет весьма сложные концепции, например как устроена идиома контроля заимствований и владений (borrow and ownership checker), которая является гарантом безопасности сегментов памяти и защищает критические секции памяти от записи в них при совместном доступе к ним нескольких исполняемых потоков в многопоточном режиме.

https://www.youtube.com/watch?v=lO1z-7cuRYI

Оказывается, Нико также как и я в школе в своё время сильно улекался C++, очень ждал в качестве подарка (правда я на день рождения) тот самый справочник Герберта Шилтда по C++ и зачитывался им! Ностальгические воспоминания, such same feelings! 😄👍

https://www.youtube.com/watch?v=lO1z-7cuRYI&t=1m9s

https://t.me/technologique/104

Тот самый справочник, до сих пор со мной, спустя 14 лет! 😄😭😂👍

О возможностях безопасного автоматического управления памятью в Rust.

В Rust используется механизм подсчёта ссылок (ARC), доступный в LLVM, но проблему thread safety, критических секций и сильных/слабых указателей решили применением заимствования доступа к сегментам памяти и дополнительным механизмом проверки владений и заимствований - borrow & ownership checker, который проверяет все strong и weak references на соответствие и наличие циклических указателей (в RC механизме интерпретатора Python тоже есть подобный механизм).
И этот механизм - основная идиома безопасности памяти в Rust.
Помимо этого есть автоматические scope-based деструкторы - механизм RAII, который также есть в Vala, Genie и D; raw memory management через unsafe блоки; region based memory management, которое редко используется, чаще в unsafe режиме доступа к памяти; cам ARC механизм; но также есть и потенциальная возможность применения GC в Rust, например того же Boehm GC или иного, язык эту возможность не ограничивает, но возникает вопрос, зачем он нужен если даёт дополнительный run-time overhead и есть более эффективные механизмы проверок для безопасного автоматического управления памятью, позволяющие вообще исключить применение GC и связанные с его применением STW latency потоков, и иметь в run-time только саму программу в чистом виде, которая сама по себе самостоятельно и безопасно утилизирует память с минимальными накладными расходами на автоматическое управление памятью.

https://www.youtube.com/watch?v=qDzZjFHFoZk

https://ts.data61.csiro.au/Events/summer/16/lin.pdf

http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rust-ismm-2016.pdf

https://aturon.github.io/blog/2015/08/27/epoch/

https://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/

https://manishearth.github.io/blog/2016/08/18/gc-support-in-rust-api-design/

https://github.com/Manishearth/rust-gc

https://crates.io/crates/gc

https://docs.rs/gc/0.3.0/gc/

Tammy Butow на GopherCon 2017 - о крупномасштабном внедрении и использовании Golang в DropBox.

https://about.sourcegraph.com/go/go-reliability-and-durability-at-dropbox-tammy-butow

https://gophercon.com/speakers/14


Постепенно оправдывается всё то, о чём ещё в 2012 году писал Роб Пайк и для чего Go был задуман - для разработки крупномасшабных масштабируемых сервисно-ориентированных облачных инфраструктур.

https://talks.golang.org/2012/splash.article


Links:
https://t.me/technologique/1008
https://t.me/technologique/841