Обновить
59

Пользователь

22
Подписчики
Отправить сообщение
Как-то давно, узнав о такой возможности, написал вычисления определителя матрицы в compile-time.

Кстати, интересно, что МП на шаблонах в Си++ — чистый функциональный язык.
А в HTML писать умеет?
Вообще, конечно, многопоточность unicode и вывод в несколько получателей логов для библиотеки логгирования звучит как «поддерживается сложение, умножение и вычисление определителя матриц» для математической библиотеки.
Отучился 5.5 курсов в той же Бауманке. Не получил ничего, чего не мог бы получить один и дома. Собственно, несоразмерно большая часть моих знаний получена мной не там, даже та, которая касалась самого обучения. Наоборот, лишняя трата времени, так как частенько приходилось жопу просиживать на младших курсах, а не обучаться.
Всё потому, что LINQ — монада :)
Кстати, если немного усложнить пример:
test2 = do
    x <- response "hello"
    io $ putStrLn x
    y <- response x
    z <- response (++ show (:: Int))
    io $ putStrLn $ "select from DB: " ++ show y ++ show (:: Int)
    t <- io $ selectSmthFromDB y z
    io $ writeFile "tmp" t
Спасибо большое за обширный ответ, попробую внести правки, чтобы всё это было проще понять. Без свежего взгляда сложно понять, что именно может вызвать трудности в понимании.
Если хочется жечь, берите Spartan 1W. Демонстрация лазера и дифракционных решёток.
Прошу прощения.
Все проще, в си объявления сделаны подобными использованию, т.е.:
long **foo[7];
Должно использоваться как
**foo[n] и будет иметь тип long.
Т.е. указали индекс, два раза разыменовали, получили long.

Аналогично становится легко понять
void (*foo)(int (*bar)(int), float);
(*foo)(&bar, 10.f)
Ум — инструмент, им тоже надо уметь пользоваться. Сам допустил, сам и расхлёбывает.
Известно же, что
Объекты — замыкания для бедных

и
Замыкания — объекты для бедных
Мне, например, частично помогает разбиение на очень мелкие подзадачи. Потому что когда впереди 100км рутины, становится жутко лень и неинтересно; а когда 100 мини-задач, то как-то проще заставить сделать одну две в перерывах между тем, что интересно. А там смотришь — уже на 10 задач ближе к цели.
Haskell
Начав пользоваться легковесными потоками уже не могу от этого отказаться. Это жутко удобно.
Си++ код тоже можно записать так же компактно, без иерархии и десятка наследуемых друг от друга классов.
Не понял толком отличия forwarder'а и прочих, поэтому повторил как понял.
Опять же неясно, зачем нужны forwarder'ы, если основная идея в цепочности.
У меня при возврате Just v сообщение идёт дальше по цепочке, при возврате Nothing цепочка прерывается. А route нужен, чтобы ответвить сообщение в другую цепочку.

module Event (
    ) where

import Prelude hiding (id, (.))
import Control.Category

data Node a b = Node (a -> IO (Maybe b))

instance Category Node where
    id = Node $ return . Just
    (Node g) . (Node f) = Node $ \v -> do
        f v >>= maybe (return Nothing) g

endnode :: (a -> IO ()) -> Node a ()
node :: (a -> IO ()) -> Node a a
run :: Node a b -> a -> IO (Maybe b)
run_ :: Node a b -> a -> IO ()

endnode f = Node $ \v -> f v >> return Nothing
node f = Node $ \v -> f v >> return (Just v)
run (Node f) v = f v
run_ (Node f) v = f v >> return ()

server = endnode putStrLn
route to = node $ run_ to
forward to = node $ run_ to
network to = node $ run_ to

test = run test' "correct" where
    logmsg = node $ \s -> putStrLn ("log: " ++ s)
    test' = logmsg >>> test'' >>> server
    test'' = route (network fw2) where
        fw2 = forward fw1
        fw1 = forward serv
        serv = server
Haskell:
check = any isDigit
Единое название куче сущностей «орк» вы дали сами. Интуитивность при разработке крайне редко приводит к хорошим решениям. Именно поэтому с ООП столько проблем (все хотят объект «мошына»), а не с самим подходом.
> Все имхо разумеется, просто надоело вправлять ООПухоли мозга
Мне лично нравится ФП. То, где нет наследования и сопутствующих проблем.
Скажем, объект «орк» должен наследоваться от следующих классов:

Зачем? Более разумных способов нету, чем пихать всё и вся в один объект?
Огромное скажу. Я теперь без REPL нормального программирования не представляю.
У Haskell на удивление простой и удобный интероп с C, так что реальной проблемой при достаточно серьёзном проекте эти требования стать вряд ли смогут. В данной конкретной задаче можно было вызывать сишную функцию, передавая raw pointer на данные картинки и название.
Хотя, конечно, отсутствие библиотеки из коробки не есть хорошо.
В оправдание можно лишь сказать, что библиотек-то на самом деле много на почти все случаи жизни.
generateCode и его напарник параметров не принимает, в чём смысл городить интерфейсы?

Код ниже туп, прост, при этом легко изменяется. Понадобятся параметры, сделаем tuple<...> makejava(int param) { return make_tuple(...); }. Затем можно и интерфейс выделить.

java = make_tuple("Java...", "http...");
php = make_tuple("PHP...", "http...");

void gen(tuple<std::string, std::string> const & lang)
{
// ...
}

int main()
{
gen(java);
}

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность