[G0rman]

ccubed, on 13 October 2012 - 11:14 PM, said:

You're lucky if they teach you the basics of one. Programming != computer science. Computer Science is computational and numerical theory, it is not programming, ides or libraries. The more you talk about this course makes it sound like the worst computer science course I've heard of. They taught a UI class in CS? They taught you how to use VS? That doesn't even have a thing to do with CS. Programming and Programming Languages are subsets of CS. They are fields that exist as a branch of CS, but they are not CS.

Oh ok, I must be confused, because our CS degree teaches us programming as well as computational and numerical theory.

So CS majors in US can't program? That seems kind of funny to me
Oh well, I guess our degree just goes above and beyond, since they teach us the basics of so many languages in addition to everything that you "expect" a CS major to know.

Kind of ironic that a Computer Science major in the US apparently doesn't use a computer! Well I guess there are all kinds of places in the world!

ccubed, on 13 October 2012 - 11:14 PM, said:

This is perhaps the only thing so far that sounds like you had it in a CS course.

I'm confused, didn't you just list a bunch of stuff that you expect to find in a CS degree, and didn't I easily explain them all?

ccubed, on 13 October 2012 - 11:14 PM, said:

Your definition is correct, however there are no official one way functions for CS. Your encryption is a candidate for the title but has not been proven to be one, let alone the fact that we haven't even agree the things exist at all.

> there are no official one way functions for CS
What has that got to do with anything?
> What is one way function? HAHA I TRICK YOU THERE ARE NONE
As far as I know, modular calculus is entirely one way. And until someone proves P=NP, it's going to stay that way.

ccubed, on 13 October 2012 - 11:14 PM, said:

I wasnt, but if you didn't take computer science don't label it as such. If you did, then you did but it doesn't sound like it at all. Anyone would question it based on your description.

I did take Computer Science, and I WAS able to answer all of your test. It's pretty damn rude to get upset at someone because their degree includes things that yours didn't, then you make me jump through hoops, and when I do you still act angry when I correctly answer everything.

I'm sorry if your degree didn't teach programming and mine did, but how is that my fault?

ccubed, on 13 October 2012 - 11:14 PM, said:

Writing any of your code in goto is a scope killer. A modern control structure creates scope when it is called. Rewriting it using goto destroys that because goto doesn't create a scope. Which means control flow local variables become useless and stay in memory until the end of its parent scope. I don't need to explain to you the problem with that I wouldn't think.

You wouldn't need to explain it, if you weren't completely misrepresenting the situation.

foo(int i) {
if(i==10) goto ten;
return "not ten"
ten: ;
return "ten"
}

This is the situation I described, jumping within a scope.
Explain to me how I just "killed the scope" by jumping within the scope.
Explain to me how I destroyed the scope. Show me how the "control flow local variables" are useless.
Explain to me how this affects these "control flow local variables" so that they will stay until the end of their parent scope (which they apparently would not remain until if not for the goto).

Your description makes absolutely 0 sense. I've never heard anyone saying that local variables don't survive until the end of the scope, nor that gotos will somehow destroy a scope.

You do need to explain it because this thread is not "don't explain anything because everyone knows everything already".

ccubed, on 13 October 2012 - 11:14 PM, said:

If you need a script for that example you aren't planning enough and don't know how to control your programs memory use. This is something you would have learned in CS.

> we don't need tests because you will never do anything wrong
> if you learnt CS you would know this

Yeah sorry mate, I guess that's where our degrees diverge again. The degree I took taught that you should include testing, and that programmers do make mistakes often and you should write code and tests to try and prevent this.

Hell, if no programmers ever make mistakes, why do you disagree with the use of gotos? Surely these perfect programmers will always use them completely correctly with 0 risk, so why not let them?

[

ccubed, on 13 October 2012 - 11:14 PM, said:

What different level of abstraction? They belong in ASM and they should stay there. This is modern programming and in modern programming we've evolved control flow and scope.

> there are only 2 levels of abstraction
> ASM, and "modern programming"

What? What about hardware below ASM, or system architecture above "modern programming"? ASM and "modern programming" are not the only 2 levels of abstraction.

When you plan out a system, do you do it straight in C? You don't draw any diagrams or anything?

ccubed, on 13 October 2012 - 11:14 PM, said:

I'm going to be super condescending here, but your responses so far are getting flimsier and less based on rationale and your answers to some of the questions posed to you further iterates that there's a fundamental issue with how you organize things.

> there's a fundamental issue with how you organize things
What's that issue?

ccubed, on 13 October 2012 - 11:14 PM, said:

Many people with more experience than you I'm sure have told you not to use Goto. When asked why we agree the issue is largely not technical and tell you the reasons are scope, deprecation and universality.

> 'I know better than you and I'm telling you NO'
What does "universality' even mean? I have never in my life heard that term. Gotos are /too/ universal?

> 'the reason is scope'
Did you mean to say structure?

[cfoley]

It's a shame this thread has turned to insulting G0rman's degree, his job and his school. Most of us don't agree with his opinion but I for one was enjoying the thread until about now.

And what does a CS degree have to do with anything? I don't have one and I think a few of the more knowledgeable contributors to the thread don't either.

[macosxnerd101]

Quote

A compiler won't catch everything either. Why does that make writing a test script a waste of time, and using a compiler not a waste of time? (barring that a compiler is more than just a syntactic validator).

Define writing a test script. Do you want to write something in bash to test a Java program? Why not just use other more standard forms of testing like JUnit for unit tests? I honestly cannot tell if you are writing a parser or talking about standard forms of testing. Please specify. And why are we ignoring the functionality built into a compiler?

Quote

I have written parsers and compilers before, luckily a test to check that you are taking the right number of parameters and returning the right number is neither a parser nor a compiler.

No, it is a parser. A basic parser, but a parser nonetheless. And why do we need to write these checks if avoiding gotos and using a compiler will do it for us? You are making the case against yourself quite well.

Quote

If I recall correctly, VS can be set up to automatically do things like this, I remember having my C# code formatted all neatly according to company coding standards, I'm sure you could tweak it to verify any kind of syntactic requirement.

I took a class where a plugin for Eclipse was provided to us. This plugin was used to allow us to format our code to adhere to formatting conventions.

Quote

It's kind of funny when you extend the "if it doesn't contribute to your final product then don't do it" logic. No need for testing or source control, IDEs are a waste of money!

Your argument is that testing, source control, and IDEs help us do the job better, as does goto. Yet in your posts, you show ways where we have to account for gotos in additional ways that introduce more room for error and mistakes on the developers' parts.

Quote

Yeah sorry mate, I guess that's where our degrees diverge again. The degree I took taught that you should include testing, and that programmers do make mistakes often and you should write code and tests to try and prevent this.

There are plenty of good ways to test. Again, let's use tools we know work rather than reinventing the wheel on each case. I trust existing testing tools rather than a bash script you or I wrote because the existing tools have the test of time and lots of developers using them.

[jon.kiparsky]

cfoley, on 13 October 2012 - 01:10 PM, said:

It's a shame this thread has turned to insulting G0rman's degree, his job and his school. Most of us don't agree with his opinion but I for one was enjoying the thread until about now.

This is why I've backed out of this thread: it's getting harder to respond to G0rman's posts without raising these questions, and I'd like to stay above the line.

Quote

And what does a CS degree have to do with anything? I don't have one and I think a few of the more knowledgeable contributors to the thread don't either.

A CS degree is not a requirement for doing or understanding software development. However, if you claim to have one and you say things that sem to contradict this, it's going to raise an eyebrow.

[G0rman]

macosxnerd101, on 14 October 2012 - 02:11 AM, said:

Define writing a test script. Do you want to write something in bash to test a Java program? Why not just use other more standard forms of testing like JUnit for unit tests? I honestly cannot tell if you are writing a parser or talking about standard forms of testing. Please specify. And why are we ignoring the functionality built into a compiler?

No, it is a parser. A basic parser, but a parser nonetheless. And why do we need to write these checks if avoiding gotos and using a compiler will do it for us? You are making the case against yourself quite well.

To give you the context of the quote that you extracted;
> C code
> A snippet using gotos to emulate functions to demonstrate their power
> "hey but it can't do X"
> "that is easily fixable with a quick script if you really need it"
In other words, because it was a theoretical situation.

If someone asks "show me the power of gotos" and you give them a piece of code that is in Java (which has no gotos) and uses JUnit then they are going to be very confused!

macosxnerd101, on 14 October 2012 - 02:11 AM, said:

Your argument is that testing, source control, and IDEs help us do the job better, as does goto. Yet in your posts, you show ways where we have to account for gotos in additional ways that introduce more room for error and mistakes on the developers' parts.

Nope, read again
My argument was that if your philosophy is "don't do anything that won't be in the final product" then wouldn't that imply that you won't use testing, source control and IDEs, etc.

You could call that reducto ad absurdum, but it seems pretty logical to me.

macosxnerd101, on 14 October 2012 - 02:11 AM, said:

There are plenty of good ways to test. Again, let's use tools we know work rather than reinventing the wheel on each case. I trust existing testing tools rather than a bash script you or I wrote because the existing tools have the test of time and lots of developers using them.

Ok, feel free to link an existing testing tool which can check that your ad-hoc goto-emulated functions are valid, please feel free to.

Otherwise, I think you have _completely_ pulled things out of context.

jon.kiparsky, on 14 October 2012 - 02:28 AM, said:

This is why I've backed out of this thread: it's getting harder to respond to G0rman's posts without raising these questions, and I'd like to stay above the line.

A CS degree is not a requirement for doing or understanding software development. However, if you claim to have one and you say things that sem to contradict this, it's going to raise an eyebrow.

You say you wanted to "stay above that line" but you just made a post where the whole content was "I didn't post because I don't think he studies CS." Oh but you did, post, so I guess it's just "I don't think he studies CS".

You made it very clear that you think I don't study CS.

Why do you think this? Because the degree covered legacy languages? Because it involved programming at all? I apologies profoundly that my degree involves actually using a computer.

This post has been edited by G0rman: 13 October 2012 - 11:37 AM

[jon.kiparsky]

Quote

My argument was that if your philosophy is "don't do anything that won't be in the final product" then wouldn't that imply that you won't use testing, source control and IDEs, etc.

But since nobody advocated that philosophy, you're wasting your breath.

Quote

Ok, feel free to link an existing testing tool which can check that your ad-hoc goto-emulated functions are valid, please feel free to.

There is no such tool. Why? Because no developer in the world needs such a tool. Why? Because no developer in the world writes code like this.
Why? Because there is no point in the world in writing "ad-hoc goto-emulated functions" when you can just use real programming languages to write real code and get something real done.

Dammit, I was done with this thread. Stop being wrong!

This post has been edited by jon.kiparsky: 13 October 2012 - 11:37 AM

[G0rman]

jon.kiparsky, on 14 October 2012 - 02:35 AM, said:

Quote

My argument was that if your philosophy is "don't do anything that won't be in the final product" then wouldn't that imply that you won't use testing, source control and IDEs, etc.

But since nobody advocated that philosophy, you're wasting your breath.

But you did?

Not in those exact words, but read your posts again. It's pretty clear that you are saying you don't bother writing automations and scripts that won't be in the final deliverable.

eg "I could write a bash script to find this, but then you've got me once again spending my time and attention on things which are not important to me"

Besides that, how is "but no one said that" a defence for a blatant strawman?

This post has been edited by G0rman: 13 October 2012 - 11:40 AM

[jon.kiparsky]

G0rman, on 13 October 2012 - 01:40 PM, said:

jon.kiparsky, on 14 October 2012 - 02:35 AM, said:

Quote

My argument was that if your philosophy is "don't do anything that won't be in the final product" then wouldn't that imply that you won't use testing, source control and IDEs, etc.

But since nobody advocated that philosophy, you're wasting your breath.

But you did?

Not in those exact words, but read your posts again. It's pretty clear that you are saying you don't bother writing automations and scripts that won't be in the final deliverable.

Not in those words or in any words. There's a far cry from "writing tests" and "interrupting the profit-making development work that I'm paid to do in order to write a parser in bash to replicate the functionality already provided by the compiler so I can write worse code that will take me longer to write and almost certainly run slower".

One is a requirement of the job, and the other would get you fired from any profit-making software venture. The only way you could improve on that, as bad ideas go, would be to propose writing your code in brainfuck or whitespace.

[G0rman]

jon.kiparsky, on 14 October 2012 - 02:35 AM, said:

There is no such tool. Why? Because no developer in the world needs such a tool. Why? Because no developer in the world writes code like this.
Why? Because there is no point in the world in writing "ad-hoc goto-emulated functions" when you can just use real programming languages to write real code and get something real done.

Of course there is no such tool!

*head desk*

jon.kiparsky said:

If you haven't got an example of this power and flexibility - and I'm honestly interested in seeing it - I think there's not much point in continuing with this.

g0rman said:

// sub() with goto
stack dynamiclinks;
stack args;

// foo {
foo: ;
dynamicLink.push(&&foo_1);
args.push(7);
goto bar;
foo_1: ;
printf("%d",args.pop());
// }

// bar(int i) {
bar: ;
i=args.pop();
i++;
args.push(i);
goto dynamicLink.pop();
// }

someone said:

How would you deal with making sure there are no errors if you change the imports?

g0rman said:

Write a script

macosxnerd101 said:

There are plenty of good ways to test. Again, let's use tools we know work rather than reinventing the wheel on each case. I trust existing testing tools rather than a bash script you or I wrote because the existing tools have the test of time and lots of developers using them.

g0rman said:

Ok, feel free to link an existing testing tool which can check that your ad-hoc goto-emulated functions are valid, please feel free to.

jon.kiparsky, on 14 October 2012 - 02:35 AM, said:

There is no such tool. Why? Because no developer in the world needs such a tool. Why? Because no developer in the world writes code like this.

Do you see how yours and macosxned101s' responses are entirely ridiculous?

jon.kiparsky, on 14 October 2012 - 02:47 AM, said:

Not in those words or in any words. There's a far cry from "writing tests" and "interrupting the profit-making development work that I'm paid to do in order to write a parser in bash to replicate the functionality already provided by the compiler so I can write worse code that will take me longer to write and almost certainly run slower".

One is a requirement of the job, and the other would get you fired from any profit-making software venture. The only way you could improve on that, as bad ideas go, would be to propose writing your code in brainfuck or whitespace.

Sure, when you pull things COMPLETELY out of context.

> originally discussing how we would validate code where sub() was emulated with goto
> suddenly morphed in to "if you wrote a validator then you will be fired because you shouldn't have written that code becuase actually you are at a job working and this isn't at all related to your current project"

I do not see how or why you made that leap. Well I can see why, it's an easy way to pretend that you are right.

Mind if I change context? You are now in the early 50's and everyone is using GOTO and you are refusing to use them at work and so you are fired. Too bad!

This post has been edited by G0rman: 13 October 2012 - 11:51 AM

[jon.kiparsky]

No, I don't, but don't bother explaining. This is a pure waste of time.

SpectateSwamp, where are you when we need you?

This post has been edited by jon.kiparsky: 13 October 2012 - 11:52 AM

[modi123_1]

Starting off with 'gotos: smear campaign explained' and 'teaching OO and patterns are bad because that's how people will always view things' smacks of someone is having a bad day. Wanna talk about it?

Spoiler

This post has been edited by modi123_1: 13 October 2012 - 11:53 AM

[macosxnerd101]

Quote

I already laid the groundwork by writing // bar(int i) { Now I just need to parse my code and check that whenever I goto bar I first args.push() once. By following some simple conventions this problem is not at all difficult. For example I could generalize and say that one must write // bar takes <list of types> and returns <list of types> then it would be trivial to validate. Read through the code and generate a list of valid signatures, then read it again and make sure all goto calls are valid.

This is what you suggested doing. If I don't use gotos and use a compiler, then I don't have to write all this extra code to handle these checks.

And if I want to test my code, I can start with unit testing frameworks like CUnit or Check, both for the C language.

Quote

My argument was that if your philosophy is "don't do anything that won't be in the final product" then wouldn't that imply that you won't use testing, source control and IDEs, etc.

The argument is two part. First- be economical and use tools that provide the most utility. IDEs, source control, testing frameworks, etc., already work. Why reinvent the wheel (a point you still have not addressed regarding your home-cooked bash script to parse the code)? Second- why do extra work that is more error-prone (including logical errors) to compensate for gotos, when not using them allows me to do less work?

Quote

Otherwise, I think you have _completely_ pulled things out of context.

Not really. I think you are ignoring and contradicting your prior statements. I'm seriously interested in a direct answer on the two points listed above:

• Why reinvent the wheel with a bash script when existing tools are better than what you or I could home roll?
  
• Why do extra work that is more error-prone (including logical errors) to compensate for gotos, when not using them allows me to do less work?

Quote

Not in those exact words, but read your posts again. It's pretty clear that you are saying you don't bother writing automations and scripts that won't be in the final deliverable.

eg "I could write a bash script to find this, but then you've got me once again spending my time and attention on things which are not important to me"

He's saying the same thing I am- let's spend our time on viable tests rather than creating a bash script to check things that the compiler already does so well.

Quote

Mind if I change context? You are now in the early 50's and everyone is using GOTO and you are refusing to use them at work and so you are fired. Too bad!

Why are we changing the timeframe when this clearly isn't the case? Why do I have to pretend that I have my hands tied when I don't? Because it validates your argument? If I was in the 50's, I would probably agree with a lot of your points. We're not. Things have evolved.

[G0rman]

macosxnerd101, on 14 October 2012 - 02:53 AM, said:

This is what you suggested doing. If I don't use gotos and use a compiler, then I don't have to write all this extra code to handle these checks.

And if I want to test my code, I can start with unit testing frameworks like CUnit or Check, both for the C language.

Sure

BUT

The question was "If you haven't got an example of [goto's] power and flexibility - and I'm honestly interested in seeing it - I think there's not much point in continuing with this."

Is "I would not use gotos and then I would test my code using CUnit and Check" an acceptable way to show the power of gotos?

I'm pretty sure it isn't!

PLEASE CONSIDER THE CONTEXT.

macosxnerd101, on 14 October 2012 - 02:53 AM, said:

The argument is two part. First- be economical and use tools that provide the most utility. IDEs, source control, testing frameworks, etc., already work. Why reinvent the wheel (a point you still have not addressed regarding your home-cooked bash script to parse the code)? Second- why do extra work that is more error-prone (including logical errors) to compensate for gotos, when not using them allows me to do less work?

This is not an "IDE/source control/testing framework VS goto" situation! This is a "write a quick validator script VS don't bother".

PLEASE CONSIDER THE CONTEXT.

macosxnerd101, on 14 October 2012 - 02:53 AM, said:

Not really. I think you are ignoring and contradicting your prior statements. I'm seriously interested in a direct answer on the two points listed above:

• Why reinvent the wheel with a bash script when existing tools are better than what you or I could home roll?
  
• Why do extra work that is more error-prone (including logical errors) to compensate for gotos, when not using them allows me to do less work?

• Because existing tools don't validate ad-hoc goto-emulation of sub()
  
• Because we are talking about validating an ad-hoc goto-emulation of sub() which jon.kiparsky asked me how I would validate it.

PLEASE CONSIDER THE CONTEXT.

macosxnerd101, on 14 October 2012 - 02:53 AM, said:

He's saying the same thing I am- let's spend our time on viable tests rather than creating a bash script to check things that the compiler already does so well.

No, he's not.


macosxnerd101, please man, please, you are killing me here. Read the thread, understand the context.

You can't give an example of goto's power without using goto's.
You can't validate a script with some weird structure with existing tools.
You can't say "no I will ignore the context and just make things up"

Please man, PLEASE.

jon.kiparsky, on 14 October 2012 - 02:51 AM, said:

This is a pure waste of time.

> Write me some code using gotos
> Validate the code
> Now you are fired for writing a validator for code with gotos instead of writing in Java

Scumbag boss.

This post has been edited by G0rman: 13 October 2012 - 12:02 PM

[no2pencil]

G0rman, on 11 October 2012 - 09:43 AM, said:

GOTOs are considered "evil", but does that mean they should be forbidden knowledge?

GOTO is not efficient in functional coding. If I were paying for school, I wouldn't want them teaching me bs that isn't going to help further my career.

There is nothing wrong with proactively learning outside of the box. But if you are not going to use GOTO in a script or 8 bit computing, you are wasting your time.

[jon.kiparsky]

The request you're referring to specifically asked for an example of "something I'd actually want to do" that GOTO allows and existing control structures do not allow. Reinventing these wheels is not something that any sane person would want to do, and you've demonstrated quite thoroughly just why that is. Thank you. Are we done yet?