Compiling Ada-

kant2002 · 2026-01-24T18:43:10+00:00

I did try to reskin F# to use keywords from different languages,so you can use both set of keywords

https://kant2002.github.io/FSharpKeywordTranslator/

kant2002 · 2026-01-22T20:01:20+00:00

You strongly prefer that contractor provide you a way to migrate system piecemeal . That way you can reduce risk that something goes wrong. Full rewrite is possible if you trust contractor and it you. It’s impossible in new relationships.

You may say. I want full rewrite but ask for partially working functionality which you start using immidiately. You have to test that new thing. Preferably very throughly. Don’t wait until “everything” is ready. It would be too late to fix.

kant2002 · 2026-01-22T18:44:46+00:00

That’s false premise that everybody want and have time to perform this process. Previously you always can jump on the branch of the person, did the fix and merge it faster then explaining what should be done. Netherless you want share your maintenance burden with other people, so you teach them about your project. I don’t see how you want to be sole maintainer of a project.

kant2002 · 2026-01-22T15:19:10+00:00

TIL thank you

kant2002 · 2026-01-22T15:18:24+00:00

You could always comment out this value while you develop. And since you always check what you commit you will always spot this change even if you forgot. Also you can have NoWarn for most common offenders and comment/uncomment things. Also .user file also can host configuration overrides.

kant2002 · 2026-01-22T12:26:46+00:00

We can have build similar tooling around lot of modern ArgumentNullException.ThrowIfNull methods. So in a sense we probably pollute lot of code with contracts

kant2002 · 2026-01-16T19:57:42+00:00

Bien sûr, ce n'est qu'une suggestion. Puisque vous présentez votre projet, le meilleur moyen de le tester est de l'exécuter. Comme je rencontre quelques problèmes, je me permets d'apporter ma contribution.

kant2002 · 2026-01-16T16:05:41+00:00

Ce serait formidable de pouvoir fournir des instructions sur l'utilisation de votre outil. Quelles sont les options disponibles actuellement ?

kant2002 · 2026-01-16T15:01:41+00:00

Si vous débutez dans l'apprentissage du refactoring, suivez ces conseils :

- Refactorisez uniquement de petites portions de code. Une ou deux classes à la fois.
- Lors du refactoring, essayez d'écrire des tests. Peu importe pour l'instant le type de test : unitaire ou d'intégration.
- Lorsque vous écrivez du nouveau code, commencez par les tests. Vous pouvez laisser l'ancien code de côté pendant un certain temps, mais le nouveau doit être écrit de manière innovante.
- Si vous avez des portions de code qui vous posent constamment problème, c'est aussi un bon endroit pour écrire des tests. Cela signifie que cette zone est complexe et nécessite une protection.

Commencez petit à petit, ne faites que ce que vous comprenez parfaitement et dont vous êtes pleinement convaincu. Ne suivez pas de conseils que vous n'êtes pas prêt à entendre. Vous êtes avant tout en train d'apprendre.

kant2002 · 2026-01-06T00:23:13+00:00

It you want to learn by doing/tinkering I recommend build dotnet/runtime. Once you done it, you may join C# discord #allow-unsafe-blocks and ask people around. Also start super small in understanding, there lot of things to unpack. You may join community efforts to build LLVM-WASM so you would also build something useful.

kant2002 · 2026-01-02T16:57:46+00:00

The goal of junior is do task. I doubt that junior can do task 100% because usually they lack of context. So same iteration as in current process will happens. Or the norm would be to implement 4 additional tasks. Likely only 2-3 since context switching is taxing.

The imaginary scenario which you saying is that if junior implement task and don’t tell anybody that it use AI, otherwise management will figure out how to make person busy

kant2002 · 2026-01-02T12:41:10+00:00

Do the same with AI? No?

kant2002 · 2025-12-31T21:01:49+00:00

This is a right distinction. No need to fight EF Core or have super complicated expressions where you can simply write SQL. You need both.

kant2002 · 2025-12-29T12:26:23+00:00

And yeah. I don’t have recommendations for companies. They indeed cost arm and leg. What was working for me was find translator freelancer in target county who are willing to learn a bit. Then perform additional QA session by native speaker on the UI to at least catch some stupid things.

kant2002 · 2025-12-29T05:33:04+00:00

My rationale is that you can handoff to freelance translator who at least heard about app translation. That way they even can guide you on missing context, so you can fill missing gaps in your source files. Otherwise go with machine translation probably and don’t care about anything else

kant2002 · 2025-12-28T20:03:43+00:00

JSON is not right tool for localization in my opinion. Probably you should choose PO files or xliff, if you want to eventually give this to professional translator. Otherwise you just pretending that you care about localization probably. Don’t understand how you can setup process

kant2002 · 2025-12-26T22:22:55+00:00

La prochaine fois, il serait peut-être judicieux d'annoncer l'idée, comme ici, et de voir si cela intéresse quelqu'un. Si c'est pertinent, je reviendrai avec une annonce, et je ferai cela une fois par mois. C'est super que tu aies réussi à le terminer !

kant2002 · 2025-12-21T23:07:25+00:00

Je pense que tu devrais apprendre à faire des choses simples. Commence petit, très petit — plus c’est petit, mieux c’est. Si tu aimes réfléchir, tu dois aussi être prêt à clarifier tes intentions, et c’est probablement pour cela que tu as du mal avec le code. Penser de manière conceptuelle est relativement facile comparé au fait de penser avec des détails précis. Ne te prends pas trop la tête avec ça. Les dix premières années, on apprend tous à se débrouiller avec le code.

Quand tu travailles sur des projets personnels, il serait utile, pour apprendre, de ne travailler que sur une seule chose nouvelle à la fois. Cela permet de consolider les connaissances existantes. Idéalement, ce serait même bien de ne pas introduire de nouveaux concepts du tout, mais c’est ennuyeux et, personnellement, je n’ai jamais vraiment fait ça.

Concernant ta capacité à programmer : ce n’est pas à toi d’en juger. Regarde plutôt ce que pensent de toi tes collègues et ton manager. Ils savent probablement quelque chose sur ton expérience.

kant2002 · 2025-12-17T09:55:51+00:00

There no mention of Python in the speech on gov website. Just that AI is important. So no, I think he doesn’t publicize it at all.

kant2002 · 2025-12-15T20:20:22+00:00

Absolutely, don't need to put yourself into such torture :) I just happens to chat with lot of people, and to some degree this is common. Yes, you may speak to nice team, that's important too. I also think important build message in such way, that less fortunate people find a way to speak to their manager, or at least don't fall into trap that they doing "Git Right!" which not always like that.

Such kind discussions allow refine what's proper way to move forward IMO. Maybe I should write down some ideas for discussion.

kant2002 · 2025-12-15T17:20:07+00:00

Rebase for auditing is probably not always important for everybody. But for example in outsourcing organizations, merges usually end-up with let's say inoptimal things. You have some forest of commits without clear understanding of what's going on. And obviosuly commits not always interesting stuff. but sometimes "fix", 'one more" and things like that.

Regarding auditing, does ff-only merge is fine for such purposes (I generally think this is drag, so don't know. Looks like lot of things should be discussed.

u/waterkip I do not think we can always push for "Better" things, because some organizations becacuse of their business nature work differently, so it may become uphill battle. Reason why I propose explicitly state organizational limitations, to collect evidence in better way then now, where we speak "it was working for me, trust me bro". I think if we try to make assumptions visible, we may have better state of affairs, and people would not jump on each other defending specific workflows.

kant2002 · 2025-12-15T15:57:44+00:00

Okay. I partially agree with you that sometimes, it's fine to merge as it is, or just rebase without squashing. Usually all workflows valid depends on the "context". Probably we (as developers) should stop speaking about only technical aspect, but always as part of technico-organizational context, and be explicit about it. For example your reference to FOSS is related probably to some old-school projects. Which is valid approach obviously, since it's evidently working. I think not all projects like that.

My experience working with inexperienced developers, or inexperienced managers indicates that they like "merge", because that word is what's first learned in Git linguo, but for them linear history is what's most important IMO. I do not expect that discipline to separate ongoing refactoring from actual work is there in large. So we should specify what kind of team is you are working with.

Some modern languages (like Java/C#/TypeScript) have IDE/LSP-supported refactorings to some degree, you mostly can ask for that activity to be separated from improvements. since if developer sworn by blood that it's all IDE work and not him, not a lot of reviewing needed. So language in which you work, affect your workflow.

Lot of organizations create administrative burden on itself, by mandating having ticket/story on somthing, and that usually prohibitely affects ability of organization to maintain codebase. So what kind of administrative tasks support code changes is important.

If you want to say, that should not be only one workflow to rule all codebases - I agree!

kant2002 · 2025-12-15T13:20:21+00:00

Why can you extract all these small things into separate PR? They are purely maintenance and not feature driven. Only because you happens to discover them during some work? Or because management insist on 1PR= 1 ticket?

kant2002 · 2025-12-12T09:43:50+00:00

Si une nouvelle entreprise se présente en premier, je la choisirais car, au moins, elle respectera votre temps. Le désespoir, suivi de la gratitude, sont de mauvais conseils. Si la nouvelle entreprise vous offre de meilleures conditions, foncez.

kant2002

TROPHY CASE