diff options
| -rw-r--r-- | gemfeed/2022-05-27-perl-is-still-a-great-choice.md | 2 | ||||
| -rw-r--r-- | gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.md | 16 | ||||
| -rw-r--r-- | index.md | 2 | ||||
| -rw-r--r-- | uptime-stats.md | 2 |
4 files changed, 19 insertions, 3 deletions
diff --git a/gemfeed/2022-05-27-perl-is-still-a-great-choice.md b/gemfeed/2022-05-27-perl-is-still-a-great-choice.md index 2de9d9b8..a04c149f 100644 --- a/gemfeed/2022-05-27-perl-is-still-a-great-choice.md +++ b/gemfeed/2022-05-27-perl-is-still-a-great-choice.md @@ -103,7 +103,7 @@ About the first point, using Perl for better "shell" scripts was actually the or Here are some reasons why not to chose Perl and look for "better" alternatives: -* If performance is your main objectives, then Perl might not be the language to use. Perl is a dynamic interpreted language, and it will generally never be as fast as statically typed languages compiled to native binaries (e.g. C/C++/Rust/Haskell) or statically typed languages run in a VM with JIT (e.g. Java) or gradually typed languages run in a VM (e.g. Raku) or languages like Golang (statically typed, compiled to a binary but still with a runtime in the binary). Perl might be still faster than the other language listed here in certain circumstances (e.g. faster startup time than Java or faster regular expressions engine), but usually it's not. It's not a problem of Perl, it's a problem of all dynamic scripting languages including Python, Ruby, .... +* If performance is your main objectives, then Perl might not be the language to use. Perl is a dynamic interpreted language, and it will generally never be as fast as statically typed languages compiled to native binaries (e.g. C/C++/Rust/Haskell) or statically typed languages run in a VM with JIT (e.g. Java) or languages like Golang (statically typed, compiled to a binary but still with a runtime in the binary). Perl might be still faster than the other language listed here in certain circumstances (e.g. faster startup time than Java or faster regular expressions engine), but usually it's not. It's not a problem of Perl, it's a problem of all dynamic scripting languages including Python, Ruby, .... * Don't use Perl (just yet) if you want to code object-oriented. Perl supports OOP, but it feels clunky and odd to use (blessed references to any data types are objects) and doesn't support real encapsulation out of the box. There are many (many) extensions available on CPAN to make OOP better, but that's totally fragmented. The most popular extension, Moose, comes with a huge dependency tree. But wait for Perl 7. It will maybe come with a new object system (an object system inspired by Raku). * It's possible to write large programs in Perl (make difficult things possible), but it might not be the best choice here. This also leads back to the clunky object system Perl has. You could write your projects in a procedural or functional style (Perl perfectly fits here), but OOP seems to be the gold standard for large projects nowadays. Functional programming requires a different mindset, and pure procedural programming lacks abstractions. * Apply common sense. What is the skill set your team has? What's already widely used and supported at work? Which languages comes with the best modules for the things you want to work on? Maybe Python is the answer (better machine learning modules). Maybe Perl is the better choice (better Bioinformatic modules). Perhaps Ruby is already the de-facto standard at work and everyone knows at least a little Ruby (as it happened to be at my workplace) and Ruby is "good enough" for all the tasks already. But that's not a hindrance to throw in a Perl one-liner once in a while :P. diff --git a/gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.md b/gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.md index ce166fe2..893e7af4 100644 --- a/gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.md +++ b/gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.md @@ -21,10 +21,26 @@ Let's list what's new! ## Switch to GPL3 license +Many of the tools and commands (GNU Bash, GMU Sed, GNU Date, GNU Grep, GNU Source Highlight) used by `Gemtexter` are licensed under the GPL anyway. So why not use the same? This was an easy switch, as I was the only code contributor so far! + ## Source code highlighting support +The HTML output now supports source code highlighting, which is pretty neat if your site is about programming. The requirement is to have the `source-highlight` command, which is GNU Source Highlight, to be installed. Once done, you can annotate a bare block with the language to be highlighted. E.g.: + +``` + ```bash + if [ -n "$foo" ]; then + echo "$foo" + fi + ... +``` + +Please run `source-highlight --lang-list` for a list of all supported languages. + ## HTML exact style +The resulting HTML has changed. + ### Use of Hack webfont by default ## Mastadon verification support @@ -1,6 +1,6 @@ # foo.zone -> This site was generated at 2023-07-17T05:18:04+03:00 by `Gemtexter` +> This site was generated at 2023-07-17T20:24:46+03:00 by `Gemtexter` ``` |\---/| diff --git a/uptime-stats.md b/uptime-stats.md index 9ded080b..95863e49 100644 --- a/uptime-stats.md +++ b/uptime-stats.md @@ -1,6 +1,6 @@ # My machine uptime stats -> This site was last updated at 2023-07-17T05:18:04+03:00 +> This site was last updated at 2023-07-17T20:24:46+03:00 The following stats were collected via `uptimed` on all of my personal computers over many years and the output was generated by `guprecords`, the global uptime records stats analyser of mine. |