@@MrModez I never used it before, installed it through my package manager in about ten seconds and started it for the first time in about a second. Compared to any other relatively widespread engine, this is astronomically fast. What is your problem?
23:30 Linker takes 0.16 seconds. JB: man, linkers are so slow! Meanwhile, web-developers: our page takes 5 seconds to load; seems good enough! No need to optimize further! That would be premature optimization!
That's some nice tribal behavior you've got there. "Web-developers" aren't a different species. Their DNA is 99.9% identical to yours. Different software has different performance requirements. Running really fast matters when you have to update the entire screen every every time your monitor refreshes. One 5 second load time followed by NOTHING isn't a big deal. Get it now? Thanks.
Pro tip for whoever edited this video: how about cutting to the wider shot where we can see the slides when the speaker is pointing at them and talking about them, and not freaking randomly?
It even lines up with the theme of the talk! Instead of doing the obvious, simple thing of one static camera that shows everything, they chose the more complex route of having multiple cameras, editing between them, and having an objectively worse result where you can't see what you want to see.
Yeah no that's dumb. What you really want to do is develop for the target that you think a bulk of your users have. It's nonsensical to not take advantage of what you know your users will reasonably have by making compromises so everything works on a potato. Yup, let's butcher the capabilities of a program so that it runs on 4 people's shitty machines. Makes a LOT of sense (WOW).
@@youtubesuresuckscock Obviously we're not gonna hamstring the product just to get it to run on everything! We're not single minded dodos who focus on optimisation to the point that we're making a worse product as a result!
@@youtubesuresuckscock Have you ever noticed that most if not all performance issues related to modern software nowadays are never the developer's fault? Worse than people that over-optimize software prematurely is people that think end users are an infinite pool of resources and can and are willing to throw money at every performance related issue, as it's never the developer's fault, but the user's hardware. That's the culture modern developers are pushing today. We're getting faster and faster hardware, but our software is getting slower and slower, requires more and more resources and it's more and more complex.
@@BrunodeSouzaLino I pretty much disagree with everything you wrote. I think it's generally accepted that most software is poorly written shit that was rushed out the door without a lot of thought. It's also generally accepted that consumers have an incredibly high tolerance for shitty products, and that's why they get away with it. The bottom line is that the overwhelming majority of people don't really give a shit if their banking site takes 5 seconds to load. As long as you show a spinning animated GIF they'll just accept it. They'll also sit through 30 minutes of commercials after paying $20 to watch a comic book movie. It's also generally accepted that CPUs pretty much hit a brick wall in single threaded performance 10+ years ago, and so even though some hardware is getting faster (mainly mobile crap and graphics cards just because there's a lot of low hanging fruit to get out of the former and the latter is massively parallel in nature and so you can just keep throwing more hardware at the problem), a lot of hardware isn't really getting faster, effectively.
I admire Jonathan blow, he's a kind of developer I want to be someday, he cares about important topics, for a regular user 7 seconds it's nothing, We are starting to degrade because we got used to ”just 7 seconds ” because of developers like Jonathan the progress doesn't stop!
It's a pretty dumb presentation, honestly. "I'm going to ignore RAM and hard drive speed when talking about load times, which are largely dictated by RAM and hard drive speed." Genius. In the early 2000s, I couldn't have a web page open while playing Quake 3 and burning a disc without Windows crashing. Today, programs basically never crash, I can FUCKING STREAM VIDEO over the internet at resolutions higher than I used to run games at, while burning discs, while downloading something, while having multiple 4k videos playing in the background in a browser window, while encoding video. But no, it's just all downhill and everything's slower. What a fucking farce. Blow is so full of shit it's pouring out of his chrome dome. The first half of this video is basically a legion of straw men. Honestly, Blow strikes me as a bit of a charlatan. He passes himself off as some guy who's been making games since the 90s, yet he has 0 game credits before Braid. What's up, Blow? Bullshitting us a little, there?
I didn't get turned on to how slow programs have gotten until a few years ago and now it kills me everyday. I'm not a hardcore developer but i've switched to Linux because booting Windows is slow, and auto downloading rss feeds because web pages are slow. Seeing how fast computers can be and how complacent we are makes me excited for this language. If even 5% of devs take performance more seriously as a result, it's still a net win!
@rvi 64 Windows 10 basically hasn't crashed on me since I started using it. Almost every time it's some kind of hardware failure or hardware incompatibility. Bad RAM, unstable clock, etc. Windows has a lot of problems and blows ass for gaming, but honestly, it really doesn't crash.
I'm waiting in anticipation to try this language out. After developing a fast, multi-threaded game engine using Vulkan in C++, I 100% support most of these design ideas. I know I would have a lot more hair left if I didn't have to write so many hacks just to make something that's abstract-enough to use in writing actual game code while also maintaining a Data-Oriented layout. I think I'm most excited about how structs and inheritance are handled. If I didn't have to enumerate every new entity, that would significantly reduce the strain of writing new features and debugging them.
Q&A 50:15 Will Jai support easy rearrangement of data structures for performance? 52:45 Will Jai work with existing code such as C/C++ libraries? 55:10 Will Jai support Just-In-Time (JIT) compilation? 57:25 Will Jai handle optimized code generation within the compiler or use an external tool such as LLVM? 1:00:32 Are you implying that if Adobe Photoshop was rewritten in Jai then it would run faster?
Something I took from this language is that it is WAY too far ahead of it's time, in a great way. I don't think most even understand how smart this guy is. This is insane. These features are literally the future depending on how they are implemented. I would imagine this language won't be picked up mainstream for a long time due to the immense learning curve of some of these out of the box features. This guy has been programming industry standard C/C++ code so long he was able to take that experience and go straight from mind to program with improvements, optimizations in workflow, a whole ass new programming language, great syntax, great features, and all. This will be under appreciated at first.
The learning curve isn’t too immense if you’ve programmed in C++ before! It’s quick to start writing code you want (in a month I was comfortable), but the skill ceiling is much much higher which is great :)
He'd be enraged to learn that current Photoshop CC loads several times slower than his version. On my older computer which didn't have an SSD, it frequently took between 2-4 minutes to load. On my current machine, with an M.2 drive, it takes between 17-30 seconds. Insane!
So in the end programming is no different from any other field of professional activity in that traditions dominate and even at the bleeding edge the research questions is shaped by the traditions people model the world through while the best ideas are discovered early which leads to an obvious increasing difficulty in finding new beneficial ideas and as an end result progress slows down due to diminishing returns on developing the tools and practices. Endless progress is a myth that obviously is not supported by the laws of reality.
@@arminbarazesh640 The strong version of the Sapir-Whorf hypothesis has been discredited: en.wikipedia.org/wiki/Linguistic_relativity Your tools do not make your thoughts, or shape them, but act as guides that influence some comfortable modes of thought without really preventing uncomfortable modes of thought which are merely awkward for the tool, but not impossible. In programming, so long as a tool is Turing complete, anything is possible with it, just not necessarily easy. That said, it is still valid to make new tools to make it easier to think in different ways, that would be hard or discouraged by traditional dominant tools.
@thatonespathi Yes, programming is very much dominated nowadays by tradition and marketing talk that go hand in hand. And by people just copy-pasting code from the web. I find it absurd how in Node.js programming people actually make a whole library just to avoid writing a simple trimming function. Then again we're talking about industrial mainstream programming here so obviously there's gonna be a lot of nonsense. Essentially OOP seems to be a tool that became dogma. There's the old Alan Kay quote about OOP: “I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind.” -Alan Kay. Back in the day Javascript was called a object-based programming language because people didn't understand that class-based OOP isn't the only form of OOP around. Copy-based and prototype-based OOP for example are a thing. Nor does the term OOP even have an unambiguous consensus definition. And much of the marketing talk about OOP is just plain nonsense. Even Uncle Bob in his OOP talks points out that in the simplest sense plain C does encapsulation better than most modern OO languages. Like you say there's a lot of ideas in the history of programming but many, if not most, programmers nowadays do not seem to know basically anything about the history of the field which leads to them misunderstanding a lot of stuff and not being able to appreciate that there's many different ways of looking at things.
I feel like in the past incremental builds were really good because computers were slower so it was worth splitting everything up and only compiling what you need, but now it's faster to just compile everything at once and skip all the side stuff added from linking disparate parts
Non incremental builds aren't even realistic for huge projects. And no, his little game isn't a huge project. It's really easy to yell at clouds and call everyone an idiot for what's been done so far, but the reality is that many things are the way they are for good reasons.
@@youtubesuresuckscock The point is that the C/C++ environment has such a bloated and legacy build pipeline that his full builds are much faster (for The Witness-sized programs) or probably comparable (for huge projects) than an incremental build.
What makes programs slow -> lack of understanding of control flow and overprotective programming. For example in Unreal Engine whenever you change a property value a OnConstruction script should be run on an Actor - in case it uses that property and want to reconstruct somehow using new value. While that approach is sub optimal, but it knda works. The main problem with it - is that OnConstruction script can be run five times for one property value change - just because it is triggered from different functions in the update call chain, just because there was some bug sometime when it was not run, so to make sure developers added that call everywhere it was needed/ So instead of 1x construction script time operation now takes 5x construction time. And that kind of stuff happens in every program - because in the beginning programs start simple, and then they grow, new layers add up and they need to update and nobody can fix old logic because to many people already depend on it.
I can clean-rebuild almost a million lines of code (EQUINOX-3D) in 3 minutes, and load a gigabyte scene with millions of polygons and many thousands of transform nodes in 10 seconds in EQUINOX3D. It completely baffles me why systems take hours to build and apps, like Unity, or Maya take 10 minutes to load trivial scenes. What the hell are they doing in there?
This project shows once again: Building more features works better in a team, building (or at least designing) something small and good with conceptual integrity works better alone. Mathematica dhows the same thing. Projects need a benevolent expert level dictator.
I'm pretty excited about this, and looking to jump ship from my current language, which I like a lot (delphi) but want to move to something quicker, cross-platform, and a bit more hard-core in terms of graphic programming. If this comes out soon, I'll definetly give it a nudge, otherwise, I'm about to bite the bullet, and teach myself C++
Very interesting. I've noticed the hardware/software slow down. A lot of it is bloating. You see this in anti-virus a lot. All in one software runs muuuuuuch slower than smaller specialized tools. So I wish him much success with this language. But, if someone like Adobe gets ahold of it it will wind up bloated too. *sigh*
"All in one software runs much slower than smaller specilized tools." Uhhm... Nope! The perfect example to disprove your point is the JAI-compiler itself. No giant build-tool mess, just: >> jai.exe myProg/first.jai And *_everything_* to get a complete program is done by the compiler. Linking wasn't handled back then but should be implemented already and/or pretty soon. ;)
He's certainly got courage and stamina. I think there are many who feel that the state of things, when it comes to software programming, is not particularly good, but to figure out just how and why that is is difficult. Even much more difficult than that, is to actually create a new solution and convince people that it's not just another more-or-less pointless attempt at starting a fad. I mean, there are many very smart people that has had a lot of time to do something about these problems, but they haven't. He's like a single worker ant trying to move the entire ant colony. The odds are certainly against him. But as some clever people have said, it's the things that are hard to do that matters.
He's genuinely an inspiration, I mean since I've started listening to him, It really helped me pushed myself, into being harder with myself, he's one of the few that try to remind people that part of the value that we are delivering through programming is time. Fast software is not just great because it's fast, on a scale of a person's life, even a 10s decrease in build time is probably days of life saved, powerful builtin metaprogramming features that let you cut some of the dirty work and let you avoid macro insanity, and help you debug your program more efficiently can help you save month in the long run, there is really a compounding effect in having the underlying tool being powerful, I think the next generation of language are really going to be awesome compared to C/Cpp, like Zig, Rust (even tho I'm not a big fan of it but people are certainly building cool things with it), Mojo, etc.
The best programming language shows up whenever it is created to solve a specific problem. Such as C was created as simple higher level language over assembly while other languages sucked.
No, C was created to integrate into Bell Labs Unix. Now we have shitty monstrosities like the C std lib that remain in that 70's fairyland, with some feeble updates in the 90's and 10's.
It was created as a high-level assembly language in order to do portable systems programming, namely writing Unix. C and Unix were developed by colleagues within a certain group at Bell labs. C came first, but it's purpose was always something like Unix. There was other OS work at Bell, Unix won out. Unix wasn't even the preferred project, C and Unix both won the day. C's successor language B actually had some more rich features which were left out because the goal was to great a language that abstracted over the assembly mental model that one would need to be thinking about while doing systems programming work.
Rust does the smart front end thing. They have an additional IR layer called MIR which really helps resolving type system related constructs, optimizations, borrow checking and others. Some stuff is probably just deferred all the way to llvm, but certainly not all. Of course some things you would want to defer and other things you'd want to push up into the front end so it all depends, but they seem to have it pretty straightened out.
Rust doesn't do smart thing in front end, and it shows. LLVM backend really struggles to process all the stuff Rust throws at it. Rust mostly makes Rust things in its frontend, and generally does not optimize. I'm sure they will put more effort on that front some day, but today they still primarily focus on features.
And it's like 1/20 of unity load times. And this is a full scene that takes less time to load than empty unity project with one capsule, one script and one cube.
This is soooo good.. all these days the AI hype taking over programmer jobs?? 😂😂 As if some token parser will replace me .. calling a token parser an AI is in and itself fraud and a warcrime
It doesn't take a genius to realize why hasn't software speed scaled up in sync with hardware advances. Its business. Why would you need that new RAM or new CPU if your Photoshop can run nearly identical on a ten year old machine?
Well the idea is that you could have many more features in new software, and with new hardware it should be running at the same speed as the simpler software on older hardware. But it’s not. It’s exponentially slower.
@croHDgaming that’s nonsensical for the simple reason that it’s in a companies best interest to provide a good user experience. The hardware manufacturers are not in bed with photoshop to sell better hardware...
I don't quite understand the argument of Photoshop being slow to view an image. For one you're using a large Photo Editing suite to "view" an image so of course it'll be a bit slower starting up as it has to load ALL those tools in prep of what most people use PhotoShop for. If the real problem is that Photoshop became the default Image viewer then you simply clicked 'ok' to allow it and need to switch that out in your OS. The reasoning behind the invention of your new language was still a bit confusing as to the actual TRUE benefits of it over say Cpp in another Engine, such as UE. I like that it has more of a dynamic type system, but that has proven to introduce a whole new set of issues that has shown in the industry. I enjoyed the talk though and I do appreciate the work and knowledge from Johnathan Blow, the guy is truly brilliant.
7 seconds is not "a bit slow". It is a REALLY long time on a modern computer. I can't phantom why any image editor need that much time to start up - even it loads all its tools (which probably could be lazy initialized or similar). The real problem is modern software developers not respecting their customers' time, productivity and power consumption.
Photoshop was a good analogy he made. He could have also used internet browsers. Prior to Google Chrome most browsers, like Firefox took a minute (a literal 60 secs) to popup . That's just bad coding. Of course, with Chrome, you saw Firefox and many others were forced to look to write better code to streamline the load up process. Photoshop, because it has no real competitors, doesn't give a damn about load time.
Core Wavefunction bullshit I used Firefox way before chrome came out, shure it would hang sometimes. Never ever ever a minute or even close to a minute though. Chrome was maybe 20% faster than Firefox, at launch.
@@PregnantSausage Bullshit. Firefox never took a minute to load for me. Stop spreading misinformation. Blow is largely full of shit here. The video is nothing but straw men and ignoring every fact that happens to conflict with his agenda.
@@alvarohigino I feel like you're being disingenuous. If you're not, C++ is not a super set of C, and early on C++ changed the core language. Things like function signatures have slightly different meanings between the two languages. In C void fn() in C++ void fn() Those two things have different meaning. One is describing a function that will exist that may take any number of any arguments, the other is describing a function that takes zero arguments. It is actually not difficult to write C code that absolutely will not compile in C++. Issues with C++ would be things that exist in C like void pointers or macros still existing in C++. Or how integer operations always get promoted to a larger size, or how things decay to a pointer type, so you can't actually return an array without a wrapper like std::array. None of those problems are an issue with the core of the language. But it is a possible pain point when you do more advanced things. If you are being disingenuous; what are you trying to prove with a gotcha? That you don't understand logic, or you don't know what you're talking about?
It boggles my mind why nobody before jonathan thought of making the build process invovles the actual language you compiling CMAK MAKE and all this shenanigans were needless i hope JAI language adopt a syntax that is pretty and human readable like C#, i don't know why languages don't copy C# Clean syntax, writing C# code is just easy on the eye and less frustrating to read
He's not solving any problems with this, just creating something that caters to his personal preference. That's fine if that's what he wants to use, but 95% of developers disagree with his preferences, so this isn't going to be anything more than a personal project.
His mission is to create a language that is as fast or faster than C++ but more enjoyable to work with. The problem he set out to solve is writing fast game code that doesn't make you want to pull your hair out in the process. I personally think he's on the right track with this stuff.
@@michaell9203 It's basically the solution to a problem no one has. I honestly don't see a lot of real game devs (ie. people who actually make games and not arm chair weirdos on the internet) complaining about modern C++. It's actually pretty fucking easy to use.
Someone who wrote a stupid comment on RU-vid, commenting as if he knows who is or isn't a programming guru... He's not qualified to do X because I don't like something else he did is not an argument, try again He's not qualified to tell me how space and time works because he dropped out of school and worked as a patent clerk... would be a ridiculous reason to dismiss the theory of general relativity for example or, you're really bad at drawing so how can I trust you on economics
@@kevinscales Still doesn't change the truth of what I said. I might be a nobody on RU-vid, but he is no programming or game development guru.There are many others that are (Carmack for one)
You seem to be commenting as if him talking about this is offensive to you (or to programming gurus) yet you haven't said why. I don't care who the better programmer is (and don't understand why you care), I care about good ideas vs bad ideas. What is he right about? What is he wrong about? That is what matters. If your only problem is his attitude, then I don't get the complaint, he seems reasonable and passionate, nothing offensive about that.
Am I the only one who gets annoyed with the continued slurping of that water over the mic? I've never known anyone to do that. So distracting and in my view, quite unprofessional.
I don't think it's bad at all. The stage is hot due to the lights and the constant talking makes the throat dry. I'd rather have him drink some water every now and then, instead of him not being able to speak at all.
I didn't mind but i just wish Jon timed it better to take a sip when he completed a thought. Maybe that is what you are trying to say? It seemed he stopped mid-sentence to drink which I can see how some could find that annoying. I just chalk it up to he being a genuine developer and etiquette is therefore not his strong suit.
@@PregnantSausage on the other hand, stopping mid-sentence means you're hanging on his next word, which keeps you engaged... There's a reason trained speakers go slowly with lots of pauses (e.g. Obama).
