Re[18]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 03.05.15 06:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Я знаю несколько контор в которых пилилась всякая разная виртуализация. Что интересно, ни одна не выстрелила. Хотя везде её пилили люди на привычных им инструментах, в т.ч., скажем, дотнет и джава. Идея ясна ?

Пилить системщину только на шарпе или Java как то уж очень необычно.

I>Если идея это всё что надо, очень странно, что проект выстрелил только у вас.

Может потому, что идея ещё должна быть хорошей?
Re[18]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 03.05.15 06:27
Оценка:
Здравствуйте, Sharov, Вы писали:

CC>>Storage.

S>Это многое объясняет.

Любопытно, что именно?
Re[19]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Sharov Россия  
Дата: 03.05.15 13:30
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Любопытно, что именно?


Прощу прощения, я не видел раннего комментария про storage virtualization.
Все ясно, благодарю.
Кодом людям нужно помогать!
Re[19]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.05.15 07:53
Оценка: +1 -1
Здравствуйте, CreatorCray, Вы писали:

I>>Я знаю несколько контор в которых пилилась всякая разная виртуализация. Что интересно, ни одна не выстрелила. Хотя везде её пилили люди на привычных им инструментах, в т.ч., скажем, дотнет и джава. Идея ясна ?

CC>Пилить системщину только на шарпе или Java как то уж очень необычно.

Ну как же, зато инструмент привычный и всё такое.

I>>Если идея это всё что надо, очень странно, что проект выстрелил только у вас.

CC>Может потому, что идея ещё должна быть хорошей?

Ога.

Хорошая идея с кривой реализацией -> говно, которое никому не нужно.
Идея без реализации -> говно
Хорошая реализация с кривой идеей -> говно

Вроде понятно, что нужен правильный баланс, так сказать, гармония. А тебя послушать, так оказывается, что идея это всё, а на реализацию можно забить. Смотри свои же слова про шарп и джаву — ты споришь, что характерно, сам с собой
Re[20]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 04.05.15 21:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ну как же, зато инструмент привычный и всё такое.

Кроме привычности инструмент должен ещё быть подходящим к предметной области.
Неэффективно пытаться писать код в системное ядро на js и веб скрипты на ассемблере.

I>Вроде понятно, что нужен правильный баланс, так сказать, гармония. А тебя послушать, так оказывается, что идея это всё, а на реализацию можно забить.

Мой поинт в том, что язык реализации — третьестепенен.
Re[21]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.05.15 04:38
Оценка: 2 (1) +2
Здравствуйте, CreatorCray, Вы писали:

I>>Ну как же, зато инструмент привычный и всё такое.

CC>Кроме привычности инструмент должен ещё быть подходящим к предметной области.
CC>Неэффективно пытаться писать код в системное ядро на js и веб скрипты на ассемблере.

А если получился уникальный эффект, о чем это говорит ?

I>>Вроде понятно, что нужен правильный баланс, так сказать, гармония. А тебя послушать, так оказывается, что идея это всё, а на реализацию можно забить.

CC>Мой поинт в том, что язык реализации — третьестепенен.

Ты сам себя опроверг чуть выше
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.06.22 16:43
Оценка: :)
Здравствуйте, -n1l-, Вы писали:

N>Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.


Похоже, так написали, что до сих пор тот код не смогли выбросить.

N>Подведу итог, на хаскель я сейчас смотрю как на супер оружие 21 века, со всеми этими паттерн матчингами и так далее.

N>Уже лежит книга по многопоточности на этом языке и уже читается другая по синтаксису.

Выбрось.

Смотри сюда: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/haskell.html
Все что тебе надо, это понять примеры по ссылкам. Вот, например,
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-ghc-3.html
import Foreign.C.Types
import qualified Data.Vector.Storable as V
import qualified Data.Vector.Storable.Mutable as M
import Foreign.Ptr
import Foreign.Marshal.Alloc
import Data.Word
import Control.Monad
import Foreign.Storable
import System.IO
import Control.Concurrent
import Data.Foldable
import Data.Char

-- first some foreign imports (Haskell does not have a proper pcre2 binding!)

foreign import capi "pcre2.h value PCRE2_JIT_COMPLETE"
  c_PCRE2_JIT_COMPLETE :: CUInt

foreign import ccall "pcre2.h pcre2_get_ovector_pointer_8"
  c_pcre2_get_ovector_pointer :: Ptr MatchData -> IO (Ptr CSize)

foreign import ccall "pcre2.h pcre2_compile_8"
  c_pcre2_compile :: Ptr CChar -> CSize -> CInt -> Ptr CInt -> Ptr CSize
    -> Ptr () -> IO (Ptr Code)

foreign import ccall "pcre2.h pcre2_jit_compile_8"
  c_pcre2_jit_compile :: Ptr Code -> CUInt -> IO ()

-- This one is marked unsafe for extra performance.
-- See https://wiki.haskell.org/Performance/FFI
foreign import ccall unsafe "pcre2.h pcre2_jit_match_8"
  c_pcre2_jit_match :: Ptr Code -> Ptr CChar -> CSize -> CSize -> CUInt
    -> Ptr MatchData -> Ptr MatchContext -> IO CInt

foreign import ccall "pcre2.h pcre2_code_free_8"
  c_pcre2_code_free :: Ptr Code -> IO ()

foreign import ccall "pcre2.h pcre2_match_context_create_8"
  c_pcre2_match_context_create :: Ptr GeneralContext -> IO (Ptr MatchContext)

foreign import ccall "pcre2.h pcre2_jit_stack_create_8"
  c_pcre2_jit_stack_create :: CSize -> CSize -> Ptr () -> IO (Ptr JitStack)

foreign import ccall "pcre2.h pcre2_jit_stack_assign_8"
  c_pcre2_jit_stack_assign :: Ptr MatchContext -> Ptr () -> Ptr JitStack
    -> IO ()

foreign import ccall "pcre2.h pcre2_match_data_create_8"
  c_pcre2_match_data_create :: CUInt -> Ptr GeneralContext
    -> IO (Ptr MatchData)

foreign import ccall "pcre2.h pcre2_match_context_free_8"
  c_pcre2_match_context_free :: Ptr MatchContext -> IO ()

foreign import ccall "pcre2.h pcre2_jit_stack_free_8"
  c_pcre2_jit_stack_free :: Ptr JitStack -> IO ()

foreign import ccall "pcre2.h pcre2_match_data_free_8"
  c_pcre2_match_data_free :: Ptr MatchData -> IO ()

data MatchData
data MatchContext
data Code
data GeneralContext
data JitStack

data GrowString = GrowString
  {-# UNPACK #-} !(M.IOVector Word8)
  {-# UNPACK #-} !Int

-- Freeze and trim
freezeGrowString :: GrowString -> IO (V.Vector Word8)
freezeGrowString (GrowString dat siz) = V.unsafeFreeze (M.slice 0 siz dat)

-- Function for searching a srcString for a pattern, replacing it with some
-- specified replacement, and storing the result in dstString.
--
-- dstString might be reallocated so this function returns a new GrowString.
-- For optimal performance you should not use the old GrowString anymore.
replace :: V.Vector Word8 -> V.Vector Word8 -> V.Vector Word8
  -> GrowString -> Ptr MatchContext -> Ptr MatchData -> IO GrowString
replace !pattern !replacement !srcString !dstString !mcontext !mdata =
  alloca $ \errorCode -> alloca $ \errorOffset -> do
    match <- c_pcre2_get_ovector_pointer mdata

    -- Compile and study pattern.
    regex <- V.unsafeWith pattern $ \patternPtr -> c_pcre2_compile
      (castPtr patternPtr) (fromIntegral (V.length pattern)) 0 errorCode
      errorOffset nullPtr
    c_pcre2_jit_compile regex c_PCRE2_JIT_COMPLETE

    -- Find each match of the pattern in srcString and append the characters
    -- preceding each match and the replacement text to dstString.
    let
      go !pos !dstString = do
        !x <- V.unsafeWith srcString $ \srcStringPtr ->
          c_pcre2_jit_match regex (castPtr srcStringPtr)
            (fromIntegral srcStringLen) (fromIntegral pos) 0 mdata mcontext
        if (x >= 0) then do
          !match0 <- fromIntegral <$> peekElemOff match 0

          -- Allocate more memory for dstString if there is not enough space
          -- for the characters preceding the match and the replacement text.
          let
            growLoop str@(GrowString !dat !siz)
              | siz + match0 - pos + replacementSize > M.length dat = do
                !dat' <- M.grow dat (M.length dat) :: IO (M.IOVector Word8)
                growLoop (GrowString dat' siz)
              | otherwise = return str
          (GrowString dat siz) <- growLoop dstString

          -- Append the characters preceding the match and the replacement text
          -- to dstString and update the size of dstString.
          let
            !siz' = siz + match0 - pos
            !siz'' = siz' + replacementSize
          V.copy (M.slice siz  (match0 - pos)  dat)
            (V.slice pos (match0 - pos) srcString)
          V.copy (M.slice siz' replacementSize dat) replacement

          -- Find the new pos to continue after the current match.
          !pos' <- fromIntegral <$> peekElemOff match 1

          go pos' (GrowString dat siz'')
        else return (pos, dstString)
    (!pos, !dstString') <- go 0 dstString

    c_pcre2_code_free regex

    -- Allocate more memory for dstString if there is not enough space for the
    -- characters following the last match (or the entire srcString if there
    -- was no match).
    let
      growLoop str@(GrowString !dat !siz)
        | siz + srcStringLen - pos > M.length dat = do
          dat' <- M.grow dat (M.length dat) :: IO (M.IOVector Word8)
          growLoop (GrowString dat' siz)
        | otherwise = return str
    (GrowString dat siz) <- growLoop dstString'

    -- Append the characters following the last match (or the entire srcString
    -- if there was no match) to dstString and update the size of dstString.
    V.copy (M.slice siz (srcStringLen - pos) dat)
      (V.slice pos (srcStringLen - pos) srcString)

    return (GrowString dat (siz + srcStringLen - pos))
  where
    srcStringLen = V.length srcString
    replacementSize = V.length replacement

main :: IO ()
main = do
  let
    f = V.fromList . map (fromIntegral . ord)
    countInfo = map f
      [ "agggtaaa|tttaccct"
      , "[cgt]gggtaaa|tttaccc[acg]"
      , "a[act]ggtaaa|tttacc[agt]t"
      , "ag[act]gtaaa|tttac[agt]ct"
      , "agg[act]taaa|ttta[agt]cct"
      , "aggg[acg]aaa|ttt[cgt]ccct"
      , "agggt[cgt]aa|tt[acg]accct"
      , "agggta[cgt]a|t[acg]taccct"
      , "agggtaa[cgt]|[acg]ttaccct"
      ]
    replaceInfo = map (\(a,b) -> (f a, f b))
      [ ("tHa[Nt]", "<4>")
      , ("aND|caN|Ha[DS]|WaS", "<3>")
      , ("a[NSt]|BY", "<2>")
      , ("<[^>]*>", "|")
      , ("\\|[^|][^|]*\\|", "-")
      ]

  input <- (\x -> GrowString x 0) <$> M.new 16384
  sequences <- (\x -> GrowString x 0) <$> M.new 16384

  -- Read in input from stdin until we reach the end or encounter an error.
  let
    readLoop (GrowString !dat !siz) = do
      bytesRead <- M.unsafeWith (M.slice siz (M.length dat - siz) dat)
        $ \inputPtr -> hGetBuf stdin inputPtr (M.length dat - siz)
      if bytesRead > 0 then do
        -- update the size of input to reflect the newly read input and if
        -- we've reached the full capacity of the input string then also double
        -- its size.
        dat' <- if (siz + bytesRead == M.length dat)
          then M.grow dat (M.length dat) :: IO (M.IOVector Word8)
          else return dat
        readLoop (GrowString dat' (siz + bytesRead))
      else return (GrowString dat siz)
  input' <- freezeGrowString =<< readLoop input
  let !inputSiz = V.length input'

  let
    threadInit = do
      mcontext <- c_pcre2_match_context_create nullPtr
      stack <- c_pcre2_jit_stack_create 16384 16384 nullPtr
      c_pcre2_jit_stack_assign mcontext nullPtr stack
      mdata <- c_pcre2_match_data_create 16 nullPtr
      return (mcontext, stack, mdata)
  (mcontext, stack, mdata) <- threadInit

  -- Find all sequence descriptions and new lines in input, replace them with
  -- empty strings, and store the result in the sequences string.
  sequences'@(GrowString seqDat seqSiz) <-
    replace (f ">.*\\n|\\n") (f "") input' sequences mcontext mdata

  -- Work on performing all the replacements serially.
  replaceVar <- newEmptyMVar
  -- Fork this thread explicitely to capability 0 to discourage the scheduler
  -- from interrupting this thread.
  forkOn 0 $ do
    -- We'll use two strings when doing all the replacements, searching for
    -- patterns in prereplaceString and using postreplaceString to store the
    -- string after the replacements have been made. After each iteration these
    -- two then get swapped. Start out with both strings having the same
    -- capacity as the sequences string and also copy the sequences string into
    -- prereplaceString for the initial iteration.
    prereplaceString <- (\x -> GrowString x seqSiz) <$> M.clone seqDat
    postreplaceString <- (\x -> GrowString x 0) <$> M.new (M.length seqDat)

    -- Iterate through all the replacement patterns and their replacements in
    -- replaceInfo
    let
      cons (pre@(GrowString dat _),post) (a,b) = do
        dat' <- freezeGrowString pre
        post' <- replace a b dat' post mcontext mdata
        let pre' = (GrowString dat 0)
        -- Swap pre and post in the next iteration.
        return (post', pre')
    -- If any replacements were made, they'll be in the fst element of the
    -- tuple instead of the second because of the swap done at the end of each
    -- iteration.
    (GrowString _ !siz, _) <- foldlM cons
      (prereplaceString, postreplaceString) replaceInfo

    c_pcre2_match_context_free mcontext
    c_pcre2_jit_stack_free stack
    c_pcre2_match_data_free mdata

    putMVar replaceVar siz

  -- Iterate through all the count patterns in countInfo and perform the
  -- counting for each one on a different thread if available.
  first <- newMVar ()
  rest <- replicateM (length countInfo) newEmptyMVar

  for_ (zip3 countInfo (first : rest) rest) $ \(pattern, prev, next) ->
    forkIO $ do
      (mcontext, stack, mdata) <- threadInit
      match <- c_pcre2_get_ovector_pointer mdata

      -- Compile and study pattern.
      regex <- alloca $ \errorCode -> alloca $ \errorOffset ->
        V.unsafeWith pattern $ \patternPtr -> c_pcre2_compile
          (castPtr patternPtr) (fromIntegral (V.length pattern)) 0 errorCode
          errorOffset nullPtr
      c_pcre2_jit_compile regex c_PCRE2_JIT_COMPLETE

      -- Find each match of the pattern in the sequences string and increment
      -- count for each match.
      let
        go !count !pos = do
          x <- M.unsafeWith dat $ \datPtr -> c_pcre2_jit_match regex
            (castPtr datPtr) (fromIntegral siz) pos 0 mdata mcontext
          if x >= 0 then do
            -- Find the new pos to continue searching after the current match.
            pos' <- peekElemOff match 1
            go (count + 1) pos'
          else return count
          where
            (GrowString dat siz) = sequences'
      count <- go 0 0

      c_pcre2_code_free regex

      -- Print the count for each pattern in the correct order.
      takeMVar prev
      V.unsafeWith pattern $ \patternPtr ->
        hPutBuf stdout patternPtr (V.length pattern)
      putStr " "
      print count
      putMVar next ()

      c_pcre2_match_context_free mcontext
      c_pcre2_jit_stack_free stack
      c_pcre2_match_data_free mdata

  siz <- takeMVar (replaceVar)

  takeMVar (last rest)

  -- Print the size of the original input, the size of the input without the
  -- sequence descriptions & new lines, and the size after having made all the
  -- replacements.
  putStrLn ""
  print inputSiz
  print seqSiz
  print siz
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.06.22 19:28
Оценка: +1
Здравствуйте, -n1l-, Вы писали:

N>Где-то у меня мелькала статья про лисп.

N>Парни создали софт, веб приложение используя лисп, а все остальные не могли за ними угнаться.
N>Так как они внедряли новые фичи со скоростью света.

Эти ребята назывались Paul Graham, Robert Morris и Trevor Blackwell а их приложение называлось Viaweb.

Yahoo купило их поделие за 49 миллионов баксов и переименовало в Yahoo! Store. A Paul Graham стал властителем человеческих дум, написал кучу эссе, которые принято считать непреложной истиной, и даже основал компанию YCombinator, которая вкладывает небольшие денежки в IT стартапы и форматирует мозги их основателям. Получить деньги от YCombinator'а считается столь почетным, что никто, на самом деле, не решается их тратить, а засовывают чек в рамочку, вешают на стену и с гордостью всем показывают. Миллионеры, увидев на стене чек от YCombinator'а в рамочке, сразу падают в обморок, а придя в себя, не задумываясь выдают такому стартапу настоящих уже денег на развитие и карманные расходы.

N>Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.


Я слышал, краем уха, что Yahoo вроде в конечном итоге переписало это поделие на нормальном языке. Но могу и ошибаться.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.06.22 19:30
Оценка: 2 (1) +3
Здравствуйте, Ikemefula, Вы писали:

Y>>А еще они все пили воду и носили штаны. За штанами будущее!


I>Ты что сказать хотел ?


Он хотел сказать, что может они и не из-за лиспа преуспели, а просто повезло сделать удачную штучку, не важно на чем.
Re[3]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: vsb Казахстан  
Дата: 16.06.22 19:47
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Я слышал, краем уха, что Yahoo вроде в конечном итоге переписало это поделие на нормальном языке. Но могу и ошибаться.


Не ошибаешься.

А вообще я так и не понял фишки лиспа, хотя я даже его компилятор писал (не дописал, но тему изучил достаточно, чтобы представлять себе всё, что надо). Обычный язык. Ничем от джавы не отличается принципиально. Любой код можно плюс-минус одинаково перенести. Есть некоторые головодробительные концепции вроде continuations (даже не уверен, что они есть в общем лиспе), но на практике они особо не нужны и заменяются другими концепциями. Ну единственное, чем отличается лисп от других языков — нормальные его реализации стоят абсолютно диких денег. Может потому его и пиарят — типа раз заплатили такие деньги, стыдно себе признаться, что бесплатная жмв с идеей за 100 баксов гораздо круче.

А жаваскрипт вообще один в один лисп. Только вместо s-выражений — c-подобный синтаксис.
Отредактировано 16.06.2022 19:48 vsb . Предыдущая версия .
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Michael7 Россия  
Дата: 16.06.22 20:10
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Успех им обеспечило то, что они взяли знакомый им инструмент. Пока конкуренты осваивали Яву и писали фидбек её авторам, старички пилили Лисп со скоростью опытной машинистки. И не потому, что Лисп круче, а потому, что кроме Лиспа они ничем не владели. Владели бы они Фортраном — вы бы сейчас писали "о, надо писать веб-магазины на Фортране".


Ну нет, лисп таки крут был своим метапрограммированием, да и сейчас неплох. Собственно многие фичи лиспа и фп с тех пор проникли в мейнстрим от C++ до Javascript и C# и совсем не случайно. В 90-е же мейнстрим куда убоже был.

S>Если вы хотите скопировать их успех, не надо копировать Лисп. Надо копировать подход "если у вас есть бизнес-идея, пилите её на знакомом вам инструменте, в котором вы уверены".


Ну это тоже верно конечно. Но и выбор инструмента имеет все же очень важное значение.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.06.22 22:16
Оценка:
Здравствуйте, -n1l-, Вы писали:

N>Не аргумент, на шарпе, хоть он не и знаком, я бы делал это дольше в разы.

N>Попрограммировав чуть-чуть на лисп, я понял, что он потрясающий.
N>У меня даже стиль изложения изменился.

Да, ты теперь всегда в уме подсчитываешь скобки.
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 17.06.22 00:56
Оценка: +2 -1
Здравствуйте, Sinclair, Вы писали:

S>Успех им обеспечило то, что они взяли знакомый им инструмент. Пока конкуренты осваивали Яву и писали фидбек её авторам, старички пилили Лисп со скоростью опытной машинистки. И не потому, что Лисп круче, а потому, что кроме Лиспа они ничем не владели. Владели бы они Фортраном — вы бы сейчас писали "о, надо писать веб-магазины на Фортране".


Эта команда владела еще много чем и подобрала наиболее подходящий им инструмент под конкретную техническую задачу. Задача была блестяще решена и продукт взлетел. Умело подобранная тобой метафора "скорость машинистки", предполагает высокую скорость набора текста, но их секрет в том, что лисп им дал в разы меньший объем кода, чем любая альтернатива того времени.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.06.22 13:41
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Эта команда владела еще много чем и подобрала наиболее подходящий им инструмент под конкретную техническую задачу. Задача была блестяще решена и продукт взлетел. Умело подобранная тобой метафора "скорость машинистки", предполагает высокую скорость набора текста, но их секрет в том, что лисп им дал в разы меньший объем кода, чем любая альтернатива того времени.


"команда владела еще много чем" означает что опыта у них было дохренища, чего у типичных команд нашего времени вобщем не бывает.

На тот момент их подход к бизнесу был довольно востребованым, без чего бы мы про их успехи и не узнали.

Я шота более чем уверен, выбери вместо лиспа другой высокоуровневый языки, типа питона или что навроде, результат был бы не хуже.
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: IT Россия linq2db.com
Дата: 17.06.22 13:56
Оценка: -1
Здравствуйте, -n1l-, Вы писали:

N>Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.


Известная история. Типичные лямбда-самцы, в коде которых никто не может разобраться по причине того, что это write-only код.
Кстати, их говно-код потом был полностью выброшен на помоечку и приложение полностью переписано.
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 17.06.22 15:18
Оценка: 1 (1) +1
Здравствуйте, Pauel, Вы писали:

P>Я шота более чем уверен, выбери вместо лиспа другой высокоуровневый языки, типа питона или что навроде, результат был бы не хуже.


Откуда такая уверенность? Лично я экономил на стэке и архитектуре, которую можно было дешево реализовать только в нем, в разы. Силами очень небольшой команды за счет профессионализма и инструмента.

А профи (те, кто доводит до пользователя непростые проекты с хорошим соотношением цена/качество), которые выбрали бы неудобный для решения задачи стек "типа питона" и терпеливо жрали бы долгое время этот кактус, мне не встречались. Обычно они понимают, что и зачем выбрали, а не действуют по принципу — мы крутые машинистки и на пэхапе наклепаем.
Re[3]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 17.06.22 15:23
Оценка:
Здравствуйте, IT, Вы писали:

IT>Известная история. Типичные лямбда-самцы, в коде которых никто не может разобраться по причине того, что это write-only код.

IT>Кстати, их говно-код потом был полностью выброшен на помоечку и приложение полностью переписано.

Вот кто бы говорил? ) Много команд потянут мейнтейн linq2db без особой подготовки?

Мало ли архитекторов найдется с мнением, что надо все выкинуть и переписать на Go?
Re[4]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: IT Россия linq2db.com
Дата: 17.06.22 18:01
Оценка: 4 (2) +4
Здравствуйте, Ziaw, Вы писали:

Z>Вот кто бы говорил? ) Много команд потянут мейнтейн linq2db без особой подготовки?


Если не ошибаюсь там был простенький толи магазинчик, толи mail клиент. И его потом не смогла поднять профессиональная команда разработчиков, чтобы его развивать и поддерживать. Не помогла ни подготовка, ни переподготовка. Дело не в ней. Лямбда-самцы действительно способны писать на FP шедевральные вещи, которые нам, простым селянам не доступны в силу нашего скудоумия. Но FP здесь лишь катализатор, очень мощный, но не критичный. Можно и без FP наворотить одноразового кода, который невозможно будет развивать.

linq2db пережил уже мильён сто тыщь пицот и ещё семь доработок, рефакторингов и глобальных фичедобавлений. При этом базовая архитектура хоть и расширяется, но тотально не меняется. И, кстати, большинство последних фич сделано людьми, которые присоеденились к проекту далеко не сразу.

Z>Мало ли архитекторов найдется с мнением, что надо все выкинуть и переписать на Go?


Не стоит обобщать. Конкретно данный пример с лиспом — это пример того как изначально провальный проект выдают за шедевр инженерного творчества и неспособность плебеев понять глубину мысли истинных ламбда-джедаев. Хотя, думаю, история выглядела немного по-другому:

Несомненно талантливые парни вооружились нетривиальным, но и не самым очевидным инструментом и начали клепать разные несложные поделки. Пока "ментальная" модель этих поделок целиком умещалась в голове, то при добавлении новых фич можно было переписывать код хоть каждый раз с нуля (не раз наблюдал такую картину). В таких продуктах, прости господи, архитектура обычно отсутствует напрочь, даже намёки на неё. Это всегда просто слепок "ментальной" модели, воплощённый в коде. Этакий монолит, идеальный круглый шар, артефакт, великолепно и эффективно выполняющий возложенные на него задачи. Хотя и вещь в себе, ни добавить, ни убавить.

Далее их заметили, купили, повосторгались и предложили из поделки сделать настоящий продукт. И вот здесь размер той самой "ментальной" модели превзошёл возможности несомненно талантливых парней. Адаптировать модель под требуемые фичи стало всё сложнее. Тем более, что список новых фич формируется уже не самим тобой, а другими людьми, часто обладающими несовместимой с твоей фантазией. Если раньше любую невпихуемую фичу можно было отбросить (с собой договориться элементарно), то теперь надо делать. Требование заказчика. Но ведь архитектуры как не было так и нет. Возможно была даже предпринята попытка что-то соорудить на коленке. Но боюсь это только усугубило проблему.

В результате получилось — слепок "ментальной" модели с прилепленными сбоку плохо совместимыми фичами и возможно попытками всё это заархитектурить. Помножим всё это на своеобразность выбранного инструмента и получаем абслютно бесполезный в плане развития продукт. Идеальный шар поломался, в кучу не собирается, не монолит и не артефакт, а артехрень. Единственно правильное решение — это взять веничек и замести это всё в мусорное ведёрко. Что, как я понимаю, и было сделано.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: SkyDance Земля  
Дата: 17.06.22 20:31
Оценка: +1
vsb>А вообще я так и не понял фишки лиспа

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

Можно писать веб-приложения на С++.
Можно писать распределенные системы на Фортране.

Но некоторые технологии позволяют людям с определенной подготовкой работать намного эффективнее, и добиваться поставленных целей с бОльшей вероятностью. Кроме того, поддержка продукта на некоторых технологиях может быть существенно дороже (потому что мало кто помнит COBOL), но может статься, что и на порядок дешевле (потому что достаточно одному грамотному инженеру изучить COBOL, и обойтись без найма 20 писателей на С++).

Сами процессы перехода тоже очень длительные, занимают поколение или даже больше. Причем в первую очередь эти изменения обусловлены такими на первый взгляд несвязанными вещами как школьная программа. Школьники с младых лет могут быть сунуты головой в "лого-черепашку", пошагово исполняющую программу. А могут и в другую сторону — через функциональный подход, в виде "рецепт изготовления пирога", где пирог зависит от теста и начинки, тесто — от муки и воды, начиинка — от яблок и корицы.

Маленькие компании не могут рассчитывать на армию в 100500 тружеников на С++, потому вынуждены искать более эффективные средства решения их проблем. Почему бы и не лисп. Или Хаскель.
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 17.06.22 20:36
Оценка: +1
P>Я шота более чем уверен, выбери вместо лиспа другой высокоуровневый языки, типа питона или что навроде, результат был бы не хуже.

Уверен, что результат был бы хуже.
Потому что им пришлось бы вместо решания задачи воевать с инструментом (языком), а также со своим нежеланием преодолевать кривизну оного инструмента.

Второе зачастую важнее, чем первое — если инструмент нравится, то и дело с ним спорится. А если нет, то вместо работы постоянно отвлекаешься на раздражающие проблемы. У меня так с С++ было, слишком часто нужно заглядывать в те или иные мануалы, слишком часто консультироваться с гуглом, слишком долго ждать сборки или запуска тестов. Та же Java многие из этих проблем решила, хотя сам по себе язык не то чтоб отличается (по крайней мере не так сильно, как LISP).
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.