ciarand

If you don’t already have a preferred workflow for autogenerating these, you might be interested in vhs https://github.com/charmbracelet/vhs

I am not affiliated, I just think it’s a neat tool

I don’t mind sticking to bash, but some of the other choices seem overly opinionated. In my experience the best Makefiles just invoke other commands, so you’re only using make for its dependency tracking. That way the Makefile remains fairly simple and you can use something more sensible (bash instead of bash-in-make, python, whatever) to write your actual build logic.

The Makefile should probably be listed as a dependency for all the rules too, otherwise you’re gonna end up dealing with stale results and adding a “clean” target.

I think Drew lists some of his complaints here https://sourcehut.org/blog/2021-05-08-sourcehut-is-the-faste...

Basically GitHub is pretty unusable on slow connections / computers (for some definition of some). Git on the command line is fine, but for browsing code that’s not already local to your machine you want something that can quickly show you the contents and then get out of your way

Yeah, as long as there's a way to specify a strict type then I'd be happy. Libraries and other code that's intended to be used by 3rd parties could probably benefit from weak type hinting, but internally I'd really like the confidence that comes from strict hinting.

>PHP plays a bit too loose with those rules

I don't think you or I disagree on this. The language does not handle strings gracefully.[1][2] The more magic casting and conversions I can remove from my codebase, the happier I'll be.

I'm sure there are some individuals that would misuse strong typing, but it would help a whole lot of people avoid some really, really dumb bugs. This isn't so much about knowing what's going on internally (binary representations), this is about being able to catch bugs early and often. It also helps in refactoring and improves the quality of linters.

But yeah, if SWTH casts if a parameter matches the definition of a type (e.g. 1.5 is not an int but 1.0 is) then SWTH is fine. There'd probably be a little bit of a performance penalty, but as long as the devs implement strict casting rules (according to Nikita's favorite proposal) then it solves my problems. As a sidenote, Nikita actually agreed to the casting change after posting that article[3].

[1]: http://phpsadness.com/sad/47 [2]: http://stackoverflow.com/a/1995196 [3]: http://www.jejik.com/articles/2012/03/a_php_type_hinting_alt...)

I've read that article, and like most of the commentators I'd like the option for strict type hinting. It's a choice I make, it's not forced on me. Having strong type hints removes any doubt from the code. I know exactly what's being passed around and what it represents, and I can be comfortable in knowing what that means. I don't need the engine to do anything magic[1] in the background.

While the idea of "strong weak type hinting" is interesting, and would certainly be useful for some code (especially libraries), it's not what I want from type hinting. At least 70% of the bugs I encounter in the wild are due to unexpected types. SWTH doesn't fix that - if I pass in a string and it looks like a number, the function will blindly accept it. That's not a behavior I want, that's something I want caught before I even think about deploying.

I guess it depends on what you expect type hinting to provide you, but it looks like I'm not alone in wanting guaranteed safety (Facebook and Box seem to agree). Only strict typehinting fixes that.

But, if the community decides that SWTH is worth pursuing I'd like to choose a syntax structure that allows both to coexist. "foo(int $int)" can be strongly-typed, while "foo(~int $int)" can be strongly weakly typed.

[1]: http://www.php.net/manual/en/security.magicquotes.php

Edit: forgot link

First, you're right - the core library and API does have a long way to go. Imo, we need a new major version (6) so we can break backwards compatibility for some of this craziness.

But as for the annotations, the most compelling argument I've seen is to make it string (===). If you supply "123" and the method signature requires an int, it should throw an exception. If you don't want that, don't include the typehint.

That also gives the option for something like a "~number" typehint if necessary, but I don't care about that. I want strict type checking, anything less than that does not solve the core problem.

Also try gh[1], a Go port of hub. It's faster (mostly due to the difference in speed between Go and Ruby), and it doesn't require Ruby be installed.

[1]: https://github.com/jingweno/gh