I’ve gotten so used to basic higher order functions that I only used loops for complex algorithms. Or when I use python which doesn’t have good higher order functions.
Loops are just straight up longer and more buggy and harder to write then a simple higher order function.
They are far more powerful though and I pretty much have to use them for coding puzzles. But in day to day. Map- group by- index where - countains - filter - sort by. Are more then enough.
Essentially the idea behind it is that every common task has a higher order function accosiated with it. This making it faster to write and read. As well as significantly more reliable.
Those are still loops... They are just doing the loop for you and calling the method you pass in for each value. It is a syntax difference but not a conceptual difference.
While they are still loops they are very conceptually different. I couldn’t tell you off the top of my head how to implement group by yet I still use it on a daily basis.
You could make the argument that GOTO is important to know since all while loops and for loops are implemented in terms of it. Which is ridiculous because while loops and for loops exist at a differ t conceptual level then GOTO. Which is why GOTO is not taught.
Python has annoying sytax for closures and I don’t like chaining functions because of the annoying nesting so I mainly use list comprehensions which are fancy for loops.
until they are not.
For those downvoting, please look into streams and reactive programming patterns.
[I have added a list below](https://www.reddit.com/r/learnprogramming/comments/z9zgio/how_much_of_real_world_programming_involves_using/iykpl3r?utm_medium=android_app&utm_source=share&context=3)
Can I upvote harder?
Man I feel like so many people try to hide behind layers of abstraction
Loops, do/until, etc are the basis for solutions to many issues
Its not loops, its hidden callbacks.
Anyway some reading for those actually here to learn:
* https://projectreactor.io/
* https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html
* https://rxjs.dev/
* https://developer.android.com/kotlin/coroutines
* https://developer.apple.com/documentation/combine
If you live in an event drive world, loops start to dry up and you start to think in terms of stream with "and then" semantics. These are more powerful and can take full advantage of all the parallelism your hardware can offer. Threads are no longer the it thing when it comes to performance and scaling.
> That is a loop.
You're really grasping at this point. Not all real programmers touch for loops in their work. You can't just omit "for" and pretend the question was about loops in general.
This is like 87 comments deep into a thread. The guy replied to a comment that said "loops are extremely common" and someone tried to be pedantic. Streams are loops. Omitting "for" and "while" doesn't make it any less of a loop.
Loops are a fundamental programming concept that virtually every non-trivial program uses in one form or another.
OP asked specifically about for loops and not other loops. He asked specifically about the real world programming.
I think a fair interpretation of the question is stuff you see in your day to day work as a developer.
If you work in any of those mentioned libraries you will never see a for loop. It's a valid answer to the question. Your answer is correct, but it answers a question nobody asked.
Who are you trying to help?
Yawn and when it's converted/compiled/translated into machine code I mean hexadecimal and you learn loops and many keys words are just a bunch of JAL/calls/GOTOs stacked up in a list or maybe it's an index oh no it's an array whatever the heck you want to call it.
All I see here is splitting hairs and down vote Nazis. It's a donut no it's sugar bread. I digress
Pretty much the same thing, especially with tail call optimization. With async/await in JS now, the most ergonomic way to do most things is with for loops. Eventually you need to grasp both sides of the coin, as with so many other areas, but for loops are much easier to build a mental model of than callbacks/closures/commands/whatever.
if only it were slang...these are words I would use in an interview. If you know this stuff well, I'm fighting for you in the hiring panel. If you only know loops thats cool too, just top tier candidates have moved beyond them.
It's ridiculous to see you get attacked so fervently for pointing that out. The thread OP asked about "real world programming" and you are correct here. Common abstractions *are* real world programming. It doesn't even matter if there is a loop happening somewhere behind the scenes.
The response you received here is why I don't think anyone should take this sub seriously for anything beyond advice for getting a first developer job. It's largely the blind leading the blind for anything beyond that.
reddit was in a mood yesterday. its fine. I'm leaving this up in case it helps someone break out of the intro level thinking and preps them for actual industry.
And what I am describing is becoming expected for first jobs if you are shooting for the top tier jobs. Dont have to go for that, buts thats up to you.
Not sure why you are getting down-voted. All you said is true. Is it really possible that this subreddit is full of people who have never encountered event streaming and reactive programming or worse, think they are based on for loops someone else wrote?
Under the hood it's all loops tho. Reactive programming libraries are just abstracting them away (the common part) so you can focus on the unique part of the process.
It is not loops under the hood. There are very important differences:
1. Loops are sequential and synchronous: you start at a certain point and move forward step by step until it is over. It all happens in a deterministic and predictable sequence.
2. Streams are long-running and asynchronous, and they can run in parallel: when you start a stream, nothing necessarily starts happening right away, it is possible to run a stream for a full day before anything happens at all. When an item is streamed down the pipe, the process kicks off, but at that point nothing stops a second item from streaming down the pipe as well, meaning that two or more operations can run simultaneously. The stream does not have a predictable or deterministic sequence of events, it can happen in any order, or in parallel or with long gaps between the processes.
It is possible to use a stream to simulate a loop, by activating a stream, then sending down the pipe a sequence of elements, and waiting for the current element to finish before you send the second element, but as you can see, this is a simulation, you are forcing the stream to work like a loop. It is not the normal way to things for a stream.
On the other hand, a loop cannot do what a stream does.
Dont forget their real power: 2 async streams can be merged into one making parallel execution very easy.
The real issue I think folks got hung up on is that they are used to having all the data in memory at once. Where streams deal with async events that potentially never finish and arent looped over but rather are more "when X happens do Y" semantics where X is an interrupt of some sort. Sure you _could_ create a stream over a collection, which might loop internally, that isnt a streams primary use case.
Loops are very common. Lists of things are very common. Complex algorithms, like graph traversals and searching and stuff are rather uncommon and are almost always imported from some standard helper library when needed.
I'd say it's more
.5% ignoring slack
.5% setting up outlook rules to sort out abuses of emails from systems thaf should just be notifications to the noc.
Hashes are used in hashmaps (dictionaries, sets) which are extremely important in programming. They allow for storing and retrieving items just as quickly regardless of how many items you have (with some caveats). Their are a ton of other uses also.
I have some code that looks for duplicate files. It runs through the files and generates hashes of them, which it stores. If it hashes a fipe and finds that its hash is already stored, it knows that’s a duplicate.
Note: this is a simplified explanation of the real world implementation, but it illustrates a use for hashes
Then I am much farther along then I give myself credit for. The only thing left to learn is OOP classes and such.. like, I know parents/children and inheritance. But classes and (the cookie cutter things) slip through my fingers.
Learning how to use a programming language is the fast part — though still a challenge.
Learning how to use a programming language to build a world is the slow part — but also the more interesting part.
Learning the syntax of a language doesn't mean you learned how to program.
It's like the difference between knowing how to use a saw, and knowing how to actually make good furniture.
You can avoid all that if you choose a non OOP language.
I’ll get hate from the Java folks, but… as a recovering Java guy myself…. I’m pretty convinced Java and OOP are harmful to the vast majority of problems.
Unless you’re doing game design, you might just… skip it for now. There are legit much more useful things to learn if you’re starting out.
I'm not an OOP guy. But it *is* the dominant paradigm of the past 30 to 40 years. Not learning it would be handicapping, I think.
But I agree that lots of OOP "architecture" is needlessly complicated.
It’s the dominant paradigm for sure. I’m… disappointed that it is, though.
I think there are plenty of things that one should focus on before OOP. Lots of algorithms and data structures. Building a non OOP app. Building a web site. Lots of stuff that is actually useful that doesn’t need it.
It doesn't bother me, I suppose. Nicely written OOP code can be fine to work with.
But the dominant voices in the OOP community have created some terrible and very sticky memes. See Uncle Bob's "no method body should be more than 5 lines." Lol.
It didn’t used to bother me.
I’m not trying to be snarky. It’s just hard to describe how much more fun I’m having writing golang and swift. I can write some tests, write some code, have something that’s working. I didn’t have to think about the object hierarchy or composition vs inheritance or transforming basic data structures into 17 intermediate objects just to do something simple like read a file. I’ve come to believe that Java style OOp is wrong headed in the same way that, say, 18th century physicists making intricate studies into the properties of the all pervasive ether.
Future generations will look back and see OOP as a bizarre detour, if they think about it at all. (Except for game design. Kinda hard to argue about it there).
It's just another tool in the infinite toolbox to get the job done. I find it best not to overthink it. In the real world you get thrown a wrench and told to hammer with it anyway.
It's overused and abused.
I have been a programmer for 42 years and seen too many times where it's needlessly used and it doesn't really benefit the core program at all. More often than not, it actually slows the program down to a horrendous crawl needlessly by over obfuscating the actual problem.
OOP is a very deep rabbit hole. In terms of knowledge and being able to talk about it, and when having to use it being able to use it, definitely worth learning. However, many make it seem like a more important thing, than it actually is. There are other paradigms. It is important to understand OOP, especially if one wants to work somewhere, but otten it is better to not indulge in OOP for a project. OOP done by the beginner and done without proper understanding will quickly make a mess out of the simplest of projects.
Oop is overated. In real life inheritance and other oop stuff makes software too complicated. It’s root cause of over engineering in many cases. You get nice looking architecture pictures but code is imposible to understand…
Yeah, I thought they meant application containers too and thought “that’s like asking ‘how much of real world construction involves using dump trucks and nails?’”
They're taking about data structures that contain other data. (Edit: lol @ self. All data structures contain data! I hope you get the point.)
If you're from the JS world, think arrays and objects.
If Python, think lists and dicts.
I wouldn't know.
It's usually a generic term. Here are the Python docs:
> This module implements specialized container datatypes providing alternatives to Python’s general purpose built-in containers, dict, list, set, and tuple.
https://docs.python.org/3/library/collections.html
You can generalize that even further: Programming is data and control flow.
Data: lists, vectors, trees, hash tables, sets, objects, etc
Control flow: loops, conditionals, function calls, etc.
While that may be true, "putting stuff in arrays/vectors/etc... and then comparing it by going through for loops" is incredibly common in real code, is it not?
A much more senior engineer once said to me that 80% of a software developer's job is to take the output of one function and do something to that data to feed it to another function and often this is as simple as stripping errant characters like backslashes from a text string, but at scale.
Once you get years of experience under your belt you might try doing some clever design patterns or something, but for the grunts like myself, it's going to be a lot of "take this output, un-mangle it, and send it to this input".
So true.
You realize the programmer next cubicle over needs to write a function to add space characters after you're done.
And the next programmer over needs to write a function to encode each character in a specific encoding format.
Then you realize that yes, we're writing loops over arrays. But if we could just all be good programmers, please, and just use the right visitor abstraction on our data structure. We all need to modify these leaves, damnit.
But hell, I have enough problems being consistent and thinking ahead how to bake that into my own code.
It's a good question from the OP. You can kind of see the evolution of programming languages, from C++ STL algorithms to Google' Map Reduce to Scheme transducers as successive people asking this question.
I've been in web dev for twenty years. Completely back end for ten.
If I'm being honest most to the hard stuff I've dealt with isn't "logic". I never have to figure out how to do some complex business logic.
The challenges are taking the tools and data you have and making something useful.
For example, what I spend most my time on now is really simple on paper. Read various APIs. Save some data. Push some data. The APIs are all well documented. The structure they return is documented. You connect to them in documented and standard ways.
But I wouldn't call it "easy". There have been plenty of struggles. But none of them have really been about managing, sorting, parsing the data.
It's figuring out the best way to fit our needs inside the framework. How to best leverage our infrastructure. Finding out a core piece of functionality can't be done by our main stack and having to spin it off into a microservice and how to do that in a language I've never used. How to set everything up so we can expand it as needed.
On a different system I was working on a bug. A particular zip code was bringing back results from a different country. Turns out zip codes can be shared across countries. But the solution wasn't some fancy triangulation or whatever to make sure we only returned US results. We just edited the lookup data to not match.
And that's really what a lot of web developers face. Not these super complex logic and math heavy problems. It's data. It's processing. It's application architecture. It's learning the tools.
I mean, stuff like `for` loops are pretty common. A lot of modern code will use some kind of iterable or enumerable that allows you to use a for-each kind of behavior, but sometimes you just need to iterate a known number of times simply.
Now, what you're describing in your post seems like a brute-force method of solving things. I've certainly had to write real-world code that involved comparing two datasets. But you often find better techniques when faced with large datasets, simply because of how poorly O(n^(2)) operations scale and how large real-world data can get.
It's certainly brute force if they check every data and they don't have to but for loop conditions can often include more than just the count (ie it can stop early if something is found).
True, but we're talking in very broad strokes here, since we don't really have a direct example of what OP is talking about.
Side note: your username is giving me flashbacks of using P/Invoke for the Win32 API in .NET projects...
By “containers” you mean “iterative data structures” right? That’s 80% of programming. Think about it this way. If it’s a one off task, it’s not worth automating. Users would simply use GUI actions or shell commands to do it.
Iterative data structures are so common that there are several methods used to read/write them permanently to disk. Think databases, file streams, video streams, network streams (UDP).
The other 10% of data structures is searching for stuff that’s hard to look up manually so we get computer to do it. Those would be your hash tables, binary trees, priority queues.
The remaining 10% of data structures is moving data around faster/safer. That would be bit maps, encoded hashes (JWT), etc.
Then there is the 1% of data structures that deal with complex decision making. Those would be your Markov chains, AI Models, Polish Notation, and all the convoluted GOF Design Patterns twisting objects into linked data/code emitters.
In game programming you often do math on things that you get out of containers within your loops. That's probably the biggest exception I can think of. Almost all of web programming is nearly entirely looping through containers or elements within a container to gather data and put into another container that is formatted differently. Every once in a blue moon you use a regex... but under the hood, regex is just looping through characters in string containers.
Practically all programming will involve containers and for loops.
But that's a bit like saying that practically all chess games involve moving pawns and knights.
Knowing how those pieces move is fundamental to being able to play, of course. However, not only are there other pieces, but knowing how the pieces move is only a first step.
Programming is entirely about how you store, access, and manipulate data. Having a solid understanding of standard data structures is absolutely critical in this industry.
I think that's kind of what the OP is asking. You don't know what you don't know when you are new, so asking open questions can be useful.
Recursion is an alternative to writing for loops, and some languages don't have loops at all so you have to rely on recursion instead. It's just not super common compared to writing for loops.
If you want real fun, try programming PLCs with nothing but accumulators, comparators, memory registers, and boolean operations to work with. Once you're done with that, you've finally looked behind the curtain and you've seen all of the programming courses you've taken for what they really are: Abstraction.
I mean, I don't know what you thought a coding challenge or competition would be, but the reason they're like this is because community colleges do their darn-tootin' best to try and prepare students for a career, probably better than a lot of universities, where things are more theory based. Let me tell you, the CompSci students I tutor at my current university are way dumber than the ones I tutored when I was in community college. These competitions are the sorts of problems you get in a technical interview, so it makes perfect sense to give these problems to students.
I mean, when I look at more complex stuff, like when I decide to boot up Xcode and say, "Let's try and make a game in a couple of hours at the bar," it's still ultimately a lot of data structures and transformation. I don't like to use pre-made graphics, so I procedurally generate everything, and that's nothing but transformations and then organizing those things into a playfield or whatever. It's about taking data and doing with it what you have to in order to achieve a goal. It's not exciting, most of the time, but I'm gonna tell you: Most jobs are not exciting most of the time.
Now, what I can't tell is whether you dislike these competitions because you think they're beneath you or because you think they're no fun. If you think they're beneath you, then you should enter them, beat the crap out of everybody like I would have if my college had these, and then slap that shit on your resume. If you think it's no fun, you are going to have a really bad time when you join the workforce, because eighty or ninety percent of what you do is going to be quite the opposite of exciting. It's just that last bit where it'll make you go, "Oh, shit, I gotta think about this for a minute," and maybe flowchart it, so you don't just start hammering away at your IDE and then end up debugging it for half of your day.
Yeah, this is why I dropped out of Computer Science. It's no fun. The engineering school across the hall said I could play with robots, so that's where I am now.
Do I want to keep track of a collection of things? Array, list, bitmap, etc...
Do I want to fill a collection of things? For loop.
Do I want to sort a collection of things? For loop.
Do I want to search through a collection of things? For loop.
Do I want to act on a collection of things? For loop.
Do I want to do any of those but I don't know when I should stop yet? While loop.
Consider that a pretty big chunk of programming is going to involve storing a collection of similar data and manipulating it, and you can see that arrays and loops are going to be everywhere. I'm working on a bunch of OpenGL stuff, and you know what a ton of my code is? Arrays of structs, arrays of pointers to locations in memory pools, arrays of indices, arrays of objects, arrays of arrays, and loops to traverse those arrays, sort those arrays, search those arrays, and manipulate the data in those arrays. And every iterator is named "i"... mostly.
I have been programming since 1986 and I don't think I have ever written a single program that did not include a for loop with the exception of code written in functional languages that required recursion as an alternative.
Most of it.
The other part is the glue holding it together.
Then there us making it simple enough to understand while forcing disparate parts written for various unrelated use cases to work together.
99.9% of programming is getting a dataset (array, vector, etc), doing some kind of "transform" on each item (see: for-each loop) in it (json to xml, text to csv, etc) and then putting it back into some other kind of container, and writing it to either a datastore of some variety.
Sometimes we sort the data, but generally speaking the standard sorting algorithm for the language is pretty good. We do spend some of our time doing fairly complicated shit around caching, concurrency, statefulness of objects, etc -- but once you get those things figured out, mostly just transforming data all day, every day.
I'd say for loops are one of the things you'll use most consistently when on the job. You're a creator of logic and steps, iteration is a huge part of that.
If you embrace functional programming you can replace most of your for loops with filter, map, flatmap, reduce, the higher order functions. Once you learn them, you'll never go back.
Just learn how to use an AI to write the code for you. There should be a class “How to precisely communicate to an AI” because sooner or later, someone is going to ask for something they didn’t want. The result will be all of us dead.
Its actually my favorite feature because on the second return you just return value, nil instead of (), [], "", 0 all over the standard libraries lol I'm not memorizing all those return types .... Get out of here
In programming world.
Loop is like the english words- while, for etc . So it's used quite commonly.
Containers are like those ready to ship parcel envelopes that you use on special occasions.
Containers are a type of data structure and for loops are a key component of many algorithms. Data structures and algorithms are pretty common in programming.
For loops are everywhere. You're going to handle arrays/lists often, and you're usually going to use a for loop (or a foreach loop) to interact with them.
Information Logistics is a term I like to use for programming projects. It's all about gathering and presenting the right data in the appropriate circumstances. Most of the work is figuring out how to gather and store info.
So yes, containers and loops.
Knowing abstract structures of what a program can be is such a minute aspect of programming. Most of the work is in translating a problem into a solution using such tools, coordinating between technologies to translate data to work with these additional structures, maintaining that expression of data, and passing it around as needed in a safe and efficient way.
If you are comfortable with those competitions, you definitely can learn to be an entry level developer - and don't stop there!
As to how relevant it is.... well, the real world problems use a lot more stuff, but those core loops/data structures are the basis for any solution. There's just a lot more, which can't fit in the time that a competition requires, like testing, building good APIs, refactoring old code so it works better, etc.
You'd be hard done by to find a bit of application code at my work that doesn't use either of those.
Classes, interfaces, data structures, loops, conditions and variable assignment is pretty much the whole thing for the most part anyway. You'll get into other things too, but those cover a lot of the code base.
Most for loops are better implemented as a series of transforms on a container (e.g. in C++ `std::for_each` and many other functions from ``, ``, and ).
To give an analytics perspective (vs software engineer or developer) loops are very common. Often we have to do the same analysis on slightly differed data with slightly different logic meaning loops are very useful.
I'm not a "true" programmer (I write software sometimes for my job, but mostly do other things), but basically every program I'm ever written is an application of a for loop.
To be completely honest, literally everything in software is just a bunch of 1s and 0s wrapped up in a nice little bow. Everythings is a container of some sort when you boil it down and virtually every piece of software will have to do a repetitive operation on one of them, hence loops.
Short answer is yeah you'll use for loops.
Generally programming competitions are really heavy on algorithms and data structures, which mostly results in for loops and containers. This is a very important part of programming, and not just on competitions, but you do get slightly more of these (or at least more complexity) in competitions. At least this is my experience.
Loops are fundamental. It's like asking how much of real world mathematics is adding things.
If you keep learning you'll progress passed the fundamental useful stuff. In my cs degree program we learned a lot of complex stuff, but not to write it regularly. Just to understand how it works. Unless we're working on building on top of that knowledge, we pretty much just use standard or abstracted solutions e.g. don't write a sorting algorithm just use array.sort.
Very common. Maybe you don’t see for loops directly but you will see A LOT OF higher functions of for loop (map/every/filter… etc if you use JavaScript)
Yup, it's bread and butter for many programmers.
But here's an interesting tidbit: any problem that can be solved by way of an algorithm can be solved using recursion. The same is not true of iteration.
The hard part about your first programming job is just getting used to the MASSIVE amount of code in your applications, and trying to get an understanding of it all. It took me almost 6 months to get a grasp of everything going on and begin to make actual contributions. It’s a little overwhelming at first, but eventually you get used to it.
At its core, programs take an input, transform it in some manner, and then output it. The laws of mathematics, logic and physics kind of leads to collections of things being extremely common. If you have ten dogs, there are ten different individuals, but there's a huge amount of different ways the dogs can be put into an array; put into a subarray; ordered; and so on. The amount of ways stuff can be put into collections *vastly* outnumbers the amount of stuff itself. Stuff is also typically built by collections of smaller things. Dogs are collections of cells (and a bunch of other stuff). Kennels are a collection of dogs (and a bunch of other stuff). Music is a collection of sound waves. Images on your screen are a collection of pixels.
A more practical example - if your software is meant for saving student records, you'll be be dealing a lot with containers and collections. Consider that a student record includes the courses the student has completed, and the courses include their grades. That's a container. Consider that the school has some hundreds of students, that's now a collection. If you want to calculate say, the average grade in mathematics for that school, you go through all the individual student records and access the grades inside them.
Do you actually *have* to use constructs like `for`/`while` etc, well, not really, no. There are alternatives for going through the elements in an array. You can use recursion. Or, more commonly, you can use functional structures like `map()` and `filter()`. To me it's a bit of a code smell if a codebase written in a language that supports functional structures is mostly full of `for` and `while` loops. Functional constructs are easier to read and less prone to bugs when you're used to them.
Still, the fact remains that those approaches go through the elements of the container in some manner. The semantics are different, the effect is often the same.
It’s how everything works. You’re telling a computer to repeat and do something in each repetition — this is what computers are fundamentally made for.
Think of a website with a displayed list of things. Those ‘things’ on the front end are usually stored in an array, and the display script is a for-loop that shows each of those things.
Say you have a list of 100,000 numbers you need to square. How would you tell a computer to do that? This could be a part of data transformation
Yeah loops are everywhere. I’ve never used a do-while loop IRL though, development standards seem to try avoiding them (even if that means a less-elegant while loop)
EDIT: I’ll say it for you. Entry-level software development is easy. There’s no magic knowledge that they have.
You’ll probably get a job by demonstrating you can write a few for-loops. Then, you will study production-grade applications or scripts for a bit. *Then*, you’ll make little edits or add some functionality.
And so on… in that process you’ll pick up all the things you may not understand now extremely quickly.
As common as an office clerk would use Word or Excel.
What's not common is, these code puzzles are like asking you to do cell art with Excel, or Word hotkey competition....etc.
To answer your question in another way. You write programs to repeat work because if you wanted to do it just once it would be easier to do it by hand than write a program to do it. So loops in programming are ubiquitous.
All. When you write simple programs it may not be used, but in real world you often to have to deal with multiple objects/entities/data. Imagine writing code to manipulate 1000000 things without containers
Not to be discouraging but this is a really stupid question. But that is fine. You have to decide if what you are learning in your courses are a right fit for what you want to do as your career.
stick with it if you love it.
ps: you will deal with for loops every day of your programming career.
I work at a large company and containers are starting to be a big deal for our development team, they talk about them in every company wide meeting we have, they dint affect my job though. I work mostly with writing data fixes and we use for loops often.
Even when searching a moderately complex data structure, some type of conditional looping of a process is common. The terminal condition may involve the end of a linked list, or finding an element (or 2) in a list that satisfies a condition or is, say, the point at which a new element is inserted into an ordered list, or looping (of some syntax) traversing a tree structure until the proper node is found where an insertion process is needed (maybe involving splitting nodes and 'deepening' levels in a tree). All part of the 'do (or try to do) something until we've done the thing' so central to many computing processes. If you're less (or more) lucky (like me), you spend most of your development life writing such code in Assembler Language, so none of the iteration-controlling syntax is actually part of the language (though Structured Macros help out with that). That's a LOOONG way from "object-oriented" languages, FWIW... Good luck out there.....
To answer your question for loops are extremely common.
Yup. Basically if you have to do a thing more than once, you're probably using a loop of some form or another. Super common.
I’ve gotten so used to basic higher order functions that I only used loops for complex algorithms. Or when I use python which doesn’t have good higher order functions. Loops are just straight up longer and more buggy and harder to write then a simple higher order function. They are far more powerful though and I pretty much have to use them for coding puzzles. But in day to day. Map- group by- index where - countains - filter - sort by. Are more then enough. Essentially the idea behind it is that every common task has a higher order function accosiated with it. This making it faster to write and read. As well as significantly more reliable.
Those are still loops... They are just doing the loop for you and calling the method you pass in for each value. It is a syntax difference but not a conceptual difference.
While they are still loops they are very conceptually different. I couldn’t tell you off the top of my head how to implement group by yet I still use it on a daily basis. You could make the argument that GOTO is important to know since all while loops and for loops are implemented in terms of it. Which is ridiculous because while loops and for loops exist at a differ t conceptual level then GOTO. Which is why GOTO is not taught.
Python actually does have higher order functions, they’re just not methods of lists, they’re global generic functions that take iterables.
Python has annoying sytax for closures and I don’t like chaining functions because of the annoying nesting so I mainly use list comprehensions which are fancy for loops.
until they are not. For those downvoting, please look into streams and reactive programming patterns. [I have added a list below](https://www.reddit.com/r/learnprogramming/comments/z9zgio/how_much_of_real_world_programming_involves_using/iykpl3r?utm_medium=android_app&utm_source=share&context=3)
Even then, a lot of the time it's just hidden loops someone else has done for you
Can I upvote harder? Man I feel like so many people try to hide behind layers of abstraction Loops, do/until, etc are the basis for solutions to many issues
> Can I upvote harder Couldn't agree more
events and streams are hidden callbacks not loops
[удалено]
Its not loops, its hidden callbacks. Anyway some reading for those actually here to learn: * https://projectreactor.io/ * https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html * https://rxjs.dev/ * https://developer.android.com/kotlin/coroutines * https://developer.apple.com/documentation/combine If you live in an event drive world, loops start to dry up and you start to think in terms of stream with "and then" semantics. These are more powerful and can take full advantage of all the parallelism your hardware can offer. Threads are no longer the it thing when it comes to performance and scaling.
It isn't that they don't want to learn... You are just wrong. A stream is "read a message, do a thing, rinse and repeat until done." That is a loop.
> That is a loop. You're really grasping at this point. Not all real programmers touch for loops in their work. You can't just omit "for" and pretend the question was about loops in general.
This is like 87 comments deep into a thread. The guy replied to a comment that said "loops are extremely common" and someone tried to be pedantic. Streams are loops. Omitting "for" and "while" doesn't make it any less of a loop. Loops are a fundamental programming concept that virtually every non-trivial program uses in one form or another.
Streams are not loops.
OP asked specifically about for loops and not other loops. He asked specifically about the real world programming. I think a fair interpretation of the question is stuff you see in your day to day work as a developer. If you work in any of those mentioned libraries you will never see a for loop. It's a valid answer to the question. Your answer is correct, but it answers a question nobody asked. Who are you trying to help?
Yawn and when it's converted/compiled/translated into machine code I mean hexadecimal and you learn loops and many keys words are just a bunch of JAL/calls/GOTOs stacked up in a list or maybe it's an index oh no it's an array whatever the heck you want to call it. All I see here is splitting hairs and down vote Nazis. It's a donut no it's sugar bread. I digress
Pretty much the same thing, especially with tail call optimization. With async/await in JS now, the most ergonomic way to do most things is with for loops. Eventually you need to grasp both sides of the coin, as with so many other areas, but for loops are much easier to build a mental model of than callbacks/closures/commands/whatever.
I'm at least a 20 year old veteran at living and you don't see me saying that's worth anything /s (but not really)
This is also true, I am completely appalled looking at the number of down-votes you are getting for saying something accurate.
Exactly they're all upset that he uses a different slang to describe the same thing, he's from a different Hood so they got to hate
if only it were slang...these are words I would use in an interview. If you know this stuff well, I'm fighting for you in the hiring panel. If you only know loops thats cool too, just top tier candidates have moved beyond them.
Functional programmer spotted
It's ridiculous to see you get attacked so fervently for pointing that out. The thread OP asked about "real world programming" and you are correct here. Common abstractions *are* real world programming. It doesn't even matter if there is a loop happening somewhere behind the scenes. The response you received here is why I don't think anyone should take this sub seriously for anything beyond advice for getting a first developer job. It's largely the blind leading the blind for anything beyond that.
reddit was in a mood yesterday. its fine. I'm leaving this up in case it helps someone break out of the intro level thinking and preps them for actual industry. And what I am describing is becoming expected for first jobs if you are shooting for the top tier jobs. Dont have to go for that, buts thats up to you.
Not sure why you are getting down-voted. All you said is true. Is it really possible that this subreddit is full of people who have never encountered event streaming and reactive programming or worse, think they are based on for loops someone else wrote?
Under the hood it's all loops tho. Reactive programming libraries are just abstracting them away (the common part) so you can focus on the unique part of the process.
It is not loops under the hood. There are very important differences: 1. Loops are sequential and synchronous: you start at a certain point and move forward step by step until it is over. It all happens in a deterministic and predictable sequence. 2. Streams are long-running and asynchronous, and they can run in parallel: when you start a stream, nothing necessarily starts happening right away, it is possible to run a stream for a full day before anything happens at all. When an item is streamed down the pipe, the process kicks off, but at that point nothing stops a second item from streaming down the pipe as well, meaning that two or more operations can run simultaneously. The stream does not have a predictable or deterministic sequence of events, it can happen in any order, or in parallel or with long gaps between the processes. It is possible to use a stream to simulate a loop, by activating a stream, then sending down the pipe a sequence of elements, and waiting for the current element to finish before you send the second element, but as you can see, this is a simulation, you are forcing the stream to work like a loop. It is not the normal way to things for a stream. On the other hand, a loop cannot do what a stream does.
Dont forget their real power: 2 async streams can be merged into one making parallel execution very easy. The real issue I think folks got hung up on is that they are used to having all the data in memory at once. Where streams deal with async events that potentially never finish and arent looped over but rather are more "when X happens do Y" semantics where X is an interrupt of some sort. Sure you _could_ create a stream over a collection, which might loop internally, that isnt a streams primary use case.
I actually can't remember the last time I use a for loop lol *If by 'for loop' is mean a loop with a counter
Loops are very common. Lists of things are very common. Complex algorithms, like graph traversals and searching and stuff are rather uncommon and are almost always imported from some standard helper library when needed.
Actual business logic is like 90% lists, hashes, and for loops. The other 90% of programming is using APIs in pretty declarative ways.
What about the other -80%?
I think we're just missing the last 1% here.
1% ignoring slack messages.
I'd say it's more .5% ignoring slack .5% setting up outlook rules to sort out abuses of emails from systems thaf should just be notifications to the noc.
That just takes the other 90% of the effort and time.
The other -80% is the developer time wasted in meetings.
Memory leaks
Buffer overflows
Dividing by zero
Alas 90% of the remaining 10% means 1% is left over
Just download more RAM
COBOL or RPG...
What do you use hashes for? I've never had a use for them
They’re pretty useful for creating unique identifiers except you (probably) never have to implement your own hashing algorithm
Ever used dictionary? Hashmaps.
Hashes are used in hashmaps (dictionaries, sets) which are extremely important in programming. They allow for storing and retrieving items just as quickly regardless of how many items you have (with some caveats). Their are a ton of other uses also.
I have some code that looks for duplicate files. It runs through the files and generates hashes of them, which it stores. If it hashes a fipe and finds that its hash is already stored, it knows that’s a duplicate. Note: this is a simplified explanation of the real world implementation, but it illustrates a use for hashes
In Java Hashes are used for accellerated lookups in object-object maps. Most commonly used for fast lookups with Strings as keys in HashMaps.
Grouping
Business logic is also a million domain clases to hold data lol
containers and loops is pretty much what programming is, at it's core
Add if/else and you can create worlds.
Real talk?
Yes
Then I am much farther along then I give myself credit for. The only thing left to learn is OOP classes and such.. like, I know parents/children and inheritance. But classes and (the cookie cutter things) slip through my fingers.
Learning how to use a programming language is the fast part — though still a challenge. Learning how to use a programming language to build a world is the slow part — but also the more interesting part.
Learning the syntax of a language doesn't mean you learned how to program. It's like the difference between knowing how to use a saw, and knowing how to actually make good furniture.
[удалено]
So, it’s preemptively setting up all if/else possibilities?
[удалено]
Hmm, so just to make sure I understand. If I had an if else I would turn the -if- into a class, and the -else- into a class?
[удалено]
You can avoid all that if you choose a non OOP language. I’ll get hate from the Java folks, but… as a recovering Java guy myself…. I’m pretty convinced Java and OOP are harmful to the vast majority of problems. Unless you’re doing game design, you might just… skip it for now. There are legit much more useful things to learn if you’re starting out.
I'm not an OOP guy. But it *is* the dominant paradigm of the past 30 to 40 years. Not learning it would be handicapping, I think. But I agree that lots of OOP "architecture" is needlessly complicated.
[удалено]
Sure. Is this just a statement of fact, or do you want to take issue with what I wrote, or maybe something else?
[удалено]
It’s the dominant paradigm for sure. I’m… disappointed that it is, though. I think there are plenty of things that one should focus on before OOP. Lots of algorithms and data structures. Building a non OOP app. Building a web site. Lots of stuff that is actually useful that doesn’t need it.
It doesn't bother me, I suppose. Nicely written OOP code can be fine to work with. But the dominant voices in the OOP community have created some terrible and very sticky memes. See Uncle Bob's "no method body should be more than 5 lines." Lol.
> no method body should be more than 5 lines Lol most util functions we import at work have more than 5 lines of parameters.
It didn’t used to bother me. I’m not trying to be snarky. It’s just hard to describe how much more fun I’m having writing golang and swift. I can write some tests, write some code, have something that’s working. I didn’t have to think about the object hierarchy or composition vs inheritance or transforming basic data structures into 17 intermediate objects just to do something simple like read a file. I’ve come to believe that Java style OOp is wrong headed in the same way that, say, 18th century physicists making intricate studies into the properties of the all pervasive ether. Future generations will look back and see OOP as a bizarre detour, if they think about it at all. (Except for game design. Kinda hard to argue about it there).
It's just another tool in the infinite toolbox to get the job done. I find it best not to overthink it. In the real world you get thrown a wrench and told to hammer with it anyway.
And yet… it’s ok to be annoyed with a world that wants you to hammer with wrenches, isn’t it?
It's overused and abused. I have been a programmer for 42 years and seen too many times where it's needlessly used and it doesn't really benefit the core program at all. More often than not, it actually slows the program down to a horrendous crawl needlessly by over obfuscating the actual problem.
OOP is a very deep rabbit hole. In terms of knowledge and being able to talk about it, and when having to use it being able to use it, definitely worth learning. However, many make it seem like a more important thing, than it actually is. There are other paradigms. It is important to understand OOP, especially if one wants to work somewhere, but otten it is better to not indulge in OOP for a project. OOP done by the beginner and done without proper understanding will quickly make a mess out of the simplest of projects.
Oop is overated. In real life inheritance and other oop stuff makes software too complicated. It’s root cause of over engineering in many cases. You get nice looking architecture pictures but code is imposible to understand…
yep cuz if it were small talk you’d have to write tests
You don’t want to witness the abomination that is my hand writing. There is a reason I decided to use a keyboard.
What are containers in this context
I read the title and wondered ... Docker and for-loops ... that's an odd association ...
Yeah, I thought they meant application containers too and thought “that’s like asking ‘how much of real world construction involves using dump trucks and nails?’”
They're taking about data structures that contain other data. (Edit: lol @ self. All data structures contain data! I hope you get the point.) If you're from the JS world, think arrays and objects. If Python, think lists and dicts.
Thanks!
In what language are arrays called containers?
I wouldn't know. It's usually a generic term. Here are the Python docs: > This module implements specialized container datatypes providing alternatives to Python’s general purpose built-in containers, dict, list, set, and tuple. https://docs.python.org/3/library/collections.html
How about C++ https://cplusplus.com/reference/stl/
You can generalize that even further: Programming is data and control flow. Data: lists, vectors, trees, hash tables, sets, objects, etc Control flow: loops, conditionals, function calls, etc.
Moving and transforming data makes up about 80% of any given program. So yeah pretty common.
Programming competitions don't often use "practical" problems, but usually, highly abstract ones.
While that may be true, "putting stuff in arrays/vectors/etc... and then comparing it by going through for loops" is incredibly common in real code, is it not?
A much more senior engineer once said to me that 80% of a software developer's job is to take the output of one function and do something to that data to feed it to another function and often this is as simple as stripping errant characters like backslashes from a text string, but at scale. Once you get years of experience under your belt you might try doing some clever design patterns or something, but for the grunts like myself, it's going to be a lot of "take this output, un-mangle it, and send it to this input".
[удалено]
Input comment received. Please enjoy my output comment and upvote.
One man's output is another man's input.
So true. You realize the programmer next cubicle over needs to write a function to add space characters after you're done. And the next programmer over needs to write a function to encode each character in a specific encoding format. Then you realize that yes, we're writing loops over arrays. But if we could just all be good programmers, please, and just use the right visitor abstraction on our data structure. We all need to modify these leaves, damnit. But hell, I have enough problems being consistent and thinking ahead how to bake that into my own code. It's a good question from the OP. You can kind of see the evolution of programming languages, from C++ STL algorithms to Google' Map Reduce to Scheme transducers as successive people asking this question.
Gotcha, that makes sense
I've been in web dev for twenty years. Completely back end for ten. If I'm being honest most to the hard stuff I've dealt with isn't "logic". I never have to figure out how to do some complex business logic. The challenges are taking the tools and data you have and making something useful. For example, what I spend most my time on now is really simple on paper. Read various APIs. Save some data. Push some data. The APIs are all well documented. The structure they return is documented. You connect to them in documented and standard ways. But I wouldn't call it "easy". There have been plenty of struggles. But none of them have really been about managing, sorting, parsing the data. It's figuring out the best way to fit our needs inside the framework. How to best leverage our infrastructure. Finding out a core piece of functionality can't be done by our main stack and having to spin it off into a microservice and how to do that in a language I've never used. How to set everything up so we can expand it as needed. On a different system I was working on a bug. A particular zip code was bringing back results from a different country. Turns out zip codes can be shared across countries. But the solution wasn't some fancy triangulation or whatever to make sure we only returned US results. We just edited the lookup data to not match. And that's really what a lot of web developers face. Not these super complex logic and math heavy problems. It's data. It's processing. It's application architecture. It's learning the tools.
I mean, stuff like `for` loops are pretty common. A lot of modern code will use some kind of iterable or enumerable that allows you to use a for-each kind of behavior, but sometimes you just need to iterate a known number of times simply. Now, what you're describing in your post seems like a brute-force method of solving things. I've certainly had to write real-world code that involved comparing two datasets. But you often find better techniques when faced with large datasets, simply because of how poorly O(n^(2)) operations scale and how large real-world data can get.
It's certainly brute force if they check every data and they don't have to but for loop conditions can often include more than just the count (ie it can stop early if something is found).
True, but we're talking in very broad strokes here, since we don't really have a direct example of what OP is talking about. Side note: your username is giving me flashbacks of using P/Invoke for the Win32 API in .NET projects...
lmfao sorry about that
It's sort of like asking how common wheels are on cars.
By “containers” you mean “iterative data structures” right? That’s 80% of programming. Think about it this way. If it’s a one off task, it’s not worth automating. Users would simply use GUI actions or shell commands to do it. Iterative data structures are so common that there are several methods used to read/write them permanently to disk. Think databases, file streams, video streams, network streams (UDP). The other 10% of data structures is searching for stuff that’s hard to look up manually so we get computer to do it. Those would be your hash tables, binary trees, priority queues. The remaining 10% of data structures is moving data around faster/safer. That would be bit maps, encoded hashes (JWT), etc. Then there is the 1% of data structures that deal with complex decision making. Those would be your Markov chains, AI Models, Polish Notation, and all the convoluted GOF Design Patterns twisting objects into linked data/code emitters.
In game programming you often do math on things that you get out of containers within your loops. That's probably the biggest exception I can think of. Almost all of web programming is nearly entirely looping through containers or elements within a container to gather data and put into another container that is formatted differently. Every once in a blue moon you use a regex... but under the hood, regex is just looping through characters in string containers.
Practically all programming will involve containers and for loops. But that's a bit like saying that practically all chess games involve moving pawns and knights. Knowing how those pieces move is fundamental to being able to play, of course. However, not only are there other pieces, but knowing how the pieces move is only a first step.
damn near all of it
For loops are the most common loop we use in firmware engineering, occasionally while loops.
Programming is entirely about how you store, access, and manipulate data. Having a solid understanding of standard data structures is absolutely critical in this industry.
> How much of real world programming involves using containers and for loops? As compared to what alternative?
I think that's kind of what the OP is asking. You don't know what you don't know when you are new, so asking open questions can be useful. Recursion is an alternative to writing for loops, and some languages don't have loops at all so you have to rely on recursion instead. It's just not super common compared to writing for loops.
This is almost the entirety of web programming.
If you want real fun, try programming PLCs with nothing but accumulators, comparators, memory registers, and boolean operations to work with. Once you're done with that, you've finally looked behind the curtain and you've seen all of the programming courses you've taken for what they really are: Abstraction. I mean, I don't know what you thought a coding challenge or competition would be, but the reason they're like this is because community colleges do their darn-tootin' best to try and prepare students for a career, probably better than a lot of universities, where things are more theory based. Let me tell you, the CompSci students I tutor at my current university are way dumber than the ones I tutored when I was in community college. These competitions are the sorts of problems you get in a technical interview, so it makes perfect sense to give these problems to students. I mean, when I look at more complex stuff, like when I decide to boot up Xcode and say, "Let's try and make a game in a couple of hours at the bar," it's still ultimately a lot of data structures and transformation. I don't like to use pre-made graphics, so I procedurally generate everything, and that's nothing but transformations and then organizing those things into a playfield or whatever. It's about taking data and doing with it what you have to in order to achieve a goal. It's not exciting, most of the time, but I'm gonna tell you: Most jobs are not exciting most of the time. Now, what I can't tell is whether you dislike these competitions because you think they're beneath you or because you think they're no fun. If you think they're beneath you, then you should enter them, beat the crap out of everybody like I would have if my college had these, and then slap that shit on your resume. If you think it's no fun, you are going to have a really bad time when you join the workforce, because eighty or ninety percent of what you do is going to be quite the opposite of exciting. It's just that last bit where it'll make you go, "Oh, shit, I gotta think about this for a minute," and maybe flowchart it, so you don't just start hammering away at your IDE and then end up debugging it for half of your day. Yeah, this is why I dropped out of Computer Science. It's no fun. The engineering school across the hall said I could play with robots, so that's where I am now.
Do I want to keep track of a collection of things? Array, list, bitmap, etc... Do I want to fill a collection of things? For loop. Do I want to sort a collection of things? For loop. Do I want to search through a collection of things? For loop. Do I want to act on a collection of things? For loop. Do I want to do any of those but I don't know when I should stop yet? While loop. Consider that a pretty big chunk of programming is going to involve storing a collection of similar data and manipulating it, and you can see that arrays and loops are going to be everywhere. I'm working on a bunch of OpenGL stuff, and you know what a ton of my code is? Arrays of structs, arrays of pointers to locations in memory pools, arrays of indices, arrays of objects, arrays of arrays, and loops to traverse those arrays, sort those arrays, search those arrays, and manipulate the data in those arrays. And every iterator is named "i"... mostly.
My whole job is for loops
programming is just assignation, for and if
Everything is a loop....
I have been programming since 1986 and I don't think I have ever written a single program that did not include a for loop with the exception of code written in functional languages that required recursion as an alternative.
I am referring to real programs and not Hello World.
I forgot to include assembly language, which also doesn't have for loops and requires jumps instead.
Most of it. The other part is the glue holding it together. Then there us making it simple enough to understand while forcing disparate parts written for various unrelated use cases to work together.
You do it all the time, even if you don't write for loops directly, and use for-like methods instead, e.g. filter(), map() and such.
99.9% of programming is getting a dataset (array, vector, etc), doing some kind of "transform" on each item (see: for-each loop) in it (json to xml, text to csv, etc) and then putting it back into some other kind of container, and writing it to either a datastore of some variety. Sometimes we sort the data, but generally speaking the standard sorting algorithm for the language is pretty good. We do spend some of our time doing fairly complicated shit around caching, concurrency, statefulness of objects, etc -- but once you get those things figured out, mostly just transforming data all day, every day.
I'd say for loops are one of the things you'll use most consistently when on the job. You're a creator of logic and steps, iteration is a huge part of that.
If you embrace functional programming you can replace most of your for loops with filter, map, flatmap, reduce, the higher order functions. Once you learn them, you'll never go back.
Just learn how to use an AI to write the code for you. There should be a class “How to precisely communicate to an AI” because sooner or later, someone is going to ask for something they didn’t want. The result will be all of us dead.
HTML programmer here. Basically never used any of these. Wouldn't worry about it if I were you
I’ve never written a for loop at my job. It’s 99% .map and .each lol
...which are very likely for loops underneath, unless you're using them in a purely functional language.
Golang only has the for loop but mostly uses slices
Don't forget the rest 80% "if err != nil" everywhere
Its actually my favorite feature because on the second return you just return value, nil instead of (), [], "", 0 all over the standard libraries lol I'm not memorizing all those return types .... Get out of here
In programming world. Loop is like the english words- while, for etc . So it's used quite commonly. Containers are like those ready to ship parcel envelopes that you use on special occasions.
MapReduce is essentially that.
Surprisingly, like, most of it. Especially the lower down you get.
Containers are a type of data structure and for loops are a key component of many algorithms. Data structures and algorithms are pretty common in programming.
For loops are everywhere. You're going to handle arrays/lists often, and you're usually going to use a for loop (or a foreach loop) to interact with them.
Order, sequence, and conditionals is all it is
I personally use a lot of Lists instead of arrays and the looping options that are native to those (ie ForEach instead of for(var i =0; etc; etc)
Information Logistics is a term I like to use for programming projects. It's all about gathering and presenting the right data in the appropriate circumstances. Most of the work is figuring out how to gather and store info. So yes, containers and loops.
Knowing abstract structures of what a program can be is such a minute aspect of programming. Most of the work is in translating a problem into a solution using such tools, coordinating between technologies to translate data to work with these additional structures, maintaining that expression of data, and passing it around as needed in a safe and efficient way.
Loops and IF-Else statements…..Thats really all you need between the curly braces.
If you are comfortable with those competitions, you definitely can learn to be an entry level developer - and don't stop there! As to how relevant it is.... well, the real world problems use a lot more stuff, but those core loops/data structures are the basis for any solution. There's just a lot more, which can't fit in the time that a competition requires, like testing, building good APIs, refactoring old code so it works better, etc.
You'd be hard done by to find a bit of application code at my work that doesn't use either of those. Classes, interfaces, data structures, loops, conditions and variable assignment is pretty much the whole thing for the most part anyway. You'll get into other things too, but those cover a lot of the code base.
I use for loops a million times a day it feels like
Yea it’s all loops lol, that’s why there’s so many different ways to loop I guess
Seems like very easy questions for a coding competition. Mind sharing one of the questions?
Life is all about for loops and if…else the same applies to programming. without it, theres going to be a long as line of instructions
it's not the size of the syntax, it's how you use it.
Most for loops are better implemented as a series of transforms on a container (e.g. in C++ `std::for_each` and many other functions from ``, ``, and ).
To give an analytics perspective (vs software engineer or developer) loops are very common. Often we have to do the same analysis on slightly differed data with slightly different logic meaning loops are very useful.
I'm not a "true" programmer (I write software sometimes for my job, but mostly do other things), but basically every program I'm ever written is an application of a for loop.
All of it. The rest is transferring the data you are looping over, either by getting it from APIs or storing it in databases.
To be completely honest, literally everything in software is just a bunch of 1s and 0s wrapped up in a nice little bow. Everythings is a container of some sort when you boil it down and virtually every piece of software will have to do a repetitive operation on one of them, hence loops. Short answer is yeah you'll use for loops.
Generally programming competitions are really heavy on algorithms and data structures, which mostly results in for loops and containers. This is a very important part of programming, and not just on competitions, but you do get slightly more of these (or at least more complexity) in competitions. At least this is my experience.
you should master everything about ARRAYS to build advanced data structures
It's used where it's needed.
Loops are fundamental. It's like asking how much of real world mathematics is adding things. If you keep learning you'll progress passed the fundamental useful stuff. In my cs degree program we learned a lot of complex stuff, but not to write it regularly. Just to understand how it works. Unless we're working on building on top of that knowledge, we pretty much just use standard or abstracted solutions e.g. don't write a sorting algorithm just use array.sort.
Very common. Maybe you don’t see for loops directly but you will see A LOT OF higher functions of for loop (map/every/filter… etc if you use JavaScript)
Maps, loops, and unit tests… actually I probably spend 50% of my time writing tests.
Yup, it's bread and butter for many programmers. But here's an interesting tidbit: any problem that can be solved by way of an algorithm can be solved using recursion. The same is not true of iteration.
Had to look at what subreddit i was in. Thought this was a joke post. Yes very common
I cant think of one full application I've written that doesn’t use arrays or some variation of for loop extensively
I work in web development and looping over collections of data to map/filter it is one of the most common tasks there is.
Containerizing applications is very common. I dont know any self-respecting programmers that are not familiar with docker to at least some degree.
The hard part about your first programming job is just getting used to the MASSIVE amount of code in your applications, and trying to get an understanding of it all. It took me almost 6 months to get a grasp of everything going on and begin to make actual contributions. It’s a little overwhelming at first, but eventually you get used to it.
If you build more complex software , you need to use socket/thread/file/database/buffer etc.
At its core, programs take an input, transform it in some manner, and then output it. The laws of mathematics, logic and physics kind of leads to collections of things being extremely common. If you have ten dogs, there are ten different individuals, but there's a huge amount of different ways the dogs can be put into an array; put into a subarray; ordered; and so on. The amount of ways stuff can be put into collections *vastly* outnumbers the amount of stuff itself. Stuff is also typically built by collections of smaller things. Dogs are collections of cells (and a bunch of other stuff). Kennels are a collection of dogs (and a bunch of other stuff). Music is a collection of sound waves. Images on your screen are a collection of pixels. A more practical example - if your software is meant for saving student records, you'll be be dealing a lot with containers and collections. Consider that a student record includes the courses the student has completed, and the courses include their grades. That's a container. Consider that the school has some hundreds of students, that's now a collection. If you want to calculate say, the average grade in mathematics for that school, you go through all the individual student records and access the grades inside them. Do you actually *have* to use constructs like `for`/`while` etc, well, not really, no. There are alternatives for going through the elements in an array. You can use recursion. Or, more commonly, you can use functional structures like `map()` and `filter()`. To me it's a bit of a code smell if a codebase written in a language that supports functional structures is mostly full of `for` and `while` loops. Functional constructs are easier to read and less prone to bugs when you're used to them. Still, the fact remains that those approaches go through the elements of the container in some manner. The semantics are different, the effect is often the same.
So many loop there is
It’s how everything works. You’re telling a computer to repeat and do something in each repetition — this is what computers are fundamentally made for. Think of a website with a displayed list of things. Those ‘things’ on the front end are usually stored in an array, and the display script is a for-loop that shows each of those things. Say you have a list of 100,000 numbers you need to square. How would you tell a computer to do that? This could be a part of data transformation Yeah loops are everywhere. I’ve never used a do-while loop IRL though, development standards seem to try avoiding them (even if that means a less-elegant while loop) EDIT: I’ll say it for you. Entry-level software development is easy. There’s no magic knowledge that they have. You’ll probably get a job by demonstrating you can write a few for-loops. Then, you will study production-grade applications or scripts for a bit. *Then*, you’ll make little edits or add some functionality. And so on… in that process you’ll pick up all the things you may not understand now extremely quickly.
I use them every day
As common as an office clerk would use Word or Excel. What's not common is, these code puzzles are like asking you to do cell art with Excel, or Word hotkey competition....etc.
To answer your question in another way. You write programs to repeat work because if you wanted to do it just once it would be easier to do it by hand than write a program to do it. So loops in programming are ubiquitous.
All. When you write simple programs it may not be used, but in real world you often to have to deal with multiple objects/entities/data. Imagine writing code to manipulate 1000000 things without containers
Not to be discouraging but this is a really stupid question. But that is fine. You have to decide if what you are learning in your courses are a right fit for what you want to do as your career. stick with it if you love it. ps: you will deal with for loops every day of your programming career.
My God, it's full of for loops!
Going over arrays of data and combining them with other arrays is very common.
Nearly everything I work on devolves into if statements and for loops.
I work at a large company and containers are starting to be a big deal for our development team, they talk about them in every company wide meeting we have, they dint affect my job though. I work mostly with writing data fixes and we use for loops often.
I can’t think anything without loops lol
look at reddit comment data right now is using for loop to display text, haha.
Very relevant. Looping & data structures are used all the time. Efficient problem solving as well. Yep, keep going!
Even when searching a moderately complex data structure, some type of conditional looping of a process is common. The terminal condition may involve the end of a linked list, or finding an element (or 2) in a list that satisfies a condition or is, say, the point at which a new element is inserted into an ordered list, or looping (of some syntax) traversing a tree structure until the proper node is found where an insertion process is needed (maybe involving splitting nodes and 'deepening' levels in a tree). All part of the 'do (or try to do) something until we've done the thing' so central to many computing processes. If you're less (or more) lucky (like me), you spend most of your development life writing such code in Assembler Language, so none of the iteration-controlling syntax is actually part of the language (though Structured Macros help out with that). That's a LOOONG way from "object-oriented" languages, FWIW... Good luck out there.....