I am unhappy with my web design assignment

[urjaman]

What side effects? You act like it will jump to random point of your program or a different process even while it's 100% defined and predictable. I suppose you never coded asm?

It will if someone else modifies it later.

---- ??? ...


I dont understand this. Care to explain deeper? Modifies what? Error cleanup is (mostly) undoing what you have done so far, and of course if you need to add something to-be-undoed into the sequence (or remove), you will need to edit the cleanup sequence accordingly. Example: with your method-style, if something to-be-cleaned is added before goto fail1, you would need to add 1 cleanup method and modify all 3. In this code you would need to add one goto fail0 (or renumber them, not a big task either) and one fail0: dofreeingofstuff()-line.

I equally hate switch statements.

You have then never done state machines or interpreting virtual machines?

 

[notaz]

our source control repository is at revision 48000

Ours is approaching 70000

What side effects? You act like it will jump to random point of your program or a different process even while it's 100% defined and predictable. I suppose you never coded asm?

It will if someone else modifies it later. Have you never shared code with someone else? Or worked in a team of more than 1 person?

I have and I don't recall any problems where someone could not deal with use of goto specifically. If a person knows what he is doing that is, if not he'll find how to break it anyway.


If what you say was true every collaborating project using 'goto' would be doomed, and yet running grep on .37 Linux kernel outputs this:


grep -R '\<goto\>' linux/ | wc -l


84679

And yes I did a lot of assembly. But even though it's very interesting to understand how everything works internally, that's as much a computer language as the wind is a human language.

How is assembly not a computer language?

I don't know how is that better code, you device various workarounds just to avoid that 4 letter word. In this case it doesn't look too bad yet, but add a couple of nesting levels and it becomes horrible.

Agreed, and that's what I said. That's not the word goto that I want to avoid, that's everything that breaks the normal flow of the program. I equally hate switch statements.

Well if you hate 'switch' why do you like 'if' then - the flow might also jump from one point to another, it's also the same goto in disguise.

 

[AquaAnalogue]

Agreed, and that's what I said. That's not the word goto that I want to avoid, that's everything that breaks the normal flow of the program. I equally hate switch statements.

Well if you hate 'switch' why do you like 'if' then - the flow might also jump from one point to another, it's also the same goto in disguise.

This exactly, Theo-- there is no such thing as the "normal flow" of a program as you describe it. You seem to be describing a magical, quantum-physics-based non-linear memory addressing scheme where an if statement forks the code into two "paths" forward. This is not the case-- although it looks like it at first glance, look at a page of code and you will see that even though you may think of it that way, the execution still moves in one dimension-- vertically. Try following some simple code with your finger and you'll find your hidden gotos. Like it or not, this magical memory does not exist yet-- to get from one point in the program to another, we either increment the program counter register (done automatically), or we suddenly change its value (a branch/[conditional] jump). Those are the only two options.


I apologise if you thought I was insulting you-- the "stupid" was the general sentiment, not you, and the generally aggressive mode and "You're being British, stop it" are examples of my brand of humour that is only funny to me. Sorry. I don't hold you at any lower esteem because of some silly argument over programming preferences.


The reason I spoke out is simply-- I am against the no-goto holy crusade that Dijkstra started. With that code as an example, there is a time and a place for goto to be used. A goto is the only intelligible, non-duplicative approach to exiting multiple nested loops, for instance. A goto-label pair as follows is also great to implement an infinite loop:

loop:

// do stuff 

goto loop;

Why? Well, two reasons. Firstly, it beats typing while(true), while(1), for( ; ; ), or whatever other monstrosities people use to construct their infinite loops.



More importantly, though: it is a direct equivalent of the corresponding machine/assembly code:

loop:

      // do stuff (or not? we have used this to "halt" in class examples)

      jmp loop

My argument in favour of goto is that in many cases, it just makes sense.

 

[urjaman]

^ I have to add here, that IMHO, while(1) or for(;; ) is cleaner since it allows for cleaner formatting (indendation and { } ).

 

[notaz]

Right, using goto for jumping back is usually a bad idea. If you want a loop you use loop.

 

[Viking]

Yaaay! I created a random dice generator in C#!


public partial class _Default : System.Web.UI.Page


{


int [] antall = new int[6];


protected void Page_Load(object sender, EventArgs e)


{


if (Session["antall"] != null)


{


antall = (int [])Session["antall"];


}


}


protected void btnSlaa_Click(object sender, EventArgs e)


{


Random minRandomGenerator = new Random();


int terningverdi = minRandomGenerator.Next(0, 6);


lblResultat.Text = "Terningen viser " + (terningverdi + 1);


antall[terningverdi] += 1;


lblResultat.Text += "<br /<>br />";


int sum = 0;


foreach (int a in antall)


{


sum += a;


}


int maksBredde = 500;


for (int teller = 0; teller < antall.Length; teller++)


{


int soyleBredde = (int)(maksBredde * (1.0 * antall[teller] / sum));


lblResultat.Text += "Antall " + (teller + 1) + " er: " + "<img src=\"redbar.png\" height=\"5\"width =\"" + soyleBredde + "\">" + antall[teller] + "<br />";


}


}


protected void page_unload(Object sender, EventArgs e)


{


Session["antall"] = antall;


}


}


So proud of myself right now

 

[AquaAnalogue]

^ I have to add here, that IMHO, while(1) or for(;; ) is cleaner since it allows for cleaner formatting (indendation and { } ).

Not sure if it follows standards, but I just compiled:

#include <stdio.h>

int main ( void ) {

   loop: {

      printf("Hello World\n");

   } goto loop;

}

using GCC.

Right, using goto for jumping back is usually a bad idea. If you want a loop you use loop.

Given the above (unless it is nonstandard), why? (This is not a sarcastic question).

 

[- Theo -]

Well, I didn't want to start another goto war, I've been through several already


I'll refer you to this thread on codeguru which seems to have all the arguments (it has arguments both in favor of and against the use of goto).


I think we can agree to disagree. Basically I think any structural complexity can be reduced by better ways than goto, ways that preserve the flow of the program using well-defined constructs. Goto (and its derivatives switch, break, continue) is always the lazy way to fix a problem

I equally hate switch statements.

You have then never done state machines or interpreting virtual machines?

I have done plenty, and that's a very good example actually. I think there are good and bad ways to do a state machine. Switch is a bad way, the visitor pattern is a good way (or any other OOP technique). It may appear complex, but state machines are usually a lot more complex than they appear. For FSM, and in C++, you can use the Boost Statechart Library, which separates the model (UML) and the implementation.

 

[AquaAnalogue]

I think we can agree to disagree [...] switch, break, continue [...] always the lazy way to fix a problem

Sure -- except for the switch being lazy bit. I mean, you can't be serious. Switch statements? Lazy? Really? They don't teach goto in freshman CS; they teach switch statements in freshman CS.


I'm in agreement mostly with break and continue-- I think break and continue are useless (for me, thus far, anyway) except for breaking out of a switch statement of course.


It's widely accepted that goto is bad form (if only because Everyone Says So :angry: ) but I've never, ever heard of a switch statement being bad form. Ever. They implemented it in Java, even (in which goto is a reserved word but does absolutely nothing) so it must still be kosher, dude.

I have done plenty, and that's a very good example actually. I think there are good and bad ways to do a state machine. Switch is a bad way, the visitor pattern is a good way (or any other OOP technique).

I'm not attacking you ( ) but I'm wondering, you do know that object-oriented programming has its time and place, right? It is not the "(relatively) new way to do everything." OOP generates extreme amounts of unnecessary overhead, and so do those "design patterns" (yes, I took Software Engineering too... pointless course, but it was required).


EDIT: I really shouldn't say pointless-- I might be biased because I nearly failed it. I actually got something out of the "design" portion of the course-- UML diagrams and stuff. Pretty cool stuff. I'll still never code in Java (of my own accord) again though.

 

[- Theo -]

It's widely accepted that goto is bad form (if only because Everyone Says So :angry: ) but I've never, ever heard of a switch statement being bad form. Ever. They implemented it in Java, even (in which goto is a reserved word but does absolutely nothing) so it must still be kosher, dude.

Switch is a set of gotos in disguise. By Lazy, I meant that's it's obviously easier and quicker (I'd say dirtier) to code in a sequential way with switch statements. But I'll give my opinion again: it's a bad practice (there, now you've heard it at least twice )


It does indeed exist in Java, and I occasionally use it for very simple things, but I would never consider it as a basis for a complex program (like a state machine).

I'm not attacking you ( ) but I'm wondering, you do know that object-oriented programming has its time and place, right? It is not the "(relatively) new way to do everything." OOP generates extreme amounts of unnecessary overhead, and so do those "design patterns" (yes, I took Software Engineering too... pointless course, but it was required).

I have to disagree again on that OO does indeed generate some overhead, but in no way unnecessary. If only because it makes the code testable, and I would never consider a piece of code complete without full (or almost full) unit-tests coverage. And that's only the lower layer, I also usually throw in system tests to check integration with third-party or other components, and acceptance tests to document users specification in a dynamic way (using something like fitnesse for example). And I would run this complete set of tests automatically with every build in a continuous integration server, just to make sure nothing has been inadvertently broken. That ensures a very low number of bugs in the system, and that allows very deep refactoring to be done on the code without sweating too much.


I'm not saying that as a CS course evangelist or anything, these are common practices (including first and foremost the OO bits) that I use daily in my job, and noone in my team would consider doing differently. It simply produces better code, and our users are happy because the system just works.


To give you an example, around 55% of our current system codebase is tests. We have around 2000 of them, unit / system / acceptance tests and they take 25 minutes to run. But when we break something (even the smallest thing), we know it instantly because the build goes red.

EDIT: I really shouldn't say pointless-- I might be biased because I nearly failed it. I actually got something out of the "design" portion of the course-- UML diagrams and stuff. Pretty cool stuff. I'll still never code in Java (of my own accord) again though.

Actually I'm not a big fan of UML myself (sorry, I don't do that on purpose!) because usually I find it too cumbersome and more annoying than useful. It slows down communication where it was created to help it. The only part of UML I use quite often is the class diagrams, when discussing a database/application model with colleagues on a whiteboard.

 

[AquaAnalogue]

I have to disagree again on that

ohh boy! I certainly hope you weren't disagreeing with the "time and place" part. That would just be silly :lol:

OO does indeed generate some overhead, but in no way unnecessary. If only because it makes the code testable, and I would never consider a piece of code complete without full (or almost full) unit-tests coverage.

Ah, but sometimes you don't have that overhead to work with-- this is the problem I have with people who, say, write otherwise amazing games in Java (*coughminecraftcough*). Sure, you can test it to the bajeezus, but will it run like the wind? If you're writing a pizza delivery system (our SE project), sure it will. If you're writing a game engine, not so much. Who cares about adherence to some paradigm when you can save millions of cycles and bits by not worrying about:

• garbage collection
  
• constructing large "objects" for the purpose of saying you did it (or 'testing' which will be irrelevant to the end user)
  
• using design patterns that are overgeneralised and therefore, inherently not optimised
  

In my opinion (but I consider it fact) the only criterion for something being "necessary" is hardware compatibility. I can test my program without needing JUnit or whatever to hold my hand. It's possible-- tonnes of good code was written before OOP came along. Someday, some new paradigm will come out and be the new "Way To Do Things," and my eyes will already be tired from rolling at OOP


Here is my central issue with OOP being the "Way To Do Things": machines don't speak in objects. A computer (as of yet) has no idea what an "object" is, and as long as you continue trying to teach it new things, it will just implement them in old ways. I am not fond of humans thinking like humans whilst they code. In order to write efficient, non-bulky, low-overhead code, you have to minimize the use of training-wheel concepts such as OOP. You have to think, "What is the machine doing now, with this code?" The idea that you can write a program without knowing what the underlying machinery will do with it is pretty cool-- for a hobbyist. It has absolutely no place in professional software development, unless the product is an initial mockup or something.


I get the sense that this is at the very heart of our disagreement. You would most likely cite code aesthetics and "non-hackishness" as your highest priority-- I would cite performance.


I seriously love me some C++ (I had my larval stage in it), and don't get me wrong; I love OOP, it's fun and we tend to have enough bits and cycles to play around with these days. However, I'm not going to write a testable little self-contained class for every single thing I do, just so I can test it with some utility and watch things turn red. That's what asserts, standard i/o, and shell scripts are for.

It simply produces better code, and our users are happy because the system just works.


To give you an example, around 55% of our current system codebase is tests. We have around 2000 of them, unit / system / acceptance tests and they take 25 minutes to run. But when we break something (even the smallest thing), we know it instantly because the build goes red.

Something I can admire about your approach is its inherent quality factor. It may cost you some speed and make a whole hell of a lot more work for everyone-- you said it best, over half of your codebase is testing stuff-- but as a result very few bugs make it into a release, ever, and I can admire that. I sure as hell wouldn't want to hire someone just to write and watch over tests, though. To me, that's something that can (and should) be done by everyone for their own individual units. Plus, then you wouldn't have to deal with trying to explain your code to someone else.

Actually I'm not a big fan of UML myself (sorry, I don't do that on purpose!) because usually I find it too cumbersome and more annoying than useful. It slows down communication where it was created to help it. The only part of UML I use quite often is the class diagrams, when discussing a database/application model with colleagues on a whiteboard.

You're kidding the only part I use is class diagrams, so we finally agree on something. I might do a state diagram someday if I'm -actually- thinking in terms of "states," like in a game engine, but most of that stuff just works in my head. That's what I didn't like about SE. I couldn't just do things in my head... comments weren't even enough. I actually had to make diagrams for how my things worked on the inside... and I kept thinking, what use are these, except for grading? if my unit works, why does everyone else need to know -how-? Isn't that the point of collaborative OOP?

 

[- Theo -]

Ah, but sometimes you don't have that overhead to work with-- this is the problem I have with people who, say, write otherwise amazing games in Java (*coughminecraftcough*). Sure, you can test it to the bajeezus, but will it run like the wind? If you're writing a pizza delivery system (our SE project), sure it will. If you're writing a game engine, not so much.

Oh yes, definitely! We use high-level languages only when performance is not that much an issue. When you need real-time speed or otherwise very good performances, I agree you need to go back to low-level languages.

Who cares about adherence to some paradigm when you can save millions of cycles and bits by not worrying about:

• garbage collection
  
• constructing large "objects" for the purpose of saying you did it (or 'testing' which will be irrelevant to the end user)
  
• using design patterns that are overgeneralised and therefore, inherently not optimised
  

In my opinion (but I consider it fact) the only criterion for something being "necessary" is hardware compatibility. I can test my program without needing JUnit or whatever to hold my hand. It's possible-- tonnes of good code was written before OOP came along. Someday, some new paradigm will come out and be the new "Way To Do Things," and my eyes will already be tired from rolling at OOP

Do you really think that something like robustness of your system or strict adherence to specifications are irrelevant to the user? I don't. I think the main purpose of a computer program is to do exactly what it was intended for. Without tests, you never know if it works consistently. Yes, it's a trade-off. The extra levels of complexity gives you support for more advanced tasks and optimisation at the price of speed. But the reason is not to "adhere to some paradigm", or constructing objects "for the purpose of saying you did it". We do it because designing and maintaining a complex system is genuinely easier this way.

Here is my central issue with OOP being the "Way To Do Things": machines don't speak in objects.

Yes, and humans don't speak with words. They speak with movements of air molecules that moves from your mouth to my ear, using vibration to modulate the flow. Then there are higher levels. And on the highest levels, there are words, that you can understand. But you have to cross all the levels down to the physical one (interaction of atoms) to explain how that works. It's adequately good to use any of these levels to "describe" human language. I prefer to use words myself.

A computer (as of yet) has no idea what an "object" is, and as long as you continue trying to teach it new things, it will just implement them in old ways. I am not fond of humans thinking like humans whilst they code.

Except that's the whole point of a computer.


I don't use a computer by designing the flow of electrons on a silicon board. Because ultimately, that's all computers "know". Even your low-level language (be it asm or anything else) is an abstraction that was coded somehow. I'm just bringing that way of doing one level higher than c. As long as every level is properly tested and considered working, that works.

In order to write efficient, non-bulky, low-overhead code, you have to minimize the use of training-wheel concepts such as OOP. You have to think, "What is the machine doing now, with this code?" The idea that you can write a program without knowing what the underlying machinery will do with it is pretty cool-- for a hobbyist. It has absolutely no place in professional software development, unless the product is an initial mockup or something.

Then we don't have the same definition of efficient, and we don't speak about the same "professional software development" job. Because I can tell you it definitely has a place in my own.


(I'm saying that with no offense intended, I genuinely believe there are many ways to consider development, depending on what you want to achieve).

I get the sense that this is at the very heart of our disagreement. You would most likely cite code aesthetics and "non-hackishness" as your highest priority-- I would cite performance.

Indeed it is, except aesthetics is not the right concept. I'm, also, talking about efficiency. What good is performance when your program is fast but riddled with bugs?

I seriously love me some C++ (I had my larval stage in it), and don't get me wrong; I love OOP, it's fun and we tend to have enough bits and cycles to play around with these days. However, I'm not going to write a testable little self-contained class for every single thing I do, just so I can test it with some utility and watch things turn red. That's what asserts, standard i/o, and shell scripts are for.

*shivering*

Something I can admire about your approach is its inherent quality factor. It may cost you some speed and make a whole hell of a lot more work for everyone-- you said it best, over half of your codebase is testing stuff-- but as a result very few bugs make it into a release, ever, and I can admire that. I sure as hell wouldn't want to hire someone just to write and watch over tests, though.

Yes, that's exactly that. Except we don't watch over tests, that's the beauty of it. We don't have to! When they're done, they stay with the system, and you can forget about them. When you inadvertently break something, you instantly know it. Think about the advantages of it: how often are you afraid of hacking and slashing into a big obscure 10000- lines-of-code piece written by someone else (or by you 3 years ago) because you don't know how to make it continue to work fine? With tests, you just don't care. You do what you think, you run your build, and it tells you exactly if it still works according to specifications, and if not what exactly is broken.

You're kidding the only part I use is class diagrams, so we finally agree on something. I might do a state diagram someday if I'm -actually- thinking in terms of "states," like in a game engine, but most of that stuff just works in my head. That's what I didn't like about SE. I couldn't just do things in my head... comments weren't even enough. I actually had to make diagrams for how my things worked on the inside... and I kept thinking, what use are these, except for grading? if my unit works, why does everyone else need to know -how-? Isn't that the point of collaborative OOP?

Yes, completely. If your code is well-done, it should be self-explanatory. I don't like comments, they quickly become outdated. Your documentation is made by two things

• the tests (they explain how to use the code)
  
• the simplicity (if it's to complex to read, rewrite it)
  

And keeping that approach when working in a full-time team of 10+ people is not easy. OO and testing help us achieve that.

 

[Blue Protoman]

This thread is now about Sweden.

 

[- Theo -]

This thread is now about Sweden.

It always was, didn't you notice?

 

[AquaAnalogue]

This thread is now about Sweden.

This thread is now about finding Blue Protoman on Google.


Oh, look!

Spoiler

On topic: good points with the electrons / air molecules, Theo. I hadn't thought of that before. I guess as long as you acknowledge there is a time and place for all programming paradigms, we can agree to disagree about all the personal opinion stuff

 

[Blue Protoman]

Who made that!? The account is mine, but the image isn't...

 

[AquaAnalogue]

Who made that!? The account is mine, but the image isn't...

I made it just now.

 

[Blue Protoman]

How did you know that I have a GBAtemp account?

 

[Asiyura]

How did you know that I have a GBAtemp account?

He found your IP and sent a trojan.


Now he can watch everything you do!

Spoiler

or he simply made a search on google for "blue protoman"…

 

[Austin25]

This thread is now about Sweden.

This thread is now about finding Blue Protoman on Google.


Oh, look!

Spoiler

Spoiler

On topic: good points with the electrons / air molecules, Theo. I hadn't thought of that before. I guess as long as you acknowledge there is a time and place for all programming paradigms, we can agree to disagree about all the personal opinion stuff

I thought the topic was Blue Protoman's web design assignment?


:blink: