"shut up and agree with what we say or we will deflect and drag your argument into a tarpit"
How noble.
1,557 karma · joined May 8, 2012
How noble.
What should I say now? "AI works in mysterious ways"? Doesn't sound very useful.
Also, should I start parroting innacurate outdated generalizations about regular software?
The post doesn't teach anything useful for a beginner audience. It's bamboozling them. I am amazed that you used the audience perspective as a defense of some kind. It only made it worse.
Please, please, take a moment to digest my critique properly. Think about what you just said and what that implies. Re-read the thread if needed.
The fact is, we kind of know how to prevent problems in AI systems:
- Good benchmarks. People said several times that LLMs display erratic behavior that could be prevented. Instead of adjusting the benchmarks (which would slow down development), they ignored the issues.
- Accountability frameworks. Who is responsible when an AI fails? How the company responsible for the model is going to make up for it? That was a demand from the very beginning. There are no such accountability systems in place. It's a clown fiesta.
- Slowing down. If you have a buggy product, you don't scale it. First, you try to understand the problem. This was the opposite of what happened, and at the time, they lied that scaling would solve the issues (when in fact many people knew for a fact that scaling wouldn't solve shit).
Yes, it's kind of different. But it's a different we already know. Stop pushing this idea that this stuff is completely new.
He is trying to lax the general public perception around AIs shortcomings. He's giving AI a break, at the expense of regular developers.
This is wrong on two fronts:
First, because many people foresaw the AI shortcomings and warned about them. This "we can't fix a bug like in regular software" theatre hides the fact that we can design better benchmarks, or accountability frameworks. Again, lots of people foresaw this, and they were ignored.
Second, because it puts the strain on non-AI developers. It blamishes all the industry, putting together AI with non-AI in the same bucket, as if AI companies stumbled on this new thing and were not prepared for its problems, when the reality is that many people were anxious about the AI companies practices not being up to standard.
I think it's a disgraceful take, that only serves to sweep things under a carpet.
Hm, I'm listening, let's see.
> Software vulnerabilities are caused by mistakes in the code
That's not exactly true. In regular software, the code can be fine and you can still end up with vulnerabilities. The platform in which the code is deployed could be vulnerable, or the way it is installed make it vulnerable, and so on.
> Bugs in the code can be found by carefully analysing the code
Once again, not exactly true. Have you ever tried understanding concurrent code just by reading it? Some bugs in regular software hide in places that human minds cannot probe.
> Once a bug is fixed, it won’t come back again
Ok, I'm starting to feel this is a troll post. This guy can't be serious.
> If you give specifications beforehand, you can get software that meets those specifications
Have you read The Mythical Man-Month?
That would shut up a lot of skeptics. I'm surprised live coding videos are not the main way of spreading this knowledge.
https://medium.com/@stefano.solimito/is-alphastar-really-imp...
> the AI sees the map as a whole while Mana despite is APM is restricted on what it can fit in his screen
That is probably why we haven't seen more of it.
Also, AlphaStar is not an LLM and it bears no resemblance to LLM tech except for the generic "AI" label.
Also, programming is not like those games, in the sense that it's not adversarial in nature and not a closed system.
I remember something like a KML overlay that would display magnetic data on Google Earth, but it was kind of obsolete and didn't had any historical data that could be used to observe change.
Well, in that case, I need some sources. For example, I'm not convinced that people project on social media to the extent that you're implying they do. It's a statement that needs support (which you didn't provided).
I am confident that you are able to find those sources, then we'll be able to talk about it on a common ground!
No tutorial, no rehearsing, just an organic capture of someone working with those tools in a real world problem.
I know that "portable" often means that it has no dependencies and it's self-contained, like in portableapps.com.
However, in shell scripting, the word "portable" is often used to describe a script that is not tied to a specific interpreter (it's not a bash script, or a zsh script, it just runs in any bourne shell).
I often recommend people to do both (can run on any shell and it is self-contained requiring no external dependencies), portable in any way.
---
You could, in theory, distribute this as a single file that runs on both bash and powershell, by making a polyglot, such as this one:
https://gist.github.com/alganet/2c1c004d0580e8d92cc1c167fa4f...
It would be called `ingest.cmd`. If you make the names of the functions the same across both, maybe you can even de-duplicate some parts of it into the part of the polyglot that addresses both interpreters (as long as that common part only deals in calling commands passing parameters).
---
> show_help() {
> echo "Usage: $0 [options] [source directory]"
> echo ""
May I introduce you to shell HEREDOCs? They're a great way to embed text, such as help snippets, directly into code without the need to resort to multiple echo calls.
Despite the warnings, companies insisted on marketing superintelligence nonsense and magic automatic developers. They convinced the market with disingenous demonstrations, which, again, were called out as bullshit by many people. They are still doing it. It's the same thing.
I also didn't knew that replicator programs were canon.
Here, classical programming done by Seven of Nine.
She is typing into the computer, while she describes the issue:
"The data stream degraded during transmission. Elements have been dislocated, rearranged. It's going to take some time to decompress the message to be arranged in the proper sequence."
Later:
https://youtu.be/rh7AJ8AdyJY?t=474
"The algorithm is working, it's reconstructing the data block"
She debugged the issue, programmed some shit, and that shit is working.
---
These people are definitely not vibe coding.
This is evidenced by both Neelix's and the Kazon surprise when the Voyager crew is able to replicate water.
There is a catch in the first episode, which clearly shows replicator technology being employed by the sporocistians (it's how they beam down food to the Ocampa).
Holoprogramming is a recurring theme in TNG and VOY. There's even a recurring character that is supposed to represent this role of specialized programmer, Reginald Barclay, among other one-ofs (such as Dr. Zimmerman).
> Picard says "Tea, earl grey, hot" and the computer instructs the replicator to create such a beverage. He doesn't even think about someone coding up a "tea" app - the computer is intelligent enough to know what he needs and controls the device to deliver.
You are clearly not versed in the ways of Star Trek. This notion is directly confronted in the classical scene of Lt. Paris asking the replicator for tomato soup in VOY, and getting super annoyed by the way it is programmed.
Remove the precursor, remove the problem.
The only thing you cannot do anymore is show off such projects. The portfolio of mini-tutorials is definitely a bygone concept. I actually like that part of how the culture has changed.
Another interesting challenge is to set yourself up to outperform the LLM. Golf with it. LLM can do a parser? Okay, I'll make a faster one instead. Less lines of code. There's tons of learning opportunities in that.
> The only "worthy" problems left are the hard ones
That's not true. There are also unexplored problems which the AI doesn't have enough training data to be useful.
The only exception here is learning (solving a solved problem so you can internalize it).
There are tons of problems that LLMs can't tackle. I chose two of those (polyglot programs, already worked on them before AI) and bootstrapping from source (AI can't even understand what the problem is). The progress I can get on those areas is not improved by using LLMs, and it feels good. I am sure there are many more of such problems out there.
I don't see it as particularly convenient if I want to stream a large array of small independent objects and read each one of them once, then discard it. The incremental parsed array would get bigger and bigger, eventually containing all the objects I wanted to discard. I would also need to move my array pointer to the last element at each increment.
jq and JSON.sh have similar incremental "mini-object-before-complete" approaches to parsing JSON. However, they do include some tools to shape those mini-objects (pruning, selecting, and so on). Also, they're tuned for pipes (new line is the event), which caters to shell and text-processing tools. I wonder what would be the analogue for that in a higher language.
I would expect an object JSON stream to be more like a SAX parser though. It's familiar, fast and simple.
Any thougts on not chosing the SAX approach?