Hi,

after using the mikrotik scripting language I wonder why Mikrotik holds on to this archaic and painful language. It is widely known that there are small and useful alternatives like LUA or Micropython. I saw that LUA was supported in some Betas and then again dropped in some 4.X release. Is there anybody with more insights into this topic and could explain why in 2023 we seem to be stuck in the 80s with what we get for scripting? Having TCL on the Cisco back in the days was more comfortable than what we have here. And even if there needs to backward compatibility there seems to be enough flash in all newer devices with 7.x to have LUA or Micropython as an alternative.

Thanks,
Mischa

amen

Wait September and you will have a surprise with RouterOS v7.11.9...

@Mischa
Spot on ….

You're talking to a guy who bought his first Mikrotik specifically because I loved the idea of Lua being integrated with config. But since they didn't update their web pages, the unit I got didn't support Lua anymore...but totally unclear if your just read the wiki/webpage.

But I personally find the current scripting language one the greatest assets of RouterOS. It completely integrated with config scheme, which is a set of tables that you manipulate it. If you knew functional programming like LISP etc, their language makes a lot more sense. That just do go all the way, and left things at 80% done, like a lot of the other features.

So agree it's missing a few functions to make it more "user friendly" – no argument – but add some and fix it! You'd have to change how all CLI works for some newer scripting language, and it that may come out worse (see the new BGP scripting language). It hard to both be a good script language and also have a good REPL at same time (see JavaScript).

And, I think the container so this need today – use what ever language. Most modern languages have a library for both REST and API & unless you explain how you'd doing normal CLI config with micropython or Lua, I'm skeptical.

What is about the current scheme that is so limiting that requires wholesale replacement, vs add some missing functions (like JSON, unicode)? How are you sure it wouldn't be worse...

Add few built-in functions for convenience, find a way to provide more feedback on errors than silent death, and I'll be willing to say that it's ok.

Wait September and you will have a surprise with RouterOS v7.11.9...

This is hopefully a "self-fulfilling prophecy" or do you have inside details on what could be possible?

A work-around is to use your own programming language of choice and call the API to fetch/change things. Run code outside the router.

And, I think the container so this need today – use what ever language. Most modern languages have a library for both REST and API & unless you explain how you'd doing normal CLI config with micropython or Lua, I'm skeptical.

集装箱的问题rs is that they are not supported on all architectures and especially switches that lack enough ram and flash.
I tried to implement a mechanism where mikrotik network devices are deployed with a set of tools that allow them to connect to a central controller, look for its config, apply what is given (in this case json data) and apply this to the local device. The controller supports many more platforms than mikrotik so staying with a provider independent format (json) was a given requirement. When trying to implement a robust solution the current scripting language really showed - at least for me - that the lack of sane error handling, the way functions and variable handling is done, the data structures available, ... just make this potentially simple task very hard. That said writing the same code in python or lua is a really fast, save and pleasant experience. But YMMV/

Make Busybox accessible

Make Busybox accessible

I think folks forget some of these devices have very low memory/disks, which makes adding stuff tricky. And there is no busybox under-the-covers to even expose. busybox assumes the underlying files/system is exposed, which hasn't been Mikrotik's philosophy to allow. Kinda think if managing the underlying OS is what you want to do, flashing OpenWRT seems like a better approach...than trying to make RouterOS more like OpenWRT.

NOW if you asking if Mikrotik should map more of the POSIX/"busybox" into RouterOS equivalents, different question. And think some progress on the multiyear request list formore built-ins functioninto the scripting language would go a long way to making the scripting better, than replacing it.

Proper support for functions would be greatly appreciated. I could not get the current "variable calling" to work with nested "function calls".

Proper support for functions would be greatly appreciated. I could not get the current "variable calling" to work with nested "function calls".

Open separate topic (if you do not have already done that), for see what is the problem.