Probably worth drawing this thread's attention to the debate over whether ancient Hindu texts mention nuclear weapons and atomic war. Up to the beholder whether that makes those texts sci-fi or not, I guess.
Every great culture, over the millennia has imagined great weapons and unlimited godlike destructive power. You could, as you are doing now, retrofit our narrative on any of those if you wish. Make your own sci-fi fantasy. Those texts are not.
It's true that ancient Indians had some interesting insights into astronomy and natural sciences (recognizing the heliocentricity as early as the aitareya BrAhmaNa, and some ideas about electricity) and have some evidence about Indo-Aryan warfare being evolved with variety of weapons.
But it would sound like boomer uncles to claim that there is mention of space travel or nuclear weapons in our epics. The astra-s are simply figments of imagination.
You need to be twice as smart to debug code as you need to be to write it. So if you write the smartest code you can, then you by definition are too dumb to debug it
I hold KISS above most "Enterprise Patterns" with YAGNI as a close second. I think abstractions should be used to reduce complexity with code as opposed to making it harder to reason about. If a pattern increases complexity in understanding, then it should make sense in more cases than not.
I'm also a fan of feature-oriented project structures. I want the unit test file in or next to the code it's testing. For UI projects, similar with React it's about the component or feature not the type of thing. For APIs I will put request handlers with the feature along with models and other abstractions that go together based on what they fulfill, not the type of class they are.
I consider this practice more intuitively discoverable. You go into a directory for "Users" and you will see functionality related to users... this can be profile crud or the endpoint handlers. Security may or may not be a different feature depending on how you grow your app (Users, Roles, Permissions, etc). For that matter, I'd more often rather curate a single app that does what it needs vs. dozens of apps in a singular larger project. I've seen .Net web projects strewn across 60+ applications in two different solutions before. It took literally weeks to do what should take half a day at most.
All for one website/app to get published. WHY?!? I'm not opposed to smaller/micro services where they make sense either. But keep it all as simple as you possibly can. Try to make what you create/use/consume/produce as simple as you can too. Can you easily use/consume/interact with what you make from a system in $NewLanguage without too much headache? I don't like to have to rely on special libraries being available everywhere.
When I was a kid learning programming, I would skim through the whole book teaching Python and type the code using as much keywords as I learned each day, just to boast on my parents and my non-programmers peers about the obfuscated mess that came after.
As I grew I started to contribute to other open-source projects and I came across every kind of unmaitanable spaghetti code, so that I just gave up contribuiting on said project, that is when I gained the consciousness about being zealous on keeping the code as simple as possible so that the next person who comes after me to change the code don't have as much trouble understanding the code, even myself when I revisit the code later.
That altruistic mindset about caring how others read your code, you don't acquire easily unless you get experience how your previous peers did feel.
Writing simple code is also much harder then writing complicated code. If you write some complicated code at the limit of your mental capabilities you can not debug it, but you might also not be smart enough to write the simple code.
I guess this means that one should solve the appropriate problems for a given skill level
My #1 belief about engineering, and one I harp on constantly, is that simplicity is harder than complexity.
I use it as a heuristic. If my work is getting more complex, it's a warning sign that I might be doing something wrong or using the wrong approach. If it's getting simpler it means I might be headed in the right direction.
This is not just about writing code, but designing systems. If you design the smartest (most complex) system you can, you won't be able to debug/fix/extend/maintain it.
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
Holy shit you don't get anything for _free_ as a result of adopting Kubernetes dude. The cost is in fact quite high in many cases - you adopt Kubernetes and all of the associated idiosyncrasies, which can be a lot more than what you left behind.
For free as in "don't have to do anything to make those features, they're included".
What costs are you talking about? Packaging your app in a container is already quite common so if you already do that all you need to do is replace your existing yaml with a slightly different yaml.
If you don't do that already, it's not really that difficult. Just copy-paste your your install script or rewrite your Ansible playbooks into a Dockerfile. Enjoy the free security boost as well.
What are the other costs? Maintaining something like Talos is actually less work than a normal Linux distro. You already hopefully have a git repo and CI for testing and QA, so adding a "build and push a container" step is a simple one-time change. What am I missing here?
HN username for an extremely talented software engineer and software-engineering communicator, justine.lol. Probably most known around here for her cross-platform C code (cosmopolitan) and relatedly redbean, a zip file and tool that is also an executable file-server-file that hosts itself and can produce other such self-hosting cross platform executable zip file servers.
To carry on, this is because they're both very interested in "knowledge in depth", rather than because of what they actually work on day-to-day. They've both made careers out of knowing what's going on with the thing they're building down to the most basic level possible.
Actually he recently founded an AGI company. But this post is about optimization more than AI, which he is definitely good at (though he doesn't claim to be the best).
For someone to optimize something they need to have a good domain understanding. I do not buy that someone who developed games before just becomes an expert in LLMs overnight.
Sorry, it's definitely not true that you need to be an expert in LLMs to optimize BLAS kernels. Also, he started working on AI at least five years ago, which is a long time in AI world, probably before Justine Tunney started actually. And he's been optimizing code his whole life.
I was part of the Google Brain team working on TensorFlow back in 2015. Please note that doesn't mean I understand how LLMs work. Although I do know how matrix multiplication works now. At least until I apply my focus to the next area of impact and forget everything I just learned.
He literally squandered the last 10 years of his life working on absolutely nothing for Zuckerberg. And only after the rest of the world innovated on AI (transformers, etc) did he clearly feel embarrassed and had to proclaim he's going to focus on AGI in a "one-up" way.
He got paid a lot to do something he was presumably passionate about and enjoyed. It also might surprise you to find out that there's quite a lot of people that just work as a means to an end, and find value and enjoyment primarily from other parts of their life.
that's great for him. i'm glad he enjoyed the $$$ playing with VR. that has nothing to do with my point about his irrelevance to this LLaMa discussion.
He's not irrelevant, though. Literally the first thing he did after leaving Meta was start an AI business, and the original point wasn't even necessarily about AI. They just said they wanted to see two engineers in conversation, and you used it as an opportunity to denigrate one of their previous employers. That's bewilderingly irrelevant.
Altman isn't even relevant here. He is focusing on LLM's instead of a framework that gets us to AGI. He can't describe how we get there or any such theories around AGI. It's a complete failure.
Saying "Eastern Europe" as opposed to "Moscow" is a little coy, isn't it? They're in the same time zone and one seems likelier than the other, to put it one way.
Edit: speaking of, these guys might also have some time pressure at the moment with regards to hacking stuff lol. Kind of fits the bill with what we know about the hack
kind of miss n-gate coverage of FOSDEM to be honest, it was great for putting stuff in (sarcastic) perspective. More conferences should have a treatment like that.
In true n-gate fashion I believe the n-gate collapsed under the increasingly worse takes he had to come up with to counter the bad takes the n-gate witnessed from an hackernews. The parody indistinguishable from the idea of the original that was lost years ago, in a blurry confusion of what was and what the thought of what it was was. Having lost the meaning of its existence, it merely ceased to exist.
