This explains the Scotch-Irish settling in Appalachia. It felt like home, but without the overbearing Brits nearby.
surely you mean overbearing English, old man?
Readit Newslibrasteve commented on The Scottish Highlands, the Appalachians, Atlas are the same mountain range vividmaps.com/central-pan... · Posted by u/lifeisstillgood
Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here:
https://htmx.org/essays/when-to-use-hypermedia/
Also, please try unpoly:
It’s another excellent hypermedia oriented library
Edit: the article is actually not nearly as unreasonable as I thought based on the just-f*king-use template. Still prefer a chill vibe for htmx though.
HTMX Sucks
> I'm curious what the CX-83D87 and Weiteks look like.
The Weitek's were memory mapped. (At least those built for x86 machines.).
This essentially increased bandwidth by using the address bus as a source for floating point instructions. Was really a very cool idea, although I don't know what the performance realities were when using one.
http://www.bitsavers.org/components/weitek/dataSheets/WTL-31...
haha - took me a while to figure out that's Mauro Bonomi's signature
iirc the 3167 was a single clocked, full barrel shift mac pipeline with a bunch (64?) of registers, so the FPU could be driven with a RISC-style opcode on every address bus clock (given the right driver on the CPU) ... the core registers were enough to run inner loops (think LINPACK) very fast with some housekeeping on context switch of course
this window sat between full PCB minicomputer FPUs made from TTL and the decoupling of microcomputer internal clocks & cache from address bus rates ...
Weitek tried to convert their FPU base into an integrated FPU/CPU play during the RISC wars, but lost
Looks like a log multiply-adder ... maybe a 5 clock cycle? Also, on the microcode ... them FP divide algorithms are pretty intense.
Would be cool to hear a real designer compare to the Weitek 1064.
librasteve commented on Perl's decline was cultural beatworm.co.uk/blog/compu... · Posted by u/todsacerdoti
I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense. Then there was the whole one-liner thing that was all about being clever and obscure. Everything about Python came off as being much more serious and normal for a young nerd who wasn't a theater kid.
> Perl has always “flowed” for me and made mostly intuitive sense. Every other language I’ve had to hack on to get something done is a struggle for me to fit into some rigid-feeling mental box
That is just how I felt about Perl (4 years full time dev in the 2000s) and how I now feel about https://raku.org (aka Perl6). Anyway, I tried to gather some fellow feelings here about 18 months ago:
https://rakujourney.wordpress.com/2024/05/22/perl-love-notes...
It is sad that Perl became so despised after the error of preannouncing a non-compatible upgrade. I understand that people couldn't wait. But Raku is here now and it is worth a second look imo.
Deleted Comment
librasteve commented on Perl's decline was cultural beatworm.co.uk/blog/compu... · Posted by u/todsacerdoti
I loved Perl and all the obscurity. It felt like black magic back then. It should have become what python is today.
actually Perl was what Python is today - the go to scripting language
librasteve commented on Robust code generation combining grammars and LLMs raku-advent.blog/2025/12/... · Posted by u/antononcube
TL;DR
- Combining grammars and LLMs produces robust translators.
- Three translators with different faithfulness and coverage are demonstrated and used.
- Two of the simplest, yet effective, combinations are implemented and - demonstrated.
- Parallel race and grammar-to-LLM fallback.
- Asynchronous implementations with LLM-graphs are a very good fit!
- Just look at the LLM-graph plots (and be done reading.)librasteve commented on Thoughts on Go vs. Rust vs. Zig sinclairtarget.com/blog/2... · Posted by u/yurivish
Probably was downvoted because it seem to copy-paste/derive-off an LLM output since, even if you say you wrote it yourself, some distinct LLM grammar/style characteristics appear. (Could just be you picked them as habit after use of such tools.) It doesn't appear to in same vein either. The submitted article's descriptions are, for each language, {philosophy} & {specific design examples}. Yours is mainly on {design}.
That said, agree Raku is cool. A big disadvantage though it has (or had?), more than the sigils-everywhere syntax & small ecosystem, is performance. It's slower than pre-JIT Python. Go also natively-compiles to self-contained binaries, which some people appreciate. (And there're those that prefer Go's simplicity and don't want very high expressiveness other than specific features.)
Well - sure - I meant wrote as in "sourced a set of relevant sentences from ChatGPT and then close edited them to convey precisely what I wanted to say" - got me bang to rights there!
librasteve commented on Thoughts on Go vs. Rust vs. Zig sinclairtarget.com/blog/2... · Posted by u/yurivish
I tried to get an LLM to write a Raku chapter in the same vein - naah. Had to write it myself:
Raku
Raku stands out as a fast way to working code, with a permissive compiler that allows wide expression.
Its an expressive, general-purpose language with a wide set of built-in tools. Features like multi-dispatch, roles, gradual typing, lazy evaluation, and a strong regex and grammar system are part of its core design. The language aims to give you direct ways to reflect the structure of a problem instead of building abstractions from scratch.
The grammar system is the clearest example. Many languages treat parsing as a specialized task requiring external libraries. Raku instead provides a declarative syntax for defining rules and grammars, so working with text formats, logs, or DSLs often requires less code and fewer workarounds. This capability blends naturally with the rest of the language rather than feeling like a separate domain.
Raku programs run on a sizeable VM and lean on runtime dispatch, which means they typically don’t have the startup speed or predictable performance profile of lower-level or more static languages. But the model is consistent: you get flexibility, clear semantics, and room to adjust your approach as a problem evolves. Incremental development tends to feel natural, whether you’re sketching an idea or tightening up a script that’s grown into something larger.
The language’s long development history stems from an attempt to rethink Perl, not simply modernize it. That history produced a language that tries to be coherent and pleasant to write, even if it’s not small. Choose Raku if you want a language that let's you code the way you want, helps you wrestle with the problem and not with the compiler.
I see that my Raku chapter was downvoted a couple of times. Well OK, I am an unashamed shill for such a fantastic and yet despised language. Don’t knock til you try it.
Some comments below on “I want a Go, but with more powerful OO” - well Raku adheres to the Smalltalk philosophy… everything is an object, and it has all the OO richness (rope) of C++ with multiple inheritance, role composition, parametric roles, MOP, mixins… all within an easy to use, easy to read style.
my $forty-two = 42 but 'forty two';