I was 8 years old the boy in the block invited me said I have something to show you. His parents bought him a Macintosh. He typed my name on the black screen and there was a response.
He said look it says “How are you?” And I was mesmerised got so excited I was like wow 😲
Guess what the text was actually saying? syntax error 😂 Little did I know at that time!!
I went home and told my parents, can you believe what I’ve seen today?? Computer responded me talked to me!!
On my birthday I got a Commodore 64 that year and the story begun.

!rant
... so... maybe not that much of a thing, but i think it is:

a gal (27 years old) i started teaching programming two weeks ago, who had literally no previous experience with programming, algoritmization nor c#...
... just now, after 3 lessons of 6 hours altogether, and after yesterday when i explained to her what arrays are and reminded her what loops do...

... invented bubble sort. on her own. no googling. on paper. no "trial and error code typing and running".

i'm actually pretty proud of her :)

... putting the algo concept into actual code will still be a bit of a struggle, but yeah, hell, can't help thinking that she's actually pretty smart :)

(p. s. fist lesson was i drew uml of a fibonacci algo and forced her to understand what it does, second lesson was i explained the minimum required c# syntax for her to be able to implement it and forced her to write it (with as little help as i could), third lesson was the concept of array and "okay, now here's array of numbers, make a function that will sort them")

looking forward to what will happen when i explain recursion and nudge her towards quicksort O:-)

Today on "How the Fuck is Python a Real Language?": Lambda functions and other dumb Python syntax.

Lambda functions are generally passed as callbacks, e.g. "myFunc(a, b, lambda c, d: c + d)". Note that the comma between c and d is somehow on a completely different level than the comma between a and b, even though they're both within the same brackets, because instead of using something like, say, universally agreed-upon grouping symbols to visually group the lambda function arguments together, Python groups them using a reserved keyword on one end, and two little dots on the other end. Like yeah, that's easy to notice among 10 other variable and argument names. But Python couldn't really do any better, because "myFunc(a, b, (c, d): c + d)" would be even less readable and prone to typos given how fucked up Python's use of brackets already is.

And while I'm on the topic of dumb Python syntax, let's look at the switch, um, match statements. For a long time, people behind Python argued that a bunch of elif statements with the same fucking conditions (e.g. x == 1, x == 2, x == 3, ...) are more readable than a standard switch statement, but then in Python 3.10 (released only 1 year ago), they finally came to their senses and added match and case keywords to implement pattern matching. Except they managed to fuck up yet again; instead of a normal "default:" statement, the default statement is denoted by "case _:". Because somehow, everywhere else in the code _ behaves as a normal variable name, but in match statement it instead means "ignore the value in this place". For example, "match myVar:" and "case [first, *rest]:" will behave exactly like "[first, *rest] = myVar" as long as myVar is a list with one or more elements, but "case [_, *rest]:" won't assign the first element from the list to anything, even though "[_, *rest] = myVar" will assign it to _. Because fuck consistency, that's why.

And why the fuck is there no fallthrough? Wouldn't it make perfect sense to write

case ('rgb', r, g, b):
case ('argb', _, r, g, b):
case ('rgba', r, g, b, _):
case ('bgr', b, g, r):
case ('abgr', _, b, g, r):
case ('bgra', b, g, r, _):

and then, you know, handle r, g, and b values in the same fucking block of code? Pretty sure that would be more readable than having to write "handeRGB(r, g, b)" 6 fucking times depending on the input format. Oh, and never mind that Python already has a "break" keyword.

Speaking of the "break" keyword, if you try to use it outside of a loop, you get an error "'break' outside loop". However, there's also the "continue" keyword, and if you try to use it outside of a loop, you get an error "'continue' not properly in loop". Why the fuck are there two completely different error messages for that? Does it mean there exists some weird improper syntax to use "continue" inside of a loop? Or is it just another inconsistent Python bullshit where until Python 3.8 you couldn't use "continue" inside the "finally:" block (but you could always use "break", even though it does essentially the same thing, just branching to a different point).

Hired a new BI developer. She tested reasonably ok in SQL, and certainly showed good strengths in visualising data, plus had a good attitude in the interview. We hired her. She broke her laptop the first day. We got her another then she complained the camera didn't work but didn't realise the lever in front of the camera was to move the privacy shutter off and on.

Assigned her some work of taking queries that are used in a BI tool that targets the transactional database directly, and re-jigging them for Snowflake which we're using as a data warehouse now, aggregating all our data into one place. Yet, she's struggling to understand why the SQL query she's pasted in doesn't work as-is.

I go over it again; the source schemas and tables are this, but in Snowflake we've named them this. She then bemoans how much work that is to change them all - I say use find and replace. She then struggles with Snowflake syntax errors and asks for a guide on T-SQL to Snowflake. I show her Google and say "this is what I did when I hit these problems - search for 'Snowflake equivalent to T-SQL getdate()' or 'how to get current date in Snowflake' but she still doesn't understand. I ask if she's every had to work between T-SQL and MySQL or MySQL and PostgreSQL or Oracle and so on and she says yes. I say the syntax isn't the same, is it? And she goes oh, now I understand.

She scored reasonably in her SQL test but I'm now concerned there's something fundamental missing in her grasp of SQL. I gave her a detailed demo of the tools, I explained in the interview and on her start about our move to a data warehouse for all our apps, and put her through some training plus gave her time to work through our Confluence pages - not expecting she'll remember everything, but more to ensure she recalls they exist and what the general contents are.

Anyhow, that's my rant.

Americans be like "I'm offended! My compiler said I have a syntax error!"

Started writing a parser for moonscript. Because I want to do my own syntax highlighting and error support.

I'm sorry, but was this supposed to difficult? Every article I read claimed this was gonna be some impossible feat of herculean effort. I half dreaded it, the other half was kinda elated.

Only it didnt live up to the hype. The tokenizer is a glorified character stream. The lexer is little more than a tokenizer, and the "most complicated" bit is nothing but a fancy transformation of the token output into a tree.

I'm completely to new parsers proper and semantic checking and maybe that's why it seemed easy, but I dont see what all the forewarning in tutorials were ever about.

Interesting...

On Friday, I was playing with the ChatGPT integration in DBeaver. I was using the DBeaver sample SQLite database. This database has a couple of tables, among them Album and Artist, where Album has a foreign key into Artist.

So, I asked it:

"give me a query that lists all albums from artists who's name starts with s"

The query I got back was:

SELECT * FROM Album

Uhh, okay.

But then, I noticed that I wrote "who's" instead of 'whose', which would be proper grammatically. So, I changed that, and then I got this query:

SELECT * FROM Album WHERE ArtistId IN (SELECT ArtistId FROM Artist WHERE Name LIKE 'S%');

Hooray, that works! I'm not sure it's the best way to write the query... I might have written:

SELECT * FROM album a, artist r WHERE a.artistid=r.artistid AND r.name LIKE 'S%'

...I'd have to check to see if one performs better than the other, and consider which syntax I find clearer, but that's a separate issue, it's just nice to see a working, reasonable query generated because that's the point, after all.

But I found it interesting that such a minor error would cause it to not work, that's my main point.

Interestingly, it seems to have learned: I just tried the same thing, and I got the right query either way. So that's pretty cool.

It's a pretty neat feature and I can see some legitimate value in it. I'm pretty good writing SQL myself... I've managed to write some truly hideously complex queries over the years... but there are definitely instances I can recall where the query didn't seem obvious at the start, and having an AI that can MAYBE produce something that is AT LEAST a starting point is definitely something I can get onboard with.

Experimented with embedded Rust. Fuck that. C is a brilliant small language. Trustworthy. Rust is just C++ killer, it doesn’t belong in embedded domain. Bloated syntax, verbose error handling, crap quality crates with little to no documentation.

font-family expects a comma-separated list. Fonts haven't been displaying on my blog for months because of this issue.

Why could NONE of the browsers I tested this on give me a real syntax error instead of "invalid property value" which could mean literally anything.

Edit: Actually, why can't the CSS plugin for VSCode tell me that I'm making a syntax error in the value of a well-known property?