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
2018-01-04, 02:02 PM
Post: #23
RE: someone can teach me what is vector3?
(2017-10-08 05:57 PM)jcordeiro Wrote:  
(2017-10-08 02:05 PM)Gladyon Wrote:  But the most important thing is that all the 'easy to make code' and 'slow languages' are very important for at least these reasons:
- faster to code (it's better to have a slow program rather than no program at all)
- faster to debug (the editors have access to more information than just a bunch of compiled instructions, so it can help you, and will help you find bugs)
- you can do things that are nearly impossible with these modern languages (I say nearly because with years and a lot of expertise it is possible to do everything)

But that brings us to 2 other aspects of this new era:

1 - Most programmers now, understand 0% about how the hardware processes their code, they dont know what a file pointer is, what a stack counter is, what a bus is, they just use some line they googled and expect it to do the job. They have no clue that their program is reducing the hardrive expected lifespan because their program is constantly forcing the disk to reset. They don't know that running their code with a x^3 algorithm is only good for the 1st 1000 items and they only tested with 100 items. They just do crappy code, full of bugs, then they fix those bugs with glue and more bugs...

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.

But then comes the Big Problem with "libraries + low cost programs":
A vulnerability is found:
  • The impact?
    A single vulnerability in a common library will impact almost every program in that language that does that type of operation, we are talking about millions of computers affected by a single bug despite they are not using the same programs.
  • What does it mean?
    Depending how deep the library is used, most programmers will not know that their program is affected at all. And if they know, they dont know how, and how bad it is.
    They will also be unable to supply any type of quick work around to prevent hacks while they fix the code.
  • Who will fix it?
    Depending how deep the library is used, it may not be up to the programer to fix it:
    Imagine you use your program, mycrap.jar uses middle.jar, and middle.jar uses affected.jar.
    affected.jar is a main lib that was found to have a security bug, after 5 days they send a affected.fixed.jar out.
    Then the mycrap.jar will have to wait for a fixed middle.jar. but middle.jar is now a dead project and will never be fixed.

    Who support the cost of remaking mycrap.jar to not use middle.jar??
  • How to fix it?
    Most fixes will come to the new versions of the affected library.
    So will the programer wait for some miracle that makes his version of the library fixed? Or will he support the cost of rewriting his app?

So using googled libraries creates a world where a single bug affects millions of devices and makes bug fixes nearly impossible.

The obvious answer is:
No one fixes old programs anymore, just buy a new device with a new OS and install the latest app. Then you may be good for 2 years until you should get a new device with a new os and a new app.....

Sad programing times....

well, I did that cuestiom because I want to learn
1: how can I use the vector 3
2: I want to understand how the system ejecute that code, because that's the way of how I program, If I didn't learn to program like that, I can't program in at least 7 different languages (but still not at a very hig level)

****warning: a crazy engineer is in the thread****

Totally not me!!!!
Find all posts by this user
Quote this message in a reply
Post Reply 

Forum Jump:

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