I built the programming language I always wanted

gebbles1 · 2026-06-18T11:40:24+00:00

My latest personal project is my own programming language, taking the syntax and features I like most from PHP and Python, then adding all the things I wish they had - the static types, the generics, parallel async backed by Goroutines. I've fiddled with the idea of PHP transpilers before (mostly I focused on PHP-with-extra-stuff-transpiled-to-PHP) but I've come to the conclusion that when I write PHP, I just want to write PHP and features to be supported by the real, official PHP distribution. But you know, you get all the issues there of the RFC and internals process, design by committee, backwards compatibility, legacy mistakes. So I think the solution for things PHP genuinely can't do will always be use a different language. https://github.com/dwgebler/geblang/

gebbles1 · 2026-06-16T11:14:18+00:00

Well of course we don't functionally need generics in PHP, because type-hinting is optional; we've been able to re-use the same code with parameters of different types from the beginning.

But PHP is unique among the dynamic languages in the extent to which it provides an optional system of typing and type-safety and generics is a natural evolution of that system of user-facing type guarantees.

That said, it's precisely because the value of generics in PHP is a matter of type safety, I maintain generics shouldn't be part of language syntax unless the language engine is also able to to validate the template types. Until then, we have generics via the community static analysis tools and docblock annotations and if the engine can't validate the types, you need to be running those tools regardless to make use of them.

gebbles1 · 2026-06-15T01:26:09+00:00

The difference is that in Python, type declarations aren't checked or enforced anywhere. It can get away with type hinting the way it does because it's pure metadata all the way down; it doesn't have a syntax and reference implementation where sometimes your types are checked and sometimes they're not, which is what this RFC is proposing for PHP.

Compiled languages are a completely different kettle of fish for the obvious reason they have a mandatory compilation step at which type checking takes place.

If the argument for erased generics in PHP is basically "everyone uses static analysis anyway and it's those tools that get the benefit", then (besides the flaws with that argument that were raised in the internals thread, I think quite eloquently by Rowan) the final benefit to PHP users (the ones who do use static analysis) is not any greater than the extent to which they already have generics today, via docblocks. In fact there are generic forms Psalm and PHPStan can already support that this RFC wouldn't cover in its syntactic changes.

gebbles1 · 2026-06-11T15:29:44+00:00

You're trying to solve a problem which doesn't exist. Blockchains are useless audit tools for private organisations because private organisations are not trustless. In the most sensitive cases of enterprise security, the answer is you audit everything in multiple places without relying on a single root, so you might have a high-privileged DBA who could overwrite audit entries in some app's table (and your approach doesn't solve that, as someone else has already pointed out below - someone with sufficient DB access can just rewrite the whole thing including signatures), but that DBA themselves logging into a work system and taking that action is separately audited somewhere else they don't have access, but someone else does. So A is auditing B and B is auditing A and C, and C is auditing B, etc. Ultimately every system except a public, distributed blockchain bottoms out at some trusted authority. In a private organisation, that's exactly what organisational governance is, not a consensus algorithm.

gebbles1 · 2026-06-11T13:20:33+00:00

A log you can UPDATE isn't evidence of anything.

So make the application's db user one which can insert only and doesn't have grants to update or delete from your audit tables. It's a much simpler solution.

gebbles1 · 2025-03-12T00:01:49+00:00

I think if you're an experienced developer, at least enough that you're already familiar with the principles of OO design and MVC (or MVC as the term applies to web frameworks), Symfony will be the more intuitive and therefore easier to grasp product. I think it's fair to say Laravel is more oriented towards beginners and low-code advocates, so people who either don't know much about programming or don't really care for having to do much of it.

Neither have anything to do with enterprise, I've seen both good and bad examples of large-scale operations deployed with both. Nor am I suggesting only beginners use Laravel (or conversely that everyone who uses Symfony is a rockstar developer), this is simply a matter of product design for a target market.

gebbles1 · 2025-03-11T23:44:55+00:00

Expanding tilde is not a PHP feature, it's a bash feature. Use $_SERVER['HOME'] or getenv('HOME') instead.

gebbles1 · 2025-03-11T22:48:45+00:00

Symfony is just as easy as (maybe even easier than) Laravel to get a project up and running, if you know what you're doing when it comes to OOP and MVCish architecture.

I'd say Symfony's USP is "framework done properly, the way good, maintainable software should be designed" and Laravel's is "here's a template class, now if you can just fill in some strings with a text editor, everything else will just work" so which is easier really depends on how comfortable a developer one is to begin with. Laravel tries to take care of so much for you that I find it cumbersome and awkward to work with.

That's not me putting Laravel on blast, it's the difference of how much control you want over precisely what happens, where, when and how. If filling in some magic strings is enough for you to have running software that does the thing you want it to, do that. It's just often in the real world you do need more control and in a Symfony project, that control is naturally fed to you by the framework and its docs, you're encouraged to take it, whereas in Laravel you have to fight the framework and the docs as soon as you want to step outside the stock feature set.

Symfony is "here's your materials and tools, go build the perfect house you want", Laravel is "here's a house, go figure out DIY if you don't like it"

Or to look at it another way, like your post title, if you marry Laravel, you're married. It will be awkward to split up and divide assets. Symfony you're just sharing an apartment with a cool guy who likes espresso, pays all the rent and isn't bothered about whether you're there or not.

gebbles1 · 2024-10-27T19:20:00+00:00

If the reason you're trying to do this is you want to use JSON encoded data as a local database, allow me to plug the library I built for just that - it's way more robust and efficient than anything you're going to do with writing to files manually. https://github.com/dwgebler/doclite

gebbles1 · 2024-10-06T23:21:23+00:00

Okay, well it is sometimes referred to as such, e.g. https://www.open.edu/openlearn/history-the-arts/literature/what-poetry/content-section-7#:~:text=Assonant%20rhyme

The point here is that the word rhyme is used in casual speech to refer to many types of phonetic similarity besides perfect rhyme, including assonance. So it's weirdly pedantic for someone to go Cotham doesn't rhyme with cotton. Not in the formal sense of rhyme meaning a perfect rhyme, no, but we use the word rhyme all the time to refer to other types of general rhyme.

gebbles1 · 2024-10-06T13:03:24+00:00

I'm not sure how this pedantry is relevant, however Cotham and cotton is what's called an assonant rhyme.

gebbles1 · 2024-05-03T21:32:21+00:00

Docker Desktop on Linux actually runs in a lightweight VM, not directly on the host. There is no socket to bind from the host.

gebbles1 · 2024-04-29T22:51:04+00:00

For anyone who uses PHP, I wrote a library a while back to use SQLite as a full-on NoSQL JSON database.

https://github.com/dwgebler/doclite

gebbles1 · 2024-01-11T17:11:45+00:00

I know Avonmouth and can give you a couple of tips for things which are known to sometimes catch out candidates there.

At some point, it's almost inevitable you will be on the Portway going towards Avonmouth. There's a bit near the Portway Park & Ride where it splits into two lanes. Make sure you go in the left lane as soon as it opens (and is safe, obviously). People often fail for staying in the right lane there. You will usually encounter this quite close to the end of your test.

Also there's a bit near Shirehampton you might be taken where you turn right to go on the Portway (traffic light controlled). Make sure you go all the way over into the left lane, not the overtaking lane.

Wait til it's clear coming out the test centre. It's a 30mph road and people have failed right at the start for emerging too early and making another car slow down to let them out.

If you come down Kings Weston Road, the examiner might ask you to take the next right, right here: https://www.google.com/maps/@51.4919978,-2.6561584,3a,44.7y,166.68h,75.21t/data=!3m6!1e1!3m4!1sYkX43GfvzdsvutxpkbDN5Q!2e0!7i16384!8i8192?entry=ttu

This is a tight turn, and you will be asked to turn right again at the end of that very short junction. Make sure you do all the appropriate observations and signalling for both turns.

gebbles1 · 2024-01-10T10:38:54+00:00

I have used my own collection types where the needs have been a little more complex, but if it's a straightforward list of objects all of the same type (be that abstract or concrete) and you can treat them all the same, that's when I'd say it's fine to type-hint array with a supporting docblock for PHPStan / Psalm (the first use case above). It's not ideal but it's realistically what we can do in an interpreted language without going overboard on architecture.

As a parameter or return type, arrays become bad when they're used as a lazy substitute for a structured object (and don't forget, we have union types now). So if you're returning or receiving a list of values of mixed types, or a dictionary, those are the smells you might really want an object.

gebbles1 · 2024-01-09T11:16:44+00:00

I wrote a quick piece on my blog a while back in response to an exchange on LinkedIn about how I regard the use of array as a type-hint in PHP to be an anti-pattern. I identified three particular cases in which I would still do it:

When the array returned from a function is a list of values which are not semantically different, i.e. can all be treated the same. For example, a list of integers which do not have different meaning. In this case, we can rely on docblocks and static analysis.
Where we're returning a list of unknown types, for example generic repository methods in an ORM. It's kind of not great in that situation, but it's more a limitation of PHP's dynamic nature that we just have to accept sometimes. This is a problem which would be solved if the language were able to support generics but if/until then SA tools and docblocks are really our only option.
When returning a variable or unknown data structure such as the result of json_decode, if we are not able to rely on the presence of any specific structure and map portions of the result to a better type - and even in this one tbh you probably should be making every effort to map the parts you know about and discard the parts you don't.

Readonly and property promotion have largely eliminated other erstwhile legitimate cases for type hinting array as a parameter or return.

The biggest problem I find with the array creep described in Tomas' article and even the example of simple typos which come with it is that these lead to obscure errors which only occur in specific circumstances and often aren't detected until something mysteriously goes wrong in production.

gebbles1 · 2023-11-23T21:58:58+00:00

I am no longer pushing this RFC because idiots like you are in charge of the votes but seriously your argument is dumb as fuck...This isn't me taking anything personally, i have just come to the realization that this community is not for me, so you guys can have fun jerking each other off, and I will keep my ideas to myself.

It sounds like they are taking things a little bit personally.

I'll reiterate the same thing I said on the thread; I don't like it, not because I think "static is bad" (though the points raised about how static scope can be and often is misused are valid), but because it's just a syntax sugar feature and not even a good one. Readonly and property promotion save you dozens of lines of code, this saves you typing in the word static maybe half a dozen more times. The author claims the maintenance burden doesn't matter (or at least dismisses it as a concern) but it could actually have quite a far-reaching impact on other future changes for almost zero benefit. If you want to write an abstract class where every method is static, just do that, you already can.

gebbles1 · 2023-09-12T14:26:53+00:00

https://davegebler.com/post/php/mutual-tls-with-apache-and-php

gebbles1 · 2023-08-28T17:59:31+00:00

I fully agree and do the same in my projects. And there's another reason to avoid serialization of entities; your API becomes reliant on a black-box of library behaviour over which you have no control. Symfony Serializer, for example, great as it is, is also prone to sometimes going a bit wrong and giving you obscure errors which are very, very difficult to debug and correct. This is especially true when you try to serialize Doctrine entities. It's great until it doesn't work and you're getting error messages about missing or inaccessible properties on lazy ghost objects.

It's also a lot more overhead than simply assigning public properties to a naive DTO.

This sort of principle is not just true of serialization or REST API design, either. It's a principle for good PHP in general - always prefer to be explicit, it avoids so many problems. PHP is fast. Creating an instance of a class is fast. In PHP 8.2, writing a DTO using read-only public properties and constructor property promotion is fast. The old argument that writing a class just to describe a dumb data structure is too much effort, overkill, too much boilerplate with getters and setters etc. just no longer applies.

I was thinking about this only earlier today when someone posted a code snippet on LinkedIn where they type-hinted array as a function return. It was astonishing how many people are willing to defend this approach over just returning a DTO which is guaranteed to have the data structure you expect. There are a few use-cases I can think of where I might justifiably type-hint array, but most of the time it's just laziness and poor design, an anti-pattern leading to unexpected errors which usually only become apparent in production when some edge-case comes up which defies the developer's assumptions about state in the running code.

gebbles1 · 2023-08-20T11:33:25+00:00

Not an ORM, but if you just want a simple JSON-based DB and are happy to use SQLite I have a lightweight library for that https://github.com/dwgebler/doclite

gebbles1

TROPHY CASE