и учитывает?

Это второй вопрос. Когда дело доходит то реализации, то любая красивая задумка начинает буксовать.

> Потому что у меня почти нет публикаций на эту тему, а те которые есть не содержат в заглавии LRnLA (еще имей ввиду, что обычно указывается не полное имя а инициалы).

м? Иванов А.В. Кинетическое моделирование динамики магнети-ков // Математическое моделирование — 2007. — Т. 19, вып. 10. — С. 89--104

Я на ЛОРе подобную аннотацию писал раз дцать по моему... надоело если честно. Но - если поиск тебе дается так сложно, мог бы сказать об этом и ВЕЖЛИВО попросить - я бы написал тут в дцать первый. Тебя мама не учила что хамить некрасиво?

не вижу причин «ВЕЖЛИВО» формулировать вопрос к хамски написанному посту. Мог бы 21 написать: математическое моделирование/численное инегрирование/dynamics of nanostructure in the thin-layer magnetic materials. 3 строчки и сразу понятно примерная область и характер алгоритмов.

Эффективность С++ - это сказочка из той же области, что и юношеский максимализм типа крутости ассемблера.
1. Скорость разработки: тут С++ проигрывает любому современному языку, за исключением, разве что, С (считаю, что тем кто пишет прикладное ПО на Plain C нужно гвоздь в голову забить). С++ и быстрая разработка несовместимы, это очевидно любому вменяемому человеку.
2. Скорость выполнения программы: когда программа на С++ становится чуть больше нескольких сотен строк начинается прикручивание всяких костылей типа смартпойнтеров, которые скорости выполнения не прибавляют. В сети куча бенчмарков, где в тестах с активным выделением памяти, языки вроде Ocaml с нормальной сборкой мусора, рвут плюсы как тузик грелку. Современные компиляторы очень хорошо оптимизируют код и по скорости исполнения он приближается к нативному, в то время как в плюсах высокоуровневая оптимизация крайне затруднена из-за сишного наследия. Невообразимо кривая система типов вызывает множественные приступы фейспалмов у людей, работавших с вменяемыми языками. С++ будет быстрее только на числодробилках, но чем сложнее логика, тем медленнее получится результат. При этом специфической ниши у плюсов нет и не предвидится.

> Иванов А.В. Кинетическое моделирование динамики...

Это мое, но про LRnLA там нету. Если так интересно подтверждение того, что я имею отношение к, то напр. вот:

Иванов А.В., Каплан С.А., Каракин А.В., Левченко В.Д., ЛевченкоТ.В., Рок В.Е. Вычисление полного сейсмического волнового поля в геосреде на основе нового метода решения прямых задач сейсмоакустики. Геоинформатика-2006, №3, с. 59-61.

не вижу причин «ВЕЖЛИВО» формулировать вопрос к хамски написанному посту.

Пример МОЕГО хамски написанного поста в студию пожалуйста (до того как ты начал брызгать слюнями вот тут http://www.linux.org.ru/jump-message.jsp?msgid=6630622&cid=6631463 )

В смысле? Ты же не имеешь ввиду, что можно выполнить V -> L -> !

я имею в виду, что в императивном языке L будет вычислен до вычисления V полностью, а V — до !

в функциональном же L будет вычисляться только по мере необходимости получить его (голову:хвост) в V, что при наличии сайд-эффектов в определении L и V приведет к совершенно другому результату, нежели в императивном коде:

Prelude> let p x = print x >> return x
Prelude> let q x = do { y <- x ; print (y^2) }
Prelude> let l = map p [1..10]
Prelude> let v = mapM_ q l
Prelude> v
1
1
2
4
3
9
4
16
5
25
6
36
7
49
8
64
9
81
10
100
Prelude> 

>Хаскель из-за большого количества IO с его чистотой будет только мешать.

Внезапно, не будет. Хотя если тебя ломает один раз написать liftIO...

Скорость разработки: тут С++ проигрывает любому современному языку,

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

Скорость выполнения программы: когда программа на С++ становится чуть больше нескольких сотен строк начинается прикручивание всяких костылей типа смартпойнтеров

зашел к себе в библиотеку:

aivlib$ wc -l include/*.hpp src/*.cpp
...
4841 итого

С++ будет быстрее только на числодробилках, но чем сложнее логика, тем медленнее получится результат

Ну опять таки, наши числодробилки простотой логики никак не отличаются... результат - весьма быстрый. Щас Вам ище shty накидает если не поленится... у него таки есть;-)

> Пример МОЕГО хамски написанного поста в студию пожалуйста (до того как ты начал брызгать слюнями вот тут http://www.linux.org.ru/jump-message.jsp?msgid=6630622&cid=6631463 )

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

разъясню:

1). много пафоса и предложение гуглить алгоритм -> 2). просьба написать область -> 3). ссылка на поиск.

это я считаю элементарным неуважением собеседника.

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

Кажется кто-то путает функциональность с ленивостью

А я считаю неуважением требовать подробностей до того, как сходил погуглить, сели послали гуглить, и чего?

Пафос - приходиться опускаться до уровня оппонента, уж очень он забавный. Да и нет никакого пафоса, одни факты... мы пишем самые быстрые в мире программы - какой тут пафос если они и правда самые быстрые???

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

Не спорю, после n-го количества лет плюсисты выучивают большинство косяков своего язычка и обходят их на автомате, а программисты с малым и средним опытом 90% времени обходят трудности, создаваемые собственным языком, вместо решения непосредственной задачи

и у меня там ни одного смарт-пойнтера... ЧЯНДТ???

Много ли создается объектов и насколько активно происходит выделение/очистка памяти? Полностью ручное выделение памяти - это неизбежные утечки, ошибки и крайне неприятная отладка. В том же Haskell отладки нет как таковой, большинство программ с ошибками просто не скомпилятся.

> Не спорю, после n-го количества лет ПОЛЬЗОВАТЕЛИ выучивают большинство косяков своего язычка и обходят их на автомате

//fixed

Много ли создается объектов и насколько активно происходит выделение/очистка памяти?

Много, но ничего не течет.

> А я считаю неуважением требовать подробностей до того, как сходил погуглить, сели послали гуглить, и чего?

И я посчитал тебя троллем, уверен, так сделал не только я.

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

Далее, для того, чтобы понять ценность слов про «самые быстрые в мире программы» надо искать и другие работы по вашей тематике, для того, чтобы понять аналоги програмных продуктов (если они есть), или увидеть, что все пользуются вашими библиотеками, при этом нужно иметь знания в области, чтобы сразу отсеивать часть статьи, где подобных вычислений нет, и это всё только для того, чтобы знать, что тут нету проблемы неуловимого Джо. От человека занимающегося этой областью данная задача займёт от силы полминуты, написать: мы сделали пакет foo, есть аналоги bar, baz но они проигрывают по многим параметрам. А если потратить минут 5 то можно написать обстоятельный пост и потом посылать в него, а не в поиск.

Неправда ли, проще сделать это 1 раз, чем представлять себя в плохом свете, ну или написать, сразу что я делал это много раз на лоре, исчите. Хотя.. это ЧСВ не так поднимает, да?

Ок, убедил. Напишу я короткий фак, выложу у себя и буду тупо давать на него ссылку;-)

Много, но ничего не течет

В языке без сборки мусора такое можно гарантировать только для хелловорлда (да и то не всегда).

> ну или написать, сразу что я делал это много раз на лоре, исчите.

И да, именно так, я это делал много раз на ЛОРе, исчите. Более того - некоторые посланные погуглить не стучали лысиной по праркету а таки гуглили, и потом спрашивали вполне конкретные вещи...

Как бы есть тесты... valgrind тот же напр.

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

> Более того - некоторые посланные погуглить не стучали лысиной по праркету а таки гуглили, и потом спрашивали вполне конкретные вещи...

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

пятница только завтра а уже срач

Гарантий это не даст. Вполне может быть, что при каких-либо редко возникающих условиях проявится утечка.

Ленивость - необходимое условие чисто функционального языка.

что именно в его использовании тебя смущает?

Хотя бы наличие костыля в виде Template Haskell, который впрочем не спасает положения

Взято отсюда (шаблоны в коде - это круто!):

getHomeR :: Handler ()
getHomeR = do
  Blog entries <- getYesod
  let newest = last entries
  redirect RedirectTemporary $ EntryR $ entrySlug newest

data TemplateArgs = TemplateArgs
  { templateTitle :: Html
  , templateContent :: Html
  , templateNavbar :: [Nav]
  }

data Nav = Nav
  { navUrl :: Route Blog
  , navTitle :: Html
  }

entryTemplate :: TemplateArgs -> Hamlet (Route Blog)
entryTemplate args = [hamlet|
  !!!

  <html>
      <head>
          <title>#{templateTitle args}
      <body>
          <h1>Yesod Sample Blog
          <h2>#{templateTitle args}
          <ul id="nav">
              $forall nav <- templateNavbar args
                  <li>
                      <a href="@{navUrl nav}">#{navTitle nav}
          <div id="content">
              \#{templateContent args}
  |]

getEntryR :: String -> Handler RepHtml
getEntryR slug = do
  Blog entries <- getYesod
  case filter (\e -> entrySlug e == slug) entries of
      [] -> notFound
      (entry:_) -> do
          let nav = reverse $ map toNav entries
          let tempArgs = TemplateArgs
                  { templateTitle = toHtml $ entryTitle entry
                  , templateContent = toHtml $ entryContent entry
                  , templateNavbar = nav
                  }
          hamletToRepHtml $ entryTemplate tempArgs
 where
   toNav :: Entry -> Nav
   toNav e = Nav
      { navUrl = EntryR $ entrySlug e
      , navTitle = toHtml $ entryTitle e
      }

Полный аналог на Рельсах:

# controllers/posts_controller.rb

class PostController < ApplicationController
  def index
    redirect_to Post.last
  end

  def show
    @nav = Post.all.reverse
    @post = Post.find_by_slug(params[:id])
  end
end

# templates/posts/show.haml

%html
  %head
    %title= @post.title
  %body
    %h2= @post.title
    %ul#nav
    - @nav.each do |item|
      %li= link_to item.title, item
    #content= @post.text

Код на Руби это именно описание того, что нужно получить, и не больше, в то время как код на Хаскеле изобилует мусором не нужным ни тому, кто пишет код, ни тому, кто будет его читать

>OCamL или Erlang или Haskell

А что делает Эрланг рядом с Окамлом и Хаскеллем?

OCamL похож на F#

Бгг.

>Ведь нужно решать задачу, а не ловить ошибки компиляции

Уж лучше ошибки компиляции, чем ошибки в рантайме

толи я што-то не понимаю то ли закладываться на ocaml бессмысленно http://rsdn.ru/forum/decl/4382948.aspx

шаблоны в коде - это круто

их оттуда можно вынести

Утечки бывают и в ЯП со сборкой мусора, в том же питоне например. Кольцевая ссылка и привет... зовите gc

> мне была интересна только область физики, где ты работаешь, всё.

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

>питон

язык программирования

/0

Кольцевая ссылка и привет

Но мы же не будем называть GC то говно, что в гвидопыхе находится, так ведь?

> Уж лучше ошибки компиляции, чем ошибки в рантайме

сказал фанат Smalltalk... =)

CL - это не язык, а множество глупых раздражающих скобок.

Обычно, в редакторах они подсвечиваются самым незаметным образом.

Я специально настраиваю Емакс так, чтобы скобки были максимально яркие и мигали оранжевым цветом.

http://www.linux.org.ru/wiki/en/User:AIv/LRnLA

ну отлично, теперь есть хорошая возможность понимания предметной области. Извиняюсь, мне сейчас честно не до прочтения статей, но в приведённых внизу есть ли описание алгоритмов, или только применение? Если 2ое то ссылки на сам алгоритм (которые наверняка есть в литературе в статьях) тоже бы хотелось видеть.

Спасибо. Мне тоже пригодится.

А явную ссылку на алгоритм можно? Не сумел найти(((

Специально для Вас таки выкладываю наиболее полное описание LRnLA от автора http://a-iv.ru/trash/LRnLA.pdf ;-)

В вики тоже добавлю.

Спасибо добрый человек.

Если нагрузка на сайт будет небольшой, Erlang в производительности уступит тому же Haskell из-за динамической типизации.

Это грустно :( Если это правда

Смело плюй в лицо каждому, кто боится просядания скорости от динамической типизации на io-bounded задачах.

Спасибо, как со всякими философиями для аспирантуры разберусь, посмотрю осилю ли алгоритмы.

> На личных знаниях и опыте. А до этого - вижуалбейсик

бугага. помнится не так давно в fprog vb зарулил даже cl на какой-то там предложенной задаче, по мнению редакторов самого fprog.

так что можешь рассказать, отчего у тебя такой презрительный тон. или мне показалось?

>в то время как код на Хаскеле

Кривишь душой. Нет в коде ничего лишнего. В языках со статической типизацией необходимо тратить время и ресурсы на разработку/объявление типов. Зато они высутпают а) как интерфейсы взаимодействия; б) как вычислительные контексты.

Шаблоны в Yesod можно вынести в отдельный файл. Можно разработать более высокоуровневое решение, которое позволит касаться HTML только на очень нижних уровнях твоего ПО.

Кроме того, я лично считаю, что HTML в современных приложениях должен генерироваться на стороне клиента. Хотя это и сложнее реализуется. Например, тот же julis из yesod'а отвечает за генерацию ява-скриптов.

Я очень сильно уважаю Lua, Ruby, Python и Lisp, но меня конкретно достало играть в угадайки с компилятором в рантайме. Видимо это старость.

Если чего — пользуюсь для своих мелкоавтоматизационных нужд Happstack'ом и Blaze-Html. Он несколько пропроще. В качесте морды и аутентификатора по SSL юзаю nginx. Хотя пока я генерацию HTML на стороне клиента еще не осилил.

И как тебе такое в голову пришло?

В любом случае, энергичность не является достаточным признаком императивности

Мне больше вот это нравится. Руби тихо покуривает в сторонке.

Эффективность С++ - это сказочка из той же области, что и юношеский максимализм типа крутости ассемблера.

ахаха, жги ещё :) крутость...

не, я не могу, ежедневный кропотливый труд - не хочешь? ты думаешь ты такой крутой, открыл, блджад, «истену», что скорость разработки на С++ ниже.... может ты тут вообразил, что школьникам лекцию читаешь, или ты сам школьник? да мне покласть, если честно

я тебе только одно скажу - все кривота С++, которую __ты__ видишь - она из твоей головы, и больше не из чьей, с чем тебя и поздравляю

Но мы же не будем называть GC то говно, что в гвидопыхе находится, так ведь?

вот и мухи налетели, с большим знанием гов дела

Я очень сильно уважаю Lua, Ruby, Python и Lisp, но меня конкретно достало играть в угадайки с компилятором в рантайме. Видимо это старость.

не, не старость, непонимание зачем нужны модульные тесты

5 страниц флуда в /development
Это - win, ящитаю.

Сайты, эрланг хаскель и осамл - это ты конечно загнул.

Сайты делаются не на эрланге, а для эрланга.
Окамл для сайтов не прокатит из-за GIL-smell сборщика мусора. Т.е. многопоточное нечто ты там не напишешь особо. А так - по процессу на запрос страницы - это экономно и эффективно :)
Ну и хаскель для разработки сайтов, видимо, самый приспособленный ЯП :)

Побольше бы необычных применений обыкновенным ЯП :)

Что-то стало много анонимусов, решил деанонимизироваться (я тот, который агитировал за Рельсы)

В языках со статической типизацией необходимо тратить время и ресурсы на разработку/объявление типов. Зато они высутпают а) как интерфейсы взаимодействия; б) как вычислительные контексты

Самое главное для успеха проекта - это скорость его развития, и, похоже, что статическая типизация тут только мешает. Кто победил известно, и не думаю, что это просто совпадение: Facebook (PHP) vs MySpace (Java), GitHub (RoR) vs Google Code (Java), YouTube (в основном Python) vs много конкурентов (часто C++ и Java) и так далее

Мне больше вот это нравится. Руби тихо покуривает в сторонке.

Нет там ничего особенного. Продолжения и в Руби есть. Кроме того, его гибкость позволяет приминять не мало техник метапрограммирования, доступных в Лиспе, и этого, как правило, хватает

> Окамл для сайтов не прокатит из-за GIL-smell сборщика мусора.

А как оно будет мешать ?

Ну и хаскель для разработки сайтов, видимо, самый приспособленный ЯП :)

А как же yaws и nitrogen для Erlang ?

кэп-моде он

дима бургер - ссаная симфа, а руби - тормоз