355 karma · joined August 13, 2023
As for the good stuff like the F-35, the US still dominates. The overall problem is that it's like 100000x the cost. Take this, if the US lost it's entire navy in an instant it would take the US over a decade to rebuild. If the same thing happened to China they can rebuild that Navy in a year.
Both countries would strike the other down in a heart beat if there wasn't a huge economic cost associated with war.
Your job is to prove why ages of technologies is relevant to your argument. If it's not then the only thing you can do is admit how that part of your argument is fucking baseless. You may be happy to discuss other things with me but until you admit or prove me wrong on this point there is zero further discussion about anything. Just walking up to someone and telling them they're wrong is useless. When you say gross expectation I expect some evidence to back that shit up. If not then you can just leave.
That being said I don't think I'm in the mood discuss anything with you. Let me be clear, any response you make to me after this will be illogical because I won't care for it or respond and it will be a complete waste of your time. We are done.
The question was framed in a way where the question is total shit. I was being nice but the minute you say it's a "you" thing I'll just spill it. The question is garbage. You shouldn't ever do this it's not your thing. You can't teach and you don't know how to respect the person your teaching.
First off I can google it. First result: https://answers.microsoft.com/en-us/windows/forum/all/ethern... But I wasn't saying that. I'm saying that google is the ONLY option based off the way you framed it. You don't want to present a problem where the only way they can solve it is to google it.
The question needs to be framed in a way where the user has the tools he needs to solve the problem. If the task is how do you build a lego house, you need to provide the person with legos so he can design a house and learn what legos are. If you ask such a question to a person who doesn't know what legos are, doesn't know how legos work, then your question is complete fucking garbage. Get it?
Here's a suggestion. List a set of common networking tools in which a subset would be appropriate to solve the problem. That's one way of how it could work. You don't say hey, that's a "you" thing. No man. It's you. Yeah if you didn't catch the hint we're done.
"Computer, dim lights by 30%"
"Computer, open curtains."
"Computer, vacuum the floor."
"Computer, play some jazz"
All of these are phrases are actual literal phrases that I use in my home, some on a daily basis. It can only be done, with current consumer tech, through the internet. All you need is a roomba, some 4$ smart bulbs, a spotify account, a 30$ auto curtain robot, and an alexa. For google home you can do the same but you can't call it a "computer."
In the future they will most likely be hooking up some LLM super computer to the home. In that case it can only be online.
The idealistic version of a smart home involves what we see in Star Trek TNG. Talking to the computer and only an online version of that can fulfill this vision currently and in the future. If you go offline, what you get is what I term a "programmable home" more than a "smart home".
I now never touch a light switch.
"Computer dim lights to 40%." I never bother touching a light switch. This guys set up is too complicated. The easy way to do it nowadays is to buy smart devices that integrate with the google or alexa echo system and you just talk to alexa or google to get it to do what you want.
Heck you can argue for how HTML and JavaScript are 20 years old!! Wow that means front end hasn't changed at all for 20b years! Come on man.
Anyway my overall point wasn't even about what's changed. My point is that these are all awkward apis to use to develop a windows style UI.
Even if you think they are old, these frameworks are bending and adjusting an underlying layer to do something it wasn't designed to do in the first place. Hence the awkwardness.
It's more likely someone utilizes such errors as ammunition. Such an action is quite common. It's obvious to me that this is the more likely scenario here from the other replyer.
Another common thing is to team up with people who have similar intentions. When such a situation happens they synchronize their biases. Two coworkers with the same intent will synchronize their biases in a meeting in order to push their intent... Happens all the time.
You like the front end, my guess of what's going on with you is a team up of sorts. Malice is too strong of a word for what you're doing. You're doing a team up and you're adjusting some obvious biases to favor your intent and create alignment with your team mate. This is all done subconsciously too. But that's just my guess on what you're doing.
These are all obvious human behaviors that are quite common but people don't think about it until it's explicitly pointed out.
But in the end. Who cares. We both are now clear about what's going on. No point in debating this further.
I'm sorry but that comment alone makes me think malice. It's too obvious. To each their own.
React has been changing a lot. And before react it changed even more. There's all kinds of change in the front end world and you know it. Not even close to bullshit.
>Everything else in this area is very experimental and tentative, as it should be, but it is mostly celebrated by people who, surprise, complain that "the web is too complex".
Webgl and svg are experimental? I don't think so. Using CSS + HTML + Javascript to build an Windows like application is more experimental.
>Even "new hotness" like Tailwind is based off quite old Atomic CSS ideas that started in the late 2000s and early 2010s at Yahoo.
I never talked about whether something is based off of old technology. I'm just saying all the state of the art is always changing constantly as people build new things. Whether those new things are recycling old ideas is besides the point. The main problem is that each "new" thing is placed as this big ugly layer above something that was designed to be a high level interface anyways.
It's called a typo.
>I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL
I think you're smart enough to recognize it's a typo. The primary issue with your comment is hiliteing issues as if it weren't typos but actual lapses in experience. It's like saying someone misspelled a word and claiming they therefore have no experience with the English language. If someone did that, the intent is 100% malice, not a misunderstanding. Don't be malicious. Don't debate and use malice to prove a point. What you should do is Make a point and change your stance based off of evidence.
Also I never said it can't be done. I said it's awkward. It certainly can be done.
WebGL is low level. Same with WebGPU, it means you have to use shaders. Godot has a library for UI. Which makes it less awkward. I'm saying it's JUST as awkward to build these things with webGL then with other web front end technologies.
>Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/ >Here's one that mocks macOS - https://macos-web.app/
What do these examples prove? That it can be done? Did I say it can't be done? Again I didn't. It's obvious these examples exist, everyones seen them. Heck you can probably do the whole thing with CSS and no JS. The gist of my comment is that it's awkward to do, not that it can't be done. You can construct a house out of toothpicks and glue. I'm sure it CAN be done. But bricks are the less awkward tool.
For what they are most of these screens are far better than HTML counterparts. UI is snappier and more special effects.
Game UIs off the menu have always been better than web pages too. Look at say baldurs gate 3. I don't think such a UI is easily pulled off in web. Possible but awkward to build.
HTML was never intended for dynamic interfaces. Whenever you diverge beyond what it does best which is hypertext, things become more and more hacky and awkward. If you wanted to design an os UI in electron, you would use a framework called react, and you would use a language called JavaScript that compiles down into typescript and you'd need a whole build ecosystem and connect everything together, then you might find HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg... In both cases you miss the text rendering from HTML. If you stick with HTML then you'd be using css to move shit around and create windows which is also incredibly awkward.
People use electron because it's easy. The reason why it's easy is because of familiarity not because of actual superiority.
Web UI is one of the most hacked together technology stacks ever. Developers with nothing better to do keep coming up with new abstractions trying to build for a moving target. It's not unique in this regard but it doesn't change the reality. Godot has the benefit of a very specific design implementation for a target that is highly dynamic and likely will never change. Plus it's new so you don't have armies of developers trying to "abstract" shit on it over years and years of horizontal progress.
That's literally my only route. For example, if I asked you, how do you fix a refrigerator without a broken refrigerator in front of you... what would you do? Likely google it too.
It's hard to frame the question in a way that's actually educational in the sense that it triggers problem solving. Right now the question is framed in a way where I can only look up the answer. You see what am saying? I can't actually help you here either because I don't know how to frame it correctly.
The environment would have to be interactive though. Not a written problem set but some network of containers that exhibits the problem. That's how one gets the experience.
Think: leetcode for networking. I would pay for that.
The reason why learning something likely calculus is so straight forward is because you can just do tons of problem sets and eventually you develop the instinct for it which by default comes with understanding. I want the same thing for networking. Problem sets is the key. I guess this is a start up idea.
That being said I do think you're right. It's just that there's two underlying trends here of "mental illness". The one your addressing has been longer term and more pervasive while the recent trend is, as stated, a new trend and seemingly caused by social media.
That's what all the training materials are missing. I want to fast track this section with practical practice problems.
More like there is no theory. You just build it off of your gut feeling. Maybe you use big words like "dependency injection" or "domain knowledge" to make it feel like you have a theory but really you don't.
When you have a theory, aspects of the design are calculated. Diagraming the architecture on a whiteboard is not theory. It's still gut feelings.
So much so. that the alternative is negligible. The language compilers compile is theory based but the implementation of said compiler has a huge part of it getting unit tested and not theory based at all.
It's all black box experimental testing with little theory. That's why we have unit tests.
When there's a complete theory about something. You can actually build that something very accurately as a theoretical model and rely on that model as an accurate blue print for the real thing. No such theory exists for programming. The complex application you designed has no theory behind it at all.
bridge builders on the other hand first build the bridge theoretically before building the actual bridge. There's some testing but physical engineers don't rely on testing as much as programmers do.
Imagine if we built airplanes the same way we build programs. Let's pretend those airplane builders just use their gut feelings like programmers do and then those builders verify their built planes with a suite of unit tests only.
First off the cost would be insane as likely a failed unit test is a destroyed plane.
Hence why all other engineers besides software rely more on theory while software engineers rely more on the scientific method which is largely less effective.