TR Forums

derFunkenstein wrote:

The problem is time. In two or four years you can't possibly learn every single real-world application or cover every single scenario you're going to run into. Reading and writing text files in the file system (like Vhalidictes' situation) might be a pretty extreme example, but I've run into stuff at work quite often that wasn't covered in a course, and my guess is that every person in this thread has, too.

I probably learned more practical stuff in my first year working full time than I did in 4 years of classes.

To a large extent, a career in tech means learning how to learn, whether that is in school, or on the job. If you're not constantly learning, you run a risk of becoming obsolete (worst case), or getting stuck in a job where they eventually take you for granted.

Yeah, your programming classes aren't going to teach you exactly how to code every situation. What they SHOULD do is teach you how to problem solve and how to approach problems by using programming techniques.

just brew it! wrote:

derFunkenstein wrote:

The problem is time. In two or four years you can't possibly learn every single real-world application or cover every single scenario you're going to run into. Reading and writing text files in the file system (like Vhalidictes' situation) might be a pretty extreme example, but I've run into stuff at work quite often that wasn't covered in a course, and my guess is that every person in this thread has, too.

I probably learned more practical stuff in my first year working full time than I did in 4 years of classes.

To a large extent, a career in tech means learning how to learn, whether that is in school, or on the job. If you're not constantly learning, you run a risk of becoming obsolete (worst case), or getting stuck in a job where they eventually take you for granted.

This is definitely true; the root cause for my ignorance is that I've never programmed professionally. File handling is so basic that I'm sure that would have become a solved problem very quickly.

In my own career I worry about the next generation. Yes, Google is your friend and solving a problem quickly can be an overriding concern in some cases, but troubleshooting is becoming a lost art.

I had someone ask me the other day why I had a whiteboard, in almost the same breath as they asked why it was so messy with old diagrams. This person has easily five years of network engineering experience, they really should have known better.

Yeah, no kidding. I put everything on my whiteboard. I can't imagine someone in networking not doing the same, or at least not having some other way of physically mapping things out. At least with software a lot of it is intangible, but a network is a real, physical thing.

Vhalidictes wrote:

just brew it! wrote:

derFunkenstein wrote:

The problem is time. In two or four years you can't possibly learn every single real-world application or cover every single scenario you're going to run into. Reading and writing text files in the file system (like Vhalidictes' situation) might be a pretty extreme example, but I've run into stuff at work quite often that wasn't covered in a course, and my guess is that every person in this thread has, too.

I probably learned more practical stuff in my first year working full time than I did in 4 years of classes.

To a large extent, a career in tech means learning how to learn, whether that is in school, or on the job. If you're not constantly learning, you run a risk of becoming obsolete (worst case), or getting stuck in a job where they eventually take you for granted.

This is definitely true; the root cause for my ignorance is that I've never programmed professionally. File handling is so basic that I'm sure that would have become a solved problem very quickly.

In my own career I worry about the next generation. Yes, Google is your friend and solving a problem quickly can be an overriding concern in some cases, but troubleshooting is becoming a lost art.

I had someone ask me the other day why I had a whiteboard, in almost the same breath as they asked why it was so messy with old diagrams. This person has easily five years of network engineering experience, they really should have known better.

That is a really strange question for someone to ask, as whiteboards are very widely used.

whm1974 wrote:

That is a really strange question for someone to ask, as whiteboards are very widely used.

A lot of the younger people in my office pride themselves on being able to understand a large wide area network in their head. As far as I can tell they see drawing everything out as unnecessary work.

I'm sure this is possible. It's also possible to ride a bicycle to work, but that doesn't make it a good idea.

One concrete problem that I've noticed from them avoiding whiteboards is confusing whether an issue is layer-2 or layer-3. Logical and physical pathing are frequently different and things can get really confusing with startling speed if you're working without a diagram.

Vhalidictes wrote:

whm1974 wrote:

That is a really strange question for someone to ask, as whiteboards are very widely used.

A lot of the younger people in my office pride themselves on being able to understand a large wide area network in their head. As far as I can tell they see drawing everything out as unnecessary work.

I'm sure this is possible. It's also possible to ride a bicycle to work, but that doesn't make it a good idea.

One concrete problem that I've noticed from them avoiding whiteboards is confusing whether an issue is layer-2 or layer-3. Logical and physical pathing are frequently different and things can get really confusing with startling speed if you're working without a diagram.

Yeah it is hard to solve complex problems without writing stuff down or drawing diagrams. Trying to keep track of a bunch of stuff in your mind can be impossible.

Ryzen CPU?..........

AbRASiON wrote:

Ryzen CPU?..........

?

derFunkenstein wrote:

I dunno if it's the specific curriculum selected for the classes or what, but it feels like 90-95% of what I'm doing is applicable in the real world in different ways. It started very early as teaching things like do loops and breaking up things into methods using real-world items like CLI menus and has progressed steadily towards segmenting business logic from the UI by creating two UIs that use the same "backend" stuff.

It depends on the emphasis of the college and professors. Some colleges are focused on prepping people for MS and PhD work, and others are focused on teaching.

The university I attended was very focused on low-level coding and high concepts, which I really liked, but the most useful thing I ever learned is how to deal with floats. (Amazingly, computers can't really handle floats, and it's kind of smoke and mirrors.) It wasn't how a compiler works, AI work, or distributed programming, although distributed programming is second.

The problem is time. In two or four years you can't possibly learn every single real-world application or cover every single scenario you're going to run into. Reading and writing text files in the file system (like Vhalidictes' situation) might be a pretty extreme example, but I've run into stuff at work quite often that wasn't covered in a course, and my guess is that every person in this thread has, too.

I agree with this, and it's something to keep in mind. I'm mainly thinking of things like how to use cmake or autotools that people don't learn how to use.

I never wrote out binary data in college. It was all parsable text files.

just brew it! wrote:

AbRASiON wrote:

Ryzen CPU?..........

?

The bug where Ryzen CPUs were throwing faults when compiling software under Linux.

FlamingSpaceJunk wrote:

just brew it! wrote:

AbRASiON wrote:

Ryzen CPU?..........

?

The bug where Ryzen CPUs were throwing faults when compiling software under Linux.

I thought that was fixed already? Still a problem?

whm1974 wrote:

FlamingSpaceJunk wrote:

just brew it! wrote:

?

The bug where Ryzen CPUs were throwing faults when compiling software under Linux.

I thought that was fixed already? Still a problem?

AFAIK yes (it has been fixed). I stopped following the thread over on the AMD forums a while back after it seemed like it was under control. Guess I'll take a peek and get a feel for what people are saying in subsequent followup chatter.

So AbRASiON is either trying to make a joke or didn't read the thread before posting...

FlamingSpaceJunk wrote:

It depends on the emphasis of the college and professors. Some colleges are focused on prepping people for MS and PhD work, and others are focused on teaching.

The university I attended was very focused on low-level coding and high concepts, which I really liked, but the most useful thing I ever learned is how to deal with floats. (Amazingly, computers can't really handle floats, and it's kind of smoke and mirrors.) It wasn't how a compiler works, AI work, or distributed programming, although distributed programming is second.

Well in my specific case it's a junior college. The whole point is to be functional writing software. Theory is important, I know, but I'll leave that to the real big brains. I feel like I'm barely scraping by. Lol

Especially around here.

The most common stuff that I use regularly from the theory side is on the running time of algorithms. Knowing what it means for an algorithm to run in "linear time", and knowing how to spot an algorithm that won't scale very well once there's a bunch of stuff running through it can be quite useful even for a web developer where everything has to be sent over the wire anyway.

just brew it! wrote:

whm1974 wrote:

FlamingSpaceJunk wrote:

The bug where Ryzen CPUs were throwing faults when compiling software under Linux.

I thought that was fixed already? Still a problem?

AFAIK yes (it has been fixed). I stopped following the thread over on the AMD forums a while back after it seemed like it was under control. Guess I'll take a peek and get a feel for what people are saying in subsequent followup chatter.

Gist of the chatter over on the monster gcc segfault thread at the AMD forum seems to be that yes it has been fixed, but there are still some older chips in the distribution channel (looks like a couple of people received buggy Ryzens in recently purchased pre-built systems). AMD's RMA procedure has some issues, which has been causing heartburn; but once people with affected CPUs receive their replacements they seem to work.

(This is my educated guess based on skimming the past few weeks' worth of posts; it's not 100% definitive since the S/N ratio isn't fantastic.)

Redocbew wrote:

The most common stuff that I use regularly from the theory side is on the running time of algorithms. Knowing what it means for an algorithm to run in "linear time", and knowing how to spot an algorithm that won't scale very well once there's a bunch of stuff running through it can be quite useful even for a web developer where everything has to be sent over the wire anyway.

Yes... simple algorithms which may work just fine for a "toy" programming exercise can fail spectacularly when faced with production workloads/datasets if the algorithm doesn't scale well!

You can broadly classify algorithms into exponential, linear, or logarithmic, based on how execution time scales with dataset size. If your dataset can be very large, you want an algorithm with logarithmic behavior if at all possible (unless your users don't mind waiting), and exponential algorithms are inviting "the application just hung on me, I had to kill it" type complaints.

Oh the maddening Big O notation.

We had to seriously focus on Big O in "Discrete Structures." One of the hardest classes I have ever taken. You had to have had at least a year of C++ first as well as Cacl 2 (of the engineering variety). This is how they describe it at my school.

Mathematical foundations including logic, sets and functions, general proof techniques, mathematical induction, sequences and summations, number theory, basic and advanced counting techniques, solution of recurrence relations, equivalence relations, partial order relations, lattices, graphs and trees, algorithmic complexity, and algorithm design and analysis. Throughout there will be an emphasis on the development of general problem solving skills including algorithmic specification of solutions and the use of discrete structures in a variety of applications.

The worst part was that it was a freshman or sophomore year class depending on how far along you were in the progression (freshman for me )

I did ok in discrete structures, but I had three semesters of calculus by then, and had been coding for a few years already. At my school discrete structures 1 I think was a sophomore class, and the second semester was a 300-series class. Maybe the fact that they broke it up into two courses is part of what made it more tolerable. I had one instructor which described it as a potpourri of math for CS students.

A few things just didn't stick at first. Induction kicked my ass, but it seemed to do that to everyone else as well, and I'm not sure I ever really understood matrix multiplication. The rest of it was ok. I vaguely remember most of it.

DancinJack wrote:

This is how they describe it at my school.

Mathematical foundations including logic, sets and functions, general proof techniques, mathematical induction, sequences and summations, number theory, basic and advanced counting techniques, solution of recurrence relations, equivalence relations, partial order relations, lattices, graphs and trees, algorithmic complexity, and algorithm design and analysis. Throughout there will be an emphasis on the development of general problem solving skills including algorithmic specification of solutions and the use of discrete structures in a variety of applications.

At the end of the day, you don't really need to have a formal understanding of all of those disciplines though; just the "logic" and "general problem solving skills including algorithmic specification of solutions" will get you by. You can usually do a reasonable job of estimating scalability just by analyzing the code and asking yourself: "As the dataset gets bigger, how will that affect the number of times this algorithm will loop and the amount of memory used?"

Yeah I didn't mean to say that was the case. I just found it to be a really tough class for me (and everyone else in it at the time).

So many proofs

just brew it! wrote:

Redocbew wrote:

The most common stuff that I use regularly from the theory side is on the running time of algorithms. Knowing what it means for an algorithm to run in "linear time", and knowing how to spot an algorithm that won't scale very well once there's a bunch of stuff running through it can be quite useful even for a web developer where everything has to be sent over the wire anyway.

Yes... simple algorithms which may work just fine for a "toy" programming exercise can fail spectacularly when faced with production workloads/datasets if the algorithm doesn't scale well!

You can broadly classify algorithms into exponential, linear, or logarithmic, based on how execution time scales with dataset size. If your dataset can be very large, you want an algorithm with logarithmic behavior if at all possible (unless your users don't mind waiting), and exponential algorithms are inviting "the application just hung on me, I had to kill it" type complaints.

JBI, the most interesting parts of the classes I did take was breaking down problems into algorithms, and one of my professors talked (frequently) about the idea that learning how to approach something at a high level was necessary to every programming language, and took us though various types of pseudo-code and markup languages.

Since we were working with three different languages at once due to the CS program being in flux, he illustrated how programs were largely organized the same independent of the high level language used (and did cover how we shouldn't try this approach to assembly/low-level languages).

It was all really interesting to me. I probably should have kept going, even after the disastrous MUMPS debugging internship.

Vhalidictes wrote:

JBI, the most interesting parts of the classes I did take was breaking down problems into algorithms, and one of my professors talked (frequently) about the idea that learning how to approach something at a high level was necessary to every programming language, and took us though various types of pseudo-code and markup languages.

Since we were working with three different languages at once due to the CS program being in flux, he illustrated how programs were largely organized the same independent of the high level language used (and did cover how we shouldn't try this approach to assembly/low-level languages).

I think I would have to disagree with the last bit. The same top-down approach still applies to breaking a problem down into manageable steps. The translating of those steps into actual code is just more involved, because you're essentially playing the role of the compiler yourself.

Vhalidictes wrote:

It was all really interesting to me. I probably should have kept going, even after the disastrous MUMPS debugging internship.

Oh, good lord... there's a language I'd forgotten about. I think they taught us that as one of the parts of a course that was jokingly referred to as "Language of the Month Club".

FlamingSpaceJunk wrote:

The university I attended was very focused on low-level coding and high concepts, which I really liked, but the most useful thing I ever learned is how to deal with floats. (Amazingly, computers can't really handle floats, and it's kind of smoke and mirrors.) It wasn't how a compiler works, AI work, or distributed programming, although distributed programming is second.

Computers do handle floats really well. They even have ridonkulously quick floating point units. With vector units you even get better floating point throughput than ints. Then we have GPUs which are really just gigantic arrays of FPUs. Of course, don't confuse floats with what mathematicians call REAL numbers...

Now, back in the day commonly available computers such as those your parents might buy for the family could only handle 8-bit integers - slowly. And then fairly limited at that - just addition, subtraction, shifting left and right and Boolean operations. Fun stuff like ray tracing and exploring fractals required high precision integer or floating point calculations. So, just to multiply two 32-bit numbers required HUNDREDS of basic 8-bit instructions. I wanted to do ray tracing on my Commodore 64 so had to write my own 32-bit floating point math library that could do maybe 1000 multiplies per second, a couple of hundred divides and maybe 50 Newton-Raphson square roots. Which was maybe 10-50x faster than the built-in BASIC math library. Even then, rendering a single 32000 pixel (2 bits per pixel) ray traced frame would take hours. I had a rag-tag collections of old Commodores (C64, C128, Plus/4) and one floppy drive so build my own "render farm" using them and writing rendered frames to the 1541 floppy drive. Next problem. 20 frames = 160KB which was a bit more than the 64KB RAM in the C64 which also needed 16KB of that for page flipping frame buffers. Yep, rolled my own video compressor which was good for maybe 7-8 FPS. Fully ray traced video demo!

Pancake wrote:

FlamingSpaceJunk wrote:

The university I attended was very focused on low-level coding and high concepts, which I really liked, but the most useful thing I ever learned is how to deal with floats. (Amazingly, computers can't really handle floats, and it's kind of smoke and mirrors.) It wasn't how a compiler works, AI work, or distributed programming, although distributed programming is second.

Computers do handle floats really well. They even have ridonkulously quick floating point units. With vector units you even get better floating point throughput than ints. Then we have GPUs which are really just gigantic arrays of FPUs. Of course, don't confuse floats with what mathematicians call REAL numbers...

Now, back in the day commonly available computers such as those your parents might buy for the family could only handle 8-bit integers - slowly. And then fairly limited at that - just addition, subtraction, shifting left and right and Boolean operations. Fun stuff like ray tracing and exploring fractals required high precision integer or floating point calculations. So, just to multiply two 32-bit numbers required HUNDREDS of basic 8-bit instructions. I wanted to do ray tracing on my Commodore 64 so had to write my own 32-bit floating point math library that could do maybe 1000 multiplies per second, a couple of hundred divides and maybe 50 Newton-Raphson square roots. Which was maybe 10-50x faster than the built-in BASIC math library. Even then, rendering a single 32000 pixel (2 bits per pixel) ray traced frame would take hours. I had a rag-tag collections of old Commodores (C64, C128, Plus/4) and one floppy drive so build my own "render farm" using them and writing rendered frames to the 1541 floppy drive. Next problem. 20 frames = 160KB which was a bit more than the 64KB RAM in the C64 which also needed 16KB of that for page flipping frame buffers. Yep, rolled my own video compressor which was good for maybe 7-8 FPS. Fully ray traced video demo!

I didn't know that you could do ray tracing on a C64/C128/. I bet that was a lot of work setting all of that up. how did you "networked" them together?

Pancake wrote:

FlamingSpaceJunk wrote:

The university I attended was very focused on low-level coding and high concepts, which I really liked, but the most useful thing I ever learned is how to deal with floats. (Amazingly, computers can't really handle floats, and it's kind of smoke and mirrors.) It wasn't how a compiler works, AI work, or distributed programming, although distributed programming is second.

Computers do handle floats really well. They even have ridonkulously quick floating point units. With vector units you even get better floating point throughput than ints. Then we have GPUs which are really just gigantic arrays of FPUs. Of course, don't confuse floats with what mathematicians call REAL numbers...

Yeah, I assume FSJ is complaining about the difference between binary floating point, decimal floating point, and real numbers. The first two will always be an approximation whenever you're dealing with a fractional number that doesn't have an exact representation in base 2 or base 10, respectively. Conversion and roundoff error is an endless source of confusion for n00b programmers when dealing with floats.

whm1974 wrote:

I didn't know that you could do ray tracing on a C64/C128/. I bet that was a lot of work setting all of that up. how did you "networked" them together?

You can do anything - albeit at a certain scale and speed - with even a lowly 8-bit computer. Start with the basic building blocks. Write a simple arithmetic library. Use that to write more complicated operations - square root, trigonometric functions, exponents etc Use that to write a linear algebra library - matrix multiplication, inversion etc Use that to write fundamental operations of ray-tracing - sphere/plane intersection etc. By the time you write all these little layers the actual task of writing a ray tracer is pretty simple and you're only dealing with the abstractions of how to manage your geometry scene model, eye position, animations etc. But, obviously, you learn a whole lot more than just writing a script for Lightwave for example.

But, you gotta start somewhere and be brave enough to imagine that you CAN end up somewhere altogether more complex. Focus on the coding. Why do you think you need a new monitor when I can do so much with a 40x25 text screen displayed on a fuzzy little colour tv?

Pancake wrote:

whm1974 wrote:

I didn't know that you could do ray tracing on a C64/C128/. I bet that was a lot of work setting all of that up. how did you "networked" them together?

You can do anything - albeit at a certain scale and speed - with even a lowly 8-bit computer. Start with the basic building blocks. Write a simple arithmetic library. Use that to write more complicated operations - square root, trigonometric functions, exponents etc Use that to write a linear algebra library - matrix multiplication, inversion etc Use that to write fundamental operations of ray-tracing - sphere/plane intersection etc. By the time you write all these little layers the actual task of writing a ray tracer is pretty simple and you're only dealing with the abstractions of how to manage your geometry scene model, eye position, animations etc. But, obviously, you learn a whole lot more than just writing a script for Lightwave for example.

There were some surprisingly (to people who didn't live through that era) complex things done back in the 8-bit days. Full Pascal, C, Fortran, and COBOL compilers were available, for example. MP/M was a multi-tasking, multi-user version of CP/M. My summer job for two years of college was working on a clone of the UNIX typesetting tools troff and tbl for CP/M.

Pancake wrote:

But, you gotta start somewhere and be brave enough to imagine that you CAN end up somewhere altogether more complex. Focus on the coding. Why do you think you need a new monitor when I can do so much with a 40x25 text screen displayed on a fuzzy little colour tv?

This is why I keep saying "stay focused". @whm, you just spent a bunch of time researching which 4K monitor/TV to get, when you can't even afford one now anyway. You'll need to do at least some of that research again when it comes time to buy since the market will have shifted, so the effort was partly wasted.

You could've been making progress on your stated goal -- learning how to program -- instead.

If you really feel you need more screen space, use your laptop to pull up documentation, and code on your desktop; or set up dual-head with a second-hand monitor like I suggested before. Free (or nearly free), and no research required. As I've already noted, I only use a 4K at work because I didn't have to pay for it; at home I have a cheap 21" 1080p and a couple of ancient 17" SXGA (1280x1024) LCDs in triple head... and I have a decently paying full-time job, so I am not as budget constrained as you are.

just brew it! wrote:

Oh, good lord... there's a language I'd forgotten about. I think they taught us that as one of the parts of a course that was jokingly referred to as "Language of the Month Club".

I went to the Wiki page for it to make sure I wasn't insane (or mis-remembering), but yep, the source is commands abbreviated to single letters and spaces are sometimes omitted. Insanity.

I still remember writing a script to un-compress the source text so I could actually read it. Not that it helped too much since the programs I was looking at were truly massive.

Vhalidictes wrote:

just brew it! wrote:

Oh, good lord... there's a language I'd forgotten about. I think they taught us that as one of the parts of a course that was jokingly referred to as "Language of the Month Club".

I went to the Wiki page for it to make sure I wasn't insane (or mis-remembering), but yep, the source is commands abbreviated to single letters and spaces are sometimes omitted. Insanity.

I still remember writing a script to un-compress the source text so I could actually read it. Not that it helped too much since the programs I was looking at were truly massive.

I thought I heard of MUMPS before, so I also checked the Wikipedia.org page. Sure enough I had heard of MUMPS back when I used to volunteer at a hospital back in my late teens. Anyway looking at the code it sure does look like a nightmare language to program in.