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

попробуй luajit
заодно померяй, во сколько раз медленнее сишки –

local bit = require("bit")
function repeat_key(key, length)
    if #key >= length then
        return key:sub(1, length)
    end

    times = math.floor(length / #key)
    remain = length % #key

    result = ''

    for i = 1, times do
        result = result .. key
    end

    if remain > 0 then
        result = result .. key:sub(1, remain)
    end

    return result
end

function xor(message, key)
    rkey = repeat_key(key, #message)

    result = ''

    for i = 1, #message do
        k_char = rkey:sub(i, i)
        m_char = message:sub(i, i)

        k_byte = k_char:byte()
        m_byte = m_char:byte()

--        xor_byte = m_byte ~ k_byte
        xor_byte = bit.bxor(m_byte, k_byte)

        xor_char = string.char(xor_byte)

        result = result .. xor_char
    end

    return result
end

return xor

#!/usr/bin/env luajit

local xor = require 'xor'
local str = 'test string'
local key = 'key'

io.write(xor(str,key))

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

удаляйте

Под ЮИ или консольные мокро**ськи - терпи и юзай кресты.

Под ынторпрайз бек - только жява.

питон тормознутый в двух случаях:

• когда кто-то написал об этом на форуме.

только уж слишком тормознутый

но он таакой тормоз

• когда я специально написал бенчмарк и сравнил насколько медленее чем го он перемножает между собой миллион элементов массива.

уже 100500 раз это обсуждалось.

сначала написал на Python, а потом всех их переписал на BASH

какая лють.

Вау, еще один талантливый разработчик на старте!

Вкатывайся в JS.

когда я специально написал бенчмарк и сравнил насколько медленее чем го он перемножает между собой миллион элементов массива.

уже 100500 раз это обсуждалось.

В функции XOR шифрования, насколько я помню, нет ни единого умножения.

Только цикл, обращение к памяти и XOR двух байт. XOR, насколько я помню по assembler, одна из самых быстрых операций процессора.

На чем тогда тормозит Python? На цикле? Ну извините… Это основная конструкция в любом ЯП. Если она работает медленно, то извините. Лес - там!

Если медленное обращение к памяти, то тоже самое о лесе и направлении.

Я понимаю, что Python со встроенным сборщиком мусора, но, блин, я специально написал на Python так, что бы выделение и освобождение памяти происходило один раз за вызов функции. И разница по скорости в 1000+ раз - это явный перебор.

Вот я и решил копнуть Rust и Golang…

Meh.

Learn Common Lisp and Idris.

И разница по скорости в 1000+ раз - это явный перебор.

https://benjdd.com/languages2/

попробуй luajit заодно померяй, во сколько раз медленнее сишки –

Вот, блин… Я, вообще в первый раз узнал, что есть такой язык luajit.

Беда в том, что даже рассматривать данный язык - бесперспективно.

Он может быть чудо как хорош! Вот, просто идеальный! И под мои задачи, возможно, подойдет наилучшим образом. Но это ни чего не меняет. Ни кто не даст согласие на использование малоизвестного языка.

Я уволюсь и что? Где, как и сколько по времени будут искать нужного специалиста, еще и знающего luajit?

пельмешек бун в картинке есть, а кристов нету. как так то

На то и пайтон, чтоб его не оставалось.

я бы сразу увольнял тех кто в рабочие проекты тянет маргинальщину

На то и пайтон, чтоб его не оставалось.

https://benjdd.com/languages2/

Мама, дорогая!

Мне одному кажется, что разрабов Python нужно «Вывести в чисто поле, поставить лицом к стене, да пулю в лоб!»

вот я бы попрограмулькал на этом бы

если бы за это хотя бы 300к платили

ну тогда пиши на том, на чем говорит работодатель.

ну типа одно и то же.

а если какие то крестовые оптимизации всунуть.

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

Lua и R «медленнее»

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

был лишен неудобств старичка С

Это не неудобства Си, это недоработки в твоём образовании. Исправь их.

Вкатывайся в JS.

JS - узкоспециализированный язык. Пусть его насильственно расширили костылями, он не стал широкопрофильным.

Я работал в одной фирме, так там была толпа РНРшников. Ну они на этом РНР пилили подо все задачи.

Все было хорошо, но потом, внезапно, от заказчиков посыпались претензии, что со временем происходит переполнение памяти.

Те мудрецы на РНР запилили сервисы, которые работают неприрывно.

Ни что не настораживает?

В PHP нет сборщика мусора! Он не предназначен для длительной работы скрипта. РНР постоянно по чуть-чуть выделяет память, но ее не освобождает! И через какое-то время, out of memory.

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

А если скрипт крутится длительное время, то он сожрет всю память.

Я не хочу сказать, что у JS те же проблемы. Просто этот «язык» первоначально запилили под frontend. Потом уже начали его костылить и расширять.

Это не неудобства Си, это недоработки в твоём образовании. Исправь их.

Вот это я понимаю!

Коротко и по делу.

Сразу понимаешь, что посоветовал Великий Гуру.

Хочется некий язык общего назначения что бы он был быстрым и был лишен неудобств старичка С, но, по ходу, нет гармонии в мире IT.

https://learn.adacore.com/

Cи такой анахронизм, что придется переучиваться на что-то нормальное рано или поздно. Смотрите в сторону Zig и Odin. Rust это своя вселенная. Ну и конечно рекомендую почитать, почему принято то или иное решение в языке и синтаксисе. Еще в питоне можно отдельные функции компилировать в жит с помощью numba или jax. А еще есть Julia, которая является динамическим языком, но все компилит в жит.

На 1С пиши

А для каких целей вам нужен новый ЯП?

В PHP нет сборщика мусора!

Уже давно есть

Я не хочу сказать, что у JS те же проблемы.

Это было мудрое решение)

А для каких целей вам нужен новый ЯП?

Для самых широких. Он вечноработающих сервисов до простенькой автоматизации.

Я понимаю, что для автоматизации хорошо подходят bash & Python, но у Python сложности с переносимостью, а у bash код получается очень плохо читаемым. Мне сложно разбираться даже в своем ранее написанном коде.

Хотелось бы некий мопед, типа Go. Написал, скомпилил, и таскаешь по мошинам не задумываясь о версиях библиотек, но Go мне не нравится. Нет в нем лаконичности. К тому же, по скорости он не рекордсмен.

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

Cи такой анахронизм, что придется переучиваться на что-то нормальное рано или поздно.

Анахронизм. Согласен.

Однако, этот анахронизм еще нас с вами переживет.

К тому же, найти худо-бедно админа с худо-бедно знанием С, намного проще чем со знаем Rust, Go & etc.

По большому счету, C & bash script закрывает все хотелки, только…

Bash код, даже свой собственный, сложно читаемый.

Си слишком долог и сложен в разработке.

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

Блин, согласен с каждым словом! Вот только почему-то ни кто этой рекомендации не следует!

но вот на него переползти с С для меня окажется или непосильной задачей

Значит ты СИЛЬНО соврал что знаешь С. Так как архитектурный дизайн Rust’a ты бы сразу понял, будь нормальным СИшником. А так ты бездарь и неуч. Не занимайся программированием.

Значит ты СИЛЬНО соврал что знаешь С. Так как архитектурный дизайн Rust’a ты бы сразу понял, будь нормальным СИшником. А так ты бездарь и неуч. Не занимайся программированием.

Еще один Великий Гуру нашелся…

Могу дать совет, всем желающим, как на профильных форумах пользоваться уважением и прослыть великим специалистом:

1. Ни какой вежливости! Только хамство! Так лаконичнее и информативнее.

2. На любой вопрос нужно отвечать коротко и по существу. RTFM - лучший ответ.

3. Если, по какой-то причине RTFM не совсем подходит, то: «В Гугле забанили?»

Пользуясь этими тремя несложными правилами вы гарантированно обретете репутацию Великого Специалиста!

дайте ему говна на лопате

Для самых широких.

ИМХО, такой подход очень плохой, лучше использовать несколько разных языков, каждый под свои задачи.

Говорят, что связка Си + Tcl довольно приятная, но с последним я пока только познакомился, поэтому особо ничего не могу сказать. Python вроде за собой тащит полный интерпретатор Tcl.

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

Или какой-нибудь Lisp.

Или вообще ДРАКОН. :)))

Паскаль. Почти как сишка, но строки сделаны правильнее и есть модули. А в остальном — то же самое.

А как там со строками длиннее 255 символов?

Странно что ты пересмотрел все извращения, но не обратил внимание на .net/c#.
Это как раз и есть:

язык общего назначения что бы он был быстрым и был лишен неудобств старичка С

Поверхностно знаком с Python. Он не плох, только уж слишком тормознутый.

mojo

Ну нафига тип переменной идет после ее названия? Типа, Golang не С? Впрочем, у Rust то же самое. Ну зачем???

Не легко тебе живется.

В общем, я в печали.

c3

Я понимаю, что для автоматизации хорошо подходят bash & Python, но у Python сложности с переносимостью, а у bash код получается очень плохо читаемым. Мне сложно разбираться даже в своем ранее написанном коде.

bash - не подходит никак. И ты сам же сразу расписал почему. python подходит, да, но Си лучше.

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

Да ну. Всё там норм. Попытки изобразить из строки цельный объект данных (как ты видимо хочешь) неизбежно приводят к оверхедам и неоптимальным алгоритмам, в Си так не принято.

Посмотри вакансии в своем регионе, на них и ориентируйся.

Как-то так:

var
  Test: string;  // Declare a new Unicode string
begin
  SetLength(Test, 100000);   // Initialize it to hold 100000 characters
  Test := StringOfChar('X', 100000);  // Fill it with 100000 'X' characters
end;

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

Поэтому самый жирный открытый проект на Си – ведро люнекса – ровно так и делает:

struct seq_buf {
        char                    *buffer;
        size_t                  size;
        size_t                  len;
};

Даже Лойнуса затрахали эти ваши nul-terminated strings. Абсолютно парашная идея с самого начала.

«Правильнее» тут не подходит. Просто пожертвовали универсальностью и скоростью ради приближения к бытовому пониманию строки. В Си такие строки тоже можно сделать, если напишешь для них небольшую библиотеку.

Не занимайся подменой понятий. seq_buf это не строка. И подобные структуры я и сам часто использую, но отказа от asciiz-строк они не подразумевают. Это разные штуки для разных областей применения.

А вот нет.

program prog;

var
  Test: string;
  c: char;
  j: integer = 0;
begin
  SetLength(Test, 100000);
  Test := StringOfChar('X', 100000);
  for c in Test do
    Inc(j);
  WriteLn(j);
end.

$ ./main 
255

Там или нужна директива {H+} или использовать AnsiString.

Не занимайся подменой понятий. seq_buf это не строка.

seq_buf в ядре используется для строк.

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

Конечно не подразумевают, когда у тебя весь библиотечный код требует asciiz. Проще выкинуть стандартную библиотеку Си нахрен и сделать вид, что этого позора нет и никогда не существовало. Что, кстати, некоторые проекты и делают.

Это разные штуки для разных областей применения.

Основная область применения нул-терминированных строк – заставлять сишников обсираться на ровном месте и ловить сегфолты. Больше смысла в этом выкидыше прогаммистской мысли нет.

Напиши лучше свой язык.

Даже Лойнуса затрахали эти ваши nul-terminated strings. Абсолютно парашная идея с самого начала.

bstring?