OTheB @OTheB@mastodon.technology

MOAR LOGGING

I am now a box that is in space.

I'm definitely keeping the no-null and default value approach. I want to rethink how I'm doing exceptions and errors though. As meme-y V is at the moment, it's error system is pretty well done from a syntax perspective, so I think I want to create a new system that's still OOP, but works more in that kind of explicit way, where if you call a method that can pass an error, you have to either handle it or explicitly propagate it.

Really though, this kind of two-sides issue is only one of the things I'm really unsure about. I definitely want O to be high-level or at the very least abstracted, but at the same time I want it to be conceptually fairly simple. I feel like I've been putting loads of cool ideas and things into it that are ultimately unnecessary, like value-based declaration conditions when really only type-based conditions are needed.

Then on the other hand, if I enforce members and static classes I kinda solve the problem as well, and it seems like it would be a simpler method as it's one I understand better. The only things that would ever be external to classes would be enums and extension methods.

But *then* I'm back at the problem where writing functional-style code becomes really iffy.

*Then* you realise that actually if you can have non-member methods then static classes are just pointless, so now you have *another* thing that's inconsistent and aaaaaaaaaaaa.

I feel like if I could find, figure out, or be taught a way of getting around group A so you can still implement the same stuff in a sane manner without needing member methods, then I could start working well towards a more procedural system that's just structs and functions.

So you have these 2 main categories, the second of which is kind of in 2 rather vague subcategories. Group A *must* be a member, group B *should* be a member, and group C *should not* be a member.

What I want for O is to have a case where there are no "should"s, only "must"s I guess.

The way I've found fully OOP languages like C# get around it is by putting group C in static classes and then putting group B in a mix of both static and normal classes. Messy, but kinda works.

On the other side, you have basically *everything else*, where actually there's nothing stopping you from writing a non-member method that just takes a reference to a certain object of the type the method would otherwise be a member of (fuck me that was a sentence).

You then have a subset of these methods where there isn't one single thing of importance, only an action that bases itself on parameters. *These* are the methods that feels off being members.

I can't inherit a class and write methods that take that subclass, because when my generic method takes input of the superclass/interface, the implementation for *that* is executed, creating a method/attribute that has to be a member as a result of type inheritance and interfaces, both of which are really important things imo for making writing software simpler.

I've found you can divide methods into 2 categories: mandatory members and optional members. A mandatory member comes up when you start using interfaces. If I want some uniform means of working with enumerable things, then I make an interface with 'current' and 'next()' members, so then I can implement whatever kinds of generators and manipulators I want and chain them together however. Those members have to be members though because they're specific implementations of a generic type.

If I compromise then I end up with a language like C++ or D which are definitely not terrible languages, but because they (I'll use D as an example because that's what I know better) mix these 2 approaches it feels clunky in a way, like one approach feels more "correct" and the other feels more "natural", but their combination feels nasty even if it's actually completely fine.

So I'm sort of after this impossible situation where everything's a member *and* nothing's a member.

Ok, so because all my professional and non-newb experience with programming has been with OOP, I naturally want O to be object oriented, and that's fine.

*However*, I've been becoming increasingly interested in functional-style programming (however not pure functional languages). There's this kind of clash between full OOP and functional where in OOP *everything* is a member method, but in functional *nothing* is. (assume 'cont' on all of these)

Ok time for shit loads of waffling about language design because I'm feeling existential about #Olang. Let's fucking gooooooo

Is it just me or is V's error handling actually ok? Same kind of system as Go afaik.

Only problem I can see with it is you can't distinguish different kinds of errors unless you want to do string manipulation on the error message, which gets nasty.

I feel like having exceptions, but requiring a marker on methods that throw and better catch syntax would be the ideal.

So you have e.g. a "maythrow" attribute and you either suffix the call with a catch or use some other marker to propagate the error.

YEET. Figured out that I can make my VPS' docker-compose file run locally without issue if I just change the volumes and virtual hosts so it's sub-domains of localhost.

Makes things much easier to work with.

Tell you what, packaging stuff is a lot more fun than containerising it.

Inf: "Yeah we already have a host running Harbor that you could put the repo on."

Me: "Cool. I assume SSH is running on it? Will my normal credentials work?"

Inf: "Give me a sec I'll check"

...

Inf:

Anyone here setup their own rpm repository before? Any tips from experience? This would be for internal packages on LAN, not a mirror of the main repos.

When you think you've just completely fucked up typing your password but you hit enter and it works

I've spent basically all of today writing docs.

It's strangely therapeutic. I kinda like it.

Of course it's all great until I need to follow the docs to do the thing I'm documenting and it all just fucking breaks lmao.

I don't use IRC as a common means of communication, but I still really like it, because you're able to "just" use it. You don't need an account or any setup, there are web clients and stuff, so if a project has an IRC channel and you need help, you can just connect and chat. Very quick and convenient.

Next episode of the docker madness:

The first app I got working is an edge case. All the others require creating a connection to a config db for the installer to run, which won't be a thing outside an environment when we're just making images.

So... I'm back to the packaging route. I need to run through the installer manually, providing a connection to a sacrificial config db which the installer will write some shit to, then I package the result.

That goes in a repo and then we good.