21 replies to this topic

[gmx0]

This book is a good read. Its by Scott Rosenberg. It summarizes a 'quest for transcedent software'. I'm almost done.
Some points:
1. Software writing is not affected by Moore's law, only hardware.
2. Programming is an abstract art that has a foundation of sand.
3. Bug-free software is impossible
4. A true 'Lego'-like software that is built with different plugin modules is utopian at best.(GEX anyone?)
5. Code is easier to write than read, so code is graded by readability
6.Programmers must think as a philosopher than an engineer or architect as they handle abstract than physical.
7.Never think you are making a BIG project
8.Coding methologies are theoritical, not practical
9. Programming language must be a great guesser, not a perfect decoder(Very strict:1 bug will crash a program).
10.We must throw out our concept of a 'file' and memory for software to evolve.

Questions pertaining to GML:
1.Should GML be structured to be more readable to the normal human being?
2.Is transcedent(dynamic) software possible with GML?
3.Should software writing change direction, and how?
4. Should computers really be great guessers than perfect decoders?
Now how would that work?
Well, neural networking.
Say there is a pattern of colors. Because the hues and stuff may differ differently than the one stored in code:

pat=pattern_read_script();//pattern could be a string
return pattern_compare_script(pat); //returns 1-10(1 for being totally different to 10 for a match)

pattern_read_script()

var pat_str;
for (i=0;i<=pattern_width;i+=accuracy)
pat_string+=pattern_get_pixelcolor(pattern_x+i,pattern_y); //pseudo GML code, not to be taken seriously
return pat_string;

How would pattern_get_pixelcolor() work? Well it basicalky gets the pixel color, converts it to a 1 digit character and returns it.
The real problem is the pattern_compare_script(). It has an original pattern stored and compares the new pattern with that. But how does it grade based on probability, not hard rules?

Edited by gmx0, 23 January 2010 - 11:24 PM.

[Juju]

You can't truly represent colour as a single number by virtue of the interpretation of light being composed of three different values - red, green and blue. You would have to consider these as three separate variables which, when combined, form colour to show on the screen.

You wouldn't rank the disparity between two values on a scale of 1 to 10. Using the concept of percentage error from error analysis:

absolute_error = theoretical - experimental
percentage_error = absolute_error / real

This would mean two identical values have a percentage error of 0% and two utterly different values would tend to infinity. If you want to analyse the total error of a colour, since there are three values with three percentage errors, you use:

absolute_error = ( theoretical_red - experimental_red ) 
absolute_error += ( theoretical_blue - experimental_blue )
absolute_error += ( theoretical_green - experimental_green )
percentage_error = absolute_error / ( theoretical_red + theoretical_blue + theoretical_green )

Edited by Juju, 24 January 2010 - 01:35 PM.

[Schyler]

Colours are stored as real values in GM, not "one digit characters".

[gmx0]

I said its pseudo-code, not to be taken seriously! Its hypothetical!

[GearGOD]

You really can't compare digital data like that without context ('hard rules').

[KC LC]

I read part of the book but I wasn't impressed. A lot of it is about the development of an open-source email/organizer (Chandler). The software team he writes about seemed pretty disorganized and undisciplined. No real deadlines or budget limitations. And their work environment seemed more like summer camp.

The author raises some interesting questions. But using that group's example to discuss broader issues about software and teamwork doesn't make sense.

Some points:
...
6. Programmers must think as a philosopher than an engineer or architect as they handle abstract than physical.

This is true for nearly anything that involves designing something new, or providing a new capability. It's certainly NOT unique to software.

Many architects, civil engineers, and artists DO understand this. Many professional programmers don't.

[sylvan]

Many architects, civil engineers, and artists DO understand this. Many professional programmers don't.

This is one of the problems of programmers, which unfortunately affects a lot of computing areas. Technically, that statement should be an oxymoron. A "professional" programmer should understand the proper ways to write code and thus should avoid these problems.

There are basically two definitions of professional:
- the sporting term, where as if someone is paid to do something they are considered professional.
- the master term, where as if someone thoroughly understands something, they are considered professional.

Here is an example, there are two doctors, both know that a certain pill will solve elbow pain. One understands how and why the pill works, the other just knows that the pill will fix elbow pain.

99/100 time to the patient, there is no difference between the two. Except it would be very unprofessional if the patient asked "why does that pill work" and the doctor explained "i dunno really, I just know it solves elbow pain".

This is unfortunately what happens with programming. A lot of programmers are very unprofessional in the way they work. Making code that works is one thing, but just being paid to write code does not make someone a professional.


BASICALLY, long story short, a lot of programmers out there really have no clue how to create software properly.


To be more on topic (please note I haven't read the book):
1.Should GML be structured to be more readable to the normal human being?
No, that is what drag-and-drop code is for.
2.Is transcedent(dynamic) software possible with GML?
Possible? yes. The execute_string function is for.
3.Should software writing change direction, and how?
I do believe that making more reusable code is a good thing. However, change does not mean better. Personally, I think basically what I said above, programmers need to be more professional.
4. Should computers really be great guessers than perfect decoders?
They should be decoders. Like you said before, bug free code is unavoidable. Making a compiler imperfect, would lead to possibly random errors appearing that would only serve to mask further bug detection. Kind of like chinese whispers, a programmer writes something, the computer interprets this as something similar, and then the end result can be totally different to the original.

[GearGOD]

Many architects, civil engineers, and artists DO understand this. Many professional programmers don't.

That's because they're programmers. Their job is to write code to given specifications. Its the job of the software engineers to take abstract problems and reduce them to specifications, and we mostly feel like we're in the same boat as other engineering disciplines that encounter a big abstraction level difference between design and building. What does set software slightly apart is there is absolutely no right or wrong way to do things, nor a good way to measure efficiency. So really we have to build castles out of thin air when doing anything slightly new.

[KC LC]

That's because they're programmers. Their job is to write code to given specifications. Its the job of the software engineers to take abstract problems and reduce them to specifications

That's a good point. The Chandler fiasco lacked that guidance. Of course, the programmers themselves could have filled that role, by agreeing on a set of features ahead of time, and having the discipline to follow them. But well into the project, they were still considering major new features that someone happened to think of along the way.

What does set software slightly apart is there is absolutely no right or wrong way to do things, nor a good way to measure efficiency.

That's somewhat true. At least it's more true with software than with other fields. But there are metrics that can be used. Just not ones that are universally accepted.

My overall impression of that "team" was that they'd seen too many Disney films about geeky wiz kids who work alone, keep odd hours, and produce works of genius. And they believed it. That might have been fine 20 years ago. But programming has matured, and managers shouldn't tolerate that.

[makerofthegames]

It's certainly NOT unique to software.

Many architects, civil engineers, and artists DO understand this. Many professional programmers don't.

I think you just stated why it's in the book, then.
It's not unique to software, yet many professional programmers don't realize this.

[GearGOD]

Of course, the programmers themselves could have filled that role, by agreeing on a set of features ahead of time, and having the discipline to follow them.

I don't know. I think if they were never taught to do that, its silly to expect it of them. A compsci student at my work is causing a few headaches because he managed to mislead the management about his project's progress. Now he's leaving to live in another state and something 2 months away from being workable is being handed over to me with the manager expecting it to be ready by the end of this week.

[score_under]

4. A true 'Lego'-like software that is built with different plugin modules is utopian at best.(GEX anyone?)

Depends on the software's use, though nobody would ever write anything useful for it.

9. Programming language must be a great guesser, not a perfect decoder(Very strict:1 bug will crash a program).
10.We must throw out our concept of a 'file' and memory for software to evolve.

@9: I don't understand. All languages I have used have very strict rules as to what does what, no "guessing" involved. As for one bug crashing a program, what do you mean? Most bugs don't crash a program, they just mess up something semantically.
@10: Why? What further horizon is there? I can't see any reason to drop memory, and files are just a basic unit of human-readable storage, no matter how it's represented in memory or on disk.

2.Is transcedent(dynamic) software possible with GML?

I haven't heard the word "transcendent" in the wild applied to programming, and "dynamic" could mean anything, so I'll assume you mean self-modifying. If so, definitely yes - I've done it before. For the rest, execute_string.

3.Should software writing change direction, and how?

Yes, people should stop writing code which assumes fast hardware and go for the millisecond optimizations.

4. Should computers really be great guessers than perfect decoders?

Definitely no. That would slow them down insanely, and you'd still need to "decode" the neural network. For an example of how slow a "great guess" can be, try using your own brain to perform a fairly large multiplication without writing anything down - if you can remember the digits, it can usually take a few seconds and most of your available short-term memory (akin to RAM), while for a computer that decodes instructions as-is, it takes an unnoticeable amount of time.

The real problem is the pattern_compare_script(). It has an original pattern stored and compares the new pattern with that. But how does it grade based on probability, not hard rules?

As you said earlier, "utopian at best". You need hard rules, though it is possible to adapt - for example, if a photo is in sepia, the program could attempt to remove the tint before performing calculations on it. This too would be fairly difficult.

[Juju]

definitely yes - I've done it before. For the rest, execute_string.

There's a reason why no one uses execute_string.

[PlasticineGuy]

Think of a single way to write self-modifying code in pure GML without using object_event_add or execute_string/file.
...
I'm waiting.

1.Should GML be structured to be more readable to the normal human being?

How could GML be any more human readable? Even if you didn't know a word of code, it's easy to figure out what this does:

if(distance_to_object(dog) < 300) {
	move_towards_point(200, 200, 3);
}

It's nearly plain English: If distance to object dog less than 300 move towards point (200,200)
You could apply that to something like assembly. A normal person would see:

mov ecx,5
.forl:
push ecx
push 0
push title
push message
push 0
call [MessageBoxA]
pop ecx
dec ecx
jg .forl

And be extremely confused.

2.Is transcedent(dynamic) software possible with GML?

Please elaborate.

3.Should software writing change direction, and how?

Yes. Programmers need to be less lazy.

4. Should computers really be great guessers than perfect decoders?

Of course not. Think of Microsoft's paperclip. If I write:

char *x;

I don't want my computer to "guess" that I'm declaring a string and replace it with:

std::string x("");

What if I actually need a pointer to a single character?

Edited by PlasticineGuy, 27 January 2010 - 10:25 AM.

[gmx0]

yes, I know what execute_string is! Maybe, I wasnt so clear. But I hav no time to edit today, so...

[Gamer3D]

• "Software writing is not affected by Moore's law, only hardware." Yes, the software writing stays the same.
• "Programming is an abstract art that has a foundation of sand." Nah, almost every language is built the same set of commands.
• "Bug-free software is impossible." Clearly false. Although bugs become ever more likely as complexity increases, a bug-free state is often found.
• "A true 'Lego'-like software that is built with different plugin modules is utopian at best." A lot of software is Lego-like. Simply get the parts you need, then join them together.
• "Code is easier to write than read, so code is graded by readability." Depends on the grader. The person who takes over your project wants it to be readable, the person using your software wants it to be efficient.
• "Programmers must think as a philosopher than an engineer or architect as they handle abstract than physical." Too vague to make any statements about. Moving on...
• "Never think you are making a BIG project." Good way to avoid giving up. No argument here.
• "Coding methologies are theoritical, not practical." And theory put into practice is...
• "Programming language must be a great guesser, not a perfect decoder(Very strict:1 bug will crash a program)." Maybe a good idea for people new to programming, but a horrible idea for more advanced users.
• "We must throw out our concept of a 'file' and memory for software to evolve." Who can say? Programming could change when we throw away our concepts, but it could change anyway.

Questions pertaining to GML:

• "Should GML be structured to be more readable to the normal human being?" The point has been made before, but "Drag and Drop".
• "Is transcedent(dynamic) software possible with GML?" Ouch. This is so vague it hurts.
• "Should software writing change direction, and how?" Yes, but probably not significantly.
• "Should computers really be great guessers than perfect decoders?" No. See point 9.

[T-Bird]

1. *facepalm* that's kind of a silly statement. Of course it doesn't apply to software, the law is about hardware not about software. That's about as insightful as me saying "The US Constitution does not apply to Russian Citizens living in Russia". Besides, at the best Moore's law is a loosely worded theory left open to interpetation.

2. What does that mean. It's no more abstract than physics. If you know the rules, they always apply as you suppose, if you don't know the rules, then expect some surprises. As for the foundation of sand, since most change in programming is in the way of forward progress, then I don't care if my "building" is on shifting "sand" as long as that "sand" is taking me where I want to be.

3. False. Don't confuse improbable with impossible. Most software bugs come from RAD where speed of development is traded for quality, or by ambiguities in underlying technology. While unlikely, bug free software is entirely possible.

4. Plenty of these languages exist, it may be utopian to expect the same performance out of them as other languages, but that's a given, and it's widely understood that these higher level languages will never be as efficient as lower level equivalents, the hope instead is to develop the languages to the point that the speed differences are forgivable (much more practical)

5. Depends on who you are. I grade code by efficiency, because it's not hard to write or read code, what's hard is to use it properly and get the job done as efficiently as possible.

6. Only in a small programming team. As GearGOD pointed out, the preferred method is to have a tiered approach where several people turn the abstract into something more literal.

7. This doesn't seem to fit with the other comments - which are general sweeping statements about programing in general - since this is a direct statement to one person ("you"). But this is a common way to keep yourself on task and focused.

8. So is math. But try flying to Japan without theory.

9. What does this mean. Does it suggest programs that try to suppose the intended meaning of erred code? If so that's a terrible suggestion as it turns syntax/run-time errors into logic errors when the program acts in a way the programmer didn't expect.

10. That's like saying that we must throw out our concept of money in order to end poverty. Not having money wouldn't mean there is no value to anything and everyone is equal. Things and services still have inherent value even if there isn't a recognized word for it. The limited resources on my computer are no different, they have a value because there are only a few. If programmers don't recognize memory and storage they will use more than I want (or more than I have). Whether they want to give it a name or not, it still exists and is still a limitation.

I'll be sure not to pick up this book. It seems to be less than insightful - full of philosophical sweeping statements that aren't false for the same reason they aren't true, they're too general and unsupported.

[score_under]

Think of a single way to write self-modifying code in pure GML without using object_event_add or execute_string/file.
...
I'm waiting.

Hook the function that runs the script and make it send the pointer to the current running code tree to a DLL. You could attach some metadata to that code (in Game Maker, not at runtime ), for example, through the "var" directive with unused variables, which tells the DLL which script it is. After that, it's simply a case of getting the DLL to create a modified copy of the code, and execute it instead of the original code when it next executes (taking advantage of the hook here).

Simple?


NB. This is not blind speculation, I know where the function is, where it stores its pointers, how to hook functions carefully, how to detect the code inside token trees, and which commands correspond to which bytes.

Edited by score_under, 14 February 2010 - 03:37 AM.

[PlasticineGuy]

in pure GML

Because you can hook functions in GML (in fact, I don't know what hooking functions even means, but I doubt GML could do it).

[score_under]

in pure GML

Because you can hook functions in GML (in fact, I don't know what hooking functions even means, but I doubt GML could do it).

With the aid of a DLL... it's good enough

Hooking a function will do something like this:

Original:

  PUSH EBP
  MOV EBP,ESP
  MOV EDI,[EAX]
  ...
  LEAVE
  RETN 0C



Modified:

  JMP hook
func:
  ...
  LEAVE
  RETN 0C


hook:
  PUSH EBP
  MOV EBP,ESP
  PUSHA
  MOV ECX,[EAX+4]
  TEST ECX,ECX
  JZ hook2
hook3:
  POPA
  MOV EDI,[EAX]
  JMP func
hook2:
  MOV [EAX],some_other_data_somewhere
  JMP hook3

Turning a function from this:

var1=argument0[0];
...
return;

to:

if(!argument0[1])argument0[0]=some_other_data_somewhere;
var1=argument0[0];
...
return;

Bear in mind this is only represented in pseudo-GML to make it easier to read - hooks are for machine code, not GML. This is an extremely simple hook, for example, my anti-decompiler hooks a few functions and does a fair bit of decrypting while it's there.

Edited by score_under, 14 February 2010 - 03:50 AM.