News for hackers. Stuff that matters.

lang_agnostic

I still fail to see what exactly is the issue that is being raised beside "watermarking bad"

Watermarking is a new tool, it's useful. Are you a website aggregator with human review? watermark the content to reduce the workload.

Are you automatically tagging novels in a creative writing forum? check for the watermark.

Are you presented with extraordinary evidence for which the provenance is extremely relevant? look for the watermark and that will tell you if the evidence is fabricated

Has someone written an amazing scienific result and is claiming ownership? watermark tells how much the attribution should go to the human or the machine.

There is nothing "wrong" or no "getting caught" in those scenarios, those are just extra tools we can use in a world where text can be arbitrarily generated. This is no different than a "made in china/designed in california" tag, or a CE marking on your product.

Re:Wise refuses to let us access our $60k AUD on Wednesday May 14, 2025 @03:44AM (#43981957)
How does removing excessive regulation help this scenario?

In what you describe the difference would be that HSBC doesn't get fined and neither HSBC or Revolut does any check. How does that help?

Re:TypeScript: Branded Types on Wednesday April 24, 2024 @05:02PM (#40149603)
Isn't this just phantom types in other programming languages?
Re:Log is the "Pro" in iPhone 15 Pro on Wednesday October 11, 2023 @12:44PM (#37846815)
This isn't any trickery, this is a file format. One that actually avoid the uncontrollable computational photography done by default and actually changes the nature of the picture without the input of the user. This is helping conserve what we think of pictures as a digital capture of light. Rather than what it's becoming, which is the product of hallucinated details by a neural network.
Re:Log is the "Pro" in iPhone 15 Pro on Wednesday October 11, 2023 @11:44AM (#37845960)
> We are now moving away from auto-focus and auto shutter speeds toward on-the-fly retouching, editing, of material by the camera

This is a great point but it's not what the article is about. This is about bringing existing features of digital cinema cameras to a portable phone.

Re:Rust's Poor Composability on Thursday April 06, 2023 @10:38AM (#35468881)
Is this person actually asking for Monads and Higher Kinded Types?

It would solve the problem they're raising but somehow I suspect that's now the solution they want to hear. And also the rust version would be quite hard to use due to the memory management model.

Re:Monero founder outed as Interpol informant on Wednesday March 22, 2023 @04:38AM (#35258364)
This asking GPT for inference needs to stop immediately before it becomes accepted and commonplace. This is almost the same as "I flipped a coin and the gods spoke to me"
Re:America’s roads and highways have a big, fat style guide on Wednesday January 11, 2023 @01:27PM (#34342335)
I'm quite surprised but how large and extensive this guide is.

As someone who learned to drive in Europe I've always been extremely confused by the signage and road layout of American roads. There is a pretty big difference in quality between state roads and federal roads. The former seem to have no coherent style, layout or identity while the latter seem pretty consistent. Given the above documents I can see there is a consistent style but the style does not seem to translate to a consistent user experience.

The three things that stand out to me are the amount of text on each sign, the lack of standardized rule about entries and exists, and the lack of road markings, specially at intersections.

The first one isn't necessarily a big problem but it's very weird to have all this text when you could have instead a very recognizable sign that you can understand from afar (the one way sign is a great example), instead of a white sign with black text that you can only read once you're close to it and only understand if you know English.

The second one makes highway layout extremely confusing and, at least for me, feel dangerous and stressful. Some Signs can tell you to take an exit with make 20m of notice and it's a 90° right turn and you also need to go from 120 kmph to 30 in that span. The reduced speed sign is only visible after you've turned so if you dont know the area you're almost always going too fast. Because it's a 90° turn with trees in the sides you can't anticipate what the traffic is like after the turn. If you know the area you probably have no problem handling this situation, but driving there for the first time feels like driving through a minefield. There are other instances of this with left exits, overtaking from both sides, turn right on red, stop sights everywhere, no priority system, and more.

The last one is incredibly frustrating when you come from Europe because over there, most intersections have redundant signage and markings. Intersections have street lights that tell you where to go, the road layout is advertised on a sign well in advance, and the paint on the road tells you how to turn and where to stop and even indicates speed limits or directions. Intersections in americas provide no such affordances. Intersections are basically a free for all between the incoming trafic, the people turning right on red and the pedestrians. I was expecting a lot more from a country which is built for cars.

It feels like roads are built for cars but not for drivers.

Re:The curse of strong typing on Thursday June 02, 2022 @09:39AM (#31594726)
You simultaneously make a great and stupid point. The stupid part is obvious: operations are allowed because writing programs is useful. Now for the great, nuanced and complicated point: How do we detect errors when manipulating floats while allowing us to write the useful programs?

This boils down to two things: 1. What do we think is correct at any given time for any given program? The compiler can't know so we have to tell it, which brings us to 2 2. How do we write down in our programming language what is supposed to be correct?

The problem with floats is that sometimes you care about precision, sometimes you don't sometimes you care about overflows, sometimes you don't. Sometimes you care about inverse operations, sometimes you don't. Commercial programming language which only expose a "float" types usually are unable to deal with the greater complexity of _ensuring_ that some property you care about isn't broken. That is why compilers let you operate on floats and shoot yourself in the foot when you divide and then multiply back.

On the other hand, one could imagine a future programming language (and some academic experiments already exist) where you can tell the computer "in this part of the code, it's important that I never overflow" or "in this function, I expect multiplication and division to be inverses of each other". In which case the compiler will display diagnostic information if you do something that break those properties.

It's not clear yet what is the most convenient user interface to write down and check those properties. But many believe it by using even more advanced type systems than Rust. Many other believe that we can add static analysis atop existing programming languages to obtain the same result.

TLDR: Rust allows it for now because 50-100years in the future we'll have to tools to tell when it's ok and when it's not ok to multiply floats together. Right now we're still smacking rocks together to make fire.

Re:Germany faced its horrible past. Can we do the same? (2021) on Tuesday February 08, 2022 @01:14PM (#30262137)
Tokens of recognition aren't currency that you can use to buy redemption, I find this comment particularly ironic when this other article exists, perfectly capturing a symptom of the state of denial that the US find themselves in wrt to their tumultuous history: https://news.ycombinator.com/item?id=30261610

Germany didn't get over their trauma by having "Jew day" and "please stop treating humans like cattle" bill while routinely allowing their members of society to deny education to their children

Re:Idris 2: Quantitative Type Theory in Practice on Monday January 24, 2022 @06:24AM (#30056204)
I need my answer was focused on runtime performance, thanks for pointing it out. However, They are related for two reasons:

- idris is written in idris so any improvement in the language results in faster compile-times, if more things are annotated with 0 in the compiler, thing will compile faster.

- if some variable is only important at compile-time, the compiler doesn't have to look at it with very much scrutiny. That saves you a lot of time when typechecking

Re:Idris 2: Quantitative Type Theory in Practice on Monday January 24, 2022 @05:30AM (#30055761)
Yes. Multiplicity 0 removes the value from the runtime avoiding allocations and garbage collection. That particularly handy for type-level indices and type-level programs in general.

Technically speaking multiplicity 1 (linear variable) can be subject to arbitrary inclining though it's not implemented in the compiler.

I'm working on other multiplicities that could allow you to describe which values are "compile-time" available, and therefore subject to optimisations

Re:Idris 2: Quantitative Type Theory in Practice on Monday January 24, 2022 @04:43AM (#30055336)
I reckon we can get the raw performance quite low, but it might be a challenging environment to program in, the ergonomics of programming linear types aren't figured out and it would involve a lot of memory management. While safe, reasoning about memory can be quite hard, just like anyone learning how to handle the borrow checked in rust can tell you.

It's currently one of my project to use QTT to statically enforce performance invariants and optimisations, currently I am looking at partial evaluation of programs and explicit annotations to control which parts need to be partially evaluated and which parts need to remain Unevaluated.

Regarding the benchmarks there are two things to address to make them go faster:

- the idris parser is actually pretty slow so we should get working on that

- the examples use explicit runtime bindings for type parameters which force the types to be allocated and available at runtime, which destroys the performance of some programs (stlc notably)

It's not expected to write idris code in that way since linearity annotations also allow you to _remove_ values from the runtime and make dependent programs go faster, if you were to be concerned about runtime performance you would use _runtime erased_ type variables instead of _runtime relevant_ variables. Some of this is due to the foreign nature of QTT, and we should do a better job at teaching how to use it for performance.

On the other hand someone could argue "if idris is that smart can't it warn/perform those optimisations automatically?" And maybe that's the way to go, but we need more eyes and brain looking at the problem and coming up with prototype solutions to make progress. idris is still a small project so we don't have enough people working on it to implement those smart features

Re:Idris 2: Quantitative Type Theory in Practice on Monday January 24, 2022 @03:42AM (#30054940)
Hi there,

I'm a phd student working on Idris and I used to work with Edwin on this, if you want more info or want to see more practical applications of idris2, Dependent types, or QTT, here are a couple links:

- idris2 is written in idris2 so that's a good example of a big program using dependent types https://github.com/idris-lang/Idris2

- we have some very interesting libraries in the works: https://github.com/idris-lang/Idris2/wiki/Libraries

- my own projects in idris include a purely declarative server library where you give the API and the server is completely implemented and instantiated from your description https://gitlab.com/avidela/recombine

Re:Reviving a 16-year-old Mac App on Tuesday May 05, 2020 @09:42PM (#23087149)
Education?
Re:Continuous urbanization in Japan on Wednesday June 27, 2018 @02:09AM (#17406086)
No mention to earthquake or typhoons?

I always thought the urbanization of Japan was mostly limited by natural conditions.

Indeed, there is no point in making tall buildings if they are more likely to fall and cost more in repairs and anti-seismic technology

Re:Intel CEO resigns after relationship with employee on Thursday June 21, 2018 @12:51PM (#17366856)
I assumed it was a man because of another gender bias: I don't know many women working at Intel so statistically its likely to be a man