Amadiro

That's a quite different thing, OpenAI has billions of USD/year cash flow, and when you have that there's many many potential way to achieve profitability on different time horizons. It's not a situation of chance but a situation of choice.

Anyway, how much that matters for an investor is hard to form a clear answer to - investors are after all not directly looking for profitability as such, but for valuation growth. The two are linked but not the same -- any investor in OpenAI today probably also places themselves into a game of chance, betting on OpenAI making more breakthroughs and increasing the cash flow even more -- not just becoming profitable at the same rate of cash flow. So there's still some of the same risk baked into this investment.

But with a new startup like LeCun's is going to be, it's 100% on the risk side and 0% on the optionality side. The path to profitability for a startup would be something like 1) a breakthrough is made 2) that breakthrough is utilized in a way that generates cash flow 3) the company becomes profitable (and at this point hopefully the valuation is good.)

There's a lot of things that can go wrong at every step here (aside from the obvious), including e.g. making a breakthrough that doesn't represent a defensible mote for your startup, failing to build the structure of the business necessary to generate cashflow, ... OpenAI et al already have a lot of that behind them, and while that doesn't mean that they don't face upcoming risks and challenges, the huge amount of cashflow they have available helps them overcome these issues far more easily than a startup, which will stop solving problems if you stop feeding money into it.

It's also because around 20 years ago there was a "reset" when we switched from x86 to x86_64. When AMD introduced x86_64, it made a bunch of the previously optional extension (SSE up to a certain version etc) a mandatory part of x86_64. Gentoo systems could already be optimized before on x86 using those instructions, but now (2004ish) every system using x86_64 was automatically always taking full advantage of all of these instructions*.

Since then we've slowly started accumulating optional extensions again; newer SSE versions, AVX, encryption and virtualization extensions, probably some more newfangled AI stuff I'm not on top of. So very slowly it might have started again to make sense for an approach like Gentoo to exist**.

* usual caveats apply; if the compiler can figure out that using the instruction is useful etc.

** but the same caveats as back then apply. A lot of software can't really take advantage of these new instructions, because newer instructions have been getting increasingly more use-case-specific; and applications that can greatly benefit from them will already have alternative code-pathes to take advantage of them anyway. Also a lot of the stuff happening in hardware acceleration has moved to GPUs, which have a feature discovery process independent of CPU instruction set anyway.

In my experiments claude4 opus generated by far the best code (for my taste and purposes) but it's also a pretty expensive model. I think I used up $40 in one evening of frantic vibe-coding.

It's even worse than that, because the way they extract the causal link is just a regex, so

"vaccines > autism"

because

"Even though the article was fraudulent and was retracted, 1 in 4 parents still believe vaccines can cause autism."

I think this could be solved much better by using even a modestly powerful LLM to do the causal extraction... The website claims "an estimated extraction precision of 83% " but I doubt this is an even remotely sensible estimate.

Also when you visit most japanese websites you can see this phenomenon.

I've read an explanation once that this is because culturally, japanese people perceive a wealth of information and choice as being re-assuring and trustworthy, while most westerners feel more re-assured by seeing less content and choice presented in a more minimalist kind of way.

In my view, there is a major flaw in his argument is his distinction into pure engineering and science:

We can make a rough distinction between pure engineering and science. There is no sharp boundary, but it’s a useful first approximation. Pure engineering seeks to produce a product that may be of some use. Science seeks understanding. If the topic is human intelligence, or cognitive capacities of other organisms, science seeks understanding of these biological systems.

If you take this approach, of course it follows that we should laugh at Tom Jones.

But a more differentiated approach is to recognize that science also falls into (at least) two categories; the science that we do because it expands our capability into something that we were previously incapable of, and the one that does not. (we typically do a lot more of the former than the latter, for obvious practical reasons)

Of course it is interesting from a historical perspective to understand the seafaring exploits of Polynesians, but as soon as there was a better way of navigating (i.e. by stars or by GPS) the investigation of this matter was relegated to the second type of science, more of a historical kind of investigation. Fundamentally we investigate things in science that are interesting because we believe the understanding we can gain from it can move us forwards somehow.

Could it be interesting to understand how Hamilton was thinking when he came up with imaginary numbers? Sure. Are a lot of mathematicians today concerning themselves with studying this? No, because the frontier has been moved far beyond.*

When you take this view, it´s clear that his statement

These considerations bring up a minor problem with the current LLM enthusiasm: its total absurdity, as in the hypothetical cases where we recognize it at once. But there are much more serious problems than absurdity.

is not warranted. Consider the following, in his own analogy:

These considerations bring up a minor problem with the current GPS enthusiasm: its total absurdity, as in the hypothetical cases where we recognize it at ones. But there are much more serious problems than absurdity. One is that GPS systems are designed in such a way that they cannot tell us anything about navigation, planning routes or other aspects of orientation, a matter of principle, irremediable.

* I´m making a simplifying assumption here that we can´t learn anything useful for modern navigation anymore from studying Polynesians or ants; this might well be untrue, but that is also the case for learning something about language from LLMs, which according to Chomsky is apparently impossible and not even up for debate.

Is there any strong reason to use GeoParquet instead of straight up parquet if all I'm interested in is storing and operating on lat/lons?

I'm curious if it compresses them better or something like that. I see lots of people online saying it compresses well (but mostly compared to .shp or similar) but normal parquet (.gz.parquet or .snappy.parquet) already does that really well. So it's not clear to me if I should spend time investigating it...

I mostly process normal parquet with spark and sometimes clickhouse right now.

Sure but all pre-made, battle-tested tree datastructures you'd use in production in all languages already come with some form of iterator that you can just for-loop over, so the original articles point is still moot.

I think figuring out the fastest version of a shader at runtime is very non-trivial, I'm not aware of any game or engine that can do this.

I think it'd be possible in principle, because most APIs (D3D, GL, Vulkan etc) expose performance counters (which may or may not be reliable depending on the vendor), and you could in principle construct a representative test scene that you replay a couple times to measure different optimizations. But a lot of games are quite dynamic, having dynamically generated scenes and also dynamically generated shaders, so the number of combinations you might have to test seems like an obstacle. Also you might have to ask the user to spend time waiting on the benchmark to finish.

You could probably just do this ahead of time with a bunch of different GPU generations from each vendor if you have the hardware, and then hard-code the most important decision. So not saying it'd be impossible, but yeah I'm not aware of any existing infrastructure for this.

No need to scrape anything when you can just subpoena. That is the business palantir is in.

It looks more like Desktop GL might move to mobile devices soon. nvidia seems to be pushing really hard in that direction. But it'll remain to be seen where things go.

Eh, a lot of the recent articles on hackernews about GL have been fairly low-quality and were badly researched (like the guy who complained about timer queries blocking, because he blatantly didn't understand how CPU/GPU communication works) No need to buy into the FUD.

- if you use core profile, modern GL, there aren't a lot of quirks. It's a fairly nice API overall.

- if you target reasonably modern drivers, you won't typically find many inconsistencies and issues. If you do something unusual (like the latest idtech with megatexture) you might run into driver issues -- but that's just how things are, it's not the fault of the API. New functionality needs testing, and GPUs are still constantly evolving.

- extensions are not useless. There are a huge amount of absolutely fantastic extensions. This is, IMO, the main strength of GL over D3D (and other APIs), which does not have a mechanism like this. If you know the hardware supports a certain functionality, there will most certainly be a GL extension to exploit that functionality, even if you can't with D3D.

- in particular, KHR_debug is the best thing since sliced bread. It allows you to have the GPU driver diagnose your program for you, and give you hints such as:

- things you do wrong

- things you should do differently to increase performance

- general debug information

- information on memory usage and where your buffers are stored

No, that would make no sense whatsoever. You seem to be somewhat misinformed about GL...

* OpenGL core profile is quite clean and lean. Both apple and intel have already decided not to implement OpenGL compatibility (where all the cruft sits). There are still a few things that can and should be cleaned up, but it's pretty great already.

* Adding an additional API means there will be YET another thing vendors have to support and will be able to screw up, in addition to the already existing plethora of APIs: GL, D3D, DDX/GDI, OpenCL, VDPAU [or something like it], CUDA [or something like it], OpenMAX, Mantle. OpenVG, ... -- nobody is going to drop OpenGL or D3D for something like mantle, because that'd instantly lose you all your customers. Not even AMD.

* AMDs mantle (which is, as far as we know, just a specific thing to their cards and not even portable to any other cards) is not an attempt to make things more stable, but an attempt by AMD to gain more control over the market (something they are in a good position to attempt right now, as they have control of the console market) and to push into the direction of a low-level interface that is strongly tied to their hardware model. Mantle as an API is (as far as we know) even lower-level than GL and D3D, and hence not very suited for most programmers and applications -- there are a lot more things you can do wrong with it.

Don't believe all the FUD you read on hackernews. The main issue with OpenGL right now is that some vendors are doing a shitty job at it, which is mainly due to the heavy influence microsoft had on the gaming industry for a long time. GL is now making a major comeback due to linux, apple and mobile platforms gaining popularity, which will help rectify these issues over time.

I use chromium with a 5760*1080 resolution, and I frequently have > 150 tabs open across 3 browser windows, and I really have no complaints. I also occasionally peruse or develop WebGL/ASM.js/emscripten applications, so I suppose I fit into your description as someone who is "pushing the web browser hard".

All functionality I need to access quickly is accessible through shortcuts, so I don't typically need to access the "hamburger-menu" very often. The only thing I really use it for is to open the settings tab.

It's a matter of perspective -- to someone who has taken a university class on lambda calculus/on logic that had a chapter on lambda calculus (e.g. as part of a M.Sc. in mathematical logic or CS), anything in RWH would probably seem extremely basic and superficial. It doesn't even introduce most of the basic things a first chapter in a book on lambda calculus would probably introduce you to.

Yeah, I'm aware that some projects that apply computer science to pure mathematics (in various forms like Kenzo/CAT, PLEX (not CPLEX, that's for applied mathematics/finance/etc), agda, coq, GAP, ...) exist, but I don't think the claim that they are very very niche with mathematicians is exaggerated.

If you go to your average mathematics department and ask a few professors there that work in logic, algtop or alggeom, I doubt you'll find any that do any programming for their research. You probably won't find that many logicians that use proof-assistants either, although those are probably the least niche category of the things listed (and they are fairly popular with the CS folks)

AFAIK dynamic languages have gone away from compiling to native code because there is almost no benefit to it, if all you're doing is basically unrolling your interpreter into a unnecessarily huge binary. Methods like tracing JITs are much more effective at delivering good performance in the hotspots of your program.

The exception is when you allow yourself to annotate your code with type information, which allows you to eliminate a lot of the code you'd otherwise emit. Python for instance allows you to do this with Cython/snakeskin/etc., so the technique (that I think) you're talking about is applied there, because it is effective.

Category theory is pretty popular IME, I've seen lots of mathematician talk about it. It seems fairly popular especially with algebraic geometrists and algebraic topologists.

OTOH I've never seen any mathematician use (perhaps with the exception of myself, depending on at what point you start counting a person as "mathematician" and at what point you consider someone to be "using haskell") haskell. I doubt the haskell community actually has any mathematicians, it's mostly just people who'd like to be mathematicians but are too lazy to get a degree.

The overlap of mathematicians who care about category theory (some logicians, algebraic geometrists, algebraic topologists, ...) and mathematicians who program (mostly mathematicians from applied disciplines, numerical methods, computational physics, ...) is pretty much zero.

You probably won't find your algebraic topology professor programming in any language anytimes soon, except LaTeX.

When I visited the university of Göttingen, it was everywhere. Students also seem to have it adopted as the drink of choice.

A isn't really very low-hanging though, rewriting the build-system for something as complex as the kernel would be quite the undertaking even just from a technical standpoint, let alone that you now have to change thousands of peoples workflow by having them install and use a new build-system (some of those people are probably dedicated to just maintaining the build-system too, so their job would radically change) as well as figure out a suitable build-system in the first place (which one would work well for the kernel? which one works on all the architectures people want to compile linux on? etc)

B from linus' perspective just means "wait a year for things to automatically get better (after throwing some money at it)" which seems like the low-effort solution.

Your anecdote may tell us something about the "typical grandma end-user" situation, but it is totally irrelevant for situations that arise in large "enterprise" IT facilities, where the admins set everything up for you (in some central, network-booted/installed image), and the users don't really have to figure out anything. Configurations are centrally managed with cfengine etc.

Where I work we have around 10k RHEL workstations, and they are all centrally managed. Users neither install nor uninstall software, they don't set up printers, they don't set up their own hardware configurations, ...

Another example is Disney animations/pixar, where all animators use RHEL workstations.

Your colleague may have given up on ubuntu because he couldn't get "desktop dungeons" or "plants vs. zombies" to run without windows, but in a coorporate setting, management does not generally consider that a priority.

Chrome is not immune to bad JS and will also slow down your system until the single tab is killed/crashes.

That's true, but with like 8-or-so cores I don't really care or even notice that much (if I notice some tab is eating a lot of CPU power, I just go into the task-manager and kill it, until I need it, at which point I reload it.) No disruption to my browsing experience happens. In firefox, I'll have to close the tab, possibly restart the browser, et cetera.

The browser restarts, all tabs are still there and only load if you click them

I haven't really used firefox for a while now, but it used to lose tabs occasionally for me. I hope that's fixed nowadays.

They use them less because they are less practical and due to their purity are unable to fulfill peoples (real, rather than theoretical) requirements.

Measuring LOC required to implement a task is meaningless. If you implement a task in python in fewer LOCs than what I need in C, that doesn't necessarily mean anything, because my code might fit on an 8-bit microcontroller, run faster, ... or meet any other number of imaginary or real additional requirements I might think of (and people always have lots of those!) "Have 10% fewer lines of code" is pretty much never a given requirement, though.

Sure, erlang is a "uncompromisingly pure implementation of the actor model", but then python is an uncompromisingly pure implementation of the python model, and C is an uncompromisingly pure implementation of the C model, so that's hardly an interesting argument. Erlang is pretty much what popularized the actor model as we consider it nowadays in mainstream programming, so that's tautological.

The point (which you have not actually argued against) is that erlang is also a functional language, but not a pure one; it allows side-effects, it allows sending messages, it allows storing data in your (destructibly updatable) process dictionary, et cetera.

That means erlang benefits from the features it inherits from the functional languages, even though it doesn't go "full functional" in the sense some other languages do.

If you don't think there are programs that are difficult to write in haskell, agda, miranda, ML, ..., I have to doubt that you have done a substantial amount of them, and/or that you have applied it to any actual real-world task.

Developing USB drivers is actually totally fantastically easy nowadays with libusb(x). You can more-or-less just pretend your USB device is a server you talk to through a socket. No need to even write a single line of kernel-code, you can do it all in python in userland, if you so desire.

For many USB devices this is also a totally feasible thing to do, too, because most USB devices that are not providing some standard interface that the operating system takes care of (keyboard, mice, controllers, tablets, mass-storage, ...) just provide some sort of service that typically only one application would interact with, so just having the driver inside that application that interacts with it works well.

And just what makes you think making a purely functional language 'lambdacious' will not a few years later result in a book 'Industrial strength lambdacious'?

You're falling for the trap of thinking that pursuing a theoretically pure discipline will result in a language with less flaws; in reality, even theoretically pure concepts have issues and can be superior and inferior to other theoretical concepts/constructs [which may or may not be invented later]. Pursuing one theoretical framework may make some issues either disappear or be invisible (like garbage collection makes the issue of memory management appear to disappear -- but it still has to be done at some level, and this causes new issues, as evidenced by many talks given and books written about how to deal with $LANGUAGEs garbage-collector) but that doesn't mean that you won't have issues remaining or even create new issues.

You call "Aversion to Extremes" a cognitive bias that doesn't work well in practice, but you should realize that the opposite is true; the more extreme a language pursues a theoretical concepts, the less used it typically ends up being in practice. For every success-story you can give me about Agda (pursues dependent typing), haskell (pursues functional purity) or smalltalk (pursues object-orientedness) I can give you a thousand success-stories of people using C++, java or C#.

I can't imagine that you will be able to come up with any measure of "how well something works in practice" that is remotely sensible and makes these "purity-oriented" languages appear to "work better in practice". The reality of programming is just that there are many different requirements one might have to a language and its implementation, and properties that are very clear advantages in a theoretical framework seldomly translate to practical benefits in a nontrivial way.

A nice example (IMO) of a language that pursues functional programming without attempting to be needlessly pure about it is erlang; each "process" itself is written in a functional language that promotes separation of side-effects and communication, but from a "further up" perspective, each process is like an object, holding onto state. That way it gains the [for erlang] important advantages of having functional traits, while not sacrificing flexibility through needlessly strictly adhering to the functional paradigm.

Check if your iMac defaults to software rendering for some reason.

Absolutely not, with where the SDK is currently at.

I've tried quite a few games and demos with the current SDK (the one that is publicly available,) and several of them included text in menus et cetera. It was always an absolute eyestrain and pain to read anything. Maybe it'll get better once the new version is released, which supposedly has a much higher resolution.

But I suspect even then, it'll be impractical; not being able to see your keyboard/mouse from your peripheral vision, having to move your head around to bring different parts of the document into focus, not being able to see a book/document you have sitting next to your keyboard for reference, the added strain over time, ... as well as the added complication that most people who code probably have to look at other peoples screens occasionally, talk to other people, et cetera, which will involve a lot of switching back-and-forth, which can be quite disturbing.

See also https://www.youtube.com/watch?v=DqZZKi4UHuo this video for some experience from the owlchemy lab guys, who have been using the rift extensively during development for testing their game.

It still hurts everybody, because it bloats your files with unnecessary opcodes and forces the JIT to sift through it and optimize it away, instead of spending its time to do useful optimizations.

It might only seem like a little turd on the sideway that you can easily step over, but quite evidently in the case of flash little things like these have added up and its performance is now -- in the metaphorical sense -- up to its neck in shit.

If the hardware isn't the bottleneck, you can simply make your compression/encoding algorithms more complex, because 10% saved traffic is probably much more valuable than 10% saved CPU cycles (remember on phones traffic means a lot of energy drainage for sending/receiving). Besides that, though, FFT is old, so whatever codec you use to view HD videos on the iPhone, it probably already uses FFT or some other comparable thing like wavelets or so.

You need to write lots and lots of code to write a successful application in any language, really...