One Simple Trick to Instantly Improve Your Code - Finishing Tom Scott's FizzBuzz 

You could solve it by making another function fizzBuzzIf that takes a function instead of integers and keep the old one as an adaptor for the new one. That way you keep the simplicity of the old api, while having a new function that satisfies the requirements. I agree that code like this may be harder or more time consuming to write, but it is easier to use and document it this way and I think it pays off in the long run.

Yep, i would've prefered to just have the limit as a separate parameter to the function, but otherwise this isn't bad.

Exactly. If you have to include limit into the ruleset, the much better way would be something like: ruleset = {limit:100, rules:[{number: 3, word: 'Fizz'}, ...]}

Visit #solvemyprogrammingtask

in other languages this is not necessarily a problem because some have more clear and concise ways to organize the data in the same way without the issue you mention. for instance in Lua, you can simply go ruleset.limit = 100 and add your rules like ruleset[1] = {3, "fizz"} and you could even define some other useful values like ruleset.number_key = 1 ruleset.string_key = 2 (though it would be better if these were in some different table, probably the same table you put the function itself in, but just doing this as an example) so you can access it like ruleset[1][ruleset.number_key] as opposed to it being buried a little bit in JSON array hell. this basically accomplishes the same thing you were wanting while still having the advantages of what was shown in the video; it makes the idea of the limit be more exposed, and due to the way Lua works if you iterate in a loop over the table with just integers you will never access limit or number/string_key and by assigning rulesets to indexes like 1 or 2 or 3 you will never accidentally override or access the limit or number/string_key. and doing it in this way also gives you the advantage of keeping the sort of encapsulation shown in the video that keeps limit as apart of the same object but you dont have the issue of stepping on your own toes.

@daemon agree. The solution in the video is a nightmare in TypeScript.

This! Also, extract the function, that given the ruleset and a number returns the string, that corresponds to this number. This function can then be used with the loop, but also with some stream of numbers. (To make this even more functional, create a higher order function, which takes the ruleset as a parameter and produces a function that takes a number and produces the string).

Yes! this code is so bad. Even Toms naive approach is better.

the variables i and j are clear those are common names used in for loops

Does anyone actually bat an eye over single letter variables when their scope is clear by being defined as an iterator in a for loop that is 2 and lo and behold 5 lines of code long? In a longer loop that spans more than fits the screen or is nested with other loops you might have a point but with this complexity and simple scope, why bother?

@@fg786 Readability is very useful when coming back to a code months later trying to change something small enough to not grant a whole rewrite.

yes but what if it doesn't need to ever be updated. you'd end up having wasted time adding a database migration and writing this complex code when Tom's original code worked just fine. imo this video is refactoring prematurely but if you did need to add checks regularly then this would indeed be the way to go

@@matthias916 The whole point is to try to think ahead. If you're told to make some quick code that does the job first try, then do it as simple and intuitively as possible. But if you're told to make code that can be used years into the future, this is one of the best approaches, if not the best.

​@9nikolai you're overcomplicating things. you don't know what's gonna need to change in the future, you can guess, but you don't know. once something needs to be changed you can change it, until then, just leave it as is. if you're changing things before they need to be changed you're just wasting time because that part of code might end up never having to change after all. when you write something, you need to write it in a way such that it can be changed easily when it needs to be, but until it needs to be changed, don't change it. code that is easy to change is maintainable code that can be used for a long time, so if you're required to write code that can be used a long time from now, write it in such a way that it's easy to change

@@matthias916 Except sometimes you do know what needs to be changed in the future. Sometimes it is very obvious that some numbers you're using are just temporary, but you still need to use them. For example, if you need to do a bunch of testing to figure out which numbers to use, then you're gonna have to change them a lot in the beginning, and trust me, it is much easier when you don't have to scan the whole code to find the one bit you need to change. And again, the challenge explicitly states that the point of it is to see if you can think ahead and prepare for change, so you're only wasting time on arguing that "we can't know what will have to change in the future". Besides, the abstracted code can be much easier to reuse for other things by just changing the ruleset. The simple code just checks for whether some numbers are divisible by 3 and/or 5, while the abstracted code is a tool that can check for any factors, and can even be easily adapted to check for prime numbers. At larger scales it is easily the best option for many types of tasks to abstract them. Sure, not every code should be abstracted, especially as it isn't optimised for anything else than versatility, but don't pretend as if an experienced programmer can't tell whether or not it'll be useful.

But having the limit in the first element of array is awful. You should've do smth like config = { limit: 100, ruleset: [...] }. Also you forgot to define variable via const/let/var. Anyway, I think, Tom's version isn't worse at all.

Yeah, this is the problem with trying to come up with fancy abstract solutions for trivial things.

Visit #solvemyprogrammingtask

Be very very careful about "universal rules". And also, regarding that one in particular, give some thought to what "prematurely" means in this context.

This is the worst rule I have ever seen

Absolutely agree on. Getting things to work is more important than being optimal at first and it too doesn't mean being as careless as possible about the code design, just focusing on what matters 😁

Yeah, my solution would have been to do something like (Python, not JS, but...) def fizzbuzz(limit: int, modular_replacements: dict[int, str] | None = None) -> Iterator[str]: if modular_replacements is None: modular_replacements = {3: "Fizz", 5: "Buzz"} for i in range(1, limit+1): output = "" for divisor, replacement in modular_replacements.items(): if i % divisor == 0: output += replacement yield output or str(i) # could replace with print(output or i) if you just wanted to print instead of returning print(*fizzbuzz(100), sep=" ") # would print them all on their own line

also the whole code breaks if someone or something pushes to first place, reordering rules, or anything else. its really fragile piece of code. you should NEVER use fixed key indexes of arrays especially in a "better code" video example :D also the var j = 1 is just triggering. and the lack of optional chaining in this case could really throw some errors in the future. there are so many downsides and overcomplications in this code. i can see myself writing something like this about 5 years ago as a junior and thinking "oh well! thats genius" and now when i look at my old repositories i facepalm myself for the things like this :D :D :D

@@lilelliamy solution would’ve been to use a proper programming language like C, C++, Zig or Rust that has a compiler that can optimize and unroll the structure into a nice jump table. That’s fast all that interpreted stuff is so slow and Python is the slowest. I bet your code is 3 to 5 times slower than the video in this video. Just by the nature of how Python works and how inefficient loops and memory access are in Python.

Thank you. I'm glad to hear.

You are right, an arry not only shouldn't contain different data types, it can't. The "array", he created is in fact a list, containing multiple dictionarys.

@@cahdoge Yea, but the objects contained diffrent keys

@@4lve absolutely! your right that was my first thought. i also wrote a comment. i would prefer something like this: options: { limit: number, rules: [ { word: String, number: Number, }, ], } also i really dont like the fact that he used i = 0 AND j = 1 :D thats triggering me so much. arrays of objects should almost always contain the same "type" of object. also limit itself is not a real rule. you are not checking anything in the loop, you are predefining the length of the loop. thats more like an option or definition of the whole program, not an rule to check the values in my opinion. different usage, different name and location!

This isn't substantially slower (bottleneck is still in logging) but it is more reusable and maintainable. Clarity can be solved with type annotations in typescript or another language. If performance was the bottleneck look into batching print statements with a stream. In most situations clarity and maintainability is more important than pure speed, performance critical areas are very few and far between and need different approaches.

You're absolutely right. However my aim wasn't to create fast code, or the technicalities of using different array values (even though they are important). It was about showcasing how to write code that is as easy for future users to read and modify as possible. Maybe you're right that some might find this approach even more confusing, but I personally think it's quite straight forward. Nonetheless, thanks for taking the time to give your feedback, it's good extra information for higher level coders.

I would argue that it is indeed way too abstract for fizzbuzz. This might help by showing how you can think about abstractions. In most cases though people thend to preemtively try to "guess" future abstraction needs and are actually making it harder to restructure the code when needed. I would argue that it is in most cases better to just have a dumb fizzbuzz like solution and ONLY if there arises a need to tailor your solution to a new extensibility you want to think about an abstraction. Otherwise you will most like have to abstract twice or even worse you're going with the assumptions you made with your earlier abstraction and implement even more confusing solutions. Interestingly enough one most have learned about using abstractions in the first place before seeing where to use them appropriately. I at least learned in my time as a dev to NOT abstract early and would rather throw away my shitty code and let the new requirements design my future changes. Old me will always thank me for this. @@bit-machine

It isn't slower. Realistically the lookup to the ruleset is 1 instruction. And reading a variable is also 1 instruction. There is also the for loop. You literally nested for cycles. The one thing you should strive away from. The instructions for the loop are minimal but they do grow with the size of the ruleset so it's not amazing. So realistically speaking its the same speed unless we go down to nanoseconds. The issue in this "better" code is that you made the function far too generalized. The way scot did it is absolutely fantastic. Realistically speaking nothing to improve upon. And when you need to scale such a function up into 10+ if statements and you are thinking about abstracting it like that i would recommend taking a step back and checking the problem from a wider point of view. Do we need to even generate such a string in the first place. And then if you find a way to avoid it. Compare the 2. Are we making it faster ? Does it cost us more RAM ? Evaluate your target platform. Usually using a tiny bit more RAM at the benefit of CPU speed is a win. TBF I work in embedded dev with the linux kernel. So folks in userspace may look at it differently but this is the way to go about it if we are talking about low level development.

​@@ratelslangen now you introduce typescript to make it more clear after making it less clear...so another overhead. "In most situations clarity and maintainability is more important than pure speed,", that's correct, but my answer clearly focusses on maintainability and readability. Performance is not my main argument. "it is more reusable and maintainable", you stated that, but without any explanaition. I would argue that splitting such a simple logic problem into two areas by abstracting the actual logic is not worth it and hence a bad example for a video called "One Simple Trick to Instantly Improve Your Code". That's my problem with this video. Abstracting is fine when done properly.

I think you're misunderstanding the (constructive) criticism from others. It isn't about having the "most elaborate" or "complex" example. It's about practicality and adequacy. The example should match the practicality of typical circumstances that the solution should be applied. Take the original example of just fizz/buzz. The solution matches the example well. It's enough to demonstrate the importance of clarity + conciseness. This video tries to tackle an arbitrary ruleset. And while the solution does demonstrate the type of abstraction the creator wanted to teach, the example does not suit it very well because the simplicity of it doesn't lend itself to understanding how/when to apply this particular approach. A new programmer might think this solution is better than the original regardless of context, or might be unable to see an opportunity to apply the same logic when faced with a real world situation. In practice, such a solution is more likely to be applicable if you're dealing with a large or non-static config/dataset, or arbitrary user input where any number of rules can apply. And furthermore it's best suited for circumstances where the logic that dictates the structure of a rule is unlikely to change. The video didn't distinguish between future-proofing and overengineering. That's a problem I'm sure many seniors have encountered when dealing with new recruits, which might be why many took issue with the example. If I introduce a new rule that if the number is a factor of 2, output "wazz" and _do not output anything else_ then it's obvious how this solution created a box that an inexperienced programmer may struggle to get out of. In many cases, they'll try to fit the change in logic into the same box because they learned "that's the right solution". And that might not be too bad at first. But then I also say, if the number is a factor of 3 and 7, output "razzmatazz" and then _only_ apply rules where the divisor is greater than 15. Now what? The loss of flexibility isn't readily apparent from the video, hence students might not understand when this solution is appropriate. They might be inclined to think how they can fit logic adjustments into the solution rather than architect a new solution. Granted I could argue this is all part of honing one's skills, and making mistakes is important. The bottom line is this solution is predicated on expanding the rules, but only expanding them to a certain extent and in a certain way, and the video did not address that. To more experienced developers the intention is obvious, yes, but newer ones could easily misunderstand, and they're the target audience. An example tailored to this solution would both enhance the understanding of students as well as help the creator identify caveats before publishing it so he could raise them in the video.

@@AlbatrossRevenueperfectly explained my point and a few other points, thank you. Hope the original creator reads this

@@AlbatrossRevenuethis is such a good response man. You captures everything in a very clear way.

Teaching bad code because people "get bored" is probably the dumbest thing I've ever heard of. Next we'll teach the lore of Shrek in math class because people "get bored"

Assume you need to have different cases for different customers. How do you write the code?

@@CottidaeSEA so the thing here is that computationally this is one function with static inputs. If you want dynamic inputs that changes the thing the computer is actually doing. This abstraction should play well with database, JSON, or even config files, so it's probably good, assuming the rule set stays small. Abstractions let us separate different areas of code so we can modify them faster (as shown in the video) or just make complicated ideas easier to digest. In this example you're asking us to guess at the interface used for customers to modify their rules. All we know right now is one set of inputs, which are hard coded. If we add an i/o or configuration layer to handle different rules, that would be best solved when we know how the rules are getting to us, not when we're just guessing at an abstraction that hypothetically makes this more extensible. Otherwise we're basically adding functionality that hasn't been asked for and our abstraction might not actually represent the desired behavior whenever it is requested. Premature abstraction happens all the time and is almost as bad as premature optimization. For faster delivery and execution, don't do more than the feature and safety demand.

@@MrBreakstuff You didn't answer the question.

@@CottidaeSEA I did. I said this abstraction probably works pretty well for most cases but you really can't write code based on a what if without specifics. If you only needed to map a customer to a set of rules, you could probably rewrite this to take customer as an input and return the list or array. If the user needs to be able to set the rules at runtime, that's another problem. If you wind up with a customer that has 100 rules to handle 1000 inputs, that outer for loop is gonna look pretty silly as well, so you may want to look at your input actually generating functions that get called by a lambda.

@@MrBreakstuff No, that really isn't answering the question, you seem to be avoiding answering it directly. You're basically just saying "I would collect requirements from the customers" and that's about it. Essentially, what I am getting out of this is that you'd have the same implementation, you'd just pass the rules (or user) to the function. That is a perfectly valid way of doing things, but for someone who disliked the nested loops, you're really avoiding solving the very issue you mentioned.

If you're writing a library, it is an absolutely reasonable and necessary abstraction to make. And the client is then not non-techie people, it's other programmers using your library. Or if you need to run the FizzBuzz function in different areas of your application with different rulesets. You're not going to want to copy the function for every ruleset you need.

@@Treeniks that is if it is infact, a library. The prompt tasked the programmer to create something that will print to an output, instead of returning any kind of value, so clearest course of action states that this is a program and should be treated as such, where others shouldn't have to use any of these programming interfaces for anything other than this simple program. Nobody should be interacting with this code unless 1. a change to this program is necessitated or 2. someone wants to adapt snippets of the code to build their own things with it, in which more inline functionality is better anyways. Plus generally this was just supposed to be a simple lesson about problem solving, rather than long term coding principles. That's how I feel about it, anyway. Also forgot to mention, but the scope of the application is just the output fulfilled here, and nothing more. You shouldn't have to worry about how your function will be run in other areas of the application, because it's literally just the entire application.

@@thisguy.-. FizzBuzz is a hypothetical prompt, not a real one. While it was originally created as an interview question, in the context of the video it exists for educational purposes and as such can be very well interpreted as a library function. Change the print to a push into a vector and return the vector in the end, but that is a detail not relevant to what is being taught. If it's a binary you're working on and it only needs to be called once, then Tom Scott's original solution is just fine. But that's why it's a hypothetical prompt, what if it isn't. What if it's a reoccurring output, but with different rulesets every time. The point is to teach abstraction, not to talk about the usefulness of an over-engineered FizzBuzz function. And you can't exactly teach abstraction with examples that are too complicated to understand for beginners in the first place, so you have to use toy examples, which FizzBuzz is.

@@Treeniks If someone wanted to teach abstraction, then they could have done so much more by using a better example. Tom used the BizzFuff interview question as the example for how to solve problems, in an interview setting, not for how to do abstraction. If they wanted to take Tom's example and use it to teach abstraction, they could either have implicitly used it in that context, else they'd have to explicitly take their lesson out of it. Just saying "this is how to make your code *outstanding*" doesn't change the scenario because it's still tied to the context of trying to impress the hypothetical employer, not suddenly because what-if someone else has to use this in a library which was never a part of the discussion in the first place. If they wanted that, they would've put it in the video.

that’s because the code is bad

Tom's solution is better - it is easy to read and it is correct. This code is not east to read and can easily be made incorrect by screwing up the ruleset order.

@@NuncNuncNuncNunc really? Well i guess when you are starting out, all the tricks that you have difficulty understand at once seems to be because of lack of knowledge and IK it’s that too. Would you mind showing me what would an optimal code would be for values that aren’t constant? I asked how good this code was compared to tom’s solution in Chat GPT, it just said constant for tom and not constant for this vid is preferred .

Not from the top of my head, but I'm sure you can find books or videos easily.

Then that engineer didn’t study engineering 😂Because when I did EE the mantra was “only stupid engineers over engineer, that’s who Germany lost the war 😂” But it’s easy to over engineer it’s really hard to engineer to operational values. I’m no civil engineer but I am sure I can design a bridge that works. But it will be very expensive and heavy when in doubt “add more steel and just to be sure also add extra concrete to it”😂😂😂

And what if the client then tells you to throw away the whole division thing and to start working on something actually useful? Of course requirements change over time, the point is for you optimise for what you reasonably think you will need to do. If the next thing you're going to be asked is to add another 100 numbers to check against, witch is a perfectly reasonable assumption given the context of the interview question, this is an entirely valid refactoring.

​@David_Box I'm not sure you understand what I'm trying to say. I'm saying the code in this video is overcomplicated imo, unless the client actually asks for you to check whether x is divisible by other numbers, you dont need this code. Tom's code is fine imo since nobody currently needs more checks than 3 and 5. You shouldn't write code like in this video unless you're asked to add more checks, only then should you refactor, this is premature refactoring.

@@matthias916 I understand that troughout development you may create features that you may never use and that is bad. What I'm arguing is that you will in fact need to add more numbers in the future (in this particular case) so you might as well plan big. The whole point of the interview question is to see if you can plan for features not explicitly asked for. Even in the original Tom Scott video he basically said this. If you do not need to check against any other numbers, then the first variant where you check if it's divisible by 15 is actually better since a simple check is faster than string concatenation in most cases, but that is obviously a bad way to write code unless you really know you will not need to check against any other number.

​@@David_Box you don't know whether you need to add more numbers though, and even if you think you do, writing the code to support that in this case is just a waste of time. refactoring fizzbuzz so it supports more numbers takes a couple of minutes, why would you do it now when all it does is make the code harder to read. this is premature refactoring

the point of fizzbuzz is to see if you know how to write code at all, not whether you can design a complex system or think ahead, the question is way too simple for that

In JS === checks for the same value of the same data type. Good practice if you know your data types will match (int, int in this case). == would return true for 3 == "3".

Thank you for your feedback. I'll take it on board.

well written code doesn't need comments unless it's some public api. if you use enough functions and name them properly any competent programmer should be able to tell what the function does just by its signature, if that's not enough, you can take a look at the body of the function, which should be short and concise

@@matthias916 I agree. Use Comments sparely. Each comment is a potential place of rot, where the "description" will start to diverge from reality. And noting is worse than a misleading comment.

Also should probably let another function do the logging.

Because we want the strings to replace the number when we hit one of the conditions. The function appends the string to the value, so if the output started out equal to i, and i = 3, we would get a result of "3Fizz".

@@WilliamJohnson-xs2vi ah, thanks, i missed that, you're right!

yeah the functionality is tightly coupled to the ruleset and in a specific order. Not good really.

That really depends on the way any future alterations might deviate from the established pattern. If there are no "irrregular" patterns, then this 100% covers it. If irregular patterns are uniform (%7 and %11 ALWAYS are written in reverse order) then this solution still 100% covers that (you only have to change the order they are represented with in the ruleset). Anything past that, you'd have to separately handle the exceptional cases (for example, %7 and %11 are reversed only if they are the only two rules that apply, that's something you'd have to test after the initial output test is done.

Good suggestions. I like the way you think!

That's the thing about programming. You can do an endless amount of mumbo jumbo to make your code nicer, faster, elegant or whatever. But you need to understand what are the actual requirements for the code that you're writing. I personally would stop at something like Tom's code and ask the interviewer for the feedback. If they ask me to go further, only then I would do a refactor like this.

Why don't you try it. Write it and see if it's viable :)

@@jamesfoo8999 well yeah it works but im not sure if its super efficient on a large scale. (It takes less time on timeit though)

@@oryged9990 so now benchmark it :) honestly this is a good way to learn, by playing around outside commercial code. You can do what you want without fear of causing problems. When you have a benchmark setup, you can just change the code and rerun the tester and see if another way is more performant. Rinse and repeat

This is what I did in python "Fizz"*(i%3==0)+"Buzz"*(i%5==0)+str(i)*(i%3!=0)*(i%5!=0) I think it is O(n) but I'm not a computer science guy so take that as you will

java

@@disrate Clearly not. I use Java and we don’t have let in our code. It could be JavaScript since I’m not as familiar with its syntax.

@@gingeral253 that’s what I meant

@@disrate why did you call it java then lol. those two are completely different beasts despite having very similar name.

@@kuba4ful they’re same thing tbh

This example is too simple to show how it saves on complexity. In a complex codebase what here is just one if can be many ifs scattered across different places. Now every time you want to change this and let's say do the equivalent of adding a new word and divisor here, you have to look for all the ifs in your code, add your new ones, make sure you don't make a mistake just copying the other ifs and make sure you don't skip a single place where it exists DRY isn't always what you want to use, but there is no point writing verbose code with all the "boilerplate" of if(x % ... == 0) output += ...

@@maticz3923I guess that is what the author meant. Good code depends on the situation. This very silky simple situation would never justify this level of abstraction. But if it for example needed to be configurable from a user user, then it is. The thing is to always balance its always easy to over engineer but engineering is to strike the right balance.

Writing technical debt causes more slowdown.

@@Sammysapphira not having generic and therefore overcomplicated code isn't a technical dept. Simple solution that is designed to solve exact task is even easier to maintain - KISS principle.

I know what you mean, but clean code is clean code, whether 10 lines and simple or 100 lines and complex. It makes it easier to understand (no matter how small/simple) and easier to extend and alter in the future.

@@jamesfoo8999 clean code is a fraud.

@@jamesfoo8999clean code is slow code, both to write and to run. Over abstraction is a sin just like early optimization.

@@CallousCoder clean code is clean code. It's slow to initially write, but fast (easy) to maintain, read, understand, document, extend... enjoy your legacy :)

@@jamesfoo8999 clean code is a religion because it’s not objectively measurable. And is it better maintainable that also is subjective and depends on the quality of your developers. It’s a fact that code these days has an a life span of only 4 years! That’s insanely short it’s even shorter than the fiscal depreciation so things are obviously not going well. Code in the past (and much of it still) ran for 10-15 years. Most code in the backend of energy, healthcare, industrial complex is decades old and still does work perfectly - and is fast especially when brought to new hardware. Unlike all the modern software, that performs significantly slower. Mainly because of stupidity of using web development and interpreted languages and microservices that are all memory hungry and introduce unnecessary dependencies en complexity. So you may say that your new software is the new legacy because most of it is probably already gone after 3 years. And again to stress this, when you have a problem maintaining someone else’s code it is a skill issue. Sure we all think differently we all solve problems differently and it may take a little side step. But then a good engineer can reverse engineer it. I do this with binaries even, have some videos on this channel where I hack videos games to achieve certain things. And I don’t even have access to the code base just the assembly. The PacMan video to get to the kill screen was a particularly tricky one because there was even a checksum implemented and obfuscated so that people couldn’t hack the ROMs. Even that I managed to do and it’s written in Z80 assembly not even the assembly in very familiar with.

That's a really good point. I'll make sure to include that in the revised video and credit you with the idea. Thanks!

I realised that after I made the follow up video to this. Now it's too late to change it. But you're right, that also makes the limit variable easy to set to a custom value when the function is called. Would have been much better.

adding more classes and function will only add unnecessary complexly if you don't know why you're decomposing it. I'm currently working in a 20 year old codebase and decomposing is exactly what they didn't do 10 years ago. so when we need to change a behaviour, we some times need to change code in 10 places because no one had the energy to create a function that did that thing and call that function 10 times. (I'm talking same logic in different classes and even servers). But I agree with you that abstraction and decomposition for decompositions sake is useless and can make the code completely unreadable as well.

@@DNA912 absolutely right

@DNA912 i mean thats great and all but again... if it takes you 10 years to put out a new rules based decision engine (as an example) because you're afraid of saying the words "if x =" more than once in a class you might just be insane. Repeat yourself. Its easier to read than a novel of classes and your program will need less resources to function.

@@explodatedfaces agree, repetition in one class isn't a problem, and readability is great, it's when you (in the long run) create the same logic in 5 different classes which is the problem, because when you updated the code you forgot there actually was 6 classes with the same logic and not 5.

I agree this example isn’t great. The first thing I always ask when I get such a requirement is: “how likely is it going to change?” That single question can save hours of useless abstraction and configuration parsing code. Because every abstraction means extra risk off errors, more testing required more complexity to overlook. I love micro optimization but I also don’t start with optimization unless it is deemed slow and in that case the first thing you again will sacrifice is abstraction when not needed 😂

I'm his little brother, won'tstoptalkingGPT but it's okay, I hear that all the time.

if you would use Typescript and define an interface for it, i could live better with that. because in compile time while you code it will scream at you that the rulesets first entry should always be an object containing the "limit" key with a number value. also is the "limit" really a "rule"? if so, maybe we should/could rethink the rules itself. ruleSet: { limit: number, rules: [ { word: String, number: Number, }, ], }

with this code you can be sure that the rules are all the same key-value pairs. and also the limit has to be set and is not itself a rule. it isnt really a "rule" in the loop itself, its defined and used just outside of the loop.

Thats not the point. The point is to use a structured object to encapsulate the required data which can be used uniformly. Granted it is all about 'what you need' vs 'what is good practice' and striking a balance of both is a different issue. Typically, going all gungho on 'best practices' causes the core problem to be overthinked sortof like polishing a turd.

Sorry, I haven't finished the video and just saw the Fizzbuzz challenge

Here's the new code after I was done watching this: ruleset = [ {"limit": 100}, {"number": 3, "word": "Fizz"}, {"number": 5, "word": "Buzz"}] def FizzBuzz(ruleset): for i in range(ruleset[0]["limit"]): output = "" for l in range(1, len(ruleset)): if (i % (ruleset[l]["number"]) == 0): output += ruleset[l]["word"] if output == "": output = i print(output) FizzBuzz(ruleset)

I cannot take an argument to use compiled languages because they can run FizzBuzz faster seriously.

@@BlazingMagpie it’s not about fizzbuzz its about programming iterative processes in general. A good compiler will always kill that interpreter because it can optimize for speed in the most ideal way. And you can do more abstraction with far less of a cost than with an integrated language - as I have demonstrated in my argument how unrolled optimized code would basically reduce the abstraction overhead to a minimal overhead compared to an interpret language. Also try fizz buzz over 1 billion iterations in Python and in day C. I did a video on Zig programming and i toon er SMaC problem, very similar really. It’s not the problem itself but it’s a vehicle to show 3 versions a single threaded version, a multi threaded without exclusive locks and a network version that streams the problem over a socket. It’s a great vehicle to show different methodologies like all academic examples, because the problem is trivial so you can focus on other aspects more easily like parallelism, unrolled vs branching etc.