Skip to content

Home

Jump to bottom
practicalcomputerscience edited this page Jun 29, 2026 · 25 revisions

Further advances

2025-10-20: all major advances starting with scripting language wren and all major modifications of existing source code will be noted here


  • 2026-05-22...2026-06-19: another round of refactoring

(A) POSIX [:graph:] + POSIX [:alphanumerical:] at variable pattern (for a regular expression) if possible <==> variable char_set (for a set/hash of characters/strings):

development target: move more program versions, if feasible and reasonable, (back) from char_set to pattern. It succeeded nicely with GNU Smalltalk, and thus should be possible with many more languages: this refactering will definitely decrease the SLOC's of a number of program versions (like already done at AssemblyScript)!!

  • first question here should always be: is pattern matching simple enough in language xy? Can I stay within this language or would pattern matching with regular expression need external resources? (don't implement such a solution; stay "native")
  • use Google AI to see, if a set of chars can be refactored into a regular expression (named pattern); have a look at the elegant Go solution
  • if using regular expressions are not possible or feasible:
    • for a set/hash of characters/strings, take the (old) Groovy or (old) Java or old Scala implementation as a role model which uses characters instead of codepoints throughout, here in Scala:
      • var char_set = (('a' to 'z') ++ ('A' to 'Z') ++ ('0' to '9')).toSet
      • _ char_set = (('!' to '~')).toSet_
  • so, if possible, check if characters can be used instead of codepoints, which are then transpiled into chars/single char strings

(B) check for other potential improvements, mostly for saving source lines of code, at the first user dialog:

  • can the elegant Java implementation of: if (answer_str.matches("\d+")) {..} be a role model to strictly check string answer_str to only allow strict integer values? => try to save one if-then-else construct to reduce this section to two if-then-else constructs:
    • if#1: is answer_str strictly an int value? (check for only allowing decimal digits)
    • if#2: if yes, is its value >= 8?

(C) if done, update language in this list: Pattern matching: (POSIX compliant) regular expressions or a set or hash of characters or single character strings, respectively?

  • 2026-06-18: Pike

  • 2026-05-21: Smalltalk

  • 2026-05-19: Java

  • 2026-05-18: Haxe

  • 2026-05-11: Ballerina

  • 2026-05-07: JS++: program isn't completely working (try-catch exception handling fails); thus only "speed part" implemented, which is otherwise basically working => no further consideration of JS++

  • 2026-05-03: AssemblyScript

  • 2026-04-27: COBOL

  • 2026-02-17: CoffeeScript

  • 2026-02-12: TypeScript: 05d - TypeScript on Bun and Deno runtimes + TypeScript and JavaScript

  • 2026-02-11: PHP

  • 2026-02-09: another clean-up job: have dedicated string variables bits_x_str + bits_hex_str in the masterloop (which have been introduced for testing); if needed, rename existing string variables bits_x_str + bits_hex_str to bits_x_str_total + bits_hex_str_total: this will further even out the different implementations of the algorithm (though, it shouldn't have a siginificant effect on execution speeds)

2026-02-08: done: Dart

2026-02-05: done: Groovy

2026-01-26:

  • re-checking if the very low level string concatenation solutions in C and C3 and specifically Ada can be brought to at least the more abstract level of Fortran or C++ without sacrificing too much of execution speed. Also the Eiffel solution of create bits_x.make (M1) and bits_x.append (bits_x_str) may serve as a role model here
  • Ada: no faster solution with copying little strings bits_x_str at a dynamic position in the one, big string bits_x of fixed length than the original C-like solution: 20.6ms versus original solution with 18.8 ms
  • C: no faster solution with using function strncpy to copy from little strings into the big strings: 8.2 ms versus original solution with 7.8 ms
  • C3: in contrast to Ada, the new solution with copying little strings bits_x_str at a dynamic position in the one, big string bits_x of fixed length is even a little bit faster than the original C-like solution!
  • fixing Perl 5 with its confusing variable naming (for experimental reasons back then)
  • with the fixing of the Perl 5 program came a more polished version of the Raku program (which didn't fix the issue of its slow exe speed, however)
  • fixing V with its confusing variable naming (for experimental reasons back then)
  • fixing Inko for having, like the other languages, extra string variables bits_x_str and bits_hex_str (just to be fair and having them for testing purposes)
  • trying to a find better solution in Swift for the needed string padding of bits_x_str: I didn't find anything

2026-01-24: done: Eiffel

2026-01-22: done: D

2026-01-19: done: Ruby

2026-01-15: done: C++

2026-01-13: done: Nim

2026-01-12: cleaned up the "masterloop" in the PowerShell programs a bit to have a more logical and efficient program

2026-01-09: done: Odin

2026-01-06: done: Fortran

2026-01-05: change of mind: I plan to implement the microbenchmark program, if possible for me, at last in J, because I'm afraid that it will take me a long time, longer than a week for example. Although, my first baby steps in J worked. Before, I just shortly played with ELI - A System for Programming with Arrays, but didn't get it working. This language (from McGill University: https://www.sable.mcgill.ca/~hanfeng.c/eli/) hasn't been updated since 2015. The only question then is what to do with The Nial Language: https://www.nial-array-language.org/, as another array-oriented language.

2026-01-04: done: Julia (which is not a contender to Mojo or Chapel)

2025-12-31: full microbenchmark program in Bigloo Scheme. It highlights the differences to Racket Scheme.

2025-12-25: cleanup work almost done; cf. Bigloo Scheme

2025-12-16: I'm not continuing with LFE (Lisp Flavoured Erlang: https://lfe.io/about/): even already compiled escripts are being re-compiled when running them again ($ rebar3 lfe run-escript); thus, LFE programs always have a slow start. I'm happy with Gleam as a (performant) language on Erlang's virtual machine and will keep it like that.

2025-12-13: update to latest Mojo version 0.26.1.0... with the Pixi package manager. The old Magic package manager, a fork of Pixi, is now deprecated: https://docs.modular.com/pixi; some slight, formalistic source code changes to get rid of new warnings: Mojo

2025-12-10: Oz: "speed part" of microbenchmark done, though not the rest because that has become practically impossible with this dead programming language

2025-11-22: done: SWI Prolog as a representative for the still numerous and actively maintained Prolog systems

2025-11-16: done: Mercury, a logic and functional language in a purely declarative style: my microbenchmark program is working correctly and swiftly in this language. However and apparently, implementing solutions for more than simple Constraint Satisfaction Problems is (almost) impossible in this language.

2025-11-01: done: Wolfram Language: too slow, but working

2025-10-29: done: Gleam, statically typed, functional programming on Erlang's BEAM virtual machine

2025-10-25: done: Futhark: not a general-purpose language, though I did a little demo

2025-10-24: done: wren: too slow, but working


2026-06-24: so far, I haven't touched yet these corners of programming languages:


GUI (Graphical User Interface)

One or two "non-web" GUI apps for random_streams_for_perf_stats for Linux:

[ ] Tkinter is Python's de facto standard GUI: https://docs.python.org/3/library/tkinter.html

[ ] binary compiled language: Vala with GNOME-centric GTK with very low overhead; compiles to C (instead of the usual combo C++ + Qt): a "Hello, World!" app is already portable and working in a few Linux distros


One or two "web-based" GUI app for random_streams_for_perf_stats for Linux:

[ ] Dart

[ ] ReScript + React: https://rescript-lang.org/docs/react/introduction/


##_ end

Clone this wiki locally