flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Heap > Why Software Sucks?

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
DimonSoft



Joined: 03 Mar 2010
Posts: 231
Location: Belarus


rugxulo wrote:

DimonSoft wrote:

Garbage collecion is not just overrated. It is the case of “one solution should suit all needs” and “yes, your user has infinite amount of memory, don’t care about flushing and taking the garbage out”. A mechanism suitable for cases so rare that it is not worth being implemented even in such cases is being used for nearly all cases.


OberonOS never required infinite amounts of memory.


I was actually referring to the fact that garbage collection is an abstraction that makes a program think that dynamic memory is available in infinite amounts. Of course, the whole point of garbage collection is to make such an assumption possible while still requiring finite amount of memory. And that is where the abstraction leaks.
Post 14 Apr 2018, 18:31
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 231
Location: Belarus


Furs wrote:
Even coding in something "portable" like C/C++ "ISO mode" you still have to learn that -- not the specific platform you code for, but the C/C++ "virtual machine" specification (which is even harder than the actual details of a platform actually). If you don't, you're a poor programmer and your software will suck.

<…>

I know that HLLs are intentionally meant to hide a lot of stuff, that's my whole point. It's not necessarily the fault of the HLL directly (hey, I love C++), but indirectly: they enable people who shouldn't even be programming to still make something -- albeit, that "sucks", but whatever.


I wish such “programmers” knew their place in the world. No big deal that they write something. They just should shut up and stop teaching others. The problem is that nearly everything in web and mobile programming and most of desktop applications are written with “it works, it sells, so I don’t care” in mind and this approach is widely advertised.


Furs wrote:
it becomes more and more a "diamond in the rough" kind of thing


Sad but true.
Post 14 Apr 2018, 18:40
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15733
Location: Crossing the Cauchy horizon


DimonSoft wrote:

rugxulo wrote:
First you make it work, then you prove it correct, then you optimize.

First you spend time to design what you’re going to write.

First you make one to throw away, then you make the real product. But ... of course, once you've spend all the time making the first one, your boss puts it into production and puts you on a new project. So the throwaway becomes the real thing and everyone hates it.
Post 15 Apr 2018, 14:14
View user's profile Send private message Visit poster's website Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction


revolution wrote:

DimonSoft wrote:

rugxulo wrote:
First you make it work, then you prove it correct, then you optimize.

First you spend time to design what you’re going to write.

First you make one to throw away, then you make the real product. But ... of course, once you've spend all the time making the first one, your boss puts it into production and puts you on a new project. So the throwaway becomes the real thing and everyone hates it.



I guess this is the reason why it is said that software should be written to be easy enough to change and maintain so that you won't need to worry about later maintainers picking the thing up knowing your home address. And any system valuable enough will be fully rewritten sooner or later anyway. Probably later though.
Post 17 Apr 2018, 21:28
View user's profile Send private message Reply with quote
MSrobots2



Joined: 21 Oct 2017
Posts: 6

The main problem why people think they are good programmers, painters, car drivers or whatever is the following.

To assess if you are good at something needs the same skills to be good at it in the first place.

So it often happens that somebody thinks he is good at something, (and is not) because he is lacking the skills to even know if he is good at it or not.

my 2 cents,

Mike
Post 19 Apr 2018, 02:44
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15733
Location: Crossing the Cauchy horizon


MSrobots2 wrote:
The main problem why people think they are good programmers, painters, car drivers or whatever is the following.

To assess if you are good at something needs the same skills to be good at it in the first place.

So it often happens that somebody thinks he is good at something, (and is not) because he is lacking the skills to even know if he is good at it or not.

my 2 cents,

Mike

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Post 19 Apr 2018, 04:52
View user's profile Send private message Visit poster's website Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction


nyrtzi wrote:

revolution wrote:

DimonSoft wrote:

rugxulo wrote:
First you make it work, then you prove it correct, then you optimize.

First you spend time to design what you’re going to write.

First you make one to throw away, then you make the real product. But ... of course, once you've spend all the time making the first one, your boss puts it into production and puts you on a new project. So the throwaway becomes the real thing and everyone hates it.



I guess this is the reason why it is said that software should be written to be easy enough to change and maintain so that you won't need to worry about later maintainers picking the thing up knowing your home address. And any system valuable enough will be fully rewritten sooner or later anyway. Probably later though.



Writing software that is easy to change and maintain? Easier said than done. The time pressure, etc. involved rarely allows enough attention to quality.

And as far as rewrites go there is always the second system effect.
Post 19 Apr 2018, 06:15
View user's profile Send private message Reply with quote
MSrobots2



Joined: 21 Oct 2017
Posts: 6


revolution wrote:

MSrobots2 wrote:
The main problem why people think they are good programmers, painters, car drivers or whatever is the following.

To assess if you are good at something needs the same skills to be good at it in the first place.

So it often happens that somebody thinks he is good at something, (and is not) because he is lacking the skills to even know if he is good at it or not.

my 2 cents,

Mike

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect



Thank you @revolution,

it even has a name, cool. I found out by personal experience, as usual.

Dunning Krueger effect. Nice.

A long time ago some doctor told me that I have OCD. I told him that he is a moron, and even IF he is right, it should at least be spelled CDO, so that the letters are in the right order...

Mike
Post 21 Apr 2018, 20:14
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2279
Location: Usono (aka, USA)


Furs wrote:

I don't know what you're trying to argue here. I was giving an example of a very bad programming practice that i call "yo-yo programming" which leads to software sucking. You cannot possibly defend that, right?



I'm not necessarily defending anything, just saying that sometimes simplicity and accuracy trump mindlessly worrying about efficiency. If convenience was never important, we wouldn't have (shell) scripting (languages) at all.


Furs wrote:

The thing is, those "programmers" aren't even aware of all this, that's exactly why the language is at fault for not forcing them to learn. In short, if they learned the hard way that programming is not so easy for them and they should find a diffferent goal in life, we'd have more quality software. The entry level is too low, and it's the fault of the forgiving languages.



But some languages (e.g. Rexx) are meant to be simple, for average use cases (business) where people aren't professional or college-degree programmers. Yes, some implementation details are abstracted away, and sometimes it's slower, but it's easier to use. Rexx was (more or less) meant to be an easier-to-use PL/I, also a "better" replacement for the EXEC shell language.

Aliased pointers, double free after use, and memory leaks are all annoying to debug.

Even sed is an interpreter, so is AWK. Some things aren't strictly designed for speed. (Actually, you could argue sed also was for larger files since ed, at the time, loaded entirely into memory where sed is strictly a single line at a time. Though buffering can still happen behind the scenes, as always.)

Nobody wants to write makefiles or shell scripts in assembly. At some point, you prefer convenience over doing everything manually by hand.


Furs wrote:

Do you want to know why software sucks? See this link, and what kind of "mentality" or doctrine such people give to others: http://rubyonrails.org/doctrine/#optimize-for-programmer-happiness. With this kind of people preaching to other, newbies, is it any wonder why software itself sucks?



Don't misunderstand them. They mostly seem sane there. It's probably less incompetent than you're imagining.


Furs wrote:

Software sucking has nothing to do with programmer "happiness" or experience, but with the end result. If the end result is bloated, big, crashes, or is slow, then the software sucks, which is the topic. Doesn't matter how happy a developer was. The end usage of the software is what matters in this respect.



Although I don't grok Ruby, it's faster and better than ever, mostly due to YARV (which is, relatively, new since 1.9).


Furs wrote:

And yes, software today sucks much more than 10 or 20 years ago. Of course, it's also because the average programmer today is much dumber than the average 10 years ago, since he is "protected" by the HLL from the "nasty details". With no workout for the brain, you become dumb. Literally. Use it or lose it.



10 years ago, Ruby was at 1.8 but ended up dropping like 9 OSes in its quest to improve. Well, Ruby always broke some little bits of compatibility. Actually, Ruby was standardized (ISO 30170), which is ironic since it's based upon (old, shunned) 1.8.6 or .7-ish! And there's also mRuby meant to compete with Lua (IIRC). And Lua has changed a lot in ten years, too. Heck, Delphi has changed tons since introduction in 1995. Same with Ada95 to '05 to '12.

Everything changes. The Atari 2600 (1977) had like 128 bytes of RAM. The original XBox had 64 MB. The XBox 360 had 512 MB, and the XBox One has 8 GB (although some of that is used by the OS). With HD/UHD, network multiplayer, large prerendered cutscenes (and vocal lines), it's going to use more. Even with multiple hardware threads, it's still going to be taxing. (The original XBox only allegedly offered like three threads on one process on a single Celeron P3. And some games had to have modified levels, e.g. Doom 3, due to such restrictions.)

I'm not saying there isn't gross inefficiency in a lot of software. But some things are harder and less obvious than others. Optimizations don't happen overnight, nor does gaining experience. The "XP" in Windows XP was supposed to stand for "experience", but we all know that XP was very insecure and old-fashioned (compared to newer). It doesn't mean they knew nothing, just that things changed and improved and got much more complicated later on. (Even beyond SP2 or SP3, and almost all software won't run on XP anymore due to various reasons, most probably not due to just developer laziness.)


Furs wrote:

(note: the total amount of good programmers might actually be higher than 10 years ago or more, but the average is not because there's simply way more dumbies into the scene today than before so they tilt the average, which is why it's so much harder to find good software today written by actual good programmers -- it becomes more and more a "diamond in the rough" kind of thing; it's not the absolute total value that's lower, it's the relative percentage that's way lower)



I don't know the population difference from then and now. I also don't know what specific programs or groups you find most problematic. There has always been buggy software. Sure, some people have more experience than others, but most errors aren't as obvious as you'd think. It's impossible to remove all bugs and inefficiencies. You just have to do the best with what you have.
Post 23 Apr 2018, 09:16
View user's profile Send private message Visit poster's website Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction

Re: Why Software Sucks?


yeohhs wrote:
http://scottberkun.com/essays/46-why-software-sucks/
(first published in 2005)

What do you think of the present situation (2018)? Are software nowadays suckier or suck more than ever? Laughing



Probably wrote this in the 1960's. Might have been in the 1970's at latest. Can't remember anymore which exact paper it was. Either way Tony Hoare wrote:

“Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways. Programming is complex because of the large number of conflicting objectives for each of our programming projects. If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather than part of its solution.”

I'm thinking of modern high level languages. C++ maybe being the worst.
Post 29 Apr 2018, 15:46
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2279
Location: Usono (aka, USA)

https://en.wikiquote.org/wiki/C._A._R._Hoare

So he was sympathetic to Algol 60 and Algol W (but not Algol 68), Pascal (but not Ada), disliked PL/I, etc. He's a well-known friend and colleague of Niklaus Wirth, who also preaches simplicity.

But different people have different ideas of simplicity, different goals, etc. Certainly Wirth would still rather suggest Oberon than anything else (which, FYI, is considered a better, simpler Modula-2). Not sure what Hoare would really suggest these days, I can only guess (probably F#).

I do think we all tend to overcomplicate everything. We probably need to focus more on minimalism, rolling our own (bootstrapping) instead of relying on heavy burdens like billion-dollar OSes and expensive, proprietary, cpus. OberonOS has already been rewritten for FPGA, which at least gives some limited hope.

But can anyone live within their means? Can they humble themselves to work without literally everything and the kitchen sink? Apparently not!
Post 02 May 2018, 01:56
View user's profile Send private message Visit poster's website Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction


rugxulo wrote:
(snip)
He's a well-known friend and colleague of Niklaus Wirth, who also preaches simplicity.
(snip)
But different people have different ideas of simplicity, different goals, etc.
(snip)
I do think we all tend to overcomplicate everything. We probably need to focus more on minimalism, rolling our own (bootstrapping) instead
(snip)
But can anyone live within their means? Can they humble themselves to work without literally everything and the kitchen sink? Apparently not!



I think Tony Hoare wrote in a different paper that one of the best pieces of advice he ever got on software project management was the question of "Why on earth did you let the programmers write code that you can't understand?" which obviously only works if the manager is a programmer himself but this does set a certain kind of constraint to the amount of allowable complexity of the codebase. I think he wrote that things went smoother after he started applying that rule in his projects.

If we factor in the requirement of having to understand the codebase when coming back to it after some time off or having been working on a different project then that places some extra constraints on how high the readability and the quality of the codebase needs to be in general. Which I think centers around the idea of the amount of unnecessary accidental complexity in the codebase and that in turn takes us back to the idea of "as simple as possible but not simpler" often attributed to Einstein.

If there is to be simplification and streamlining of things through prioritization of the work to be done in order to make something else doable I'd start dropping complexity from the high level requirements first in order to maximize the amount of work that can be skipped completely.

But I guess it's hard to humble oneself to work with a tool that comes without batteries included if you're on a fixed schedule designed around the assumption that with a different tool you can get hopefully better batteries from somewhere else for an acceptable price without having to invest any time in making your own.

After all isn't that just business? That you're just trying create added value in a way which makes it a better choice for your customer to have you do it for them than themselves or your competitors. Which sets some real world constraints on how commercial software gets written.
Post 02 May 2018, 05:06
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2018, Tomasz Grysztar.
Powered by rwasa.