Every programmer I know over the age of 40 (including me) agrees with you that the stakes are that high. The main problem isn't that programmers are dumber than they used to be, though many certainly are. The main problem is that the whole system of building software is dumber than it used to be, mostly for reasons that have nothing to do directly with technology. We all know how to write better code. Given sufficient time (which never happens), we could solve the complexity problem in most of the codebases we work on. But I don't know anyone who has the tiniest clue about how to solve the societal problems that got us into this state. We have huge tech companies with functional monopolies maintaining bloated, crappy codebases and management teams that won't recognize that as a problem, let alone fund any effort to solve it. All of that feels like a direct consequence of the business environment in the US.
Everyone in the comments misses the point. He's not doing this to make money. He's not doing it to replace other languages. He's not even doing it to make better games. He's doing it because he wants to and he can.
Keep most of the items. Tweak them. Do twists on them. Add some new ones. But change the game. I would want it to be more like Zelda. That way you could still have dungeons but also the over world would be a whole new layer to explore.
That's because most companies aren't doing software engineering. They are quickly hacking throw away code. For many applications that's perfectly fine, by the way. Most code doesn't live very long these days. There is no need to design it "correctly". The need is to get it out and then everybody moves on to the next hack.
One problem is that software operates with the domain of data, information and thus abstractions. Tons of it. Layers upon layers. As such, unfortunately there seems to be no tangible law of nature that governs it in a way that civil engineering would say.." hey it is a faulty bridge..".. because of the mother earths gravity that works really consistently to make you aware of your stupid mistake otherwise. May be the modeling of data and thus consistent information management needs to br amplified more. As we are having Turing complete systems everywhere which produced data at unprecedented rate. And very easy at that. What if this data mostly wrong due to the mistake in the code? What if the data are mostly garbage? Thus the domain such as theorem proving or defensive programming or test driven would have to be looked more often. This is even more nuanced in web development. Standards such as HTTP and HTML5 based on flaky conditions that, in distributed systems it is really easy to be out of sync, or incosistent. Even more, it has to be presentable and usable in gazillions of user decives. Compare for example at the ATM software. The presentation layer there are solid albeit very crude. If there is an element that does not load then it will hung at the first place and report. Do we see this in web? Lots of broken api calls or broken image urls but the thing still presented at your browser screen, right? 1. Too easy to make abstractions, model, library, frameworks whatever. 2. Typically there are not enough attempt to guard the invariance, the consistency of the model. 3. This is more pronounced in the domain of web programming, The standards, the tooling etc. the web programmer operating on these systems (or any programmer) would be bogged down by these variables.
You are absolutely correct that the current problem is that we are designing poorly defined distributed systems. HTTP/HTML etc. are more evolved hacks than rationally designed and cleanly implemented standards. They do work fine for most of what the internet does, though, which is to present visual information and to collect money from customers for services and sales. There are really not that many problem classes that the average web programmer has to solve.
There is nothing to look up to in case of software developers. Most haven't been paying attention in their computer science classes (if they had any) and they are making every avoidable mistake in the book. That doesn't mean that there aren't excellent people in the field (I have met one or two) but they are few and far between.
Going too soft to not hurt the "learn to code" people's feelings. If I eat and train, following Usain Bolt's regimen, can I be as fast as him and collect gold medals? No. But when it comes to mental pursuits, if I do all the coding bootcamps, (try to do) projects and work as hard as Christ Lattner can I invent, Swift, Mojo, Clang, and LLVM equivalent? All while getting a PhD, being head of tech in a few fortune 500 companies while being married and having a kid? YeS I CaN! iTs JuSt HaRD wErK!
Jon does himself a disservice with this whole "they aren't solving hard problems" thing. The actual point here is completely correct without the edginess: the tradeoff Rust is making is trading off iteration loop speed for the hope that they'll save time overall by "writing production-ready code the first time it compiles". This is mainly a pipe dream, but in the particular development environment Rust was designed in it may be the right trade-off to pursue. Maintaining a web browser is very different from making and launching a video game: web browsers are maintained for years, with features being added continuously, it needs to be maintained in a production-ready state at all times, and introducing any memory leaks is deadly for an application people leave open on their computer day in and day out. Mozilla is also a large, bureaucratic organization where by the time a developer is implementing something it has already been thoroughly designed and specced out, and the developer is on a strict deadline to deliver exactly that system as specified whether it's a good design or not. In contrast, if like Blow you are trying to iterate through a bunch of prototypes to figure out what the system should be or even what the game design should be, then obviously it's an incredibly bad tradeoff to spend any extra time getting "production ready code" for iterations you're going to throw away. Video games, very much unlike web browsers, are also basically launch-once products: very few features are typically added after release, usually just content additions if anything, and often that content is already built during development and simply gated as DLC for release for marketing reasons. As for the trade-off Blow is pursuing--to optimize for speed of iteration loops--many programming languages have pursued that trade-off, primarily in the interpreted language space. Only more recently have we seen languages that try to accomplish faster iteration speed without performance tradeoffs: with taglines like "the productivity of Python with the speed and safety of a compiled language". Go is probably the most successful to pursue that goal, but it is again in its own extremely specific development environment: servers for web services in the context of very large bureaucratic organizations. Game development is a unique development environment and will need a different solution. If Jai is trying to get fast iteration and prototyping while also achieving game-engine performance, that's definitely a fairly unique space to pursue in language design. Just because other people's problems aren't Jon's problems doesn't mean they aren't hard. For a man in his 50's he sounds like a total moron still pushing this adolescent "I'm the only one with hard problems" ignorance.
I could not relate less to a software engineer feeling "guilt" at their lack of productivity. I am very depressed as a programmer, but it is very clear that the reason things are dogshit are entirely things beyond my control. The things I have wrested control over are always incredibly good; the things the organization prevents me from wresting control over are dogshit. It is extremely clear if I didn't work at such a dysfunctional bureaucratic organization, the things would be fixed and the software would be much better. I don't feel guilt, if anything I feel resentment. I have no illusions that every developer I work with could do this, but there are two responses to that: 1. the fact that software organizations hire such inexperienced people is part of their organizational structure, they could hire PhDs but instead they hire boot camp grads, and the hiring of boot camp grads for me to babysit is part of the organizational dysfunction, 2. even the boot camp grads I've worked with would do a much better job if they were empowered by the organization to have literally any control over the software they build.
It's sad that programmer hobbyists come home from a long day at the office and start working on things that look like what a programmer in the 90s would've done as their full-time job. Most of these complex systems basically amount to hazing with the added bonus of job security.
"I'm trying to make what would have been the next step in 1996." Too late bro, GNU99 standard is already out. It's not much of a progress, but it's an open standard. Build from there at the very least.
I trust Jonathan. I find him to be reasonable even when he is frustrated [but i would encourage him not to be annoyed , he should expect to be annoyed by stuff and laugh about it]. 😺 People and Tech over complicating things. So it is an opportunity to someone like Jonathan. Maybe Epic is looking for a language like yours instead of Verse or you can upgrade Verse. Or you can go even higher goals.
@@Valentyn90A Watch his interviews and conferences, he criticize himself and criticize his own early builds of his games, he admit of his own mistakes and limitations and he is aware that other people are better than him in other aspects. He is also aware of how people perceive what he say and how he say things, so he rephrase what he is saying according to who he is talking to and stick to actually answer the questions. So i'm confident that He does have a reasonable and valuable thought process even if it is not perfect it is good enough to respect his thoughts and take it seriously. If you can't watch his stuff, Trust me ;D
wrong!! you can't compare making a prototype for UNIX when there was no software with today's standards and you are also forgetting the industry isn't just made by us engineers, it is also shaped by the market, this is why you need different shader languages. Also when the industry started there were no standards and porting was mandatory. And you can't place Haskell on the same level as C#
Another language starting, inevitably having the same limitations than other languages, because everything nowadays is just another syntax on top of LLVM. Why not contribute on something that already exists ? Or just use plain old C when you really want to have full controll ?
@@filipg4 really? I enjoy a lot listening to Jon but I can’t quite grasp sometimes what the bigger deal is about. I’m a non programmer that started making games since the Microsoft XNA days, then Unity, so basically 95% of my experience is C# and associate graphics API and shaders. Some might say that C# is not a real language and that game programming is not real programming and more “just scripting”, but I feel like I barely scratch the surface of what it’s possible, I’m using barely 10% of the language and libraries capabilities I think… can’t grasp how JAI would be so much better 😢
@@alejmcWhat you are doing is absolutely real programming and majority of people will agree, Jon included. If you write code to make the computer do something, you are doing programming, regardless of your tools/languages. Jai is perhaps a bit more difficult to appreciate if you did not get a chance to use it, or if you did not spend much time with C++. Because what Jai does really good is make things which are very messy/difficult in C++ like metaprogramming/builds/memory management/etc. - really easy without limiting what you can do. Combine that with a ton of quality of life improvements like better errors, smarter compiler, super fast compilation times, types as first class citizens, much nicer syntax, etc. and you get yourself an amazing systems language. Hope that clears it up a bit.
Jai is cool, but C and C++ will not go away. I write in C despite some of its problems, because everything has a C API, for Jai I would need to write bindings (and know C for writing them anyway).
@@filipg4 C++ has the worst syntax of any programming language not created deliberately as a joke. Rust has the worst semantics of any programming language not created deliberately as a joke.
@@filipg4 Like any other popular language. And usually bindings don't translate well (for things like preprocessor macros, for things like complex C++ template metaprogramming bananas, etc.) And then there is a mental burden of translating the documentation from C into Jai (unless the autotranslate that as well) and a general familiarity with C is still required because when your bindibg are wrong or you use them wrong because you do not know C/C++ then you have a problem. I never really like autogenerated bindings, I think it is better to write bindings manually when only very few functions/types are needed in the bindings.
its crazy that he insists on doing everything himself from scratch when nothing he's building requires any of the super fast, efficient code he's always going on about. Witness and whatever sokoban he's working on now could have been built in half the time with Unity.
@@Raxfyr it's crazy but I think it's cool. using someone else's library/framework/engine can be torture. when you build it yourself, the sense of reward is immense.
@@Raxfyr Given that increases in computing power of new CPUs are getting smaller and smaller with each passing year, (can only get so small with transistors) it's a very good mentality to have optimization and deeply understand what you're doing. We used to launch missions to the Moon with computers weaker than the cheapest Arduino, nowadays Chrome eats half of your RAM just by opening a couple of tabs. Whether we like it or not, soon we will have to go back to the reality of having to optimize everything if we want more than one program running at the same time on the same machine.
You know I woke up this morning and had the craziest thought. How much better things would be with just one more programming language... When is it going to stop? We're north of hundreds of languages at this point. It's like Linux, let's make a new distro everyday... cause we don't have enough. What you end up with is a disparate landscape where nothing works with anything else.
He isn't creating another programming language to satisfy anyone other than himself and other game programmers that have been frustrated by the same friction that he has. So if you don't grasp why it's necessary, it's not for you.
Closest thing to it right now is Rust due to the community effort. But using a systems programming language for general scripting (bash, python, lua), pc/mobile game dev (from c++ to kotlin to js), access to data science tooling (python, julia) etc. is just not worth it I am a golang backend dev and I'm better off using react+ts for a portfolio website and lua for hobby game dev and bash for scripting Also, there are multiple app communication protocols ranging from extern c to protobufs to json depending on needed level of ease of use and flexibility
Different languages are better tailored for different kind of tasks. Otherwise we'll have the mentality of JS running everywhere, even where it has no business running.
You know, this can be said about a lot of things, like why would Rimac make another car company, don't we have enough of them? Why would Framework make yet another laptop, we already have established brands. Why would anyone make another videogame, we already have too much to even find the time and play our backlog. Let the man do his thing, maybe it will be a failure, maybe it will be a success. Maybe it will solve *his* problems and that will be a success in itself. He's not doing it for money and fame, he's doing it because he thinks there is a valid reason to work for *years* to create a new language :)
It’s probably already done, it’s just not releasing until the sokoban game is done. He wants there to be a full game engine, full standard library and full game written in the language from day one.
@@gracjanchudziak4755 Jai absolutely won't eat zig. Zig is a systems programming language that integrates seamlessly with c and fixes most of c's really rough corners. So general purpose low level language with a wide target. Jai is targeting game programming and looking to eliminate a vast swath of c÷÷ complexity that isn't needed in that restricted domain. I expect both languages to become much loved to their different audiences, specifically because they both have compile time execution that allows building up low cost abstractions to actually solve the problems that these different audiences have in their domains, and not the nary fairy academic ones dreamt up without the benefit of being tested in real application limitations.
The only thing Jai is missing is docs/tutorials. I can use it efficiently without both, but we will have to make some for newcomers, because it will be hard for them to pick it up without much prior knowledge of systems programming. But all things considered, language is pretty much production ready already and there are games released for both phones and pc with it. So yeah, soom tm
Why are we being blamed for this? Its your job description nowadays an entry level software engineer is expected to know CI/CD pipeline, aws hosting, backend + frontend, documentation and after knowing all this there is no guarantee that they work his team - lead will assign him will be is a work which a 10 year software engineer should be assigned and we are expected to know because we have chatGPT and you are paying us. This is fair? You for the sake of money can launch 10 frameworks in a day but if acquire shallow knowledge for money we are culprits. You fix your job description and give us our fair chance and I assure you there are so many talented software engineers who are yearning to acquire deep knowledge but dont because " You guys pay us to get job done rather than knowing our work".
You aren't being "blamed". Most of you are throwaway employees in an industry that generates endless amounts of throwaway code. That is simply a fact. It's more a matter of business model than engineering.
The problem all those idiot selfish people out there will not listen to your bro, but it's really appreciated that you are letting the world understand the pain we are going through as developers nowadays and hopefully this will be fixed somehow
I'm sick of the people I work with who think there's one right answer to every problem. They cannot understand the concept that there are different valid approaches and tradeoffs between them. I think that grinding and memorizing leetcode puzzles instead of taking on real projects is a source of this. The people who have problem solving skills get filtered out of jobs. I've learned to stop demonstrating my problem solving process when doing interviewing questions, because interviewers have become mindless bots who expect that humans know an answer immediately, and that even pausing for a moment to work through a process of elimination or reflect on alternative approaches is a sign of weakness. I'm trying to show how I work with people, and all they hear are wrong answers.
You are correct. The problem is that the industry, on average, requires hordes of people who can hack rather than a few knowledgeable people who can build well defined and reliable systems. That is reflected in the hiring process as well. The real question for you is... why are you still working in the industry? Shouldn't you look for a more satisfying work environment?
It's funny, if you learn math or physics, you have all kinds of abstractions, but you never have abstraction "layers". It's a purely IT engineering thing.
i call it the "drafting stage". its comparable to gray boxing a level design, or using simple shapes for modeling, or outline sketching for drawing/painting. the purpose of it is to try out ideas as fast as possible. i try to prolong it as long as possible that sometimes its all thats needed to form the MVP. draw in ideas as fast as possible. throw out ideas as fast as possible. use temporary variables for complicated equations. fake up function calls if needed. add in branches, try those branches with fake variables. if theres something you dont know would work, its probably a good idea to catch errors anyway. etc etc. its fast and fun.
I feel like narrative doesn't fit together. In the first half, he is talking about abstraction and loss of capabilities in terms of higher level languages, but the second half's examples are all quite low-level problems with developers needing to be well-aware of the whole ecosystem. Also looking back at computer history, the duplicity of computing standards seems so huge in comparison to what we have to target today in terms of consumer apps (a few companies, Linux, possibly some other Unices, ARM, x86, ...). Maybe this is decrying an apparent sweet-spot in complexity after IBM PC, 8086, etc. while software still hadn't had "liftoff" w/r/t developing standards, speed of ecosystem change, new architectures, .... Maybe a more interesting presentation would explore how newer standards could have developed with a different mindset (some concrete examples of simple designs?).
There's also a key point missing from this: The point of programming is ultimately to solve real life problems. Programming for the sake of it can be fun, but it's not really a business goal someone is going to pay for. And we all have bills to pay.
I heard this in the original interview, and it's been resonating in my head for the past weeks. I realize I can make a lot of design decisions that prolong this as well.
F1 is a good example because if you're uninformed, you might assume that its the "peak" of skill, when actually F1 driving and standard commuter driving are almost entirely separate skillsets, and just like programming you should acknowledge the differences. You wouldn't get an F1 driver to drive a semi on a 48hr convoy trip, and you wouldnt get a long haul trucker in the F1, just like you wouldnt swap the jobs of, say, a networking engineer and a database specialist, or a cardiologist and a neurosurgeon
