setzer22

EDIT: Just to be very sincere and transparent. The content of this post has been removed to avoid further discussion. I do not think my kind of views are welcome in this community.

I still can feel very lost when refactoring a complex clojure system as opposed to something like Rust, because you have very little information about all the places in your codebase where a certain assumption was made.

You can go crazy and spec everything, in fact that can help, but:

- In practise, nobody does it

- Specs come with no guarantees. They could even be wrong.

- The official implementation stubbornly insists on not checking return types, so half of your annotation may just be glorified documentation (although you can use third party libs like orchestra)

Just imagine: Add a new required field to a spec, and get a convenient list of source code locations that you need to review. That's the promise of a statically checked system. It's not a silver bullet, but not having this leads to what I like calling "refactor anxiety" (i.e.: did I handle all cases?)

I still love clojure no matter what. I think in practise you can express so much, so elegantly, and with far less code, that your project size is always sorta manageable.

> He doesn't force anybody to use the Epic Store. Unless you want to play Fortinite (which is made and published by Epic Games) or games that have an exclusivity contract with the Epic Store.

So you're not forced, except when you are... I think the GP meant people is forced to use their store to play certain games. Games not developed by Epic, which were meant to be released in other stores and operating systems. You can choose not to play those games. Many people do in fact just that. But that was not the point.

Of course Tim Sweeney does not force random people at gunpoint to use their store. That's never going to be the case because there's laws forbidding him!

Specter is always on my clojure toolbox. Not only it makes transforming arbitrarily nested data painless, it also is usually more efficient than the average hand-rolled code!

A great example of why macros in Lisp are powerful, and how they empower you as a user even if you never write one.

Fair enough. But that was not my rationale, it was just a made-up corporate rationale that is not too far from what I can observe in reality. Take, for example, lobbyists in right-to-repair hearings. They use arguments like this: "If we let users repair their smartphones, they might hurt themselves, so it must not be allowed and instead always performed by a skilled technician". The implication always being, that if users hurt themselves, they will sue.

> Anyway I guess people can also buy their own computers if they want to play outside the sandbox.

My point was, precisely, that we might get to some point where this is no longer possible. Imagine they stopped selling what we today call "PC", and instead everything is closer to smartphones or tablets. There would be no way to setup a development environment on the machine. There's no sudo access, no compiler toolchain...

While impressive technology, I still get that eerie feeling of my computer's ownership being slowly taken away from me. The problem is not Github codespaces offering us an alternative to traditional dev environments, the problem may be 10 years from now, when someone says: "All the coding is done on the web nowadays, why should we allow users to install compilers and dev tools on their machine? They may use those for hacking and compromising the security of our systems. They may hurt themselves in the process and sue us! Better not take risks". I'm afraid to go into a future where this is normal...

Worth mentioning that, apparently, this is the programming language that will power DFINITY, an ethereum-like network for distributed computing.

I find the name of the NPS_0487a3ac_throttle cookie suspicious enough, but the article does not comment on it. Is this a common practice? Throttling the website for users who uninstalled your application?

Genuinely curious. You insist a VCS is not how the industry operates. But then how do those AAA devs manage synchronizing changes across a team of several hundreds of people? I imagine there must be some equivalent to VCS that better fits the gamedev indurstry. Or are people just throwing flash drives around the office?

To be fair, S-expressions are not a made up format and in fact predate most other formats you mention.

What should they do? Static analysis would be nice, but it's probably too complex to adopt in that kind of codebase.

In the end, the only viable option is to forbid this behaviour, and document a rationale so nobody will enable it back again.

Perhaps they could make this warning bigger, but other than that...

I stand corrected. I did not know numba and assumed it was similar to numpy and others, which do wrap C.

I still stand by my comment, though. We need to discuss technology by its own merits. Of course I'd also choose Python for an ML project any time of the day! But that's because Python won the popularity contest a long time ago. When discussing technology I think it's worth trying to see past that.

Exposing a C FFI may be flexible in the ways you mention (i.e. You can call the function from many languages). But I think we miss a lot on explorability. Let me elaborate a bit more with an example: Most people is not reallistically able to drill down on some implementation details when using neural network libraries like TensorFlow (which is not the whole field of AI, just an example!). At some point, if a feature is missing, you have to leave Python, learn a new language, and get a whole dev environment setup started. At that point, you're not using Python anymore, so I don't think it should count as a Python merit that you can do it.

That being said, I don't know Nim enough to validate whether using it for this would be a good idea.

The "python is performant because you call into C" argument implies that whenever any fundamentally new algorithm is developed you need to do it in C. This is actually gatekeeping things like machine learning to the few that can build and maintain the C code for libraries like TensorFlow.

Python is the ultimate glue code scripting language, but you can't build a performant algorithm without an efficient C implementation underneath. With languages like Nim taking performance seriously, people could build a complete implementation of such algorithms from the ground up.

This doesn't just mean the core implementation would be easier to maintain. There's a huge gap between people who use the python libraries and people who build the efficient code that runs underneath. This clear division between those two worlds is what makes it difficult from people to jump from one side to the other, and that's why I'm calling this gatekeeping.

Not necessarily Nim, but using a performant, simple high level language for this sort of tasks would blur this divide. In practice, this means AI researchers in universities could dive into the code that's actually doing the work, not just play with the toy buttons and levers Google and Amazon left for them to play with.

I, for one, think the HTML API (as in, the interface presented to the programmer, not talking about any other API meaning here) couldn't be worse.

How many attributes do you need to enable to place two pictures side by side in vanilla CSS? Is that composable, would the same set of flags work for two paragraphs? What about two tables?

HTML/CSS was never designed for the web we have ended up with, and I don't see how flexbox and any newer standard is making developers lives anything but miserable.