Author Topic: Programming isn't that hard  (Read 1329 times)

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1611
    • LairWorks Entertainment
Programming isn't that hard
« on: September 12, 2016, 08:36:14 PM »
So... I was doing another forum crawl and came across this post.

I came across this quote:

Quote
I'm no programmer but I think it is not hard to make something good along those lines.

I'm kind of floored at how ignorant a lot of users of software seem to be in terms of how difficult it really is to develop software. There's a reason it pays as much as it does and when I see a line like this my response is usually "If it's 'not hard' why haven't you done it?".

Am I alone in this?
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Arklon

  • Administrator
  • Hero Member
  • *****
  • Posts: 1128
Re: Programming isn't that hard
« Reply #1 on: September 12, 2016, 10:33:49 PM »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3914
Re: Programming isn't that hard
« Reply #2 on: September 13, 2016, 03:04:54 AM »
 ;D

 ::)

Offline Goof

  • Newbie
  • *
  • Posts: 33
Re: Programming isn't that hard
« Reply #3 on: September 14, 2016, 10:10:47 AM »
In the same way.

With my customers, it's hard do tell them that the "simple button" they want to get a "classical statistic report that any of my customers should want" need to handle half of their statistic database and about 50 hours of work and a bill of 5000 euros.
And that none of my others customers are interested in this feature.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1611
    • LairWorks Entertainment
Re: Programming isn't that hard
« Reply #4 on: September 14, 2016, 11:03:17 AM »
5000? That's all? I'm kind of surprised you guys don't charge more.
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Goof

  • Newbie
  • *
  • Posts: 33
Re: Programming isn't that hard
« Reply #5 on: September 14, 2016, 01:40:59 PM »
In fact 100 per hour.
Since the estimated time is nearly twice the normal time to cover ... the tinyminorchangethatisunevitable and installation / post installation maintenance.
If it worked as planed it make near 200 per hours but not less than 100 per hour.

Online lordpalandus

  • Sr. Member
  • ****
  • Posts: 452
Re: Programming isn't that hard
« Reply #6 on: September 14, 2016, 09:50:40 PM »
From personal experience the ignorance comes from:

1) A lack of understanding of how much support code is necessary to accomplish a feature. If you move an object from point A to point B, its not simply a "translation" from point A to point B. You also have to take into consideration of the various elements needed to then accomplish that movement such as animations, terrain checks, checking if the object is still alive, updating the renderer, checking to see if obstacles are in the way, pathfinding code, etc...

2) Assumption that all you ever need to do is draw something on the screen and "poof" the feature is complete without understanding that often code is connected to those visual elements and would need to be reconnected in all ways necessary for that visual element to work as intended.

3) Assumption that the feature just involves a small numerical change without understanding that everything is connected to eachother and thus that small change could have enormous complications.

4) Assumption that making a change to gameplay is like taking an eraser and erasing a sentence on a piece of paper and thus that making such a code change is a simple matter of just deleting it and its finished, without understanding that as things are connected, removing it will often cause bugs that will have to be fixed.

5) Assumption that since visual mesh creation in something like Blender is easy or drawing a sprite in Photoshop is easy and thus that must mean that programming is just as easy for programmers.

6) Assumption that programmers can easily whip up prototypes and thus assume that those prototypes are feature complete when created and thus don't need any changes without realizing that a prototype is a hastily built chunk of code to test an idea rather than being a permanent feature.

7) Assumption that since code modding an XML document is easy, then making your own code will be easy too.

I think that covers the 7 most common reasons people are ignorant. At least they were the case for me before I started to code.
BAM! You've been facehugged! Have a great day!

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3914
Re: Programming isn't that hard
« Reply #7 on: September 15, 2016, 07:56:41 AM »
Shouldn't Be Hard

« Last Edit: September 15, 2016, 07:58:28 AM by Hooman »

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1611
    • LairWorks Entertainment
Re: Programming isn't that hard
« Reply #8 on: September 15, 2016, 08:11:28 AM »
I think that covers the 7 most common reasons people are ignorant. At least they were the case for me before I started to code.

It could just be that I'm a product of my time but I always knew that programming a computer was a difficult task. I didn't know how difficult when I was very young but when I first started using computers was when the Apple 2e computers were popular and you didn't have a mouse and a GUI, you had to type commands to get it to do anything.

Then came the PC and we got it before Windows 3.1 was released... e.g., before Windows was ever considered reasonably good.

It was before Windows 3.1 was made available to us that I started learning how to program computers using QBasic and a book way back around when I was 8 or so. Getting an arc or a line to draw on the screen wasn't a trivial task (although by comparison with today's technology it was a walk in the park). It wasn't long after this that Doom came out and I wanted to learn how to do that so I started working with ASM and interrupts and all that jazz.

And then I learned about C and Windows 95 started to become popular and the rest is history.
- Leeor
LairWorks Entertainment

Titanum UFO's

Online lordpalandus

  • Sr. Member
  • ****
  • Posts: 452
Re: Programming isn't that hard
« Reply #9 on: September 15, 2016, 10:16:13 AM »
Well, the first computer I had was a 486 with 3.1 installed on it. Yes, there was some fiddling around with using MS-DOS, but overall, it wasn't too difficult to work with if you knew the commands and how to do command-lines. I grew up on GUIs so I suppose some ignorance could have come from the fact that all you had to do was press a button and "bam" you got what you wanted. In school, it wasn't ever taught how to code for computers... even in Computer Science classes in highschool. So some ignorance might come from the fact that interactions were well black-boxed and things were intuitive (well more intuitive back then than now with Windows 8.1/10 where you can't find what you need/want easily) and thus the assumption could have been that since things are so intuitive and black-boxed, they MUST have been easy to implement... right? (Nope)

Question: What came before Windows 3.1? Windows 3.0? (lol)

Question2: Why is it that Windows 3.1 took up only a couple MB and yet appeared to have all the GUI of Windows 7, but yet Windows 7 takes up several GBs? Why the huge increase in space requirements for OSs? (I'm asking as a serious question. I'm actually curious why the OS has gotten to be so huge when I recall that Windows 3.1 did many of the same things as Windows 7's GUI?)
BAM! You've been facehugged! Have a great day!

Offline UtopiaPlanetia

  • Newbie
  • *
  • Posts: 25
Re: Programming isn't that hard
« Reply #10 on: September 15, 2016, 07:33:13 PM »
Whiny gamers all the time...

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1611
    • LairWorks Entertainment
Re: Programming isn't that hard
« Reply #11 on: September 15, 2016, 08:27:27 PM »
Question: What came before Windows 3.1? Windows 3.0? (lol)

Yes though it wasn't as popular. Windows 3.1's claim to fame was dropping support for real mode.

Also before that was Windows 1.0 and Windows 2.0.

Question2: Why is it that Windows 3.1 took up only a couple MB and yet appeared to have all the GUI of Windows 7, but yet Windows 7 takes up several GBs? Why the huge increase in space requirements for OSs? (I'm asking as a serious question. I'm actually curious why the OS has gotten to be so huge when I recall that Windows 3.1 did many of the same things as Windows 7's GUI?)

Windows 3.1 was 16bit. Windows 7/10 are 64Bit. 64Bit code takes up way more space.

Windows 3.1 had limited driver availability. It supported only the most common devices, basically a few dozen devices. Anything else required special driver code from device manufacturers. Windows 7/10 supports tens of thousands of devices and each of these requires driver software which takes up space.

Windows 3.1 didn't run services the way Windows 7/10 does. There were some but not like what it does today. Modern flavors of Windows are far, far more sophisticated and don't run on top of DOS the way Windows 3.1 did. Registry didn't exist in Windows 3.1. TCP/IP stack didn't exist in stock Windows 3.1 (STOCK Win3.1, STOCK). Network protocols didn't exist in 3.1 the way they do now. Filesystem is completely different. Memory model is completely different. Multitasking and system scheduler is entirely different. Accessibility features. USB support. And so on.

Basically, Windows 7/10 has SOOOOOO much more running under the hood that it's necessarily much larger. It's less a case of 'bloated' as it is 'more'. It could use some refactoring, dropping support for older drivers and software, getting rid of features nobody needs (sticky keys), etc.
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Goof

  • Newbie
  • *
  • Posts: 33
Re: Programming isn't that hard
« Reply #12 on: September 16, 2016, 05:12:02 AM »
I do remember when a printer driver could fit on one or two 1.44 MB floppy disk.
Now you have a 20 Mb "printer only" zip file or a 100 MB+ "wizard" setup files/ISO

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1611
    • LairWorks Entertainment
Re: Programming isn't that hard
« Reply #13 on: September 16, 2016, 07:47:06 AM »
Yeah well... these days MFG's want to include a built in support chat, remote status monitor, heartbeat monitor, screen saver and 15 other useless things as part of their 'driver package'. Just write software to operate the damn printer, I don't need a built in 'order interface' to buy overpriced shit from you from an insecure and buggy interface.
« Last Edit: September 16, 2016, 07:49:24 AM by leeor_net »
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3914
Re: Programming isn't that hard
« Reply #14 on: September 16, 2016, 08:41:59 AM »
An OS is more than just the window manager. Way more. With that said, there does tend to be an awful lot of bloat in modern software. I too wonder why it gets so big.

I started on an 8086 with a full 640KB of RAM, a green monochrome monitor, and GWBasic burned into the ROM, so the computer would boot to that when the 20MB hard drive overheated and failed (which was frequent). At about that time the schools were getting 486 machines in all the classrooms, and everyone was talking about Doom. I graduated to QBasic about a year later. I soon became fond of the added functions (as in "functions" and "subroutines", as opposed to simple goto/gosub), and being able to use 3x the memory. (GWBasic was limited to a single 64KB memory segment).

I also had a VIC20 with a tape drive before that. Think I might have tried entering a program on it once or twice. It didn't stick at the time. Moon Lander was sure fun though.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1611
    • LairWorks Entertainment
Re: Programming isn't that hard
« Reply #15 on: September 16, 2016, 12:31:06 PM »
With that said, there does tend to be an awful lot of bloat in modern software. I too wonder why it gets so big.

Relying on compiler generated code vs. hand tuned ASM probably has a lot to do with it.

I noticed that my programs also tend to get very big when compiled... like more than one or two MiB even when in release mode. When I instruct the compiler to generate smaller code in ever case, the executable size dropped to less than 1Mib though at the possible expense of slower execution paths. So eh, I blame optimizing compilers.
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3914
Re: Programming isn't that hard
« Reply #16 on: September 18, 2016, 10:05:49 PM »
Compiler produced code is often pretty good. It depends of course on the quality of the code in the source language. You can always write terrible code that an optimizer can't deal well with. I don't think hand optimizing everything is really the proper way to reduce bloat.

The use of libraries can really bloat code. I think that's what the real culprit is. Trimming out unused functions has done a lot of reduce compiled executable sizes. You can still get a lot of code brought in from rarely used code paths though. Sometimes a code path may be impossible, yet references to other code from an unused code path can still bring in a lot of extra bloat. Sometimes library functions will be used that provide a lot more functionality than is strictly needed, and so extra support code is brought in. Sometimes a generic function might handle many cases, and optimized functions handle specific cases, and the program uses a bunch of specific cases, and one general case, causing all the code to be brought in, even though the one general function could have handled it all. Sometimes code is included to support legacy systems. Sometimes there are differences for string encodings, which might be set at runtime, and so all the different ways of handling strings is brought in.

There are many reasons why more code can get pulled in than you'd expect. Smarter linkers help cut down on the bloat, but there's only so much you can reasonably expect them to do.

As for optimization settings, optimizing for size often produces the fastest code, since the code is better able to fit in the cache. When it doesn't produce the fastest code, it's usually not that much slower than speed optimized code. I optimize for size by default.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1611
    • LairWorks Entertainment
Re: Programming isn't that hard
« Reply #17 on: September 20, 2016, 08:35:58 AM »
Compiler produced code is often pretty good. It depends of course on the quality of the code in the source language. You can always write terrible code that an optimizer can't deal well with. I don't think hand optimizing everything is really the proper way to reduce bloat.

Fair enough. I guess I'm not giving modern compilers enough credit. I know the LLVM compiler is pretty good at what it does and MS's compiler has gotten a lot better in their recent versions.

The use of libraries can really bloat code. I think that's what the real culprit is.

Not sure why this didn't occur to me but it makes a lot of sense. I know that a lot of libraries have become very sophisticated lately and provide a lot of functionality. Makes me think that use of multiple libraries may provide a number of internal functions/code that basically do the same thing but they aren't from the same code base so would make sense that way too.

As for optimization settings, optimizing for size often produces the fastest code, since the code is better able to fit in the cache. When it doesn't produce the fastest code, it's usually not that much slower than speed optimized code. I optimize for size by default.

Which is why I opted for smaller size. I figured with modern computers the tradeoff of the smaller code for a small performance penalty is very much worth it.
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Arklon

  • Administrator
  • Hero Member
  • *****
  • Posts: 1128
Re: Programming isn't that hard
« Reply #18 on: September 20, 2016, 10:08:04 AM »
Fair enough. I guess I'm not giving modern compilers enough credit. I know the LLVM compiler is pretty good at what it does and MS's compiler has gotten a lot better in their recent versions.
Both GCC and MS's compiler produce better code than LLVM, but that's kinda a consequence of being much more mature. Right now where LLVM shines is when you want to use its code base and build off of it, whereas GCC/binutils is a disaster of spaghetti code, and of course MS's is closed source.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1611
    • LairWorks Entertainment
Re: Programming isn't that hard
« Reply #19 on: September 20, 2016, 12:11:50 PM »
Huh, I thought LLVM was better than GCC for some reason. Oh well, I never liked GCC much.
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3914
Re: Programming isn't that hard
« Reply #20 on: September 21, 2016, 01:43:20 AM »
I had a professor who once suggested the GCC garbage collector just point a pointer at itself and be done with it.