Hacker Newsnew | past | comments | ask | show | jobs | submit | more StefanWestfal's commentslogin

Common in practice is 0.5%


There are ways to ensure the correct transfer of ownership without involving a third party. You can see these principles at work on some trading platforms already, be it for Magic cards or something else where parties cannot trust each other because they do not know each other.

Next, you would expect that the notary would educate participants and act as a source of trust, an actor in your best interest, but that is not the case. Notaries can change contracts until the last minute, and unless agreed upon, the common 14-day withdrawal period for contracts does not apply to things like buying property. Furthermore, if you are inexperienced, you can easily fall into traps.

As a concrete example, when buying a part of a shared property, it is commonly believed that the "Hausordnung" (house rules) is the owners' agreement for house rules. However, that is not the case, as there can be more, and in our case, it forbade us to keep dogs. Now, you could argue that we should have made ourselves more familiar with the law, and I would agree that is true. However, it begs the question, why do we need a notary?


> However, it begs the question, why do we need a notary?

The way I learnt it, until now, is the following:

the person you are contracting is there to perform a single specific task.

Applied to the specific context: "Notarvertrag", it means:

the notary is there to perform the notarisation (basically to read and write the contract), making legal whatever YOU are asking to do.

Any additional thing:

- you ask him/her

- you ask someone else beforehand (so yes, you need to pay an additional session for help)

And even then, you not always get what you wished for. And when s** happens, .... "that's life experience"....


> There are ways to ensure the correct transfer of ownership without involving a third party. You can see these principles at work on some trading platforms already, be it for Magic cards or something else where parties cannot trust each other because they do not know each other.

So what else is that "trading platform" then, if not a "third party"?

The way in which this problem is solved is by introducing a third party that is trusted by both, seller and buyer. There's nothing wrong with this principle. What's wrong specifically with regard to notarys as a third party in property sales in Germany is that the amount of work involved in being this third party does not really scale linearly with the value of the thing to be transferred, but the system by which the price of the notaries' work is determined assumes that a property transfer is twice as laborious (and thus must be twice as expensive) if the property is twice as expensive as some other property. Which is BS.


Indeed, my mistake and agree. Here, I wanted to refer to the fact that the transfer of ownership could likely be done even without involving a notary or a human in a properly digitalized system.


In that case you have the entity operating and maintaining the "digitalized system" which is the third party that everyone has to trust. And that entity won't do its work for free either. And it also will somehow "involve humans" which are working there.

Oh, and please don't suggest to "simply put it on a blockchain". I don't have the time to explain for the millionth' time why that doesn't work with physical properties. I consider that to be common knowledge among HN users after about 10 years of having those discussions regularly.

Also, property ownership can get ridiculously complex really fast. If just one person owns something, that's simple. But in reality, quite often multiple persons own something together (sometimes some of these persons aren't even humans, but legal entities). In that case there are a gazillion different ways in which such shared ownership can be implemented, with far-reaching implications with regard to what will happen if people disagree, split up, modify or sell the property further down the road. You cannot simply model this complexity with an SQL database because it involves legal contracts that specify the details in which a properties' ownership is shared exactly. And the notary is actually responsible in such a case to write these contracts, ensure that every participant knows about their role and rights within these contracts and isn't shortchanged.


Side question: why don't i hear horror stories about identity theft from those areas that have those evil bureaucratic notaries authenticating everything?


Actually there's been at least one known case of someone "stealing" an entire building worth about 6 million € in Berlin. Even bureaucracy and notaries didn't prevent it, so there's your potential 100% fraud prevention rate going down the drain...

Link to an article about this case (in German language, unfortunately): https://www.t-online.de/region/berlin/news/id_91147122/berli...


I've used React over the years, but now I mainly use Svelte. I like React, but for me, Svelte feels more lean and straightforward. Depending on how Threlte (a 3D library for Svelte) develops, I might switch completely. Additionally, React's Server Side Components are now introducing a paradigm shift, so it might be the right time to make the switch.


I heard good things about Bishop however I am a SE that would like do know more about what the ML team is doing and maybe work on some ML side projects. Would you recommend Bishop here or is it considerer to theoretical for such a case?


Bishop is going to be more theoretical than ISL. It is true that Bishop is taught as an introduction to ML in many universities, but if you want more hands on to start with, ISL is an excellent option. There is another text called "Elements of Statistical Learning" that pairs well with ISL for a more theoretical treatment. I haven't looked at ESL in a long time, the only concern I'd have is if they aren't covering some introductory deep learning topics. Most of ISL, ESL, and Bishop are more traditional machine learning, covering a wide variety of algorithms, so bear that in mind.


Can I easily integrate Rust crates into my Deno app like a smaller extension for number crunching or at one point even something like Polars?


You could compile them to WASM and call them from Deno


That is true for a lot of western countries but we are expect to produce and consume more concrete until 2050 then we did so far in history in developing countries.


I am always a bit disappointed when only few arguments are provided. Ken Griffin might have a good understanding of the implications of LLM or not but that is hard to tell here.

Especially law will be interesting to watch. Lawmakers have to encode their intentions into text. LLM are good at detecting patterns in texts, find inconsistencies and so on. On top of that I would argue that we learn from the past to predict the future. Laws do not change as frequently as tech does. So LLMs might turn out to be excellent at understanding the law, at least written law, and experienced from all the cases they saw during training. I think law is in for a change similar to software.


Lawyers are already sufficiently good at "detecting patterns in texts, find inconsistencies and so on" in written legal texts, that's not really the hard part in practicing law. Even legal research, despite what non-lawyers may think, isn't all that big of a problem for wide swaths of lawyers. In any given field, there's going to be a short list of relevant cases to know, and everyone will know pretty quickly when a new one comes out. Experienced lawyers don't generally spend a lot of time doing legal research. The hard part is in fitting the facts of your case to the fact pattern of the cases you're relying on for your legal argument, and then fitting it all together so that its easy to read, understand, and agree with.


It gives you a lot of freedom and doesn't force many rules like other non-dynamic languages do. This makes it great for trying out ideas and working with data and machine learning. However, when you're writing more complex programs, you need to be more careful. That's why I feel like I encounter more bugs during runtime compared to other languages. I mentioned Go because it makes you stick to a smaller number of ways to do things, which feels more "pythonic".


Hard to tell but that sounds a bit like a test problem. If you have high test coverage (which you must do in a language like python) most bugs should only result through complex interaction.


For me it helps with smaller mistakes like typos, naming collisions etc. But it can be more verbose.


For me it is convenience as tooling like fmt, testing, etc. are build in and they try to keep api close to browser api's when possible.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: