Хоть бы википедию глянул.

http://nuitka.net/pages/overview.html

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

фейсбук же или кто там сделал давно уже компилятор пыха в кресты — вот и возьми, раз тебя пых устраивает.

Haskell ибо -fdefer-type-errors.

Хоть бы википедию глянул.

Да глядел я туда, глядел.

Когда я говорил компилируемый - я подразумевал, что это будет нативный бинарь, а не байт-код для очередного LLVM.

И да - питон во всех его вариациях не предлагать.

Golang

https://play.golang.org/p/9heA0UCGBJ

фейсбук же или кто там сделал давно уже компилятор пыха в кресты

Нету этого уже, всё в hack и hhvm ушло.

Common Lisp

Golang

Оно динамические массивы хреново умеет. Писать на нем в стиле

    foreach ($input as $k => $v) {
        $data[$Node][$subNode] += [ $k => $v ];
    }

Да и всю остальную лапшу в виде

reg, err := regexp.Compile("[ ]+")
if err != nil {
   log.Fatal(err)
}
str := reg.ReplaceAllString(string(input), ` `)

$str = preg_replace('/[ ]+/', ' ', $input);

Оно динамические массивы хреново умеет. Писать на нем в стиле

Вообще-то го имеет лучшие динамические массивы из компилируемых языков c невероятно лаконичным синтаксисом и называются они slices.

https://blog.golang.org/slices

Да и всю остальную лапшу в виде

reg, _ := regexp.Compile("[ ]+")
str := reg.ReplaceAllString(string(input)," ")

руки отвалятся.

Если у пхпшника, то это только к лучшему.

Вообще-то го имеет лучшие динамические массивы из компилируемых языков c невероятно лаконичным синтаксисом

Фанбой в треде.

а не байт-код для очередного LLVM

Вы путаете llvm и jvm.

Когда я говорил компилируемый - я подразумевал, что это будет нативный бинарь, а не байт-код для очередного LLVM.

А какой толк тогда от динамической типизации?

Haskell

Так ТС'у вроде динамически-типизированный нужен

А в чём собственно цель? Динамическая типизация - это скорее недостаток ИМХО.

Все дороги ведут в Рим

С++ и Qt. Вот класс который годен для этого http://doc.qt.io/qt-5/qvariant.html

ocaml

Smalltalk

Хоть бы википедию глянул.

Не вызывает доверия эта википедия уже давно:

Невозможна перегрузка процедур и функций по типу данных — только по количеству операндов.

Кто писал?

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

lisp, julia

Вообще-то го имеет лучшие динамические массивы из компилируемых языков c невероятно лаконичным синтаксисом и называются они slices.

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

Лучшие у них динамические массивы, блин.

Если у пхпшника, то это только к лучшему.

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

Для тех кто не распарсил - мне нужны многомерные ассоциативные массивы, а не пляски с бубном вокруг байтов.

А это что по-твоему? https://blog.golang.org/go-maps-in-action

а не байт-код для очередного LLVM.

Ты хоть бы почитал, что такое LLVM, и зачем оно нужно.

А это что по-твоему? https://blog.golang.org/go-maps-in-action

Жалкое подобие левой руки (С).

Я же ясно написал - мне надо [a][c]->[d][e]. Причем количество этих a,b,c,d,e - неизвестно.

Я смотрю использование пхп бесследно не проходит. Не поверишь, но можно создать хеш-массив в котором в качестве значения тоже будет хеш массив.

С++ с его dynamic_cast<> и virtual

Ну, товарищ, я знаю что вам прописать. Принимайте Vala по 7 раз в день и будете как огурчик.

И всё это надо сделать - БЫСТРО. Есть похожая фигня на питоне, которая на машине с E5320 о 32 гигах памяти и рэйдом - делает это за 3 секнуды.

Оптимизировать софтину не пробовали? Может стоит попробовать PyPy?

В принципе, задача синтетическая, знания библиотек не требует. Бери Rust, и будет тебе быстро, да и синтаксис богатый, раз тебя Go не устраивает.

будете как огурчик

зелёный и сморщенный

Хрустящий и с пупырками

Не имею понятия. Можешь в истории глянуть. Однако, список ЯП там есть и внушает доверие. А над тем разделом плашка стоит, что там муть написана без пруфов.

perl и perlcc? или он уже давно протух?

C++17 http://en.cppreference.com/w/cpp/utility/any

Lua/luajit тебе нужен. Еще tcl очень хорош со строками, но он не компилируемый.

Когда я говорил компилируемый - я подразумевал, что это будет нативный бинарь, а не байт-код для очередного LLVM.

Если у тебя будет нативный бинарь с вм, который будет гонять байт-код тебе будет легче? Делай на си, хватит вести себя как дебил.

И всё это надо сделать - БЫСТРО. Есть похожая фигня на питоне, которая на машине с E5320 о 32 гигах памяти и рэйдом - делает это за 3 секнуды. А это - а) медленно б) питон с его рантаймом, которого может и не быть на целевой машине (или места для него).

Если язык динамический, то от компиляции он стать может разве что медленнее.

Crystal?

ТСу

picolisp.com (Не благодари)

Тот же Python имеет JIT. Как и JavaScript, и Lua, и большинство других «интерпретируемых» языков. Если ты ещё не догадался, то главный тормоз в данных случаях как раз динамическая типизация и есть, а не мифический байт-код. Принесёшь её в полностью нативный язык - получишь ровно те же тормоза.

А вообще, для того же C++ есть различные реализации типа variant. Чем тебе не динамическая типизация?

Мейнстрим языки сейчас ничего не интерпретируют. Везде JIT\AOT. Бывает даже с пропуском промежуточных представлений (v8). От того, что ты рантайм динамического языка обернешь в нативный бинарь, скорости не прибавится.

Apple Swift же! Прекрасно работает под убунтой!

Chicken scheme

Если ты ещё не догадался, то главный тормоз в данных случаях как раз динамическая типизация и есть, а не мифический байт-код.

1. На самом деле мы не знаем, что именно у него там тормозит. 2. У него каждый раз она запускается, то есть JIT каждый раз отрабатывает. 3. Он хочет иметь один статически слинкованный бинарь.

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

Ни какого ускорения такая «компиляция» не даст. Практически все современные интерпретаторы обеспечивают быстродействие довольно близкое к теоретическому пределу доступному для динамической типизации.

Дисковое I/O у меня тормозит. Поменять - возможности нет и не предвидится, питон - пока свои все ошметки загрузит - уже таймтаут на операцию выйдет.

Да, мне нужен бинарь, который запуститься без квадрилиарда модулей из /usr/lib/{python,perl,lua}/...

Для те, кто читает между сторк - мне в принципе не впилась типизация, т.к. на входе текст, на выходе - текст. Конвертить «0001» в native int чтоб потом на выходе сконвертить его назад в string - потребности нет.

Nim. Библиотек, правда, не густо, но тебе хватит стд.

Про Groovy забыли? Тоже достойный язык для всяких веб и микро служб.

Там же JVM.