Post Reply 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
someone can teach me what is vector3?
2017-10-10, 01:18 AM
Post: #21
RE: someone can teach me what is vector3?
Apologies for jumping onto an earlier post, but:

(2017-10-08 05:57 PM)jcordeiro Wrote:  2 - Most programmers now dont actualy "program", they just google libraries that do what they want and glue them together. The amount of code they actually do in the program is less then 1/10000.
This is would not be a actual problem if those programmers took the time to read the code inside those libraries before they use the code. But they don't.
They just blindly trust that guy they just heard about 10 minutes ago on their "java png to jpg" search.

I am a software engineer at Google--major user-visible applications (search, YouTube, GMail, etc.) each depend on tens or hundreds of millions of lines of code. Their developers have not read all that code--reading, let alone understanding, it would be a lifetime of work, even ignoring the tens of thousands of lines of daily changes to those dependencies.

But remember that saying "If I have seen further it is only by standing on the shoulders of giants." The crowning achievements of software engineering address seriously difficult problems, and could not be achieved so compactly as to be understood by one person. The foundation of modern software engineering is libraries with well-designed interfaces and minimal surprises, and client developers who respect the API (which is very different from reading the library and understanding its internal quirks--as a library writer I hate that sort of client, because they tend to rely on implementation details in ways that make it impossible for us to improve our library without first fixing their "cleverness").

So yes, I agree that it is possible to turn out bad code by stitching together Stack Overflow library calls without understanding what is happening. But it is equally possible to turn out bad code by stitching together re-implementations without understanding them either. But libraries, and being able to use libraries without reading their code, is essential to being able to tackle hard problems.

Allr andask.
Find all posts by this user
Quote this message in a reply
2017-10-10, 06:53 AM
Post: #22
RE: someone can teach me what is vector3?
(2017-10-09 11:08 PM)jcordeiro Wrote:  I'm all up to reusability, maintenance and fast prototyping, and i know C sucks at that.
My point is that a easy language + good hardware is no excuse for a programer to do crappy code.
I'd go further.
There is no excuse for crappy code, whatever the conditions.

(2017-10-09 11:08 PM)jcordeiro Wrote:  And i'm all up using Opensource know libraries and not reinventing the wheel. But that is no excuse for you to ignore what's inside them! You should take a look inside, at least at the headers of the functions and their sub functions.

I know there are good programmers out there, in any language. Im not saying java or C# programmers are bad.
What i am saying is that those languages allow for complete ignorant ppl to have a low paying job in programing crap.

Yes, the worse in it is that good programmers are less paid because they can be replaced easily by other programmers, because managers don't care about code quality and efficiency, they do care only about the quantity, which is silly as a smaller code is nearly always more manageable than a larger one for the same features.

(2017-10-09 11:08 PM)jcordeiro Wrote:  C does not allow that. Even if you are a really bad C programer, you have a guaranteed know how about computers.

There I do not agree.
There are a lot of C programmers that do not know how their language work.
An I think that the computer is not only the hardware, it's also the OS, assembly language and compiler or interpreter (whichever will be used with the software).
All C programmers do know that a computer has limited memory and CPU power, but a lot less do not know how the compiler interpret their code, how it may, or may not, optimize some code depending on how it is written in C.

For example, I remember having read than on an 80386 if you had a loop with a lot of iterations it was better to split it up by nesting loops.
After a loop had iterated 1000 times (example value, I don't remember the exact one...) the total number of iterations to do was offloaded from the register it was stored in to the main memory, so it had to be taken from memory at each following iteration, which is of course a lot slower.
Nowadays, caches levels, pipelines and branch prediction are more important than CPU clock, but only a handful of people know about them (as for me, I just know they exist, I have no idea of how they do work, except a bit for the cache levels, but only a bit...).

I saw some very horrible things written in C, especially on micro-controllers.
Especially with people who do not know how to handle interrupts (same thing with threads on PC).
In addition, nearly nobody follows clear and clean coding rules (such as "a function must not return a global value", it took me days to find a bug caused by that...).
Well chosen, these rules can avoid many bugs, but people don't like rules...

I'm no expert in programming, I know a lot of people a lot more technical than me.
In fact, I rely on my experience and on trials and errors.
For example, when coding my mods for FtD, I do not understand half of the FtD code I modify.
I just 'feel' that it should work 'like that', and try it.
80% of the time I'm on target, 19% of the time there's a problem I fix in a few minutes, 0.9% of the time I do not see the problem at once and have to fix it 2-3 days later, and 0.1% of the time it evades me and creates a bug in the mod that is discovered weeks later.
If I had to understand fully FtD code before modding, I would still attempting to write a text in a box...

The thing is: I test what I do.
My tests aren't 100% coverage, but with years of experience I know where most of the bugs come from, so I know where to look.
Most programmers just test the nominal cases, not the cases where there's a problem:
- what happens if there's a white-space in that file name?
- what happens if there are Chinese characters in that file name?
- what happens if the file name is longer than 255 character?
- what happens if there's no more room on the HDD when I write in the file?
- what happens if the file size is over 4Go?
- etc.
Most of these will crash a software, actually the 255 characters limit will crash FtD... Sad

(2017-10-09 11:08 PM)jcordeiro Wrote:  Just sad times..
BTW: My job is to detect and identify bugs at a major European telecom company.
So i spend my working day seeing how some programer forgot that he can't share a java class instance with multiple threads...
Or how a bugfix creates 2 more bugs...
Or how a bug is labeled "Don't Fix" because only 100 clients use that....

Sorry to hear that, findings bugs in software isn't very appealing, I hope you manage to have some fun in your job.
I understand what you endure, especially with the 'don't fix' thing. I saw several times managers hiding bugs to the clients.
The worse thing is I worked for some time with safety software: artificial heart, braking systems for an airliner, alarm systems for a nuclear plant, etc.
So, seeing people ignore bugs just to gain a few more bucks or not lose a few days was... real ugly...

I even saw the test plan for a braking system of a high speed train, all the tests results were OK.
If you looked at the code test, for some tests you could see only one line of code: "return true;" and a few comments "Should work fine", "Too complex to test", etc.
Whatever the language, this is not what I call "good work"...

And just for the sake of the argument over 'easy languages'.
I have developed an algorithm in C# that is making full use of both DATA and CODE cache.
It is nearly as fast as it can be theoretically. I mean, if you count the minimum cycles necessary to do the required operation, then in this case C# is nearly achieving it.
So, in this case C wouldn't be really better.
The thing is it took me 3 months to do that, while I could have done it in 3 days without such a drastic optimization.

That means that C# can be optimized. Not in all cases, but in most of them.
The problem is that by doing that you lose the main advantage of C#: low cost and fast dev.
So, between efficiency, cost, ease of maintenance, and bug ratio, a balance has to be found for each project.
Find all posts by this user
Quote this message in a reply
Post Reply 

Forum Jump:

User(s) browsing this thread: 1 Guest(s)