From 447c07a046bd273e2af68f91fa808cc2a929021d Mon Sep 17 00:00:00 2001 From: ivan Date: Mon, 7 Apr 2025 23:58:16 -0500 Subject: [PATCH] reworkify --- 2024.html | 60 -- gnu_emacs.png => assets/gnu_emacs.png | Bin .../made_with_emacs.png | Bin mod_perl.gif => assets/mod_perl.gif | Bin openbsd.gif => assets/openbsd.gif | Bin puffy.png => assets/puffy.png | Bin become-an-engineer.html | 84 --- dancer2-controllers.html | 73 --- docker-mod-perl.html | 143 ----- emacs.html | 53 -- in-defense-of-global-variables.html | 104 ---- index.css | 20 + index.html | 61 +- jpa-hibernate-stupid-performance.html | 60 -- maybe-escaping-evil.html | 48 -- niche-software.html | 45 -- normalize_html.pl | 47 ++ perl-oo-action-benchmark.html | 559 ------------------ trying-lite-xl.html | 17 - 19 files changed, 87 insertions(+), 1287 deletions(-) delete mode 100644 2024.html rename gnu_emacs.png => assets/gnu_emacs.png (100%) rename made_with_emacs.png => assets/made_with_emacs.png (100%) rename mod_perl.gif => assets/mod_perl.gif (100%) rename openbsd.gif => assets/openbsd.gif (100%) rename puffy.png => assets/puffy.png (100%) delete mode 100644 become-an-engineer.html delete mode 100644 dancer2-controllers.html delete mode 100644 docker-mod-perl.html delete mode 100644 emacs.html delete mode 100644 in-defense-of-global-variables.html create mode 100644 index.css delete mode 100644 jpa-hibernate-stupid-performance.html delete mode 100644 maybe-escaping-evil.html delete mode 100644 niche-software.html create mode 100644 normalize_html.pl delete mode 100644 perl-oo-action-benchmark.html delete mode 100644 trying-lite-xl.html diff --git a/2024.html b/2024.html deleted file mode 100644 index 072ac32..0000000 --- a/2024.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - 2024 - - - -
- << back -

2024

-

- 2023 was a good year, but now it's 2024. Here's some of my technical plans for 2024. -

-

- NOTE: These are in no particular order. -

-

Technology I plan to use in 2024

- -

Technology I want to learn more about in 2024

- -

Technology I might learn in 2024

- -

Technology I won't learn in 2024

-

- It's not that I hate the following, it's just that they don't really interest me, - or the people behind them do not seem to value people using them (ala Rust). -

- -

Have a safe and fun 2024.

-
- - diff --git a/gnu_emacs.png b/assets/gnu_emacs.png similarity index 100% rename from gnu_emacs.png rename to assets/gnu_emacs.png diff --git a/made_with_emacs.png b/assets/made_with_emacs.png similarity index 100% rename from made_with_emacs.png rename to assets/made_with_emacs.png diff --git a/mod_perl.gif b/assets/mod_perl.gif similarity index 100% rename from mod_perl.gif rename to assets/mod_perl.gif diff --git a/openbsd.gif b/assets/openbsd.gif similarity index 100% rename from openbsd.gif rename to assets/openbsd.gif diff --git a/puffy.png b/assets/puffy.png similarity index 100% rename from puffy.png rename to assets/puffy.png diff --git a/become-an-engineer.html b/become-an-engineer.html deleted file mode 100644 index 6652775..0000000 --- a/become-an-engineer.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - Become a software engineer - - - -
- << back -

Become an Engineer

-

- This learning track assumes you have a computer built after 2004, with - Debian Linux, FreeBSD or OpenBSD installed. (Windows simply won't do.) -

-

Start here (read both and do all of the exercises)

- -

Getting deeper (read all 3, do all exercises)

- -

Low level learning

- -

Category theory

- -

High(er) Level Languages (pick at least 2)

- -

- This is the way to becoming a truly great software engineer. I've read all of these books, and I can say that they all manifest within - me a strong sense of confidence, and the ability to adapt to any situation that might come my way in computer science. -

-

- You may be reading this list, thinking... what about Java or JavaScript??? Now, I don't think these languages are bad per-se, but I do think - they have the ability to destroy your life. Once you've used Java or JavaScript, there is a good chance you will become closed off from - the rest of the computing world, falling into a world of patterns and objects. You may also find that languages like these have the adverse - effect of having incredibly low skill-ceilings, which compounds the idea of you becoming stuck. A low ceiling, and a low floor, is a prison, not - a tool to conjure the spirits of the computer. -

-
-
-
- - diff --git a/dancer2-controllers.html b/dancer2-controllers.html deleted file mode 100644 index e834943..0000000 --- a/dancer2-controllers.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - Dancer2::Controllers - - - - -
- << back -

Dancer2::Controllers and Perl Attributes

-

Published February 26th, 2024.

-

- Recently I created Dancer2::Controllers, a simple - Moose based approach for defining routes in Dancer2. I built this as an attempt to add Spring-Boot esq annotations to - Dancer2. -

-

The approach

-

- Perl has a little know feature called "Attributes", which work as some extra arbitrary data appended to - the various reftypes in Perl. When you append an Attribute, Perl looks for the MODIFY_<reftype>_ATTRIBUTES in the current - namespace, and uses it to decide if that attribute is allowed, and lets you execute some arbitrary code as well. Perl attributes can also take "arguments". - These "arguments" actually are just part of the Attribute, and you need to parse the entire Attribute to get the arguments. -

-

- Since Perl Attributes are the closest thing I could find to annotations, I decided a generic Route attribute would be nice. - With a Perly looking argument pattern: Route(get => /foo), this feels a Perl version of Spring-Boot's - @RequestMapping(value = "/foo", method = GET), - which is exactly what I was looking for. -

-

Speed Bumps

-

- Dancer2 is built on-top of Moo, unfortunately I couldn't find a nice way to handle Attributes using Moo, and inheritance. So, I settled for adding - Moose and the wonderfully helpful MooseX::MethodAttributes dist, which drastically simplified the work I needed to do. -

-

In action

-

The following is an example of how to use Dancer2::Controllers

: - 
-            
-package My::Controller;
-
-use Moose;
-
-BEGIN { extends 'Dancer2::Controllers::Controller' }
-
-sub home_page : Route(get => /home) {
-    my $app = shift;
-    my $user_name = $app->session('user');
-    return "Welcome back $user_name!";
-}
-
-sub home_page : Route(post => /login) {
-    my $app = shift;
-    my $password = $app->body_parameters->get('password');
-    return "Here is your password: $password";
-}
-
-1;
-
-package main;
-
-use Dancer2;
-use Dancer2::Controllers;
-
-controllers([ 'My::Controller' ]);
-
-dance;
-            
-
-

Thanks for reading :)

-
- - diff --git a/docker-mod-perl.html b/docker-mod-perl.html deleted file mode 100644 index 0bb96b4..0000000 --- a/docker-mod-perl.html +++ /dev/null @@ -1,143 +0,0 @@ - - - Running mod_perl with Mojolicious in Docker - - - - - -
- << back -

Running mod_perl with Mojolicious in Docker

-

- I've been working under an old Apache mod_perl setup. I wanted to use Mojolicious for some new services, - but I needed to stay within mod_perl, so I decided to go all the way and Dockerize it. After scouring the mod_perl documentation, - Plack + Mojolicious configs, and finding an image, I hit the ground running and documented my steps. -

- - mod_perl banner - -

I love old banners :)

-

Generate your config

-

Thanks to motemen for some nicely pre-configured - mod_perl and Apache2 images. We're targetting Perl v5.36, and Apache 2.4.58 here. - We'll also add the include statement for our VirtualHost configuration file that we'll make later. -

- 
-docker run --rm motemen/mod_perl:5.36.0-2.4.58 cat /usr/local/apache2/conf/httpd.conf > httpd.conf
-echo 'Include /usr/local/apache2/conf/mojolicious.conf' >> httpd.conf
-                
-
-

- This will leave you with a httpd.conf that will get picked up by Apache when we run it under docker. -

-

Enable Prefork MPM instead of Event MPM

-

- I couldn't get Apache to run without disabling Event MPM and enabling Prefork MPM. -

-

In httpd.conf:

- 
-                
-#LoadModule mpm_event_module modules/mod_mpm_event.so
-LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
-                
-
-

Write your application

-

- All you need to do is write a Mojo application. In this case, I'm using Mojolicious::Lite but this can - be done with the whole MVC setup easily as well. Just make sure you have a sub that returns your app so you can - pass it to Plack::Builder. -

-

In lib/App.pm:

- 
-                
-package App;
-use 5.036;
-use Mojolicious::Lite -signatures;
-
-sub get_app { app; }
-
-get '/' => sub {
-    shift->render( text => "Hello World!" );
-};
-
-1;
-
-

Write your Plack shim

-

- Here we write a simple .psgi file that - will use our App library and Plack::Builder to - create a PSGI application for Plack::Handler::Apache2 to pickup. -

-

In app.psgi:

- 
-use 5.036;
-
-use lib 'lib';
-use App;
-use Plack::Builder;
-
-builder {
-    App::get_app->start;
-};
-                
-
-

Write your mod_perl Apache config

-

- Very straight-forward, just tell Apache where to find our script, and what handler to use. -

-

In mojolicious.conf:

- 
-                
-LoadModule perl_module modules/mod_perl.so
-
-<VirtualHost *:80>
-<Location />
-SetHandler perl-script
-PerlResponseHandler Plack::Handler::Apache2
-PerlSetVar psgi_app /app.psgi
-</Location>
-</VirtualHost>
-                
-
- -

Write your Dockerfile

-

- Now all thats left is making a Dockerfile. - We'll use one of motemen's images, - and copy all of the pre-reqs over, install some libraries, you know, Docker stuff. -

-

In Dockerfile:

- 
-                
-FROM motemen/mod_perl:5.36.0-2.4.58-2.0.13
-COPY app.psgi /app.psgi
-COPY lib /usr/local/apache2/lib
-COPY httpd.conf /usr/local/apache2/conf/httpd.conf
-COPY mojolicious.conf /usr/local/apache2/conf/mojolicious.conf
-RUN apt-get update -y && apt-get install -y wget make build-essential
-RUN cpan -iT Plack Mojolicious
-EXPOSE 80
-CMD ["httpd-foreground"]
-                
-
- -

Run with Docker

-

Now we can make it go!

- 
-$ docker build . -t mod-perl
-$ docker run -p 80:80 mod-perl
-$ curl http://localhost:80/
-
-"Hello World!"
-                
-
-

Running with auto-reloading (for development)

-

You can make this auto-reload if you use a docker volume for lib/ against /usr/local/apache2/lib/

-

An example?

-

- An example is available on my github. -

-
- - diff --git a/emacs.html b/emacs.html deleted file mode 100644 index 8423329..0000000 --- a/emacs.html +++ /dev/null @@ -1,53 +0,0 @@ - - - Emacs - - - -
- << back -

Why Emacs?

-

- I reccommend GNU Emacs (not Spacemacs, or Doom Emacs) to everyone. If you're just starting to program - then you're at an even bigger advantage if you pickup Emacs early. If you're a battle hardened developer - you should still be using Emacs, though it may be harder to pickup, assuming you've been using modern "IDE's" - for most of your career. I also recommend Emacs to pretty much anyone that processes text often. -

-

- Emacs provides the perfect balance of customization, to effectiveness of any editor. I think that it's foolish - to use tools that don't let you mold them to your idea of how to use them. Software tools aren't like traditional - tools like Hammers and Pipe-wrenches, and it's foolish to use them in this way. With Emacs a Secretary, Software Engineer (obviously), - Math Student, Professor, Novelist, etc, can all find ways to implement Emacs into their day-to-day. - Emacs is a tool for empowering people. It's not just a text-processor (though it's really good at that), it's also a journal, - a lisp interpreter, and really, anything you want. -

-

For Software

-

- I'm going to focus on Software Developers for the rest of this, seeing as it's who I can relate too most. - Software Developers often get stuck in ruts, I truly think Emacs is the tool to pull you out and keep you out - of said ruts. Emacs will kick you in the rear, and make you cry, and force you to work in a subpar fashion for a long time, - the GNU is not an easy beast to tame. But once you've put in the work, and elevated yourself upon it's reigns, the power you - attain is so incredibly wizard-like that you may very well consider wearing a pointed hat, and robes, at work. -

-

- Currently, I use Emacs for everything at work. Compiling, code editing, file-system stuff, docker, git, documentation, etc. - I've used other editors and nothing, comes even close to Emacs. Vim users will probably recoil, but Vim makes you context - switch so often between the terminal and your editor that I really think it doesn't even belong in the same category as Emacs. - What I would recommend to the Emacs novice, is to focus on setting up your workflows 1 flow at a time. For instance, say you want - to work on Perl code. Setup all the Perl related stuff in one-shot and don't worry about making your configuration super ergonomic - and extensible. Just make it work for Perl. Then say, you get a job in Scala, do the same thing, but refactor your configuration - to enable both Perl and Scala nicely, rinse and repeat until your hands bleed. That's really all there is to it, as you find things - you want to improve, improve them one-by-one. Don't rush in and expect to setup a perfect IDE for every language and every workflow. - Emacs really is what you make of it, but you can't really know what to make of it, until you identify the problems you want to solve. -

-

- A good way to think of Emacs, is, it's the instrument equivalent of text-processors. -

-

Links:

- -
- - diff --git a/in-defense-of-global-variables.html b/in-defense-of-global-variables.html deleted file mode 100644 index 20b2d36..0000000 --- a/in-defense-of-global-variables.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - How to Properly Use Global Variables - - - -
- << back -

How to Properly Use Global Variables

-

- Global variables, and global state in general have been under fire for as long as I can remember. - The argument is, you couple, and introduce unpredictability through managing global variables - since "anyone can update them". This makes sense in a cosmological world, filled with people - who WANT to write bad code. It's not the global variables that make code bad, it's how they're used. - We've spent many years inventing abstraction after abstraction, that could just be boiled down to global variables, - and global constants. In the end, applications will always have global state, why make it so dang difficult? -

-

Simplicity, and avoiding traps

-

- Globals are simple, so simple, that even the thought of using them might turn people off. It's hard to accept - that the simplest answer is always the best one, but it almost always is. 99% of the code I run into, is complex for the sake of "reusability", "readability", or - "scalability", but in the end none of these come to pass. You'll see interfaces, and abstract classes defined for single implementations, - horribly generic code written in obscure places, and a mess of a file structure with hundreds of files. Do you really need a generic interface for - each of your database tables, or what about a "service" for each "domain"? In reality, the most readable, resuable, and scalable code, is the code that - compiles well, and avoids mentally expensive abstraction. If I have to walk through the inheritence graph to figure out what something is doing, it's already neither - scalable, or readable. -

-

- You'll often see global variables hidden behind some "global context" like abstraction. This is down right deplorable, instead, hide your globals behind the simplest - abstraction on the market, the function. GetDatabaseHandler() is much simpler to reason about than GlobalContextHolder.getSingleton().getContext("database"). - These abstractions also, are prone to error, for instance if you use a hash-table to lookup values with a string key, what happens if I miss type the string? The compiler - won't catch that for you, and you'd be adding a lot of extra instructions just to access some state somewhere (which at its fastest is a pointer dereference). Another common way to do this, - is to pass a class object, .class in Java. However, this is even worse. Typically, a language will use reflection which or runtime type checks which can be extraordinarily slow. - To compound this, you also have no gurantees on the existence of the values, for instance, if you want a DatabaseHandler, and you make the request for it, you have no idea - if that is actually the right name or class until runtime. Contrast that with a function that will be picked up by your LSP or produce a compile-time error message. - Global contexts, and contexts in general are a huge mess of slow, hard to optimize code, you should avoid them at all costs. -

-

What to do instead

-

- As mentioned earlier, global state should exist one layer under a function. There is absolutely nothing wrong with running a database.InitializeDatabase() function, to - initialize your globals at startup, or having some sort of lazy-init built into your global accessor function. Keeping things simple is how you keep them readable, and scalable. - What's funny, is that's pretty much it. -

-

- Another thing I recommend is not accessing your globals inside of your functions, instead, pass them as arguments. This is just good-practice in general, your functions should - do their best to be as pure as possible. This also makes your code truly re-usable and adaptable, since you may have multiple different global variables with the same types. - This also makes your code easy to test, since it's not relying on any outside values existing or not. -

-

Examples

-

- Let's compare some code. In the first example, we'll do the traditional GlobalContextHolder OOP style, - where we literally do our best to make it look like we're not working on global variables. In the second example, we allow our globals to exist, - but instead of accessing them in a foolish way, we accept them as parameters. -

-

Example 1:

- 
-                
-public void saveUser(User u) {
-    // Where did this guy come from? Idk, it's probably defined in some XML file somewhere :)
-    DatabaseHandler dbh = GlobalContextHolder.getContext("database");
-    dbh.table("users").save(u);
-}
-
-// Main.java
-public static void main(String[] args) {
-    User user = new User("Bob", 23);
-    saveUser(user);
-}
-                
-
-

Example 2:

- 
-                
-// Database.java
-private static DatabaseHandler DBH;
-
-public static DatabaseHandler getDatabase() {
-    if (DBH == null) {
-        DBH = DatabaseHandler.newConnection("mysql://foo@bar:foo.com:3306");
-    }
-
-    return DBH;
-}
-
-// Main.java
-public static void saveUser(User u, DatabaseHandler dbh) {
-    dbh.table("users").save(u);
-}
-
-public static void main(String[] args) {
-    Database.initialize();
-    User user = new User("Bob", 23);
-    saveUser(user, Database.get());
-}
-                
-
-

- Overall, this drastically reduces the mental overhead of the system, allowing for simple unit-testing (if you want), and - a simplistic approach to scaling, since you don't have to worry about costly abstractions that don't actually simplify anything. -

-
- - diff --git a/index.css b/index.css new file mode 100644 index 0000000..862f8b5 --- /dev/null +++ b/index.css @@ -0,0 +1,20 @@ +:root { + --fg: #222; + --link-fg: #116630; +} + +body { + color: var(--fg); + font-family: georgia, serif; + font-size: medium; + max-width: 40em; + margin: 0 auto; + padding: 0 1em; +} + +a { + color: var(--link-fg); + text-decoration: none; + text-decoration-line: underline; + text-decoration-style: dashed; +} diff --git a/index.html b/index.html index 1e80790..c534cef 100644 --- a/index.html +++ b/index.html @@ -4,71 +4,49 @@ rawley.xyz + - -
- 
-              
-               ,        ,
-              /(        )`
-              \ \___   / |
-              /- _  `-/  '
-             (/\/ \ \   /\
-             / /   | `    \
-             O O   ) /    |
-             `-^--'`<     '
-            (_.)  _  )   /
-             `.___/`    /
-               `-----' /
-  <----.     __ / __   \
-  <----|====O)))==) \) /====
-  <----'    `--' `.__,' \
-               |        |
-                \       /
-           ______( (_  / \______
-         ,'  ,-----'   |        \
-         `--{__________)        \/ 
-              
-
+ +

- Hi, I'm Rawley a Christian, Husband, Dad, Emacs evangelist and BSD user. + Hi, I'm Rawley. I'm a full-time Husband, Dad, Emacs evangelist and Perl aficionado.

I am the creator of many free-software libraries and tools. - I have extensive knowledge of Perl, Java, the JVM, and Functional Programming. I'm always working on something, whether it be my + I have extensive knowledge of Perl, Java, JVM, and Functional Programming. I'm always working on something, whether it be my 100 year old house, or some 100 year old code. I'm always looking for fun things to work on.

-

Sitemap

+

Blog Posts

Projects

@@ -89,16 +67,17 @@ Distribution::Builder::Cmake +

- + - +

Disclaimer

All opinions are my own, they do not reflect the thoughts expressed by my employer(s) past, present, or future.

-
+
diff --git a/jpa-hibernate-stupid-performance.html b/jpa-hibernate-stupid-performance.html deleted file mode 100644 index 42f21c5..0000000 --- a/jpa-hibernate-stupid-performance.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - Achieving Stupid Performance with JPA and Hibernate - - - -
- << back -

JPA is slow, lets make it stupid fast

-

- JPA is not performant. Mainly because of things like batching, and this incessant idea that - querying relationships lazily is somehow fast, its literally just deferring the work, which makes sense - if you potentially don't want to use the data, but most people want that data anyways, or serialize it. -

-

- I experienced this recently with a massive data set, this database was 1 core table of 4 million rows, followed by multiple child One-To-Many table - of close to 10 million rows, and a single One-to-One with ~4 million rows as well. To use the service built on top of this massive data, you had to search - with JPA search specifications, which turns out also to be insanely slow. The benchmark starts us at 15 or so minutes, which is obviously unacceptable. -

-

Time to go fast

-

- By enabling 

logging.level.org.hibernate.SQL=DEBUG
and 
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE
- you're able to see the ridiculous number queries JPA is executing, they're un-countable, there's so many!! How can we fix this? -

-

- If you're thinking of using @Batch(100), it could work, only issue is JPA will batch each relationship, so each of our tables will still require - n/100 calls where n is the number of rows with relationships. So theoretically a 100x speed bump right? Well, it's actually more - like a 33x performance bump, since you still have the overhead of making the database connections, and need to get a lock every time you select. Doing this we moved to around - 3-5 minutes depending on load per large call. This however, was still unacceptable. -

-

- What if instead we just forced JPA to use OUTER JOIN? Isn't that exactly what the ANSI SQL wizards would tell you to do? - Obviously, this is the solution, one single connection, 1 lock, and let the B-Tree optimizations inside of the database handle all of this ugliness for us. - To do this you need to use something called @EntityGraph - on your JPA repository, what this does is forces JPA to use a OUTER JOIN - to join relationships. This even works on nested entities, say I have Entity A with a child B which also has a One-to-Many on C, all you need to do - is add the relationship to the entity graph with the @NamedEntityGraph annotation, then provide it with a few nice args like name, - and attributeNodes which will point to your sub entity. Then finally on your JPA repository call you stitch the entity graph back together. -

- 
-                
-@Repository
-public interface ARepository extends JpaRepository, JpaSpecificationExecutor {
-    @Override
-    @EntityGraph(attributePaths = { "bs", "B.cs" }) // Where B's are children of A's, and C's are children of B's.
-    Page findAll(@Nullable Specification specification, Pageable pageable);
-}
-                
-
-

- After applying these, the query time went down from 15 minutes to ... *drum-roll* ... 3 seconds. So please, for the love of all that is computationally efficient, force your JPA - to use OUTER JOIN, or even roll your own SQL, ORM's really are one of the biggest trade-offs, and they really can bite you. This is why tend to - stay in the DBI universe when I write Perl. It's funny shocking Ruby on Rails and Java developers with my ~15ms queries :D -

-
-
-
- - diff --git a/maybe-escaping-evil.html b/maybe-escaping-evil.html deleted file mode 100644 index 59e42ca..0000000 --- a/maybe-escaping-evil.html +++ /dev/null @@ -1,48 +0,0 @@ - - - Escaping evil-mode, maybe? - - - - - -
- << back -

Escaping evil-mode

-

- I've been using evil-mode for almost 4 years at this point, and Vim keybinds even longer. - However, I think it's almost time for me to change. In 2022 I spent the later half of the year just on default, vanilla emacs keybinds. - This was really enjoyable and let me learn more about how the puritans do Emacs, but in general, - I just felt a lot slower. So I came back to evil-mode, and have been using it daily ever since. - But with some recent annoyances in Evil, and having to almost double my config size to use Evil integrations with other packages, - I've been thinking of using Vanilla again, or exploring some of the other modal plugins like: meow, - Xah-Fly-Keys, or god-mode (don't love the name of this one :P). - So, to the disdain of my productivity, I am going to try to use each of these for a week at a time, and report back each week with an update. -

-

The test

-

- I will be comparing each mode on the following all scored out of 10: -

-

-

evil-mode's rating

-

- Here is my review of evil-mode: -

- Overall I do like evil-mode, and i'm very productive with it, but I find that a lot of little issues pop-up on a day to day basis - that could be ironed out. Things like not having re-do automatically working. At the end of the day I use Emacs for both, speed, but also, - for extensability, something that I think evil-mode restricts. -

-
- - diff --git a/niche-software.html b/niche-software.html deleted file mode 100644 index 2bbfba1..0000000 --- a/niche-software.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - Using Niche Programming Languages - - - -
- << back -

Published March 7th, 2024

-

Using Niche Programming Languages

-

- Earlier this week, - Bleacher Report - was bought out and forced to re-write their Elixir/Erlang backend in something "more-mainstream" by the - buying party (Warner), this is a HUGE mistake, and an example of how main-stream thought has eroded the foundations of software engineering. Bleacher Report had used - Elixir/Erlang since at least 2017, - when their case-study of going from 150 servers to 5 via converting their Ruby code to Elixir/Erlang was published. - All of this resliency, and engineering effort is now going to be rewritten in none other than JavaScript, which of course will be a tremedous effort. -

-

- So why did they do it? Well, they had lay-offs, and then they needed to re-fill the seats they laid off a few years later. Instead of leveraging this "gold card" - that is a niche language, Warner decides that it will be too hard to fill N seats. Which is also another issue in the software world, the "butts in seats typing" - phalacy that more will get done. Anyways, what Warner could have done, is use this fantastical power bestowed by a niche language, and got the best developers - in that niche technology. If they hired 15 Node devs for 100k a year each, they could afford 5 Erlang masterminds for 300k a year each (and then you wouldn't need a - rewrite!) The other option is to hire a few Erlang devs and have them train other devs which could be an effective cost-cutting measure as well, without - having to rewrite your codebase. -

-

- I've been asked many times by developers, "should I learn X, it's so niche but it looks cool", and to every single one of those questions, I shout "YES!!!". - Learning is ALWAYS good. But also, if you get really good at these niche technologies, you can become a SME (subject matter expert), and get hired - by a business looking for people like you. Jane Street is notorious for using OCaml for literally everything. Yaron Minsky, mentions at Jane Street states - that while there aren't many OCaml developers, the small set that does exist is typically really good, and a grade above the usual Python, Java, JavaScript developer - (you'll choke on your coffee when you read Jane Streets developer salaries as well). -

-

- When starting a new project I think you should consider using a niche language. - You learn a lot, but also when it comes time to scale your idea, and you need to hire a partner or two, - you'll be greatful you chose it, when extremely talented and passionate individuals send you their resume solely because you chose a backend written in Haskell, Scala, - Perl, OCaml, Elixir, Clojure, Lua, etc. This is what happened for NoRedInk, after writing their original MVP in Ruby, they ended up using Haskell and Elm for new - services, and now, they're one of the most well known Functional Programming shops, and they've managed to hire some brilliant people, like the creator of Elm himself! -

-
- - diff --git a/normalize_html.pl b/normalize_html.pl new file mode 100644 index 0000000..f62f4e2 --- /dev/null +++ b/normalize_html.pl @@ -0,0 +1,47 @@ +#!/usr/bin/env perl + +use 5.036; + +use FindBin; +use File::Find; +use File::Slurp; +use XML::LibXML; + +find( + sub { + return unless $_ =~ /.*.html$/xmi; + say "Processing: $_"; + my $loc = "$FindBin::Bin/posts/$_"; + my $html = read_file($loc); + my $doc = XML::LibXML->new->parse_html_string($html); + + my ($html_tag) = $doc->getElementsByTagName('html'); + $html_tag->setAttribute( lang => 'en' ); + + my @meta_tags = $doc->getElementsByTagName('meta'); + + for my $meta (@meta_tags) { + if ( my $v = $meta->getAttribute('value') ) { + $meta->removeAttribute('value'); + $meta->setAttribute( content => $v ); + } + } + + my @links = $doc->getElementsByTagName('link'); + + for my $link (@links) { + if ( $link->getAttribute('href') eq '/index.css' ) { + say "Already done $_"; + return; + } + } + + my $st = XML::LibXML::Element->new('link'); + $st->setAttribute( rel => 'stylesheet' ); + $st->setAttribute( href => '/index.css' ); + my ($head) = $doc->getElementsByTagName('head'); + $head->appendChild($st); + write_file( $loc, $doc->toString() ); + }, + "$FindBin::Bin/posts" +); diff --git a/perl-oo-action-benchmark.html b/perl-oo-action-benchmark.html deleted file mode 100644 index 7d4ba5a..0000000 --- a/perl-oo-action-benchmark.html +++ /dev/null @@ -1,559 +0,0 @@ - - - - Perl OO benchmarking - - - -
- << back -

Perl OO benchmarking

-

- I've spent a lot of time working in projects that use the Action pattern (also called the Command pattern). - Now, regardless of how i've land on OO vs Functional in the last 5 years, there has always been a question I have yet to answer: "How much does this abstraction cost, - and more importantly, how much does object instantiation actually cost?" (since the action pattern has you instantiating A LOT of objects) -

-

- So I set out to benchmark, Perl OO, using the traditional Module OO, Corinna, Moo and Moose. But I thought it may also - provide some value to compare these findings to other languages, namely ones in the same sort of realm that Perl has lives in: Ruby and Raku (formerly Perl 6). -

-

The benchmark

-

- The benchmark is fairly simple, since the goal here is to test the actual instantiation costs, so the method associated with the implemented action is very simple. - An Action object has two members, name and age. It's execute method returns a Map/Hash/Dictionary, with the following keys - { name => self.name, age => self.age }. Basically just accessing the instantiated objects age and name attributes, and associating them to - keys of the same name. -

-

- One-million Action objects will be instantiated in a O(n) loop, and executed, then destroyed all within the same scope. Like so: -

- 
-                
-my $name = 'Tim';
-my $age  = 12;
-for ( 1 .. 1000000 ) {
-    my $user = Action->new( name => $name, age => $age )->execute();
-}
-                
-
-

- This will be performed one-hundred times, then, the average of the times taken to do the one-million iterations will be the benchmark result. - It is also important to note that the initial load-time of the language run-times is included in the calculation, though they are mostly negligble especially - in the Perl case, and the actual instantiation takes the vast-majority of the time (close to 99% on average). -

-

- This benchmark was performed on an Intel i7 12700KF, using DDR5 memory. -

-

Summary Table

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LanguagePerformance
- Perl Module OO - - 454.627ms -
- Perl Module OO + Types - - 505.276ms -
Corinna564.411ms
- Moo - - 960.03ms -
- Moo + Types - - 2308.226ms -
- Moose - - 11420.455ms -
Moose + Immutable1182.109ms
- Moose + Types - - 13649.37ms -
Ruby167.627ms
Raku (MoarVM start-up subtracted)801.947ms
-

Times and implementations

-

Perl

-

Module OO

-

- Using the traditional Perl approach to OO using ref's and modules, is by far the fastest. -

-
Code:
- 
-                
-package Action;
-
-use strict;
-use warnings;
-
-sub execute {
-    my $self = shift;
-    return +{ name => $self->{name}, age => $self->{age} };
-}
-
-sub new {
-    my ( $class, $name, $age ) = @_;
-    my $self = { name => $name, age => $age };
-    return bless $self, $class;
-}
-
-1;
-
-package main;
-
-use strict;
-use warnings;
-
-my $name = 'Tim';
-my $age  = 12;
-for ( 1 .. 1000000 ) {
-    my $user = Action->new( $name, $age )->execute();
-}
-                
-
-

- This implementation is alright, it's fast, but it doesn't provide any validations, which is what I assume most OO frameworks like Moo and Moose do, especially - if you use modules like Type::Tiny. -

-
Time:
- 
-                
-PERL TIME : 454.627ms
-                
-
-

Module OO with some type checks

-

- Considering my assumptions about other OO libraries I decided to add a few checks to the Module OO implementation, - using Scalar::Util we can test if age is a number, and also ensure the defined-ness of our - attributes using the built-in defined. -

- 
-                
-package Action;
-
-use strict;
-use warnings;
-use Scalar::Util qw(looks_like_number);
-
-sub execute {
-    my $self = shift;
-    return +{ name => $self->{name}, age => $self->{age} };
-}
-
-sub new {
-    my ( $class, $name, $age ) = @_;
-
-    if ( !defined $name || !defined $age ) {
-        die 'name and age, should be defined.';
-    }
-
-    if ( !looks_like_number($age) ) {
-        die 'age should be a number.';
-    }
-
-    my $self = { name => $name, age => $age };
-    return bless $self, $class;
-}
-
-1;
-
-package main;
-
-use strict;
-use warnings;
-
-my $name = 'Tim';
-my $age  = 12;
-for ( 1 .. 1000000 ) {
-    my $user = Action->new( $name, $age )->execute();
-}
-                
-
-

This only came at a net-cost of around 50ms extra on average, which is surprisingly fast.

- 
-                
-PERL + TYPES TIME : 505.276ms
-                
-
-
Code:
-

Corinna

-

- Corinna is a new OO system added to Perl 5.38 but still marked as experimental. It performs very well compared to the features it provides, - but it is definitely not something you'll see in the wild too often. -

- 
-                
-use feature 'class';
-no warnings;
-
-class Action {
-    field $name : param;
-    field $age : param;
-
-    method execute () {
-        return +{ name => $name, age => $age };
-    }
-}
-
-my $name = 'Tim';
-my $age  = 12;
-for ( 1 .. 1000000 ) {
-    Action->new( name => $name, age => $age )->execute();
-}
-                
-
-

- I had to disable warnings on this because I wasn't sure what flags I needed to set in the feature or the experimental, - also the lack of documentation definitely hurt, it took me a while to figure out I had to use feature 'class';. For some reason I thought - the feature flag was corinna or something. -

-
Time:
- 
-                
-CORINNA TIME : 564.411ms
-                
-
-

Moo

-

- Moo is a "Minimalist Object Orientation" for Perl. It's what I've used the most, and it performs quite well for all of the - features it gives you. However, there is definitely a cost, one that a lot of developers ignore. I've done two implementations here, one with - Type::Tiny, which adds optional type-checking to attributes, and one without. The difference was quite compelling! -

-
Code:
- Without Type::Tiny: - 
-                
-package Action;
-
-use Moo;
-use namespace::clean;
-
-has name => (
-    is       => 'ro',
-    required => 1
-);
-
-has age => (
-    is       => 'ro',
-    required => 1
-);
-
-sub execute {
-    my $self = shift;
-    return +{ name => $self->name, age => $self->age };
-}
-
-1;
-
-package main;
-
-use strict;
-use warnings;
-
-my $name = 'Tim';
-my $age  = 12;
-for ( 1 .. 1000000 ) {
-    my $user = Action->new( name => $name, age => $age )->execute();
-}
-                
-
- With Type::Tiny: - 
-                
-package Action;
-
-use Moo;
-use Types::Standard qw(Int Str);
-use namespace::clean;
-
-has name => (
-    is       => 'ro',
-    isa      => Str,
-    required => 1
-);
-
-has age => (
-    is       => 'ro',
-    isa      => Int,
-    required => 1
-);
-
-sub execute {
-    my $self = shift;
-    return +{ name => $self->name, age => $self->age };
-}
-
-1;
-
-package main;
-
-use strict;
-use warnings;
-
-my $name = 'Tim';
-my $age  = 12;
-for ( 1 .. 1000000 ) {
-    my $user = Action->new( name => $name, age => $age )->execute();
-}
-                
-
-

- To my shock, Type::Tiny degrades performance by close to 300%. However, the more I looked into Type::Tiny, the more it made sense. - Type::Tiny, to enforce types uses a lot of complex meta-programming, and ref checks, that add up to a ton of extra operations. Perhaps it would be - worth using B::Concise or B::Deparse to see how many more operations this actually adds, but thats something for another day. -

-
Time:
- 
-                
-MOO TIME         : 960.03ms
-MOO + TYPES TIME : 2308.226ms
-                
-
-

Moose

-

- Moose is a heavyweight, industrial purpose OO framework for Perl, at which Moo derives from. It is big, and heavy, and unfortunately, - really slow for tasks like this. After starting this benchmark, I thought that the slowness was coming from loading the module between runs, but after timing the average load time, - the time spent was negligble (31ms at most). -

-

- Like in the Moo benchmark, I did two implementations, one using Type::Tiny, and one not. -

-
Code:
- 
-                
-package Action;
-
-use Moose;
-use namespace::clean;
-
-has name => (
-    is       => 'ro',
-    required => 1
-);
-
-has age => (
-    is       => 'ro',
-    required => 1
-);
-
-sub execute {
-    my $self = shift;
-    return +{ name => $self->name, age => $self->age };
-}
-
-1;
-
-package main;
-
-use strict;
-use warnings;
-
-my $name = 'Tim';
-my $age  = 12;
-for ( 1 .. 1000000 ) {
-    my $user = Action->new( name => $name, age => $age )->execute();
-}
-                
-
- With Type::Tiny: - 
-                
-package Action;
-
-use Moose;
-use Types::Standard qw(Int Str);
-use namespace::clean;
-
-has name => (
-    is       => 'ro',
-    isa      => Str,
-    required => 1
-);
-
-has age => (
-    is       => 'ro',
-    isa      => Int,
-    required => 1
-);
-
-sub execute {
-    my $self = shift;
-    return +{ name => $self->name, age => $self->age };
-}
-
-1;
-
-package main;
-
-use strict;
-use warnings;
-
-my $name = 'Tim';
-my $age  = 12;
-for ( 1 .. 1000000 ) {
-    my $user = Action->new( name => $name, age => $age )->execute();
-}
-                
-
-

- Just like Moo with types, Type::Tiny hits the final Moose result by around 2000ms overall. -

-

- Amendment: After publishing my original findings I was alerted to a setting you could apply to Moose classes that make them immutable. - Immutable often means faster in-terms of creation but slower in terms of manipulation, but since this workload spends most of its time creating, and none of its time editing, - this produced an incredible 10x speed improvement. -

-
Immutable trick for Moose
- 
-              
-__PACKAGE__->meta->make_immutable;
-              
-
-
Time:
- 
-                
-MOOSE TIME         : 11420.455ms
-MOOSE + TYPES TIME : 13649.37ms
-MOOSE IMMU TIME    : 1182.109ms
-                
-
-

Ruby

-

- I also did a quick Ruby implementation, since its a "true" Object-Oriented language, I assumed it would have - a lot of optimizations built-in for this sort of work, and based on its runtime, that seems to be the case. -

-

- Also, note, this was on Ruby 3.1.2, not Ruby 3.3 with YJIT, so this could theoretically be faster. -

-
Code:
- 
-                
-class Action
-  def initialize(age, name)
-    @age = age
-    @name = name
-  end
-
-  def execute
-    { name: @name, age: @age }
-  end
-end
-
-age = 12
-name = 'Tim'
-1000000.times do
-  user = Action.new(age, name).execute()
-end
-                
-
-
Time:
- 
-                
-RUBY TIME : 167.627ms
-                
-
-

Raku (formerly Perl 6)

-

- Finally, we have Raku, which unfortunately doesn't do too well. To make this a little more competitive, - I subtracted the run-time of MoarVM from the end-result. Though, I think Raku's implementation is the simplest to - understand in terms of langauge design, so it gets a +1 from me for that. -

-
Code:
- 
-                
-class Action {
-    has $.name;
-    has $.age;
-
-    method execute {
-        return %(name => $!name, age => $!age);
-    }
-}
-
-my $name = 'Tim';
-my $age = 12;
-for 1..1000000 -> $ {
-    my $user = Action.new(name => $name, age => $age).execute();
-}
-
-                
-
-
Time (with MoarVM startup time removed):
- 
-                
-RAKU TIME : 801.947ms
-                
-
-

So what?

-

- Object instantiation has a cost. A lot of people ignore this, especially when using heavyweight libraries like Moose. - You can put this into practical terms simply, using basic Perl module OO you effectively double the number of objects of this type you can create and execute a - method on given any time-frame compared to Moo without types, and twenty-two times more objects versus Moose without types. - But these abstractions exist for reasons, and they are used for a reason. -

-

- Moo and Moose have their places, especially in web-applications where the number of instantiations is low, and the expensive - operations happen during side-effects like database operations. - This also goes without mentioning some of the great features modules like Moo and Moose provide. - It is valuable to know that if you need something to perform well, Moo and Moose - may incur overhead you hadn't previously considered. This is compounded when enforcing types. - For hot-code that will be hit repeatedly within a short amount of time, this can drastically effect performance, think of things like a landing page, or a search-bar API. -

-

- Corinna, is a very nice prospect, it offers a lot of great things from Moo and Moose but seems to - exalt far less of a performance penalty. It will definitely be on my radar in the future, especially when the documentation improves. -

-

- Another approach is to simply use functions, which of course will perform the best. But, it's hard to argue to do this unless performance is the number one goal, - especially on codebases that follow this pattern. -

-
- You can view the Source code. -
-
- - diff --git a/trying-lite-xl.html b/trying-lite-xl.html deleted file mode 100644 index 2610ed9..0000000 --- a/trying-lite-xl.html +++ /dev/null @@ -1,17 +0,0 @@ - - - Using LiteXL! - - - - - -
- << back -

Trying Lite-XL

-

- -

-
- -