Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I did agree with you at first. But the more I read, the more "except that"s I've noted.
Yes, understanding how hardware works helps one to be a more efficient developer. Understanding HW does help to build more efficient code. But the truth is, noone really wants this overly efficient code, except highly-technical people. Business does not care if you make the app run 100ms/s faster. That's not what they'll be paying big bucks for.
Business pays for the idea that generates revenue and for implementation of that idea. Making it run faster - well, that's just nitpicking. Only when the app is considerably too slow (so that UX is seriously in trouble) will the business be interested to invest resources to get that sorted.
And HI level languages - they do serve their purpose and they are quite efficient. Not as much as lo-level, but good enough for the revenue.
I am sorry, I also am a guy who prefers hi-perf lo-levels.but the reality is not what I'd like it to be. Business is harsh. -
Agree. It's not like everything has to be written in C/C++. Sure, that would give more performance, but it would also take longer to develop, and if the customer doesn't need the performance, he just won't pay for it.
BUT! If you write high level and leverage abstractions, you still need to know WHAT exactly they abstract and what's going on "under the hood" so that you can use them in the right way. -
@BoomRaccoon bare metal hasn’t changed much.... it’s the abstraction that has changed. Much of the abstraction is not needed.
-
@Fast-Nop EXACTLY! thank you that is what I’m trying to convey.
You and I both know, many of the developers of which I consider more “integrators” are such as they only really configure the SDKs and API per the application layer for the customer needs and thus the extent of their existence and knowledge. They know no further than the walls of the library they use. If only they looked beyond the walls to the common foundation that the industry is built on but has mostly been “hidden” or shielded from the newer generations of programmers.
Maybe it’s the whole pointers thing..... if people understood pointers more and colleges taught it sooner rather than tip toe around it for fear of loosing students in the department. For it being considered too complex.... what’s funny is for many years pointers were natural and easy to understand but when the abstractions came suddenly pointers became something of dark magic, and thus to be fear of.
I’m not sure why or who started that notion.
The pointers discussion is like the birds and bees talk... but oddly instead of talking about pointers sooner everyone wants to wait longer and longer before teaching them. Lol -
@QuanticoCEO There's two basic things that people either get quickly, or they just don't have that part of the brain: pointers and recursion. That used to be used for weeding out the incapable ones.
But the courses were watered down for two reasons. Specifically in the US, unis make money from the number of students, not from quality. And next, the industry demands higher supply for work that is cheap in every way.
That leads to abstractions that don't actually serve managing complexity, which would be a good thing. Instead, over-abstracted, inefficient and even error-prone programming models have become the norm because too many people are just stitching shit together and are happy if it works at all. Almost. Somehow. Most of the time.
The CMS hype from the mid-2000s is a good example, and that something like WordpRess powers a third of the internet is a horrible consequence. -
@BoomRaccoon "Jack of all trades, master of none. Often times better than the master of one"...
-
@jinx YES!!!!!!!!!!
-
@dUcKtYpEd I’d have to disagree. I’ve never put that many hours in one feature ever that’s absurd and clearly the feature wasn’t defined enough, and not well thought out.
I’ve done both high level mobile development as well as low level development and everything in between like MFI program to interface embedded hardware with mobile apps.. I’ve done both sides of the spectrum.. and I can assure you timing schedules for releases and features are no different in either spectrum. -
@dUcKtYpEd The thing is that a certain amount of low level mentality makes you a better dev, even when you're doing JS.
Say when mucking around with the scroll handler, someone with a certain low level mentality will treat it like an interrupt, and you never do serious business in an interrupt.
Also, you see a lot of crap out there that abuses JS for animations, especially via jQuery, instead of using CSS, and then even animating properties that don't enjoy GPU acceleration.
Or stuff that doesn't need JS at all and should be done as HTML or CSS.
None of these examples would take disproportionately more dev time to get it right, and a good web dev will know what to choose because he has taken the time to research what's going on under the hood. -
@dUcKtYpEd, these different “concerns” you are referring to are essentially horse blinders..... that restrict you into these compartments you describe, front end backend, low level high level etc thus resulting in the coercion and synchronicity between declines are lost.
The way the industry is taught create a huge lapse in knowledge between people going from high level to low level but oddly the inverse shows no adverse effects.
If everyone had this common knowledge foundation, and was taught low level first and worked their way up to the higher abstractions I think the industry would be sooooooo much further ahead and we would have more robust systems and less issues....
Instead we allow people to jump right into web dev front end without understanding backend .... or web dev backend without understand the hardware. Or straight into mobile app development without understanding embedded.
And they end up lost when their code doesn’t work or performs poorly, or have issues they can’t solve because they relied on some 3rd party system or api of which they have no control over and are only using a fraction of the 3rd parties system capabilities.. but hey let’s load a whole api for two features... nobody cares about program space anymore....
One day these poor decisions will come back to hunt the industry. -
@dUcKtYpEd That's the thing - doing it right doesn't take more time than doing it wrong. You "just" have to know which is which. Every kind of dev has something like this. Frontend, backend, embedded, you name it.
Sure, figuring that out the first time does take time. BUT, if the job is so tightly scheduled that there's no time for self-improvement, then it's a dead end because there's no room for self-development and improvement.
It's a dead end because it won't keep you employable in the long run. You may churn 70 hours per week in your 20s, but there's no way you'll do this in your 40s. You'd suffer a heartstroke instead. Your employer won't care, they can just hire another one.
At some point, you have to do the transition from "working more" to "working better". -
I imagine people writing a browser in asm so that it will be kept close to bare metal 😂
To remind, we live in age when it's cheaper to use microcontroller and software developer than wire capacitors, coils and transistors to do the same thing.
Putting jokes aside, knowing how stuff works at metal level let's you create better code, but grasping higher abstractions allows you to solve more difficult and sophisticated problems, and hire a coding guy who can write that code on bare metal level. -
@mt3o no no no no see that’s an absurd comparison and completely not getting the point... I never said write everything in c or ASM... but what I can assure you is the embedded programmer can write a better browser for the pc using C/C++ ... hell even C# or java...BECAUSE he is disciplined enough to be conscious of certain things that affect performance... especially browsers, considering the impact they have on the computers memory, and data bandwidth.
-
@mt3o and embedded engineers are more versatile as far as adapting we can move up to higher abstractions, always the lower level writes the abstraction for the layer above..... it’s the higher level folks missing the bus who lack the understanding that is truly needed to understand performance
-
@QuanticoCEO moving up is only easy if the abstraction is just about leaving out stuff, like using a managed language.
Once it's necessary for complexity, it's a different game because the problem domain is complicated. Even a lot of embedded experience doesn't mean one could easily adapt to a project that handles some thousand machines in parallel. -
@netikras @Fast-Nop @QuanticoCEO @mt3o 1/2 OK, I was on duty so I kind of missed this whole argument, and apologies if I left anyone out here. So, to all involved:
- No processor in the history of processors accepts java or C++ or python. They all accept opcodes. The whole point of a compiler/interpreter is to be the middle man between the programmer and the kernel/processor. Meaning...
- Knowing how stuff works deep down will help in MANY ways. Things that seemed illogical will make sense. Errors can be avoided, understood and fixed if you know what runs behind, and how.
- S E C U R I T Y. Can't stress this enough, but buffer and stack overflows can only be understood at the assembly level. Libraries can contain vulnerabilities. Your code can be prone to many security flaws, that people with knowledge of the low levels can see bright as day. Just ask a C/C++ programmer about strcpy(). -
2/2 - Debugging of a crashed program, by user report, usually involves a memory address. That means knowing what your program does on the deep-low layer (essentially reverse-engineer your program)
- Because of all the abstraction layers we have extremely bloated software, and we need even more powerful hardware just to cope. Real-time systems and games are two examples when you need performance. Some games shock the industry by running smoothly despite doing things other games do with much more powerful hardware.
Bottom line: knowing what lurks underneath is tough, but essential if you want to truly know what the hell is going on. -
-
@QuanticoCEO is not about "understanding" but rather making use of it. Focusing on "performance through low level" is counterproductive, it's called "premature optimization".
I'll give you an example: loop unrolling is well known trick to make loops faster. But. Putting it everywhere - makes your code harder to understand and work with. Moreover, after some point the gain gets close to none, for example because of jmp instruction. CPU tries doing branch prediction and stuff, but it's nothing close to fully streamlined code.
Yet, working with higher abstractions it's easier to parallelize the loop, or switch the output format if you learn what the bottleneck is. Remember that in real life code that solves the problem is enough, and your time, as developer, is more valuable than the cpu's that's running the code.
I'm not neglecting need of knowing how stuff works on lower level. I'm against premature optimization. -
@mt3o @QuanticoCEO Premature optimization is something that can be done effectively only by actual hardcore experts, and it can impact a program's portability and functionality, if taken to the extreme. A modern compiler can optimize a program quite well; fine-tuning a program can be effective or crucial on specialized applications only.
There is a saying, that you need assembly for speed, speed and more speed. Well, having worked with C/C++, python and assembly, I can testify that, unless you try to design and implement VERY specialised software (real-time systems, firmware and the like) where speed AND size are critical (assembly is also the undisputed champion of small-size programs, if space is at a premium, especially on embedded systems) then you can pass through your whole career without ever looking at an opcode. But the other reasons are enough to at least study it a bit more.
This will definitely trigger many but the truth regardless of how you feel is the greatest programmers are those who understand both the hardware level and software .. only then are you more than a dev or programmer.. you are an engineer...
I challenge the devs who dis believe to go out and learn to build circuits, write optimized, efficient bare metal code.: no sdk.. no api... no drivers ..remove the unneeded abstraction layers that have blinded you...build it yourself, expand your potential and understanding..
Not only will you become more valuable overall, but you will write better code as you are more conscious of performance and space and physics of the physical layer.
I’m not talking about Arduino or raspie
Those who stand strong that high level abstraction languages and use of third party apis is a sufficient sustainable platform of development are blind to reality.. the more people who only know those levels, the less people pushing the industry of the low level.., which is the foundation of everything in the industry.. without that low level software the high level abstractions and systems cannot run
Why did we have huge technology advancements from 70s to early 2000s.... because more people in our industry understood the hardware layer..: wrote the software at the less abstracted layers..
Yeah it takes longer todo things at that low level abstraction.. but good robust products that change the world and industry don’t take a few week or months to build.....
Take this with what you will... I’m just trying to open the eyes of the blind developers to the true nature and reality of our industry
rant