Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
// And then I replaced the idiomatic Rust code for working with block like
for (dline, (sline0, sline1)) in dst.chunks_mut(dstride).zip(tmp.chunks(TMP_BUF_STRIDE).zip(tmp2.chunks(TMP_BUF_STRIDE))).take(h) {
for (pix, (&a, &b)) in dline.iter_mut().zip(sline0.iter().zip(sline1.iter())).take(w) {
*pix = ((u16::from(a) + u16::from(b) + 1) >> 1) as u8;
}
}
// with raw pointers:
unsafe {
let mut src1 = tmp.as_ptr();
let mut src2 = tmp2.as_ptr();
let mut dst = dst.as_mut_ptr();
for _ in 0..h {
for x in 0..w {
let a = *src1.add(x);
let b = *src2.add(x);
*dst.add(x) = ((u16::from(a) + u16::from(b) + 1) >> 1) as u8;
}
dst = dst.add(dstride);
src1 = src1.add(TMP_BUF_STRIDE);
src2 = src2.add(TMP_BUF_STRIDE);
}
}
What do you know, the total decoding time for the test clip I used shrank from 6.6 seconds to 4.9 seconds. That’s just three quarters of the original time!
And here is the problem. In theory if Rust compiler knew that the input satisfies certain parameters i.e. that there’s always enough data
to perform full block operation in this case, it would be able to optimise code as good as the one I wrote using pointers or even better.
But unfortunately there is no way to tell the compiler that input slices are large enough to perform the operation required amount of times.
Even if I added mathematically correct check in the beginning it would not eliminate most of the checks.
Overall, there are a few features and design decisions that limit Rust compilation speed:
Macros: Code generation with macros can be quite expensive.
Type checking
LLVM: that's the default compiler backend for Rust, where a lot of the heavy-lifting (like code-optimizations) takes place. LLVM is notorious for being slow.
Постоянно проигрываю с этого сектанткого аргумента «LLVM is notorious for being slow».
Напоминает плохого танцора, которому то мешали туфли, то некоторые части тела.
Коли не нравится LLVM, зачем было его воровать? Напишите себе быстрый компилятор на божественном Ruste, а мы посмеёмся.
При том что сам аргумент о тормознутости шланга абсолютно лживый. Обычно компилю clang/llvm поскольку собирает он быстрее чем gcc.
2018 год: Historically, the compiler has compiled your entire project, no matter how little you've changed the code. The idea with incremental compilation is that you only need to compile the code you've actually changed, which means that that second build is faster.
2021 год: Incremental compilation is off by default for release builds, so few production builds should be affected. Miscompilations that can arise from the bugs in incremental compilation generate incorrect code in final artifacts, essentially producing malformed binaries, which means that in theory any behavior is possible. In practice we are currently only aware of one particular known miscompilation, but bugs due to incremental are notoriously hard to track down: users frequently simply rebuild after some light editing if they see unexpected results from their binaries, and this often causes sufficient recompilation to fix the bug(s).
> users frequently simply rebuild after some light editing
Кстати, это вполне распространённая практика на FPGA, когда пытаешься впихнуть невпихуемое да ещё чтобы на высокой частоте работало... У альтеры даже тула для брутфорса seed'а прилагается и кнопочка "мне повезёт".
Когда какая-нибудь хуй-ня в глубине проекта не собирается при быстрой (инкрементальной) сборке и потом всё глючит и пидорасит. Обычно лечится полным ребилдом.
Да хуй с ним, полный ребилд не так страшен, как некорректная сборка...
Проблема в том, что есть ситуации, когда зависимость от какого-то файла или таргета указать забыли, но так вышло, что она удовлетворена. В итоге меняешь файл, а система сборки какой-то кусок проекта не пересобирает. На выходе получается UB.
Но пацаны, как всегда, не обратили внимания на это хаскель-отребье. Пусть беснуется, что с него взять? >>джава
>> листа Integer в массив интов
Выбрось каку. Это кака, выбрось! Фу!
А я люблю обмазываться не свежим программным обеспечением, и дрочить. Каждый день я хожу по земле с черным мешком для мусора и собераю в него все List<Integer> которое вижу.
Ну серьёзно. Привёл пример убогости Жабы (кстати скоро там напилят primitive value-types)?
Причём список ну и ладно. А тут же массив интов (!) явно для экономии памяти и байтоёбства.
И в том же предложении писать про тяжеловесные лямбды, которые в несколько раз медленее цикла.
Никлаус Вирт считает, что ООП — не более чем тривиальная надстройка над структурным программированием, и преувеличение её значимости, выражающееся, в том числе, во включении в языки программирования всё новых модных «объектно-ориентированных» средств, вредит качеству разрабатываемого программного обеспечения.
Я за Вирта
Вообще я мог бы сыграть за ООПидоров малость, но мне стыдно:-/
«А MVC это что-то хорошее? Сплошное недопонимание и суеверия. За MVC не стоит никакой теории, если сравнивать, даже у криптозоологии есть больший научный базис, чем у этой дурацкой затеи.»
В ООП архитектур интерактивного приложения n интерпретируется как количество нагромождений (наслоений) множества из n питулей. Например, для множества {Model, View, Controller, Service, Paradigma}:
Мне ясно как спроектировать вариации естественно шанс есть чем надем на 4 и чем 64, но хотелось улучшить еще шанс потому:
мы возьмем рахитектуру 4 разположение 8, унас получается 8!/4!=MVCCS
1234 5678
мне пожалуста 1680 вариаций данной архитектуры.
а можно тут чуточку по подробнее?
у меня есть код на яве.
я использовал библиотеку blazeDS.
я нашел этот код в гугле, и применил его.
сжал в байтаррей.
и закинул в localhost.
вроде бы я все правильно сделал.
но какие то глюки возникли.
ошибки нету.
но может байт аррей не правильно использую?!
подскажите нубику.
мне просто нужно сжать датасет в amf.
> Вирт считает, что ООП — не более чем тривиальная надстройка над структурным программированием
Вирт просто анскильный, завистливый лох, который обсирал всё чужое.
Вечно завидовал более успешным языкам: гнал на Сишку, гнал на C++, гнал на Бейсик.
При этом самый жопулярный язык, с синтаксисом унаследованным от Вирта — это Delphi...
Когда его предложение Ады слили на конкурсе, они с Хоаром страшно бомбили по этому поводу.
> Как Вы относитесь к языку Object Pascal, который лег в основу Delphi и какое участие Вы в нем принимали, если принимали его вообще
>>Вирт: Когда вы программируете на Delphi, вы программируете на Паскале. Здесь ничего фундаментально нового нет. Но это была достаточно успешная разработка и во многих случаях помогала продвигать Паскаль. Я никак не участвовал в этой разработке
«Это ООП, у кого надо ООП.»
«ООП конечно хуйня, но ООП в моём Паскале — успех»
Object появился в «Turbo Pascal 4.0», оттуда его подхватили все реализации «Object Pascal». Его можно было создавать и на стеке, и в сегменте данных, и на куче.
Class появился в «Delphi», оттуда тоже был заимствован более новыми реализациями «Object Pascal». Добавили новую фигню вроде свойств с геттерами-сеттерами, но запретили создавать в сегменте данных и на стеке, прибили гвоздями аллокатор в куче, чтобы классами смогли пользоваться питухи анскильные. И обсыпали сахарком, чтобы не надо было писать оператор разыменования, тоже для питухов анскильных.
Владимир Кладов решил, что «VCL» тормозит, потому что в бормандовской реализации «class» много оверхеда (обязательная аллокация в куче там, где она не нужна и т. п.), поэтому переписал все компоненты на «object». Естественно, от синтаксиального сахара вроде пропертис пришлось отказаться, заменив их явными вызовами методов.
> «ООП конечно хуйня, но ООП в моём Паскале — успех»
"ООП" это такая эфемерная хуйня, что какой-нибудь питух может на структуру и какие-то функции работающие с структурой сказать "кокококок так это же ООП!!!"
Угу, оказывается, IDE на «Turbo Vision» вышла только вместе с «TP6» в 1990-м году. До этого там была IDE, похожая на «Кубасик», только ещё примитивнее.
В турбоIDE то всё было заебись: и интерактивный дебагер с вотчами и сборщик проекта и интерактивный хелп и лексер с подсветкой и индент, и даже строчку показывало с ошибокй
Для начала 90-х просто пиздец как круто для писюка-то
Не удивлюсь правда, если это всё в емаксе тоже уже было.
Можно было ещё через MODE CON переключить или через сторонний софт, но приложения обычно переключали режим обратно, потому что были прибиты гвоздями к фиксированному разрешению.
Так то-то и оно. Приложения работали через API, предполагающий текстовый режим. Можно было вероятно заместить досвое прерывание и поддержать SVGA сосноль, но они соснули бы по причине незнания размеров экрана.
А уж если срали в память напрямую, то и вовсе пиши пропало.
Вот в прыщах и FreeBSD есть графическая консоль (в прыщах вообще издревле был fbcon).
Там приложение и не знает, на чём оно работает. Размеры может взять у структуры, связанной с терминалом через какие-то ioctl или терминальный API
Вирт не любил язык «Ада». Он считал, что её спецификация перегружена, поэтому назло создателям языка «Ада» Вирт создал «Оберон», в котором почти ничего нет.
> Я признаю, что в некоторых задачах (BLAS и подобное) функциональщина нецелесообразна.
Функциональщина может быть целесообразной на задачах типа "BLAS" если архитектура вычислителей хорошо ложится на ФП. Например, есть такие штуки, называются "systolic array"
Или "ФП" в массовом сознании айтишников ассоциируется с каким-то типодрочерством, зависимыми типами там всякими, Хиндли-Милнером? Так вот, это не "ФП", это "программирование на типах". В кобенандном SKI исчислении никаких "типов" нет.
Ну т.е. в твоём примере не ощущается, что функция -- это first-class object.
-- композим функцию из кусочков
f = mul2 . add2 . add2
-- теперь лифтим её, получая функцию, которая обрабатывает списки
m = map f
-- и можем процессить её сколько угодно списков
r = m a
А второй кусок и читается гораздо приятнее, и работает куда быстрее.
> total decoding time for the test clip I used shrank from 6.6 seconds to 4.9 seconds
Замена одного небольшого цикла ускорила ВЕСЬ декодер на 35%.
Именно поэтому рассказы что у нас компиляция тупит из-за «навороченного супероптимизирующего конпелятора» — тупая пропаганда для подростков.
Постоянно проигрываю с этого сектанткого аргумента «LLVM is notorious for being slow».
Напоминает плохого танцора, которому то мешали туфли, то некоторые части тела.
Коли не нравится LLVM, зачем было его воровать? Напишите себе быстрый компилятор на божественном Ruste, а мы посмеёмся.
При том что сам аргумент о тормознутости шланга абсолютно лживый. Обычно компилю clang/llvm поскольку собирает он быстрее чем gcc.
Шланг и гцц компилят изменившиеся файлы. А растишки вроде как весь проект целиком скармливают в LLVM. Вместе с зависимостями.
2021 год: Incremental compilation is off by default for release builds, so few production builds should be affected. Miscompilations that can arise from the bugs in incremental compilation generate incorrect code in final artifacts, essentially producing malformed binaries, which means that in theory any behavior is possible. In practice we are currently only aware of one particular known miscompilation, but bugs due to incremental are notoriously hard to track down: users frequently simply rebuild after some light editing if they see unexpected results from their binaries, and this often causes sufficient recompilation to fix the bug(s).
> unexpected results from their binaries
Воть вить как. А я то думал там мате-ма-ти-че-ски доказанная кукарректность.
У дrustунов сложность разбора чуть ли не O(N²). Но во всём виноват понятно дело llvm.
Кстати, это вполне распространённая практика на FPGA, когда пытаешься впихнуть невпихуемое да ещё чтобы на высокой частоте работало... У альтеры даже тула для брутфорса seed'а прилагается и кнопочка "мне повезёт".
Вот кстати, хоть одна билд система решила проблему случайно удовлетворившихся зависимостей из-за которой все эти косяки с инкрементальностью и лезут?
типа не надо было пересобирать, а пересобрали и получили багор?
Cmake в этом плане гораздо лучше.
Но вообще дико бесит это сишное макроговно, когда поменял один дефайн, а ему приходится из-за этого пересобрать половину проекта.
Меня успокаивает только одно: Still better than rust.
Проблема в том, что есть ситуации, когда зависимость от какого-то файла или таргета указать забыли, но так вышло, что она удовлетворена. В итоге меняешь файл, а система сборки какой-то кусок проекта не пересобирает. На выходе получается UB.
Чем больше явных циклов -- тем лучше.
Аа!! Четвёртая джава! Я отеку от того, что для преобразования листа Integer в массив интов нужно явно писать цикл!
Есть такие?
Но пацаны, как всегда, не обратили внимания на это хаскель-отребье. Пусть беснуется, что с него взять?
>>джава
>> листа Integer в массив интов
Выбрось каку. Это кака, выбрось! Фу!
Причём список ну и ладно. А тут же массив интов (!) явно для экономии памяти и байтоёбства.
И в том же предложении писать про тяжеловесные лямбды, которые в несколько раз медленее цикла.
Ну хочешь на QBasic поменяю? Или на BP
Жид не справится с инлайном?
Но по свежим бенчам на phoronix 8я ява держится бодрячком и бегает быстрее всех.
Так что сомневаюсь что стало лучше.
https://www.overops.com/wp-content/uploads/2020/09/functional.benchmark.png
Как мы видим функциональная мразь опять обосралась, но с неё так никто за это и не спросил.
https://yomama.simtech-ag.ch/blog/java/streamsvsfor
https://image.slidesharecdn.com/javanturav4-javaandlambdasandstreams-aretheybetterthanforloops-aleksanderradovanbrankomihaljevi-170217080007/95/javantura-v4-java-and-lambdas-and-streams-are-they-better-than-for-loops-aleksander-radovan-branko-mihaljevi-22-638.jpg
Последний график очень комплиментарен к стримам, и всё-равно они сливают.
Куда лучше, чем с 100500 императивных строк
Царь.
Я признаю, что в некоторых задачах (BLAS и подобное) функциональщина нецелесообразна.
Вот у ООП задач нет, тут всё ясно.
А как же написание статей о костылях, которые нельзя выразить средствами языка паттернах?
Гуи всякие, не?
Checkbox extends Button extends Widget, не?
Привычка.
Хех, придётся кому-то из нас перезайти за ООП'шников. Скучно, когда все на одной стороне.
Я за Вирта
Вообще я мог бы сыграть за ООПидоров малость, но мне стыдно:-/
Мне даже в полит-тредах не было стыдно за всяких питухов заходить. Но чтобы за ООП... Нет.
++
Вот кстати у wvxvw это очень недурно получалось.
Он заходил с того что в C++/Java/C# неправильное, убогое ООП. А нормальное например в CL, где есть мультиметоды.
А потом долго тупил про всякие заумные штуки, так что оппонент начинал нервничать и сливаться.
Виртуоз.
Охуенный тред. Помню как читал, и ловил эстетическое удовольствие от унижения MVC-дешёвок.
Жаль что хаброскоты это не читали.
https://govnokod.ru/16298#comment239203
«А MVC это что-то хорошее? Сплошное недопонимание и суеверия. За MVC не стоит никакой теории, если сравнивать, даже у криптозоологии есть больший научный базис, чем у этой дурацкой затеи.»
Вот тебе бристольская шкала паттернов
https://habr.com/ru/post/344184/
https://glossar.hs-augsburg.de/Model-View-Controller-Service-Paradigma
https://glossar.hs-augsburg.de/Logic-Data-View-Controller-Service-Paradigma
А «Джагу-джагу» с её «TVM»?
А «HMVC» (hierarchical model-view-controller)?
https://en.wikipedia.org/wiki/HMVC
Те тоже могли столетиями обсуждать триедин ли бог
зы: у джаги MTV
> Те тоже могли столетиями обсуждать триедин ли бог
https://i.imgur.com/lq2LSAA.png
https://twitter.com/grady_booch/status/1028020194227060738
В итоге дешёвки слились, и легли под всяких монофизитов, напустив к себе исламистов.
В ООП архитектур интерактивного приложения n интерпретируется как количество нагромождений (наслоений) множества из n питулей. Например, для множества {Model, View, Controller, Service, Paradigma}:
MVVCP MVCSP MPCSP MCCSP
CVVCP CVCSP CPCSP SCCSP
MVMCP MVPSP MPPVP CCVSP
Мне ясно как спроектировать вариации естественно шанс есть чем надем на 4 и чем 64, но хотелось улучшить еще шанс потому:
мы возьмем рахитектуру 4 разположение 8, унас получается 8!/4!=MVCCS
1234 5678
мне пожалуста 1680 вариаций данной архитектуры.
D:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC ;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CC DCLCSWRPWPDTLOCRSDRCWDWO;;;BA)
g: "Windows SDDL"
> у ма-те-ма-ти-ков
ХАХАХАХАХА
при всём уважении к израильтянину, но как-то экшонстриптиз слабо вяжется с ма-те-ма-ти-кой
http://www.flasher.ru/forum/member.php?u=37925
а можно тут чуточку по подробнее?
у меня есть код на яве.
я использовал библиотеку blazeDS.
я нашел этот код в гугле, и применил его.
сжал в байтаррей.
и закинул в localhost.
вроде бы я все правильно сделал.
но какие то глюки возникли.
ошибки нету.
но может байт аррей не правильно использую?!
подскажите нубику.
мне просто нужно сжать датасет в amf.
многообещающее начало
Вирт просто анскильный, завистливый лох, который обсирал всё чужое.
Вечно завидовал более успешным языкам: гнал на Сишку, гнал на C++, гнал на Бейсик.
При этом самый жопулярный язык, с синтаксисом унаследованным от Вирта — это Delphi...
Когда его предложение Ады слили на конкурсе, они с Хоаром страшно бомбили по этому поводу.
Ни один из его языков не стал мейнстримом.
>>Вирт: Когда вы программируете на Delphi, вы программируете на Паскале. Здесь ничего фундаментально нового нет. Но это была достаточно успешная разработка и во многих случаях помогала продвигать Паскаль. Я никак не участвовал в этой разработке
«Это ООП, у кого надо ООП.»
«ООП конечно хуйня, но ООП в моём Паскале — успех»
Двуличная мразь.
В object pascal'е, насколько помню, был object. В делфи object остался как value type, а class как ссылочная хуй-ня на куче.
ну и говно
В «Standard Pascal» не было ни class, ни object.
Object появился в «Turbo Pascal 4.0», оттуда его подхватили все реализации «Object Pascal». Его можно было создавать и на стеке, и в сегменте данных, и на куче.
Class появился в «Delphi», оттуда тоже был заимствован более новыми реализациями «Object Pascal». Добавили новую фигню вроде свойств с геттерами-сеттерами, но запретили создавать в сегменте данных и на стеке, прибили гвоздями аллокатор в куче, чтобы классами смогли пользоваться питухи анскильные. И обсыпали сахарком, чтобы не надо было писать оператор разыменования, тоже для питухов анскильных.
У Вирта ООП было только в «Модуле-3».
Вру, «object» появился только в 5.0 или в 5.5, нужно уточнить.
https://ru.wikipedia.org/wiki/KOL
Владимир Кладов решил, что «VCL» тормозит, потому что в бормандовской реализации «class» много оверхеда (обязательная аллокация в куче там, где она не нужна и т. п.), поэтому переписал все компоненты на «object». Естественно, от синтаксиального сахара вроде пропертис пришлось отказаться, заменив их явными вызовами методов.
> «ООП конечно хуйня, но ООП в моём Паскале — успех»
"ООП" это такая эфемерная хуйня, что какой-нибудь питух может на структуру и какие-то функции работающие с структурой сказать "кокококок так это же ООП!!!"
пасцаль, ранние кресты, достаточно старая сишка и обкектив в качестве bleeding edge
гвозди бы делать из этих людей
Автоиндент вроде уже был. И подсветка. И отладчик. Турбо-ИДЕ очень няшные же были.
но подсветка до сих пор сосёт. где мой semantic highlighting в каждом редакторе?
TP с этим IDE вышел в самом начале 90-х, не?
В турбоIDE то всё было заебись: и интерактивный дебагер с вотчами и сборщик проекта и интерактивный хелп и лексер с подсветкой и индент, и даже строчку показывало с ошибокй
Для начала 90-х просто пиздец как круто для писюка-то
Не удивлюсь правда, если это всё в емаксе тоже уже было.
Кстати, а вот что было у яблока
https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop
https://en.wikipedia.org/wiki/MacsBug
уже тогда был лишп
но пришли "у нас в контроллерах нет нихуя" и начались тёмные века
80×50 — это был режим с анскильным шрифтом 8×8 пикселей, от которого резало глаза.
Это уже в 90-е на «SVGA» появились разрешения 132 на что-то.
Да, по умолчанию запускалась в 80×25, надо было переключать самому в нужный режим. «Дос Навигатор» в этом режиме работал.
Насчёт борландовской IDE не помню. Вроде она хотела старые режимы с шириной 80.
В смысле приложение переключало? Это не считается, потому что нужно все приложения патчить
А уж если срали в память напрямую, то и вовсе пиши пропало.
Вот в прыщах и FreeBSD есть графическая консоль (в прыщах вообще издревле был fbcon).
Там приложение и не знает, на чём оно работает. Размеры может взять у структуры, связанной с терминалом через какие-то ioctl или терминальный API
В «Дос Навигаторе» был пропатченный «Турбовижн». Он знал про «VBE» («VESA BIOS Extensions»).
А уж графических функций в «DOS» вообще не было, поэтому графические программы срали и в порты, и в память.
Вот с дискурсом Царя как-то проще. У него есть рациональное зёрнышко Фофмана.
С другой стороны когда весь мейнстрим наконец-то проклянет ООП...
Какой прогресс )))
Это преподносилось как новый, крутой способ
Можешь билдить прошивку в докере чтобы не надо было ничего настраивать и ставить на хосте.
Но в контроллере никакого докера от этого магическим образом не появится.
А билдить прошивку можно и в виртуалке, и на какой-нибудь VPS-ке, но от этого у меня в контроллере не появится ни виртуалки, ни VPS
https://github.com/Fmstrat/samba-domain
Потом будешь читать ошибки ``INVALID_HANDLE`` в логах винды, делать ``sfc /scannow`` и обращаться к системному администратору )
Алсо,
https://wiki.samba.org/index.php/Windows_2012_Server_compatibility#Other_ missing_features
AD и так таит в себе много сюрпризов (кто видал USN roll-back, тот на фильмах ужасов не боится) а еще и с линуксом его мешать
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd363553(v=ws.10)#usn-and-usn-rollback
В AD каждый объект имеет монотонно возврастающий номер версии (USN), и информацию о том, какую версию на какой соседний контролер послали.
Когда объект изменяется, у него увеличивается этот номер, и он посылает обновления на другие контроллеры.
Вот ты восстанавливаешь контроллер из бекапа, и у него оказывается более древняя версия какого-то объекта.
Другие контроллеры не шлют ему изменения, ведь они уверены, что у него и так последняя версия с их точки зрения.
Ты на нем изменяешь объект, он увеличивает версию, и шлет данные другим контроллерам, но они не принимают изменений, ведь у них более новая версия.
Получается split brain.
Вот как про это написино в логах:
https://mvvrus.files.wordpress.com/2015/03/event2095.png
Поскольку в мире AD без AD не работает примерно всё, то баги начинаются феерические
А если просто сеть между контроллерами порвётся и на каждом из них админ что-то закоммитит?
DC1: "У меня новая версия петуха, а у DC2 старая. Я ему сообщу, когда он будет онлайн"
DC2: "У меня новая версия курочки, а у DC1 старая. Я ему сообщу, когда он будет онлайн"
А вот если оба одновременно поменяют данные, то наверное победит тот, у кого более свежая версия.
Жопа с роллбеком именно в том, что DC1 уверен, что он уже передавал данные DC2.
А у DC2 их нет
Функциональщина может быть целесообразной на задачах типа "BLAS" если архитектура вычислителей хорошо ложится на ФП. Например, есть такие штуки, называются "systolic array"
Например вот https://cplu.medium.com/should-we-all-embrace-systolic-array-df3830f193dc - там в гугловых TPU по-сути массив вычислительной хуйни, по которой прокачиваются какие-то байтики. Чем вам это не ФП?
Или "ФП" в массовом сознании айтишников ассоциируется с каким-то типодрочерством, зависимыми типами там всякими, Хиндли-Милнером? Так вот, это не "ФП", это "программирование на типах". В кобенандном SKI исчислении никаких "типов" нет.
..с отображением одной последовательности на другую, иными словами с методом "map" у класса с коллекцией
В труъ ФП, к примеру, было бы идиоматичнее заюзать композицию вместо массива.
* кроме всяких VHDL пожалуй
Ну и вот кстати есть: http://ghdl.free.fr/
А рантайм питона на няшной вполне практичен.
> А рантайм питона на няшной вполне практичен.
А может и от питона тоже "ощущения не те", и надо делать специальную питон-машину(по аналогии с лисп-машиной), чтобы питон давал нужные ощущения?
Вот видишь, дяденька Пи, ленивые вычисления даже в няшную сишку на микроконтроллеры завезли.
Это скорее "ленивое программирование".
Кстати, а есть файка PHPidor?