HN user

millstone

6,895 karma
Posts0
Comments1,959
View on HN
No posts found.

I think it is simply that make is too crufty to extend. It has perma-broken behavior around space handling, which nobody dares touch [1]. But you can't replace it because it is entrenched, so Makefiles must be wrapped, by configure or CMake or whatever. And these in turn have their own cruft, so must be wrapped, by autoconf and...well someone please wrap CMake!

The C and C++ ecosystem is crying out for a new build system, but there is no mechanism to converge on one. It's bad.

1: http://savannah.gnu.org/bugs/?712

Amazon ads are contrary to the company's mission statement of being the "most customer centric company." They could improve the customer experience at one stroke by eliminating pay-for-placement.

What a sad vision. Per the article, the most important thing about software is that it is safe. The role of an OS is to protect against abuse. The web is inherently safe; therefore we should use web apps instead of native apps. This is profound technological pessimism.

A different vision: computers empower people. An OS provides APIs and UI conventions, and apps can use them to build upon each other, so that users can bring their knowledge from one app to another. Users invest in learning advanced techniques because it's worth it, because all our software participates (think keyboard shortcuts or Unix pipes).

The web has none of this. Websites are not cultivating a new UI vocabulary. Most websites don't support even basic interactions beyond click and tap. They may even actively parasitize the old: Google Docs supports cmd-Z but not Edit->Undo; we are being taught to distrust our UI, the OS itself is being eroded.

users who cannot perceive or experience the web delivering great experiences

Then build those great experiences and Apple will change its tune. Seriously.

The web was a lifeboat away from native apps for Windows XP users. That lifeboat won't come for iPhone owners because Apple won't allow it.

iPhone owners are happy and Apple knows it. On the iPhone, web apps are not a lifeboat; instead the web is displacing high-quality native apps with alien-feeling lowest-common-denominator stuff. No thanks.

It does not. -XOverloadedStrings unlocks `fromString :: String -> a.` That is not a polymorphic string interface; it's just syntax sugar for making something else from a string literal.

Right. But OOP makes it central, and builds around it, while FP de-emphasizes it in preference to ADTs.

Strings are a good illustration. Instead of an abstract polymorphic String type, Haskell provided a concrete String type as an ADT. This proved too inflexible, which is why we have Text, lazy Text, ShortText, etc. Compare to NSString which also has multiple representations but hides them behind a single polymorphic interface.

I agree with that. If you create accessors as a matter of course, then you are mostly adding dead weight. But accessors can add a useful layer of abstraction at the interface layer, as you say.

OOP (as Alan Kay conceived it) was explicitly inspired by biology. Objects are cells and communicate through exchanging messages. State is local and hidden, and data itself disappears, which means that the program as written may be ignorant of how operations are performed.

"Safety" and "performance" are not always the most important considerations. For example, Apple uses OOP so that its frameworks can evolve without breaking client apps. NSDictionary is a dynamic object because it permits the implementation to be changed or replaced, and this comes at a cost of performance.

The behavior is disabled in private browsing. That suggests some acknowledgement of a privacy risk.

What is creepy here is that a random website which I closed ten minutes ago get to know when I unplug my ethernet cable. I am happy to tell a website when I close it - that is its purview. But when I close a website I want it to be closed. Now I know it lingers.

The End of AMP? 5 years ago

Google could defuse some of the AMP pushback by offering users a setting to disable it. Why haven't they done so?

These should be compilable to a single asm routine, as long as there is an homogeneous way to copy them

That's a massive asterisk. In practice, copying values to the heap is complicated. Integer values may be memcpyed. Pointer values may require read and/or write barriers, or perhaps reference counting. Compound types may require some combination. Maybe you have copy-constructors and you need arbitrary callouts! These implementation details can't be hand-waved away.

The difference between this case and the polymorphic case is that here the underlying structure (eg "compare" or "insert") isn't done in a homogeneous way (single routine) for every type: the polymorphism is ad-hoc and not parametric. The vtable solution is a form of boxing and that impacts runtime

Kindly, I think you have some confused terminology. Parametric vs ad-hoc polymorphism is a difference in the type system, and occurs long before the optimizer kicks in. Parametric polymorphism is a single function implementation parametrized by types. Ad-hoc polymorphism is multiple implementations, and the compiler chooses one based on types (e.g. C++ overloading or template specialization).

If the optimizer chooses to emit a specialization, that does NOT make it ad-hoc polymorphism. That's just a detail of the optimizer. And it is a distinct optimization from inlining, for good reasons, like not wanting to be tied to the inlining cost model.

for efficient compilation of languages with generics you need to have an efficient compilation of parametrically polymorphic functions (by type erasure)

C++ and Rust both have efficient generics without using type erasure. Boxed generics are not necessary at all, as long as you accept static linking.

Swift has tried to address this by making specialization an optimization. When it compiles a generic function, it emits a single boxed implementation, like Java. But the optimizer may also choose to specialize it for concrete types, like C++ or Rust does.

It sounds nice, but there's a huge performance difference between boxed and specialized. When you make a function generic, the compiler boxes values, conservatively emit retain/release, others.

The difference is so large, it justifies giving the programmer levers to control specialization. Swift team has added "@_specialize" as a hint. I think they should go further.

What I don't know is how specialized generics can participate in library evolution. If a dynamic library provides a sort routine, and you specialize it, what happens when the library changes? This is where a JIT or the .NET model (compile at install time) can pay off. Apple has laid some groundwork for this (bitcode, Rosetta 2) so they can certainly get there if they choose to.

Anyways I think the real dilemma is whether generics are meant to be a performance optimization (C++, Rust) or just for typechecking (Java, C#). The cost of saying yes to performance is library evolution.

You do have to use PhantomData, otherwise it won't compile:

https://play.rust-lang.org/?gist=84883cb7cdd09acdcd919888cef...

It's especially bad if your type is an enum, since there's no obvious place to put the PhantomData:

https://github.com/rust-lang/rust/issues/32739

Trial-and-error debugging which version causes a bug is busywork, preventing it right when someone introduces the potential problem is at best annoying

It's a silly limitation. For example, u64 and u128 are not From<usize> because...well I have no idea. But you can't make them From, because Rust wants to reserve the right to make them From in the future. And you can't write a function that assumes they are NOT From, for the same reason.

So it's pointlessly hard to write generics over integers. I encounter lots of weird holes like this.

https://play.rust-lang.org/?gist=600a1ca784ee7df02351e58df43...

Rust has lots of nonsense with zero practical benefit. Examples: PhantomData, higher-ranked trait bounds, "upstream crates may add a new impl". I have satisfied the compiler but no bugs were prevented. It's just busywork.

I agree. In Rust I write correct code slowly. "Productive" I am not.

But the great strengths of Rust, like memory and thread safety, are blunted in WASM, which is already memory-safe and thread-crippled. So Rust's success in WASM must be due to other factors.

Sorry but that's baloney. Web developers are not choosing Rust/WASM because of security concerns with C++/WASM. The whole point of WASM is to enable untrusted code.

Instead I believe they are choosing Rust/WASM because of the Rust ecosystem: familiar package management, tutorials, other resources.

I don't get it - what library? I may have an `async` function and this is part of the Rust language, not tied to any library. Can I make it into a blocking function without 100% CPU?

How do you find Rust to be so much more productive than C++?

I find C++ more productive. In C++ I mainly fight with template error messages. In Rust, I fight with typechecked generics, inserting & and '_ here or there, adding and deleting imports, refactoring to add Some and Ok - tons of nonsense housekeeping. These features have value but are quite a slog when writing code.

I would not think to consider C# outside of Windows, but maybe I am wrong and should update my priors.

Are there any C# programs that are regularly used ex-Windows? Something analogous to Docker (written in Go) or ripgrep (written in Rust)?