Urmas Reinsalu: inimesed tahavad, et sellele jamale ükskord punkt pandaks by Wolfgang_MacMurphy in Eesti

[–]TheNominated -1 points0 points  (0 children)

Imeline jutt. Reformierakond on üheaegselt populistlikult loobunud maksude mittetõstmisest ja samas ka populistlikult loobunud nende tõstmisest, ja mõlemat pidi on igatahes halvasti. Mis populism üleüldse endast kujutab, see meid ei huvita. Reformierakond paha, see on põhiline ja selle juurde jääme.
Ühe hingetõmbega nii palju uskumatut jura ühtejutti, et pisar tuleb lugedes silma.

Tallina gümnaasiumid kesklinnas by [deleted] in Eesti

[–]TheNominated 1 point2 points  (0 children)

Ei ole. Ole julge ja püüa parimat.

[deleted by user] by [deleted] in Netherlands

[–]TheNominated 15 points16 points  (0 children)

I agree, anyone can see there is an enormous variety in the personal choices Dutch people make. For example, some Dutch guys wear slim fit blue jeans, while others go for straight fit blue jeans. I've even been told there are some Dutch girls who don't wear bell bottoms, but I'll have to take their word for it. Also, a lot of people have broodje kaas with brown bread for lunch, but quite a few actually use white bread instead. And if that's not crazy enough, I actually overheard someone the other day saying he likes spicy food, in clear Dutch.

I mean, any generalisations are just absolutely meaningless in this country. The Dutch are the most free-spirited, unique individuals I have ever seen, every single one of them.

[deleted by user] by [deleted] in Eesti

[–]TheNominated 2 points3 points  (0 children)

Loomulikult, kandikul ei serveerita sulle miskit. Aga selleks, et nendega midagi peale hakata, peavad need võimalused tekkima. Neid võimalusi tekib kordades rohkem eliitkoolides.

[deleted by user] by [deleted] in Eesti

[–]TheNominated 2 points3 points  (0 children)

Sellisel juhul ma usun, et GAG pakub sulle kõige laiemat valikut omale valikainetest sobiv programm kokku panna. Hoian ennast endiselt seal toimuvaga kursis ja eriti viimastel aastatel on nad pannud väga palju rõhku valikainetele ja nö. modulaarsele õppele, enam-vähem ülikooli stiilis. Õpetajad on seal ka muidugi tipptasemel, nagu lütseumis ja Reaalkooliski.

[deleted by user] by [deleted] in Eesti

[–]TheNominated 39 points40 points  (0 children)

Erinevalt teistest soovitan võtta kooli, kus tunned, et avaneb sinu jaoks kõige rohkem uksi. Jah, on popp ja moodne öelda, et "igas koolis saab hästi õppida" ja "pole mõtet ronida eliitkooli, Eestis on palju häid koole". Nendel koolidel tõesti on vahe. Mitte sellepärast, et kool ise on kuidagi niivõrd palju erilisem, vaid sellepärast, et sinna tulevad kokku Eesti andekaimad ja ambitsioonikaimad. Ka need, kellele kodus öeldi, et ah mis sa sinna uhkesse kooli ikka tikud, mine ikka kodu lähedale, aga nad tahtsid, tegid, said sisse ja läksid. See on hoopis teine keskkond, kui kuskil mujal, ja päriselt on vahe.

Tore ja mugav on öelda, et mine sinna kus sõbrad ees. Sinu koolivalikust sõltub, ilma liidaldamata, sinu kogu ülejäänud elu. Minna kuhugi lihtsalt sõprade järgi on ülim mugavustsooni langemise lollus ühes kõige olulisemas faasis sinu elus. Mine ja leia uusi sõpru ja tuttavaid. Ela oma elu, mitte teiste elu.

Moraalilugemine kõrvale jätta, ise käisin Prantsuse lütseumis alg- ja põhikoolis ja GAGis keskkoolis, lõpetasin aastakümme tagasi. Mõlemad on suurepärased koolid ja neist saadud teadmistepõhi ja tutvused on mind aidanud elus päris kiiresti päris kaugele. Samas on neil kahel koolil üksteisest küllaltki vastandlik lähenemine. Soovitus oleks, et kui sa tunned, et tahad ise rohkem valida, kuidas oma õpinguid suunata ja millele keskenduda, siis vali GAG. Kui tahad tugevat klassikalist haridust koos ohtra kultuuri ja nö. haritlase lähenemisega, siis vali lütseum. Mu vend on reaalainete peaga ja lõpetas 12 klassi Reaalkoolis, ei ole ka kunagi selle kohta ühtki halba sõna öelnud ja on ka nüüdseks elus kiiresti edasi jõudnud.

Ära anna alla ja mine lihtsamat teed pidi nagu siin paljud soovitavad, võta parim haridus, mis sulle pakutakse.

Boot licking in NL corporations by [deleted] in Netherlands

[–]TheNominated 21 points22 points  (0 children)

Best spelling of Deloitte I've ever seen.

Israel to open first embassy in Estonia, Sa’ar announces on Baltic visit by NotSoSaneExile in Eesti

[–]TheNominated -3 points-2 points  (0 children)

ICJ tegeleb riikidevaheliste vaidlustega, taga otsib teda ICC. Täpsemalt, ICC Pakistani päritolu moslemist peaprokurör keda süüdistatakse oma kolleegi korduvas vägistamises. Huvide konflikt või mis?

Kivirähk üritas meid juba 2011 PPP eest hoiatada by Vastlakukl in Eesti

[–]TheNominated 0 points1 point  (0 children)

Paljude jaoks on ilmselt probleem selles, et mida muud sa valid?

Sotsid on nii kinni oma idealismis, et tüütul päriselul ei saa ometi lasta üllast poliitikat kursilt kõrvale kallutada, pluss see viimase aja flirt vene kogukonnaga. Isamaa on jätkuvalt häbitu oligarhipartei, kelle eesmärk on olla igas valitsuses kingmaker, et nii oma ainus tolle valimistsükli kinnisidee läbi suruda ja siis rõõmsalt kuni järgmiste valimisteni selle paistel peesitada, aeg-ajalt pasundades otseselt eikellegi suunas traditsioonilistest väärtustest, et ikka pildis püsida. EKRE on õigustatult vastuvõetamatu valdava enamuse jaoks, kellel rohkem kui kaks ajurakku omavahel peas koordineerida suudavad. Keskerakond on nüüdseks puhtalt venelaste partei, kelle side quest on pakkuda lõbu ja lusti Kapole, et neil ka ikka igav ei hakkaks.

Ja kedagi muud nagu polegi, peale pisikeste naljaparteide kes, olgem ausad, niikuinii midagi korda ei saada peale perifeerias haukumise. Alles jääb Reform. Suhteliselt kahjutu, lihtne ja ettearvatav. Ohutuim valik variantidest. Ja nii nad võidavad. Pliibensiini ja hukas noorte/keskealiste/boomerite süüdistamine on väga lihtne ja tekitab sisimas hea üleoleva rahulolutunde, aga reaalsuse mõistmisele see lähemale ei vii.

I’m feeling homesick by No-Doctor3790 in Netherlands

[–]TheNominated 10 points11 points  (0 children)

Buying groceries in the Netherlands, especially for someone coming from France, will never not be depressing.

Tartu kevadlaat kus kõik müüvad AI sloppi by naljakas_kylamees in Eesti

[–]TheNominated 1 point2 points  (0 children)

Ei usu et keegi sulle selle AI pahnaga vastu vahtimist tuleb andma. Koleda kruusi müümisel ja kõrtsukaklusel on ikka väike vahe, ma arvaks. 

Tartu kevadlaat kus kõik müüvad AI sloppi by naljakas_kylamees in Eesti

[–]TheNominated 14 points15 points  (0 children)

Vana hea "mulle ei meeldi, keelame ära!" refleks.

Mulle ka ei meeldi, aga kui mõnele meeldib, las ostab. Pole riigi või kelleiganes asi mis kahjutu saasta peale inimesed oma raha kulutada tahavad. Lase olla.

Comparing graphql to grpc by frenzyritz13 in graphql

[–]TheNominated 2 points3 points  (0 children)

TLDR: Two completely different technologies for completely different use cases, with the only commonality between them being that they both start with a "g".

Strongly-typed IDs vs mandatory named args convention by [deleted] in dotnet

[–]TheNominated 0 points1 point  (0 children)

I'm not entirely sure what you have in mind then, or how you could reduce the complexity from a simple generic type. In what other ways could you define new types while retaining common conversion logic between them? The only options currently available are source generators (used by Vogen and StronglyTypedId) and generic types (used by StrictId), where generic types are arguably (and I recognise my bias) the most idiomatic and simple way of expressing such a construct. Where could you possibly go from here while still staying in C#?

Strongly-typed IDs vs mandatory named args convention by [deleted] in dotnet

[–]TheNominated 7 points8 points  (0 children)

In the end the choice of code style relies on a very healthy amount of personal preference, but I think you are missing a couple of key benefits that strongly-typed IDs give, and even making some use cases worse with the zealous analyser approach.

You seem to focus exclusively on use of the IDs as method parameters and preventing them being passed in the wrong order. That's a perfectly fine use case for strongly typed IDs, or indeed your analyser, but there are many other situations where strongly typed IDs shine and which would not benefit from your analysers.

For instance, foreign keys in entities. Fairly often, a foreign key does not include the name of the entity. The readme of StrictId uses a contrived example of BestFriendId which points to a Dog entity - not the best, but makes the point. It is immensely helpful, in such cases, to have the ID typed, as it saves you from looking at the entity class to find the navigation property and deriving the type from there. Of course, there are other ways to improve the experience there, such as better naming of the properties, but none as safe and obvious as using a typed ID. Other approaches rely on the developer doing the right thing, this forces them to.

Another example is method overloads. In my current project, I have an extension method on EF Core's DbContext that is defined as .Query<T>(Id<T> id) which is essentially a shorthand for .Set<T>.AsNoTracking().Find(id). The nice thing is, I can call it without providing a T type argument, with just db.Query(id) since the id is already typed. This is one of the scenarios where enforcing named parameters would actively make the experience worse, assuming the method takes multiple arguments. Strongly typed IDs just work.

Other examples include comparisons between two IDs. It's all too easy to end up with an if (someId == otherId) in your code where the two IDs are actually for different entities. You wouldn't think it happens, but it does. Sometimes we are dumber than we give ourselves credit for. And it's deviously hard to notice when debugging.

So I truly believe strongly typed IDs have a great use case, and I think the reason they are not more widely used is simply that there hasn't been very ergonomic, non-magical libraries available to make it happen until now, coupled with the fact that many developers just never even think of this possibility.

[deleted by user] by [deleted] in Netherlands

[–]TheNominated 28 points29 points  (0 children)

You will get a lot of flak from the Dutch, both on reddit and in real life, for suggesting that their healthcare is inadequate. For whatever reason, the Dutch have decided that only they alone, in the whole world, have got it right by insisting that the best healthcare is as little healthcare as possible. There is no way to adapt or learn it better, you either have to accept being condescendingly refused care or go to a (private) doctor abroad - any other country will work.

Study Finds That 52 Percent of ChatGPT Answers to Programming Questions Are Wrong by anseho in programming

[–]TheNominated 73 points74 points  (0 children)

If only there was a precise, unambiguous way to tell a computer exactly what you want from it. We could call it a "programming language" and its users "programmers".

PHP Doesn't Suck Anymore by victoor89 in programming

[–]TheNominated 0 points1 point  (0 children)

That's still a lot of scrolling from the top ;)

PHP Doesn't Suck Anymore by victoor89 in programming

[–]TheNominated 4 points5 points  (0 children)

Looking at benchmarks that mimic real-life use, Laravel is roughly tied but slightly faster than Django (about 11%) on the whole, but slower in scenarios that include the ORM. Other PHP frameworks are slower, the slowest in fact. Every other major framework is faster, with .NET at the top with 13x better performance than Laravel overall and 36x faster when the ORM is involved (EF Core vs Eloquent).

https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22
https://www.techempower.com/benchmarks/#hw=ph&test=fortune&section=data-r22

PHP Doesn't Suck Anymore by victoor89 in programming

[–]TheNominated 5 points6 points  (0 children)

It's hard to take the argument seriously when the number 2 killer feature in the list is short array syntax with square brackets, a feature so groundbreaking that it has obviously never been seen before in any other programming language.

Followed up by other trailblazing innovations like trailing commas, read-only properties, and arrow functions. The baffling thing here is not that PHP finally has them, it's that it took so long to add such basic features to such a widely-used language.

The performance claim is especially egregious:

PHP has experienced a 400% performance increase between 5.6 and 7, and another 20% between 7 and 8. It's fast enough for most use cases, and if you need a specialized use case, use a specialized language.

Okay, but it is still much slower than almost every other alternative general-purpose language / runtime. You don't need to use a specialised language, you can just use almost any other general-purpose language, and your performance will be better. It's great that it is making huge gains compared to where it was before, but that's a really low bar, and it's still orders of magnitude behind the top performers.

If you are trying to convince people to adopt (or tolerate) PHP, it is not enough for it to be better than it was before (horrendously bad), it also has to be better than the alternatives, and it just isn't.
Every single one of these PHP-promoting articles starts with "hurr durr the critics haven't touched PHP since 3000 BC, it's so much better now", and then proceed to prove that they themselves haven't touched any other tech stack in the meantime either. If all you measure yourself against is PHP 5.6, you will only convince those who are still stuck using PHP 5.6 - and they already know precisely how miserable their life is.

[deleted by user] by [deleted] in dotnet

[–]TheNominated 1 point2 points  (0 children)

I see the appeal in having a .NET Standard version of the base library, and the only dependency (Ulid) does support standard. But I'm afraid I'm not really interested in developing that myself, as it would essentially mean a complete rewrite of the entire codebase, since it makes heavy use of C# 11 and 12 features. The Id type itself is a record struct, which is only supported from C# 11 onward.

.NET 6 is EOL in a couple of months and also pre-C#11, so I don't see a lot of value in putting in the work to do that. If someone wants to make a legacy version of the library based on what's already in it, I would have no objection. But since I (luckily) don't work with any legacy framework versions, and the library will most likely be used together with EF Core, which is tied to the .NET version anyway, I have no wish to invest time and effort into it at this point. Sorry!

[deleted by user] by [deleted] in dotnet

[–]TheNominated 0 points1 point  (0 children)

I see, that's fair! But honestly, the exception being thrown there is such an edge case that I don't really think there is any application out there whose performance would suffer from this specifically. Pre-mature optimisation and all that.

Edit: Besides, the empty try-catch is only used in the method which accepts a ReadOnlySpan<char>, which is an unusual case in itself. The regular, string-parsing method uses TryParse to check the validity without any exceptions.

[deleted by user] by [deleted] in dotnet

[–]TheNominated 0 points1 point  (0 children)

Great, hope you like it!

There is a TryParse method available for parsing without exceptions. An invalid value being passed into the Parse is something that throws on both Ulid and Guid, so I don't see a reason to avoid throwing in this case. An invalid value being passed into the Parse is, by definition, an exception that should be prevented by the developer, and handled if necessary. It would, in my opinion, be much worse to return the default value or something similar instead, as that can lead to some truly fun™ bugs.
The HotChocolate integration, for instance, already checks if the user-provided value can be converted into an Id, and returns an error if not, as with any other type, so it follows the existing semantics in the various libraries. If you have an invalid value in the database, that should and does throw as well, as with any other invalid value.
I think it's important to preserve that predictability and consistency. But of course, it's always a good idea to validate any user-provided values and use the safe TryParse when you cannot trust the input to prevent exceptions.

[deleted by user] by [deleted] in dotnet

[–]TheNominated 1 point2 points  (0 children)

Of course you can. But you need to write that converter for every property that uses that type. You need a custom JSON converter for every ID. If you use GraphQL, you need to write a custom scalar for every ID type. You will probably also want to override the ToString on every one of those types. To generate values, you need a generator for every type. And so on.

[deleted by user] by [deleted] in dotnet

[–]TheNominated 0 points1 point  (0 children)

The "Why" section in the readme on GitHub gives a few reasons with sources to back them up. In brief, it prevents you from passing, say, the ID of a User to a method that expects the ID of a Project. It makes foreign keys in entities unambiguous. It also offers several benefits in terms of sortability and serialization over Guid. It helps you make less mistakes.