Революционные возможности? Не сказал бы. Декораторы и контексты для асихронных задач давно есть в питоне, do-выражения были бы не нужны, если бы язык был больше ориентирован на выражения (а современные языки: Kotlin, Scala, Rust такими и делают), да и паттерн-матчингом уже никого не удивишь.
в таком случае, я не совсем понимаю, какой способ моделирования процессов вы предлагаете использовать вместо ООП и что конкретно предлагаете понимать под "ООП"
Этот процесс отлично выражается в функциональном стиле:
СделатьКолёса Ковш ＝Направить Рабочий Ковш ＞＞= Отлить Форма ＞＞= Ковать ЦехКовки＞＞＝Шлифовать ЦехШлифовки
Аргументируют использование 2.7 тем, что иметь 2 различных версии питона на машине неудобно, но используют виртуальные окружения. Двоемыслие какое-то...
Замерил время на возведение в квадрат 100К целых чисел. В среднем, получились такие результаты: Coconut — 87 мс, циклы — 79 мс, генератор списка — 78 мс. Так что язык, скорее всего, немного медленнее питона.
Ну да, Coconut компилируется в предположении, что на машине, где его будут запускать, есть только чистый Python. Поэтому в выходном файле оказывается довольно много функций и классов, которые лежат мёртвым кодом. С другой стороны, рантайм питона 3.6 весит 100+ МБ, так что лишних 25К на проект вряд ли кого-то будет волновать)
На самом деле, писать про использование математических пакетов в Coconut нечего, потому что используются они точно так же, как в питоне. То есть, можно написать вот так:
from operator import attrgetter
import numpy as np
x_train = protocol |> map$(np.reshape$(?, 1, w, h, 3) .. preprocess .. np.load .. attrgetter('filename')) |> list |> np.vstack
и получится рабочий код, который вы можете запустить из интерпретатора или компилировать в питоновский код, эквивалентный вашему примеру (если я правильно его распарсил, конечно). Единственная проблема, которую я тут заметил — нельзя пайпы переносить по строкам без \, но это мелочи и поправимо.
Согласен, нет таких проблем, для решения которых было бы необходимо функциональное программирование. Просто некоторые задачи при функциональном подходе решаются более элегантно, что ли. Например, данные при анализе часто приходится прогонять через несколько функций, и генераторы списков не выглядят красивым решением. Да и if/else и словари — не такие гибкие и удобные инструменты, как паттерн-матчинг.
О каких данных речь? Сняли бы галку "доступ ограничен", и посмотрели, что он будет рекламировать
Теперь стало чуть понятнее. Однако, всё ещё не понятно, чего не хватает в Hive для решения ваших задач
О чём статья? Какую проблему решали? Что такое Hive?
Революционные возможности? Не сказал бы. Декораторы и контексты для асихронных задач давно есть в питоне, do-выражения были бы не нужны, если бы язык был больше ориентирован на выражения (а современные языки: Kotlin, Scala, Rust такими и делают), да и паттерн-матчингом уже никого не удивишь.
в условном хаскеле будет примерно так:
car = mkCar "name" 100
turbo = mkTurbo 50
add car turbo
слово return тут не нужно, результатом вычисления будет равен результатом вычисления последней строки, забыть не получится
в таком случае, я не совсем понимаю, какой способ моделирования процессов вы предлагаете использовать вместо ООП и что конкретно предлагаете понимать под "ООП"
Этот процесс отлично выражается в функциональном стиле:
СделатьКолёса Ковш ＝Направить Рабочий Ковш ＞＞= Отлить Форма ＞＞= Ковать ЦехКовки＞＞＝Шлифовать ЦехШлифовки
Аргументируют использование 2.7 тем, что иметь 2 различных версии питона на машине неудобно, но используют виртуальные окружения. Двоемыслие какое-то...
а в консоль что-нибудь пишет?
Проверил — может. Правда, не очень быстро (около 20с на моей машине). С другой стороны, зачем нужно показывать одновременно 100К столбцов?
Кажется, автор путает понятия HTTP и URL. Да и обработку исключений использует не по назначению.
Прогнал тест с питоновским map'ом — получил те же 87 мс, так что проблема не в Coconut)
Замерил время на возведение в квадрат 100К целых чисел. В среднем, получились такие результаты: Coconut — 87 мс, циклы — 79 мс, генератор списка — 78 мс. Так что язык, скорее всего, немного медленнее питона.
Ну да, Coconut компилируется в предположении, что на машине, где его будут запускать, есть только чистый Python. Поэтому в выходном файле оказывается довольно много функций и классов, которые лежат мёртвым кодом. С другой стороны, рантайм питона 3.6 весит 100+ МБ, так что лишних 25К на проект вряд ли кого-то будет волновать)
На самом деле, писать про использование математических пакетов в Coconut нечего, потому что используются они точно так же, как в питоне. То есть, можно написать вот так:
и получится рабочий код, который вы можете запустить из интерпретатора или компилировать в питоновский код, эквивалентный вашему примеру (если я правильно его распарсил, конечно). Единственная проблема, которую я тут заметил — нельзя пайпы переносить по строкам без \, но это мелочи и поправимо.
Согласен, нет таких проблем, для решения которых было бы необходимо функциональное программирование. Просто некоторые задачи при функциональном подходе решаются более элегантно, что ли. Например, данные при анализе часто приходится прогонять через несколько функций, и генераторы списков не выглядят красивым решением. Да и if/else и словари — не такие гибкие и удобные инструменты, как паттерн-матчинг.