Why does that need to go in the title though? Just put some magic in the commit bodies, if you want to do versioning in that weird way. Then you aren't restricted to a single word either.
Why do you even want the issue number in the commit title? I find that super annoying and unfortunately GitHub kind of forces it on you if you use merge queues.
if IDE supports converting them into clickable links, then scrolling through a log in its Git integration (kinda like `git log --oneline`) will be a convenient list of links to issues. If the commit messages are good, you just skip over the Jira issue/ticket key/ID. If what you want is to see the requirements of a feature or steps to reproduce of a bug or some other context for the ticket, then a clickable link is very convenient. Of course, sometimes it does make sense to include some of that information in the commit message as well.
When working in big teams, it can be very hard to increase the usefulness of commit messages. On the other hand, enforcing inclusion of a Jira issue key in commit messages is easy to implement. Relying on issue tracker descriptions can be a difficult proposition as well. Quality of individual ticket descriptions can be low; depending on how responsibility for maintenance is handled, the bug tracker migrations can sometimes be handled improperly and information can be more easily lost than in a Git log.
It’s very helpful to know the motivation for the commit and if that motivation was tied to a client contract/feature. Especially in cases where a commit affects multiple files or even just one file so that all commits can be grouped into a feature/contract.
COMPANY-1234 in the title doesn't tell the reader all that much about the the feature or motivation. It does tell the client, but I'm not seeing why that is better than having it in the description as a tag, or some other nice way of extracting it.
Least of all when that ticket is older and so much of the code and the company has changed too. Like sometimes useful historical context sure but worth putting in the first line of a commit? I put it in the body with a link to the ticket or tickets as a footer, if someone wants historical context it's there.
Not my experience. I installed the IoT version of Windows 11 and have changed exactly one setting (put the start menu back on the left where it rightfully belongs). Nothing else has required any changes at all to get sanity, which is more than you can say for Mac (which requires half a dozen extra apps to make it same - SteerMouse, Karabina, Spectacle, etc.), or Linux, where the UI is mostly sane - if you're using KDE anyway - but you're beset by bugs and jank.
And don't say "it works for me". We know some people get very lucky with Linux and stuff just works. In my experience the typical experience is that stuff works much better on Windows than Linux.
E.g. something Windows figured out in 2000 - what happens when your system is low on ram or overloaded? Simple! Press ctrl-alt-del, it will pause other apps and allow you to open the task manager and choose one to kill.
On Linux? There's no task manager in the ctrl-alt-del menu (on KDE anyway), and even if there was it isn't a specially privileged UI so it wouldn't respond. Running low on RAM? No problem we'll just kill a random process and if that doesn't work (it usually doesn't), completely freeze and then hard-reboot. Yeay.
The Task Manager that many times also stopped responding or was permanently stuck behind a frozen full screen game?
On Linux, KDE has the plasma System Monitor, and if you can't use it for some reason you can switch your entire session to a TTY with CTRL+ALT+F2 and kill any process you want.
> you can switch your entire session to a TTY with CTRL+ALT+F2 and kill any process you want.
How intuitive. That's often disabled, and I've definitely had machines that were so frozen even that didn't work. I guess sysrq keys might have worked but if you're seriously going to suggest that you haven't understood the problem.
> The Task Manager that many times also stopped responding or was permanently stuck behind a frozen full screen game?
Hasn't happened once for me for as long as I can remember.
In fairness Linux has been pretty solid for me too after upgrading to 128GB of RAM and 64GB of swap. But I never needed to do that on Windows.
It's the circle of life. Dynamically typed language has fans. Other people correctly say that it would be a lot more useful with static types. Fans take this personally and say it doesn't need static types because (they aren't useful anyway/it goes against the spirit of the language/it's only a scripting language anyway/you can just use a debugger/static types hurt productivity/etc. etc.)
Then eventually they add static types. Happened to Python, JavaScript, Ruby... I'm sure there are more.
Nobody writes dynamically typed functions that can be called with any possible type.
It's not about that at all. Static types give you errors reliably at compile time instead of randomly at runtime, better documentation of what the code expects (people writing dynamically typed languages eventually resort to type comments), working IDE support, reliable refactoring and better code, all of which results in faster development.
The cost is a more complex language, occasionally difficult-to-write types, and very occasionally impossible-to-write types. But those are very very minor in comparison to the pros.
Is a valid function declaration, which specifies that blah takes a dictionary that contains at least 2 keys, :count, who's value is an integer, and :students, who's value is a length-1 list who's first element is a dictionary that contains the keys :firstname and :lastname
I mean I'm not an Elixer guy (not at all) so it's a bit opaque to me how that's not an enforcement of specific types (albeit the firstname, lastname can be anything?)
Once we get into the function itself, if two incompatible types, say a string and a filehandle.. (just random attempt, you may, if you choose, point to why the two types must have some alignment), what happens - the function dies?
That's my core issue with dynamic typing, you might argue that the function's explosion has a restricted blast radius, but that's not the point, the point is that the function was called, and was unable to compute whatever, and that's a bug.
In elixir, processes (these are Erlang "processes", not OS processes) are designed to fail when they encounter errors, and the supervising process will restart it according to various rules you can configure. This isn't dissimilar to how kubernetes restarts jobs when they fail, but at a more fine-grained level.
It's actually intended that your function doesn't try too hard to validate it's input types, and just that it will malfunction and crash when it gets something it doesn't know how to handle, because the supervision tree will rescue it and your program can continue, albeit without whatever input caused the malfunction.
This obviously isn't ideal for many types of software, but for complex backend servers and other long-running operations it works really well.
Of course this is not a guarantee to eliminate bugs, but it's a factor that reduces them more than you'd think when coming from a different programming paradigm.
I mean - you're arguing there about a small blast radius, and I genuinely appreciate that not taking down the whole system when a bug occurs is incredibly valueable.
But, the discussion is about dynamic typing, and the fact that the function is in a state where it cannot compute because of bad input.
This might as well be a Null Pointer Exception - the function has encountered bad input, and crashes.
The argument is, that a MUCH stronger position is for all callers to be forced to provide input that cannot get the function into such a state - and a major subset of the set of all inputs possible can be eliminated with static or strict typing (I know the nomenclature gets a bit hazy here, but I hope that my intended meaning is clear)
If the callers know in advance that they cannot provide input shaped in ways that the function will not handle, then they will not call the function in those ways.
And that forces the call chain to be sure about the data transferred from top to bottom.
Maths pretty much is a jobs program for nerds though. It occasionally produces results that are practically useful for society but there's absolutely no way the vast majority of today's maths research falls into that category.
There are definitely exceptions, like crypto. I still think it would be pretty silly to stop maths research anyway. And anyway part of the job of maths researchers is to teach maths to undergrads and that's obviously enormously useful to society.
But on the scale of "how useful is this research to society" it's dead last after engineering, chemistry, biology, and physics. Well maybe computer science would be last actually!
Did people doubt that this was theoretically possible? Seems self-evident to me. The interesting thing will be seeing it in the real world rather than in a controlled environment where they deliberately made all devices on the network have a known vulnerability.
There’s a difference between speculation and measurement, especially since you’d have people making arguments like saying that open models aren’t powerful/fast enough to work. Demonstrating this is a useful warning to everyone (most of the industry) who’s been slacking on internal defenses because they don’t think a well-resourced attacker will target them.
It shows that the idea can work in a somewhat realistic scenario. That doesn’t mean we’re all doomed but it’s a good wake up call for anyone who’s been slacking on internal controls or patching.
Honestly with some of the denialists here a terminator could kick down their door with lazgun in hand and they'd still tell you that AI can't do that.
And for the people that think that alignment is stupid, not training your AI to think twice about writing self spreading worms is a recipe for disaster after someone gets a token stealing, resource grabbing worm going.
reply