LINUX.ORG.RU

Ищщется компилируемый ЯП с динамической типизацией

 


0

1

Собственно ${SUBJ}. Был бы php компилируемый - цены бы ему не было.

Есть конечно мысль нарисовать обертку к duktape в стиле «а теперь мы компилируем ваш бейсик в exe»... (и выйдет электрон, ха-ха), но как-то лень. Ведь всё уже давно написано до нас?

Добавлю про применение.

Есть портянка текста (ASCII, никаких вам юникодов с псевдографикой) которую надо распарсить и привести в другую портянку текста. В зависимости от того, что распарсилось в 35 строке 5 колонке (условно) надо дропнуть всё, что было в определенном блоке (с 15 по 22 строку). Или наоборот - добавить.

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

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

Языки с всяким байт-кодом - это хорошо, но никакого толку. Тулза вызывается раз в ннадцать минут, отрабатывает один раз - прогрева *vm тупо нет и не будет, радости и пользы от него (ну кроме как - ухтыё, у нас и такое есть) - нет.

А я ищу язык, рантайм которого не весит гигабайты и зависит только от $LIBC.

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

noconformism ()

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

moot ★★★ ()
Ответ на: комментарий от peregrine

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

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

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

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

LynxChaus ()
Ответ на: комментарий от moot

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

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

LynxChaus ()
Ответ на: комментарий от nikolnik

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);
парит.

LynxChaus ()
Ответ на: комментарий от LynxChaus

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

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

https://blog.golang.org/slices

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

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

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

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

nikolnik ★★★ ()
Ответ на: комментарий от nikolnik

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

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от LynxChaus

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

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

noconformism ()

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

Singularity ★★★★ ()
Ответ на: комментарий от peregrine

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

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

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

Кто писал?

dave ★★★★★ ()
Ответ на: комментарий от Singularity

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

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от nikolnik

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

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

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

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

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

LynxChaus ()
Ответ на: комментарий от LynxChaus

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

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

Unicode4all ★★★★ ()
Ответ на: комментарий от LynxChaus

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

nikolnik ★★★ ()

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

mr_Heisenberg ()

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

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

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

Virtuos86 ★★★★★ ()
Ответ на: комментарий от dave

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

peregrine ★★★★★ ()

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

Anoxemian ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от LynxChaus

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

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

crutch_master ★★★★★ ()

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

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

anonymous ()

ТСу

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

sqq ()

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

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

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)

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

anonymous ()

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

menangen ★★★★★ ()
Ответ на: комментарий от KivApple

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

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

anonymous ()

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

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

Ushenin ()
Ответ на: комментарий от anonymous

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

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

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

LynxChaus ()

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

dnb ★★ ()
Последнее исправление: dnb (всего исправлений: 1)

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

menangen ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.