Rust атакует.

[ilovb]

2 valexey
А наличие оператора << и его перегрузка - это значить не "в языке" ?

Я к тому, что неприятие методов у традиционно простых типов чисто психологический. (имхо)

Кроме того не обязательно думать о них как о методах.

В той же Lua - это просто сахар ради удобства.

Например библиотечную функцию sub можно вызвать и так:
string.sub(mystring, i, j)
и так:
mystring:sub(i, j)

Т.е. двоеточие - это тупо сокрытие первого аргумента и обращение к нему как к объекту. Просто другая форма записи.

[ilovb]

Здесь оператор |> создаёт конвейер типа как pipe в юниксовой консоли.

Кстати да. У меня тоже такая ассоциация 

[valexey_u]

Я частенько тоже в хацкеле так делаю, хоть это и не ООП-язык:

Код: [Выделить]

process fname = do
    putStrLn $ "Processing " ++ fname ++ " ..."
    dat <- readFile fname
    let dat2 = dat
            |> lines
            |> map     (map (\c -> [c]))
            |> map     (map (\s -> if s == "\t" then "\t0" else s))
            |> map     concat
            |> map     words
            |> filter  (\xs -> length xs > 6)

            |> map     (\(time: inorg:incompr:intransm:outorg:outcompr:outtransm:_) ->
                         (time,[inorg,incompr,intransm,outorg,outcompr,outtransm]))

            |> map     (\(time, xs) -> (take 2 (if length time == 5 then '0':time else time)
                                       ,map (read :: String -> Int) xs))

            |> groupBy (\(t1, _) (t2, _) -> t1 == t2) -- сгруппируем по часам
            |> map     (\xs -> (fst $ head xs, map snd xs))

            |> map     (\(time, xs) ->
                         (time, map (\[inorg,incompr,intransm,outorg,outcompr,outtransm] ->
                                      (inorg,incompr,intransm,outorg,outcompr,outtransm)) xs))

            |> map     (\(time, xs) -> (time, unzip6 xs))

            |> map     (\(time, (inorg,incompr,intransm,outorg,outcompr,outtransm)) ->
                         (time, [inorg,incompr,intransm,outorg,outcompr,outtransm]))

            |> map     (\(time, xs) -> (time, map sum xs))

            |> map     (\(time, xs) -> (time, map (\x -> trunc3 $ fromIntegral x / (1024*1024::Double)) xs))

            |> map     (\(time, xs) -> unwords' (time:(map show xs)))


    writeFile (fname ++ ".out") $ unlines dat2Здесь оператор |> создаёт конвейер типа как pipe в юниксовой консоли. Его можно по сути считать в данном случае точкой, разделяющей объект и вызов его метода в том же Расте.

Проблема таких конвейерных обработок -- через какое-то время трудно понять что там задумывалось, даже более того -- стоит отвлечься на что-то во время написания этого кода -- и уже приходится соображать, что надо дальше в этом конвейере сделать.
Так что иногда всё же вставляю дополнительные переменные, указываю их тип, а то начинаю париться с этими типами ))
Ну, для одноразовых скриптиков можно и так наговнякать )))

Слушай, ну монады же ровно про это же. Какая-нибудь List например. В плюсах мне лично дико мешает, что там есть statement'ы.

[Geniepro]

Слушай, ну монады же ровно про это же. Какая-нибудь List например.

Да куда ж там монады-то воткнуть? List -- для хитроумной генерации списков годится, для Maybe тут надобности нет, прочие монады как сюда воткнуть -- тоже ума не приложу...
Просто серия преобразований данных и всё... Никаких монад вроде не нужно...

[DddIzer]

.....

Лично для меня ни одна из записей не имеет однозначных преимуществ, если не рассматривать конкретное применение.

P.S. Хотя в копилку "методы с точкой"  можно положить автокомплит

а речь идет именно о конкретных применениях  - точнее так.. использование цепочных выражений для ряда задач обеспечивает естественную запись алгоритма ( записанного в терминах предметной области задачи). Но разумеется из этого не следует, что такую запись надо насаждать (как ООП в шарпе или в руби). И тут же ответ на вопрос Бориса - нафига нужен for.... - для тех случаев когда эта конструкция естественным образом отображает алгоритм -  учитывайте, что решения одной и той же задачи может описываться  в рамках различных систем понятий, теорий (которые по разному моделируются алгоритмами).

[ilovb]

Да не. Я имел в виду нафиг там for конкретно в этой конструкции. Оно ведь явно с руби скомунизжено, а там сам times и есть цикл. Слово for просто лишнее.
Хотя там видимо семантика различная таки... В руби n.times - это функция, которая принимает чанк и выполняет его n раз. В расте же for судя по всему принимает итератор, и n.times его соответственно создает. Т.е. выглядит похоже, но работает унутри не так. Ну т.е. в расте times сам по себе видимо бесполезен