alt Hacker NewsWhat can you expect, when people assume as normal shipping the browser alongside the "native" application, and scripting languages using an interpreter are used in production code?
Maybe that ticket machine was coded in MicroPython. /s
Replies
- TCL/Tk slowish under P3 times, decent enough under P4 with SSE2. AMSN wasn't that bad back in the day, and with 8.6 the occasional UI locks went away.
- Visual Basic. Yes, it was interpreter, and you used to like it. GUI ran fast, good for small games and management software. The rest... oh, they tried to create a C64 emulator under VB, it ran many times slower than one created in C. Nowadays, with a P4 with SSE2 and up you could emulate it at decent speeds with TCL/Tk 8.6 since they got some optimized interpreter. IDK about VB6, probably the same case. But at least we know TCL/Tk got improved on multiprocessing and the like. VB6 was stuck in time.
- TCL can call C code with ease, since the early 90's. Not the case with Electron. And JS really sucks with no standard library. With Electron, the UI can be very taxing, even if they bundle FFMPEG and the like. Tk UI can run on a toaster.
- Yeah, there is C#... but it isn't as snappy and portable TCL/Tk with IronTCL, where it even targets Windows XP. You have JimTCL where it can run on scraps. No Tk, but the language it's close in syntax to TCL, it has networking and TLS support and OFC has damn easy C interops. And if you are a competent programmer, you can see it has some alpha SDL2 bindings. Extend those and you can write a dumb UI with Nuklear or similar in days. Speed? It won't win against other languages on number crunching, but for sure it could be put to drive some machines.
Interpreters don't have to be slow.
Forth is usually interpreted and pretty fast. And, of course, we have very fast Javascript engines these days. Python speed is being worked on, but it's pretty slow, true.