I smiled when he mentioned refactoring by letting the compilation breakages tell you what to fix. I do that quite a bit....even major refactors that cause 500+ errors. There's something satisfying about just walking down the error list fixing what the compiler points you to, and watching that error count drop 20 or so at a time.

@Medik_0001

5 ай бұрын

If only C++ compiler errors weren't insane 😂

@youtubeenjoyer1743

4 ай бұрын

@@Medik_0001 only if you overuse templates or many type indirections (they go hand in hand, compounding the compiler errors).

Static typing is indeed very useful for refactoring. This is why all the (successful) dynamic languages are adding ways to add static typing optionally

@rafadydkiemmacha7543

3 жыл бұрын

Is JavaScript unsuccessful?

@chyza2012

3 жыл бұрын

@@rafadydkiemmacha7543 tons of people are moving to typescript

@rafadydkiemmacha7543

3 жыл бұрын

@@chyza2012 tons is probably an exaggeration, but yeah - TypeScript fixes a lot of JavaScript's quirks. I wish TypeScript was smaller though.

@miko007

2 жыл бұрын

@@chyza2012 in fact, tons of people in the industry are fed up with typescript and go back to plain old javascript.

@georgeokello8620

2 жыл бұрын

@@miko007 🤣 please. JavaScript space is creating many tools through low and high end of the stack to make JS have Typescript like properties (import and export modules, flow, etc). Even the IO request response paradigm for calling external APIs was inherited from Typescript async await model (a Microsoft product), which by the way was already embedded in C# which already has that async await model already baked in. NET for years. Other devs are either moving to typescript space or making JS tools by migrating to Rust, Go, WASM and JS space depends on improvement of those tools given how extremely bloated the bundling systems and reading module systems has gotten along with terrible security issues.

Compile By Fire is one of my favourite tricks as well. Some years ago, I was working on a codebase that transmitted certain variables over the air in a particular byte order that was not the same as the host byte order, and that meant that any maths operations on it needed to flip the bytes properly before and after doing the operations. There was a missing byteswap *somewhere* in the system. By changing the name of the variable, the compiler told me all usages of that variable everywhere in any context and let me audit each instance, silence the good ones by fixing the name locally, and eventually find the missing byteswap.

@keokawasaki7833

Жыл бұрын

aye that sounds now nice, and nowadays since IDEs understand the language's AST, you can just ask the IDE to cycle through all the references ^^

@B_dev

Жыл бұрын

compiler? more like ctrl+f's bigger brother

Wow, using the compiler as an extra-safe alternative for find and replace is so meta, I love that tip

@Wyvernnnn

5 ай бұрын

Workarounds like this made him ignore that his IDE has an intellisense with the "show uses" feature on variables that is capable of semantically parsing the code

@henrycoxd450

5 ай бұрын

@@Wyvernnnn It dont work always as it should, and it works even worse for dynamic languages

@paxcoder

2 күн бұрын

@@henrycoxd450 When did it not work for you?

@henrycoxd450

2 күн бұрын

@@paxcoder literally any large enough code base

@paxcoder

2 күн бұрын

@@henrycoxd450 You must be working with larger codebases than I. Or... which language are you using, if you don't mind?

Really good montage, thanks for sharing.

@swifton

3 жыл бұрын

Glad you liked it!

@jaspergunnar1439

2 жыл бұрын

I realize I'm kinda off topic but do anyone know of a good website to stream newly released tv shows online ?

that little define trick was gold!!!

The power of lexical scopes and strong types :) Great refactoring tool, I gotta use that.

3:50 "Every place we use C is gonna be a disaster, right?" Ah... I love that this could be taken out of context. lol

this is my first time hearing, "no troll" (1:02)...i'm definitely stealing this

When I do refactoring I like to make big jumps and not fearing to destroy my system, I avoid trying to keep feeling safe. I use to refactor a lot and include that in my daily routine, I'm always refactoring as soon as I feel the code is ugly. I feel I make much more progress since I started taking this habit. First because you stress the system you designed so you become more familiar with it, and second because it's by taking risks that you become stronger. It's a good way to develop your abstraction skills. You solve problems easier in general.

@elijahbuscho7715

Жыл бұрын

In my view, as long as you can put a box around a chunk of code, isolate the inputs and outputs, and write some tests to verify the behavior remains consistent, you can make as big of jumps as you want in refactoring. Although it sounds to me like what you have been doing with the small jumps may have been missing the big picture of the system? For instance they optimized the local component well, but the best refactoring should have been to move some functionality to a different component or something like that. I reckon small jumps are probably even better than big jumps as long as the small jumps actually take into account making the system as a whole better, and not just the particular component. Does this make sense, or am I off base?

amazing thats taught me a real meaning of refactoring .

Damn that scope trick is insane !

there are similar methods in all languages to encapsulate and alter code in isolation. It does take time to get good at it. There is no better method than just keep programming. I would also say that there is no bound to getting good at the process.

Love the "Ancient Aliens"-like thumbnail.

The compiler IS the debugger lol

congrats on the awesome efficient development of your skills. :)

The problem with python is polymorphic functions. In strongly typed languages like Java you are returning a type or subtype or strongly typed implementation, so their are pretty good guard rails. In python, people can write functions that can return a variety of completely incompatible types, and this is common. Python's type hinting system allows this to be accounted for to some degree.

This man is a genuis

3:40 is absolutely genius. I am certainly using this trick next time I refactor.

I would love to see J Blow works with John Carmack

Try this in Basic: "oH HeY, LoOkS LiKe yOu mIsTyPeD A VaRiAbLe nAmE. LeT Me aUtO-dEcLaRe tHaT As a nEw vArIaBlE FoR YoU!"

@SaHaRaSquad

3 жыл бұрын

I mean it's the same in Python and others too, they just don't care and you end up with an error in the middle of some 15 minute processing task because it hit some if-else for the first time and crashed. Meanwhile in JavaScript it might not even crash but just throw an error and continue with an "undefined" instead of a floating point number and you wonder why it behaves to weird.

@tassaron

3 жыл бұрын

@@SaHaRaSquad that would raise a NameError in Python

@SaHaRaSquad

3 жыл бұрын

@@tassaron You haven't yet written a sufficiently large Python program then. I worked with database import scripts and online backends written in Python, and I've seen dozens of crashes because Python doesn't check a lot of things before execution. Sure, it'll catch typos but not that much more. Compared to newer tech like Rust's compiler which can make 100% sure all pointer accesses are valid and threads cannot cause data races languages like Python look like toys. In that space the only usable and widely supported language is TypeScript imho. It's what JS should have been from the beginning.

I am surprised more people weren’t aware of this. It became completely apparent that this was powerful when I first started using statically typed languages.

@jofla

2 күн бұрын

I think it's targeted to complete beginners

you definitely need more tests (or use an optional type checker) for languages like python if you want to be able to do refactoring . It's not as convenient and fast turn around as using a statically typed language compiler to do it. It's a trade off between the flexibility of more dynamic expressions and the fact that you have to write tests for stuff that a compiler otherwise would have given you for free. As a contractor I get a lot of jobs where I make a custom web site for a customer in a few weeks where dynamically typed languages and no tests at all helps me do very fast but if the projects are at least 6-12 months in length I might start looking at languages that offers more safety and help long term maintainability.

@Kenbomp

3 жыл бұрын

And don't forget static types make for great documentation

@pleggli

3 жыл бұрын

@@Kenbomp > static types make for great documentation Some times but when you have like 5-10 overloads with different arguments for many of your functions it starts to not be that good of a documentation. In a dynamically typed you can focus on one signature with a smaller number of arguments in total which also makes it easier to understand what the function does. Actual written documentation usually wins over plain type information anyway.

@dealloc

3 жыл бұрын

You should have tests even with static typing. Static typing doesn't guarantee that your results are correct, only that the data has the correct structure or contract. Having both will greatly improve confidence that changes won't cause havoc.

@pleggli

3 жыл бұрын

​@@dealloc I wrote "more tests" which from my experience is true when it comes to dynamically typed languages. I was not suggesting that you should ever have no tests if you want reliable code but often doing the kind of refactoring that Jon talks about is very possible guided solely on compiler errors. Since refactoring does not introduce any new functionality I believe that it is more suited to being guided by compiler errors than many other types of development, you just have to have a good plan for how you tackle the problem.

Good montage! Smart and generous guy! How does he work, live stream and talk and be productive?

@lm1338

3 жыл бұрын

He pretty much does mini Q&As in between focused work

@lm1338

3 жыл бұрын

Yeah actually this was very nice. I'm pretty sure this was when the Michael Reeves raid happened, so there were just a lot of young programmers in the chat who probably still instinctively thought stuff like python and javascript are good ideas (and they were watching Michael do Lua stuff) because there are no scary type names and memory pointers, so Jon gave very beginner friendly explanations of how to approach more complicated programs in a more reasonable way.

@swifton

3 жыл бұрын

@@lm1338 Yes, it was Programsgiving. Btw, I couldn't find Michael's VOD from that day. Was he doing something with the Open Computers mod?

The concept of refactoring (both math and in programming) with a direction or goal is a great point I never would've known. Why do I refactor in the direction that I do? Well... I'm just winging it aren't I lol

Powershell has one of the easiest to use optional typing systems, and I badly wish Javascript could inherit or borrow it somehow.

Reeeeeeeeeeee

Does optional types in Python prevent this? I have mainly worked with statically typed languages, and my go to refactoring safety net is using compiler to make sure I didn't break anything. But am doing some more python work and miss that safety net.

@swifton

3 жыл бұрын

I was actually planning to look into that this month. Some of my friends say that several pretty good type checkers for Python were made recently. I don't know if there is a sane way to open a new scope right after closing one, though. If you are interested, I will let you know what I find out.

@ioanbotez7128

3 жыл бұрын

If you use vscode as for editor, PyLance does that and a lot more cool stuff for you. But IMO, for any kind of refactoring, even in statically typed languages, you must have a great test suite. I'm kinda surprised he doesn't mention it at all...

@trugate

3 жыл бұрын

Type checking is only part of the safety net in refactoring things in general and in Python, and is a bit of a straw-man built up within this context. There are types, there are structural, chronological changes in refactoring, there is references to code or functions/methods that have been renamed or no longer exist, etc. Typing matters, sure, but that's not all there is to refactoring. If you feel lost, using a decent IDE like Pycharm can help point things out for you. Or a decent linter/debugger, if you're not an IDE person. I have used Pycharm professionally for eight years now, and it makes most of these refactoring issues mentioned a non-issue. Having said that, you can definitely do some great typing with recent Python releases. If you're interested, bring it up on the larger python discords or similar communities. Depending on what you're trying to accomplish or the type of workflow you have/are used to, I am sure there is something to fit the bill. Good luck!

@defeqel6537

3 жыл бұрын

@@ioanbotez7128 Types definitely make refactoring easier, as shown in the video, but I agree that tests are absolutely needed (not necessarily unit tests). I've more and more gone into the TDD mindset, of first creating a test or few and then implementing things messily and quickly, and once I have a better grasp on the problem, I refactor for performance and/or readability. The tricky part there is isolating a big enough chunk of code to test, but small enough to manage the state of in a readable way, and defining a flexible enough interface that it does not impede refactoring. I've come to loathe micro tests (my terminology for unit tests for very small parts of code, especially non-generic code).

@okaravan

3 жыл бұрын

@@defeqel6537 Tests are expensive. Without them you are working 3-4 times faster, and you can make big architectural changes if needed.

He did algebra in grade school? In which state did he grow up?

Going back and forward is progress if you learn, to truly understand problems which create your solution you need to implement it😄 I think people with huge experience worget that sometimes 🤔

If you want more information on refactoring and safe transformations of code, I highly recommend reading Refactoring by Martin Fowler (who also happens to be the inventor of the term "refactoring")

@robrucki6695

Жыл бұрын

I was looking at this book but I think it's tied too closely to OOP

@sprinklehomie5811

11 ай бұрын

@@robrucki6695Read it anyway, having more insights only makes you more able to come up with better answers to a problem

You can do this in Typescript too! If I ever had to write plain JS again, without the ability to track down compiler errors with all the Typescript goodness, I would be bald.

@codesymphony

2 күн бұрын

yeah and f2 button

6:25 yes that is tought when solving systems of linear equations

I had the same exact experience with algebra in school

@AutoFirePad

Жыл бұрын

Didn't your teachers told you about the range of the system's matrix?

Omg! all those nested if/else looks scary :)

Just because your statically typed program compiles after a refactoring it doesn't mean that it works again.

The key takeaway here is that story in the end.

When you feel like you don't need refactoring you probably need to desperately refactor.

I do large refactoring in lua pretty often. Changing interfaces of classes etc, which has effects that trickles down in the code base. Even though something touches hundreds of files, it is never the language that is the hard part of the refactoring. I find that the game breaks immediately if interfaces don’t match or wrong data type winds up in a variable. I basically do the same as… just hot reloading/recompiling the code which finds me error after error until I’ve gone through all the places. Hot reloading takes less than a second, which helps of course. A couple of times I need full restarts of the game. IMHO, the hard part in refactoring is when your refactoring is altering some core logic/behavior. Those are hard regardless of language because they require testing that the actual game behaves identically as it did before the change.

@u9vata

Жыл бұрын

The issue is with YOUR method compared to what Jon Blow do here is that in the dynamic language case you never find bungs that are not on the code path that you are testing. This basically - potentionally - makes you need to totally test all of your software all the time. For example lets say you have a branch that is taken only on a specific map - will you all the time go for that map and test it or will you have x% chance of totally forgetting about it and find it out ages later? We all know the anser ...

@zulupox

Жыл бұрын

@@u9vata No, not really, that isn't a problem. You just do free-text searching for all interfaces in the entire project to find all instances you need to fix. It can be scary initially for programmers used to only coding in C++ for example. But yes, we do run automatic testing for all entities and levels, so yeah. Something missed will be found pretty much immediately. I just find the power of lua when it comes to speed of development and iteration makes it worth it. I guess it depends what coding standard you have also. Since in a dynamic language you can do some pretty trippy things. We don't allow "smart" hacks in our code.

@u9vata

Жыл бұрын

@@zulupox This is again ages slower this way: you do a text search and you find the first few results where that type is used. Then see what other functions it calls, then you start looking there - and so on. All of these are much slower than static compile time checking. Also running unit tests are slower than a compiler running (in any kind of reasonably big enough system with enough coverage). What I find is that you likely mean much less by a "heavy refactor" than I do and likely you already "self-enforce" to not do all refactors so you not feel the pain and not realize the issue. Lets say a heavy refactor that once I did: in around a 400kloc code we changed how the component model worked in a realtime plugin based system - also changed how threading model works. We planned this, and could do it type safe - also semi-automated the work with vim scripts (not full automation! semi automation) and incremental builds catched errors because we kept the old system and the new got added and we only moved one component at a time and this was applied to around 50-60 of those plugin components. That is already a too much overbloated system btw - John Blow would disapprove it exists. Yet tooling really made it possible to make this refactor in a single day and knowing that we did not fuck up - can you do that in a dynamic language? I doubt so. Also at that scale most projects already have heavy doubts how well test are - I mean even if you have "coverage" the quality of individual tests might not suffice all cases still...

@zulupox

Жыл бұрын

@@u9vata Ohh, I agree it isn't as easy to do as in a statically compiled language. I just say that it isn't _that_ much harder to do in lua, you have to be more careful. I've worked in this engine, several lua/C++ projects the last 10 years. And I've done more refactors than I can count during this time. The code base for current game I'm working on is now around 1.2 million lines of lua code. (not pure code ofc, lots of it is settings files etc). Then there are similar amounts of engine C++ code, but there is a clear separation between these.

@u9vata

Жыл бұрын

@@zulupox 1.2 million lines of lua also sounds really bad. I mean unless there is not really that much, but like a system where a script is pretty much like an "app" or something really specific and you just have endless much of those. 500kloc in my more modern opinion is some sign of bad code bloat already (in any language) unless you write a kernel or something - compared to back then when I was "okay" routinely indulging 1mloc or 500kloc codebases I consider things already bad when this happens too routinely, but yes, it happens. I also agree that "non-smart-search" can lead to better results than most people think, yet my point was that static types just help more and that is factual and that's it. But for example one can do little vim scripts that "find the usage, see what functions use it further and also go into them" via combinations of global, substitute and macro and some other things. As I said I prefer not full automation, but semi-automation in these cases and just stepping through where possible positives are (can be false positive) and first manually just adding a "mark comment" there, and proceed only searching from marks and stepping through the refactor that way when I need to force myself working in a dynamically typed environment. But I find it nearly always sub-par to what is possible with proper types. Also lets say I change a type and want to find its occurences... that can grow near impossible to do fast in that environment... I mean lets imagine the type previously could have a "start transaction" and an "end transaction", but now we refactor it to "end transaction" have an optional extra parameter and I want to see where I should use that extra feature now with the new system. I mean I know that the "default" will be ok for most cases, but not in all cases so want to see where. Basically no chance... you can run endless testing of all code paths - and coverage should cover not just all functions, but all random branches of all functions - then lets hope people not do something like javascript eval and build some code up on the fly or load it from a text file from some database that is not in the code repository but somewhere else... etc... It can so easily go out of control in endless ways. So just to keep at that shit example: for some shit reason dynamic type fans from time to time pretend its a good idea to take field names as text file input from config file and such idiocy for telling what fields to modify. I saw this happening even in cases where they supposedly have "heavy code review process in place" - so I just grew to not trusting the code if its dynamic. Its like "if it works its fine, but I can say no guarantees :-("

I don't get this technique, what should I search to learn this? by the way, such good comparison of equation substitution with refactoring at the end

@lepidoptera9337

5 ай бұрын

You don't have to learn anything. Every time you rename a statically typed variable the compiler will tell you that it can't find the (old) declaration when you compile. Then you fix all the "bugs" by changing the name of the variable in the code and you are done. The reason why you can't do this in a dynamic language is because the interpreter will simply create a new variable with the old name, so now you got the new and the old around and your goose is cooked.

@dumbfailurekms

5 ай бұрын

@@lepidoptera9337 Fuck bro I'm dumb as hell can you help me out here c defined in outer scope of proper type { float c; //100 lines of code } Now it's going to give error because its the wrong type and you can go through and fix them The reason this wouldn't work in javascript is because the new variable c won't throw a type error? Is that right?? Like in javascript it would be c defined in outer scope that holds the proper data { var c; //100 lines of code } the new var c wont even through a type error it'll just try to run the code with it? Is that right? i know it's simple but for some reason my brain is struggling But it would work in typescript if you set up your functions to accept a specific type? Just want to make sure i got it right..thanks

@lepidoptera9337

5 ай бұрын

@@dumbfailurekms Sounds about right. I would advise to use some stronger naming and scoping for variables anyway. I keep all the important state variables in one location and in one global struct that is usually called g. Every time I access g it looks like g.something or g->something in the code. That is a 100% indication that something important is happening that will have severe consequences for the user if it goes wrong (because it concerns the long term state of the program). My local variables are usually index variable names like i,j,k or scratch variables like x and I don't use them outside of a loop or, at most, a short function. If it's not important, don't name the horse. You may have to eat it. This also leads to "state sparsity". If your global g has a thousand entries, then you know that something is fundamentally wrong with your architecture. Nobody needs a program that has O(n^1000) different configurations. There is no possible test suite in the multiverse that can cover that space. If you are pushing 100, then it's time to rethink what you are doing (or you are in a problem class that requires a multi-threaded approach, anyway, like a server or browser).

I'm glad I'm writing tests to fixate my assumptions about a system

Code that you won't be changing in the future is unicorn

5:00 In every python project I work on, this issue is solved by mypy. Sure, an old python 2.7 code base may be a nightmare, but in most modern python projects this really is not an issue anymore. Still, mypy is not perfect, so I just migrate new projects to statically typed languages.

automated tests give you the exact same refactoring experience in dynamically typed languages. of course it's more work to write tests than just stating types, but tests 1. are more flexible, because you can choose how much of them do u write 2. can check constraints, which are way beyond in complexity what most type systems can express

@chyza2012

8 ай бұрын

Nobody stops you from writing tests in a statically typed language, you can check all the constrains you want, the second point is completely irrelevant. And the first point is not really saying anything, yeah you can choose to not check types, but if I'm arguing for types then telling me I can choose to not have them isn't gonna convince me. Also if you really want to not have types you can just opt for void*, but void pointers are like the biggest criticism of c exactly because there's zero type checking around them

@lepidoptera9337

5 ай бұрын

If you are writing code that relies on type, then using a dynamic language was your first and primal mistake. You can't recover from that with any tools or any amount of effort.

@0netom

5 ай бұрын

@@lepidoptera9337 what does "relies on type" mean? how do u decide when should u write code which "relies on type"? i also have the impression, it's sometimes preferable to write code that way, but im not sure how describe the conditions for it.

@lepidoptera9337

5 ай бұрын

@@0netom "Rely" as in "reliability". If your software needs to have 100% uptime and be free of critical bugs that can throw interpreter errors at runtime (which tends to happen in my experience unless I guard everything with "try... except" in Python for instance) a statically typed language like C is the much better choice. In C I can handle every possible type and range error at compile time. I write plenty of code for which this doesn't matter (like Python test code) but production code that ships to the user can not be like that. It has to be "correct by design" wherever that it possible.

@tiranito2834

2 ай бұрын

@@0netom relying on type means what the words "rely", "on" and "type" mean, but put together. Let me elaborate in case you are having a hard time following this very simple concept... if your code's functionality being well defined and working properly under all circumstances requires the data used to always be of the same type... then, why did you even choose a dynamic language in the first place? that is, if your code is incapable of translating what you just gave to it to something it can reliably work with without causing errors all on its own, then using a dynamically typed language didn't help you at all and simply made it easier to get errors because it did not enforce that type that you actually required for the code to work properly in the first place... that is what statically typed languages offer. At the end of the day, your computer only understands 0s and 1s, there are no "types". All types do is define HOW the computer works with those 0s and 1s. And if you give your program a bunch of 0s and 1s and you expect it to do something with it and then it does something completely different, then you have a problem where the computer simply doesn't deal with the data that you're giving to it in the way that it should... at the end of the day, dynamically typed languages simply offer a quick and dirty solution to lazy people who don't want to make sure that their variables hold one type of data and their program does one thing correctly.

I am not sure if this technique works well in C++. I sure use it in Rust though. I change an API, fix all the compiler errors and it works.

Refactoring is also necessary for performance. You change/refactor the implementation but the interface of the library remains the same. In that case refactoring is absolutely not "a waste of time".

I haven't really thought of compile errors this way, even though I benefit from exactly that mechanism on occasion. It seems I generally view errors as evidence of my mistakes, which might have blinded me to a more reasonable viewpoint of viewing all mechanisms as tools at my disposal. The 'intended way' of use (learned or guessed) might be mostly irrelevant, and can stop me from exploiting the full potential of tools. Thank you for the montage, by the way. Jonathan might have a lot of wisdom, but I am not particularly interested in watching streams or recordings thereof, and shorter excerpts like this allow to more effectively look-up bits of information I am interested in.

1:45 *tugs at collar*

Python is good if you annotate your types. It's strictly typed which is different from whatever the fuck Lua and JavaScript are supposed to do. I loved the thing where you introduced the compile error by removing/changing the type of c... I do that a lot in C++ and C# alike.

Watched a dozend of Jonathan Blows videos now, nice to hear that he is not smarter then me, cause all the things i already know and apply to my work. Maybe has to do because we have almost same history from the good old glory days of Home Computer game programming to independent software vendor today.

@RalphScott-wu8ei

8 ай бұрын

Have you made a successful indie game?

I don't know about Lua, but there are tools for static analysis in languages like Python and even JavaScript. You can absolutely use these tools to help you safely refactor with as much certainty of correctness as you'd get from a C++ compiler.

But in dynamic typed languages can't you just rename the variable in declaration?

I thought Jon does not use templates and classes. I see them it code, though. What a shock!

The renaming c variable can be very easily done with C# tools like resharper that actually parse the code. I guess VS now has that as well. I will never be able to understand why that's not the norm in all development environments because it's such a dumb thing for this to cause any inconvenience.

@casperes0912

3 жыл бұрын

There are tools to do this in most IDEs. For me it's usually set up so if I select a variable and hit ctrl+shift+F12 I get a rename everywhere option

@seidenada526

3 жыл бұрын

Some languages are so dynamic (or so meta, hello c++ templates) that just parsing the code would not be enough to guarantee a successful rename (indirect access can happen). That’s what I think he meant, by using the compiler you can be sure again.

@naxaes7889

3 жыл бұрын

To me, it hasn't really worked that well. I often use it to change a variable in a single function or maybe a small file, but any more than that usually causes problem. Sometimes it finds unrelated variables in library code and changes them or do something stupid like that. Instead, I just copy the name to the clipboard and the do a search for the variable to change. Then I step through the search results and paste in the new variable name. This also lets me verify that everything is still nicely aligned, doesn't exceed the character limit for the line and just that everything makes sense in each context.

@CsharpPreza

2 жыл бұрын

@@naxaes7889 Oh that's weird. I use it on the daily. It fails to notice the difference between value types and reference types, but other than that, I'm happy with it and I would hate having to go back to renaming things myself.

@magnusanderson6681

Жыл бұрын

I suppose the intended use is not a simple variable rename but something like where you have one new variable that does mostly all the same stuff as the old variable because you're actually doing meaningful refactoring and not just a rename.

My humble opinion on this is as such: if what you are doing isn't making technical debt bigger, probably you shouldn't change it. Refactor when the team has some free resources. If something is causing a bug, its a different story obviously. Cheers!

U can do typing in python

what programming language is this?

@swifton

11 ай бұрын

That's the language he's developing because he doesn't want to program c++ anymore. Everyone calls it Jai, but Jon tends to call it "this language". So probably the official name will come later.

**code is horriffic** >spends 1 day refactoring **code is horriffic, but with no c**

The tip around the 4 minute mark... I think your IDE is letting you down, rename works perfectly for me always

Refactoring Python code in a large codebase is a fucking nightmare.

I don't know why YT keeps recommending these Jonathan Blow videos to me. The thing with using the compiler to make a list of things to update was really clever, but some of the other stuff makes him sound like Coding Yoda.

@wookiefurball6726

Жыл бұрын

Bug you find, refactor you must!

The find n replace thing, I'm surprised this is even needed as im used to intellij which is really good at renaming stuff en-mass. do you guys who are not using java not have that functionality in your IDEs? that must make life so hard

@tiranito2834

2 ай бұрын

any IDE with intellisense or whatever is capable of doing that automatically... for any language that it has support for. If either a) you're not using an IDE or b) you're using a language for which intellisense has not support, then what are you supposed to do? Sure, you could half ass it by lying and picking a similar enough language during editing, but that is not as reliable as actually properly making sure that everything has been refactored. Also, intellisense and other such things slow down the typing speed by a lot. I don't know about you, but everyone I know that uses any IDE with support for that kind of refactoring complains about how slowly the text appears. The delay between pressing the key and seeing the text appear is too jarring for fast typists. And waiting for for 5 minutes for a beefy computer to parse through all the code because the people who programmed intellisense don't know how to write code for shit is not really the coding experience most people want... from our point of view, your fancy IDE makes life harder when all I want to do is edit text.

@techforserious60

2 ай бұрын

@@tiranito2834 I've never really met anyone who has had issues with how fast text loads in an IDE myself. I don't think text loading speed and fast typing have any significance really, because the vast majority of the time you are developing something is not spent coding, but reading and thinking. The amount of time saved with a refactoring text edit taking 0.5s instead of 5s will have no major effect on the amount of time you spend coding. If you've spent 8 hours coding vs 8 hours and 4.5 seconds, it's the same. Being a fast typist doesn't make you any better of a developer too, that may be an instance of the illusion of progress as I call it. Better to be someone who develops with a sense of caution and attention to detail, than to be someone who is trying to speed through the work as quickly as possible. That won't get you anywhere

4:30 Not this time. TypeScript to the rescue.

Dr. No!!!

6:04 LOL. Your teachers knew it. It is basic math knwoledge. If you end up substituting indefinetly when you match constrains and variables, you are doing something wrong. THERE IS ONLY ONE KING.

3:54 Instead of float you should you use something an "empty" class like " struct Empty{}; Empty c;", because float is still a widely used data type specially at low level, but empty class with no method(operations) and no data cannot used to "compute" anything.

@cdamerius2895

Ай бұрын

Agree. After learning that I tend to do struct{}c; all the time.

just comment out c. thats just common sense. but all ides can rename a variable automatically.

this is a subset of a problem called subset combinatorics

@Jkauppa

3 жыл бұрын

if you can reuse, it will stay so

@Jkauppa

3 жыл бұрын

think like you ar writing libraries, then using them in the most top layer, or middle layers

well, thx for sharing, I'll use this everytime when someone tells me how great python (or whatever) is.

@carlossegura403

3 жыл бұрын

Python is excellent, and yes, there's a package for that - you can optionally install a static type checker ‘mypy.’ I use it along with the vs-code extension, and it works great for larger projects. Also, idk you are a game dev, but Python is not for building games.

@GonziHere

3 жыл бұрын

@@carlossegura403 I'm curently working mainly in c# and typescript, I have significant experience with c++, PHP and javascript among others. The thing that was annoying me by far the most in my career was typelessness. The hardest bugs that took the longest time to find were almost always type-related... which is why I've always hated javascript but I love typescript = the same language, just with types... To add to it, he was talking about the ability to rename something, to break the type to find errors, etc. and that you can be sure that it's not broken afterward ;) And to reply to your last line, Unreal now has experimental python support (as in scripting language), same goes for several other engines and scripting langs in general are heavily used by game designers (action script, lua, godot script). You write your engine and your systems in c++, you write your game in scripting languages, including python.

@carlossegura403

3 жыл бұрын

@@GonziHere Thanks for the additional info; it is nice to know unreal is experimenting with python. I will surely check it out!

It's too bad something like Resharper doesn't exist in other languages.

Trick use Visual assists “rename”

You could just use refactoring tools inside of Visual Studio, this seems on the level of console log to see how far your code has gone.

The first 60 seconds he took the words out of my mouth. When I refactor something, my IDE tells me exactly what I need to update, and exactly where it is. All of it. I don't like JavaScript (I'll take TypeScript), I don't like LUA, I don't like languages that aren't strongly Typed. Bugfixing them is so much more tedious, and they're far easier to break. The moment you start coding it already feels brittle. Loosely Typed languages don't feel like they offer any significant benefit to me personally. It isn't hard to manage Types.

refactoring python at the moment :/

This is the exact reason why I don't like Python. It's good for POCs or very small projects, but it doesn't scale well at all. Especially in a project involving multiple developers where no single person knows the entirety of the codebase.

During a refactor, it is possible to shoot yourself in the foot! so u have to be careful before u go change things so quickly, no matter how shit the code is, it could get worse. then the project doesnt finish.

@lepidoptera9337

5 ай бұрын

If your dependencies are already so messed up that you can't do this, then you are better off to start over with a clean design anyway.

if you keep things small, you never even have to learn this stuff. Is there such a need for huge programs? not all the time.

An under-appreciated feature of TypeScript is that it's going to yell at you about the type errors, but you can still transpile (= remove the type information) and run the code. While I find it valuable to see all those type errors, it's also very valuable to be able to run the program despite the type errors. Most of the statically typed languages won't give you this freedom of experimenting with the code.

How does he looks so much like Andrew Tate

Line 965 ? Dude, the problem is that your component is too big. Get a refactoring tool e.g. Resharper.

Why not use the editor to edit instead of switching back and forth? These command line guys will never be able to get away from it.

I have a better idea... you don't name a variable just c, either you find a name that permits to identify it as a human or as a unique name. Either float numberOfRowsForArray or c1. This way you can use any IDE to find the var in all files thanks to the unique name and replace all occurences. EDIT: Just checked, you can do it with F2 in vscode Create an object in any language you want, create a global var c outside of the object, create a method with local c var and create a c attribute too. Now in the local method, do something with the c var, the c attribute var etc... Select the c you want to change by underlining it, press f2, now you can change the var name and it will change it everywhere in the document, matching exactly the context, so the local c var will change too in the method, as well as the attribute etc... example in typescript : export const c = 30; // select c + F2 + Rename + Tap Enter => will change the c inside globalTest method export class testObject{ private c: boolean = true; // select c + F2 + rename => will change name of attribute in test method public async test(c: string){ // again select + F2 => renaming c here will change only c inside the function. also renaming the global var won't change c here. console.log(c); // local c console.log(this.c); // attribute c } public globalTest(){ console.log(c) // global c } }

Seems super hacky advice compared to the tools you have with C# and Rider. Alt-Enter and Shift-F6 for the win!

The purpose of refactoring is to facilitate inclusion of changes in the behaviour of a system throught modifications in its structure that don't affect its behavior. If you are not making any progress then maybe you are refactoring for the wrong reasons??

Or you can write unit tests before you refactor, so you know you didn't break your code.

@Viewsk8

3 жыл бұрын

He has a vid on unit testing too... he doesn’t like it

@naxaes7889

3 жыл бұрын

His view on unit tests is that it's double the code to write and maintain, and not that useful as programs are often changing.

@SaHaRaSquad

3 жыл бұрын

And if you actually try that you'll realise that sometimes the code will break in ways your unit tests did not anticipate. Which doesn't mean unit tests are useless, it's just not wise to rely on them too much. My approach is usually to only test the cases I'm unsure about as well as the inputs that caused a newly discovered bug, so I can make sure the bug is fixed and also stays fixed in the future.

if you want to be successful in the games industry implement your own programming language and ignore any developments in the last decade such as language servers with linters for literally any type "unsafe" language

@scottlee600

2 жыл бұрын

Lol Language servers are trash.

Good points, but he doesn't take into account the fact that dynamic languages typically require less refactoring. So the fact that refactoring is easier in typed languages doesn't by itself suggest they are more productive.

@Isak62

Жыл бұрын

@@someguy2016 Yup. An example would be code interacting with the database. Say you then change bigints to ints in a lot of your tables. Do you see why that would typically require a lot of changes with typed languages, but few or none in dynamic languages?

Well not true about python, it has type hints, however you're not forced to use it ;) : www.python.org/dev/peps/pep-0484/

ah yes, the "static typed languages catch your errors" trope. As if writing tests doesn't do the same damn thing

Hahah! I love you Jon, but you can totally do the same concept in Python, you just break things in different ways. I was thinking, hey I do that exact strategy (if my IDE can't intelligently do it for me, which it normally does), and then he starts bashing on Python and dynamic languages. Yes Jon, if you can't program in an experienced manner with whatever language you're using, and don't know how to work well within it, then yes, refactoring is harder - regardless of what language or style of language that it is. I'm sure I would find large refactors in C very difficult, since I haven't done it before, and it's very different than Python or say, Haxe. Okay, back off my soap box, I agree with everything else. :)

@object_name

3 жыл бұрын

Hey, im not good in python so maybe i just don't know how, but would you share how you would refactor something like this in any dynamicly typed language? Let say you just want to change the input parameter to an object in this simple function, and you forget to change a calculation in the middle of the function. // // C++ // int old( int a = 5) { a = a * 2; return a; } struct foo {int a;int b;}; int refactored(foo a = {.a=5, .b=1}) { a = a * 2; //

@trugate

3 жыл бұрын

​@@object_name In your specific example, I would have implemented the __mul__ dunder method on the object that is replacing integers, then it would not have broken. If I am creating an object that takes the place of an integer, I should know that I am doing that, and make it walk and talk like an integer. Not that you're stating it, but to clarify, I never claimed either of these things: "python has static typing" or that "typing is never an issue in python". This is more a great example of trying to use one tool as another tool is designed. Without the underlying __mul__ method implemented on your new object, the program would crash when you run it (hopefully before you put it into production! ;), and you'd get an error that described the issue. >>> class A: ... pass ... >>> a = A() >>> a = a * 2 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for *: 'A' and 'int' Every language has some form of benefit over another language. Saying all dynamic languages are inferior, as Jon likes to do, because of "no static typing" is looking at one tiny slice of what the compared languages bring to the table. No, it is not a statically typed language. Is that the end of the conversation? It probably shouldn't be. If I am used to using a hammer, and I go to use a wrench as a hammer, is it the wrench's fault? Should all tools be hammers?

@object_name

3 жыл бұрын

@@trugate Hey, thanks for the answer. If i understood you correctly though that specific code has to be executed/tested to fail right? Like if it is buried in if-statements (wich is obviously not good practice) it would likely stay unnoticed, right? Yes, there are benefits and downsides. The question at hand is do the benefits overweight the downsides. Probably everyone has to define that for himself, but if you have thought about it for a while, i think the next time someone asks you what language you would propose to use for "Project X", you might have a more definitive answer.

@trugate

3 жыл бұрын

@@object_name Again, type-related errors at runtime are only one type of error. I'm sure you are not trying to say that static typing removes every kind of issue at runtime! :) Otherwise, static typing would be the holy grail, because there would be zero bugs ever, and type issues would be the only type of human-based error that makes it into a program. Having said all of this: I am using Python to make a game, it is a non-trivial project. I use it for larger (> 30k lines of non-boiler plate code) projects professionally. Type errors are probably... 0.1%? Of my problems ever? And certainly a non-issue in refactoring and maintaining these large projects. This is made to look much more important than it actually is. Having said that, in the last two or so years, I like to declare my types. There are good tools out there, and IDE's like Pycharm and other things (even linters) can catch me doing things I shouldn't be. Again, it is rare that it catches me personally, because the tool shapes the person, to a degree, and I have used Python for quite a while. This is why I want to make it clear, I am not saying "don't type check or do static typing" - if you can do it, do it, sure. It can stop you from doing dumb things. If you're used to relying on it to stop you from writing code in certain ways, or to force you to write code in other ways, then cool! I am not going to criticize you for it.

@object_name

3 жыл бұрын

​@@trugate To your first sentence : Have you heard of elm? That is pretty much their claim, achieved through the functional paradigm + strict typing :D. My actual biggest point against loose typing is, the self documentation. But i am very likely heavily biased by having started programming with a book a compiler and some example codes, wich i had to understand in order to learn from. And whenever i for example use a javascript library (or look at a coworkers code) and want to learn about a function it provides i cannot look into its sourcecode and know what it does, even if it is not minified because it does not say anywhere what it expects the variables to be. Like is this "color" a string or an integer, or is both possible... Well i am not here to make your day bad, so i think i should stop here. I am just trying to understand why other people like to work with theses languages. My answer so far => it is just random, and whatever language made you understand programming, will influence your preference, not rational reasoning like "i just can do x y z" that is why i like it, sadly. (wich actually the case for me too, i never put up a list of pro and cons for every language i came accross and then evaluated, wich language i should use)

Instead of having extremely huge functions that do a lot of things with a hundred different variables, you should try to break down code into smaller functions. You way you won't need obscure tricks when trying to change a variable name or something more mundane.

@MidnightSt

Жыл бұрын

that's a nonsensical advice, especially when you give it like this, without any context. if a task can't be divided into logically separate smaller units, why would you try to divide it into smaller functions? that's how you end up with a set of task_part_1(); task_part_2(); task_part_3(); //etc which make no sense and break unless you call them exactly like that, one after another. I've seen it many times, and I've also done it many times. in a case like that, it's much better to have one large function, because at least it's obvious that it's one complex, undivisible task, and it's not possible in any way to not run the task as a whole.

Static Typing is a premature optimisation. Don't refactor. Rewrite. Ever cut and paste paragraphs in a novel and expect it to remain a decent story?

@etodemerzel2627

3 жыл бұрын

Lol

auto everywhere is fucking disgusting, just looking at a line in this video : auto extra = get_extra_data(interp, ti); is so unreadable.

Um. Python has type checking, if you're using an appropriate toolchain.

@lm1338

3 жыл бұрын

Every time people say that GC or dynamic types are bad, people point out that those can be disabled in their favourite programming languages, but it's never been a strong argument. Language design is nuanced and can be done much more effectively with narrower specifications. A language with good and bad things in it may well be worse in practice than a language with just the good things in it because you have more design freedom as features don't have to worry about interacting with the bad features in an unfavourable way. The culture / default behaviour also matters because inevitably, libraries, coworkers, idiots, are going to use the bad features in code that you want to use. Culture is important in many subtle ways, for example a website to teach someone a language for the first time almost always teaches them all the features in order, which will lead them to think that the people who are good enough programmers to have taken the time and effort to design and implement that language think that using those features are a good way to program, whatever they happen to be. So if a website teaches dynamic types in python or GC in Go/D, new programmers will, by default, accept that those things are probably a good idea. So you want to choose what goes into your language so that people will learn how to write good code in general, rather than having to learn to work around all the cleverness and complexity in your language that isn't effective at solving problems.

@ioanbotez7128

3 жыл бұрын

@@lm1338 then you simply cannot have scripting languages, as static analysis is impossible on those. Also, standards are set and enforced on a group by group basis. I'm pretty sure your code convention is different than Jonathan's, for example, and there's nothing wrong with that. There are far more medium, dev.tos and even books that teach bad programming practices even for "good" languages than there are good ones. It's always the personal responsibility of the developer to keep up to date, and discern good practices, and that's exactly why most software is garbage. The only languages that don't have incompetent programmers are dead languages.

@lm1338

3 жыл бұрын

@@ioanbotez7128 ​ The language that Jon is working on is (among other things) a scripting language with static typechecking and manual memory management. I don't see how "The programmer will always have to be discerning" is a reason to have ineffective paradigms (for your purpose) in the programming languages you use. There is no reason to make programming deliberately worse. To clarify, the "group" in this case is game developers. There may be other groups for whom it's practically useful to have dynamic types, but all I'm arguing is that python is bad for game programming, even though you can disable the features you don't want.

@ioanbotez7128

3 жыл бұрын

@@lm1338 Thanks for clarifying. I'm not fully aware of Jai's feature set, but that sounds pretty impressive. I see your point, and can somewhat agree. I believe the reason you don't see such changes to existing languages is backwards compatibility / fear that developers will drop the language rather than adapt. See the python 2/3 debacle. I think it had mostly to do with language creators not designing for such things from the start/not expecting popularity, then getting locked in by old/bad design choices. And yeah, python for game dev is a terrible idea for a multitude of reasons. Though, imo, static typing is the least of its worries.

@DoctorGester

3 жыл бұрын

@@ioanbotez7128 > then you simply cannot have scripting languages, as static analysis is impossible on those. How is that true? There are statically typed scripting languages, see AngelScript, what's the problem with them? There is no fundamental difference in principle between implementing a dynamically typed and statically typed language.

Use a proper IDE and refactoring tools ffs

@tetramaximum

3 жыл бұрын

I've tried clion (particularly for refactoring) many times and have always given up, because the refactoring is not perfect. And I know no better c++ IDE BTW. Which means that there is no other way than doing everything manually. And it was presented by John in this video.

@SaHaRaSquad

3 жыл бұрын

Make a proper IDE then ffs. Whenever I have to use stuff like intelliJ or Eclipse I feel the urge to go punch a wall. IDEs are like a bloated combination of all possible dev tools, each using the worst default configuration they could come up with.

@AutoFirePad

Жыл бұрын

@@SaHaRaSquad You know you can make your own plugins, don't you?

@axeldaguerre8838

Жыл бұрын

So you trust dev tools, interesting

Bro need to chill with his opinion on scripting languages and refactoring. I do a lot of Cpp, Rust, Python and Typescript. Cpp has the worst LSP and tooling support of all languages. It is unacceptable how bad it is.

@Honken

Ай бұрын

The MS one is horshite. Clangd beats every LSP I've tried in terms of reliability and responsiveness.

The code on screen is really crap. Way too complex and long block of nested if statements. If you had better (or any) structure in your code you wouldn't need that weired redefining a variable in a block thing. Static typing is a crutch for getting away with bad structure.

@32gigs96

3 жыл бұрын

its actually better to do it the way he did. because if you have side effects and mutation + a ton of little functions everywhere things become really hard to understand. carmack wrote about this: see what carmack wrote about "inline code"

@AntimaterieGame

3 жыл бұрын

@@32gigs96 Abstraction is the only really hard thing in programming. Everybody with enough time and google can hack together a 300 line file that does the job. I agree with you that having bad names makes things more confusing but the solution to that is having good names. And ofc complex code should always be pure ie have no side effects. Side effects should be trivial and at the perimeter of your program.

@lopost07

3 жыл бұрын

@@AntimaterieGame If everybody can hack 300 lines to do work, why have 1000k lines of abstractions to do the same? Good abstractions are usefull in the enterpise world with big teams, but Jonthan is basicly making it solo so there is no point making things unnecery convoluted with abstractions.

@AntimaterieGame

3 жыл бұрын

@@lopost07 Actually I evolved a bit on the topic and I think your perspective is correct

@AutoFirePad

Жыл бұрын

​@@lopost07 As a solo programmer, sometimes you forget your main idea when doing those 300 lines. Even with comments is tedious to read it. Of course is different if you just want to make your library NOW and forget. Me compiling: kzread.info/dash/bejne/jKJ-xbxmZbOemKg.html

Bullshit. You can learn to be just as effective at refactoring in Lua as you are in a statically typed language, it's just that the strategies and techniques are different and bashing on dyn languages because the same refactoring techniques don't work there is a red herring. Most people who bash dyn languages haven't written anything serious in them and their dyn lang code is usually terrible and usually shows that they can't even _think_ hi-level. I have written hundreds of KLOC in Lua and probably millions of lines of C by now and all I can say to all dyn lang bashers is: show me the code.

I pity people who write code in C++. Refactoring is unnecessarily torturous.