[mojo666]

Quote

I think I've said it 3 times before, but no one has given me an answer as to why jumps within a block or scope are bad. Do you really think it is so hard to read/debug/alter those ~10 line examples.

We'll stay with the function example. Make a change to the function and compare how easily and dependably you can change the GOTO version and the structured version. Suppose "bar" is changed to accept a second argument. How many more changes do you need to make to the GOTO version? What if bar were called in more than one place? Are there changes you can forget that wont be caught for you? How does this compare to the structured version? What if you need bar to return 2 values? Apply the same questions to this scenario. How do these extra problems scale as the code gets more complex? GOTO's leave a lot more room for error than the structured counter parts. If you change the function definition, but forget to change the call, the compiler will catch this for you. GOTO's have no such defence for these types of mistakes.

Also, in my first post, I mentioned the evolution of the code. Jumps within a block/scope are bad because they encourage you or the next guy that maintains your code to jump out of the block or scope. Even if you maintain clean restricted use of GOTO, the next guy may not be so dependable and we start getting noodles in the spaghetti bowl. Don't even give them that option. Use structures.

As for your points about low level, in low level languages we don't have structures. We are stuck dealing with the extra shit that go along with GOTO/jump because we don't have a choice. Higher level languages may support both. Given the option, stick with structures. They are safer and easier to manage. Malloc and pointers are harder to read and maintain. That is why higher level languages do that for you. Again, memory management is just another place where you can break your code. Why leave it to the programmer when it can be properly managed for them?

I hope you understand why GOTO's tend to be viewed as poor programming practice. Can you now answer my question? Given the serious advantages structures have over GOTO, strucutures are preferable. Can you come up with an advantage GOTO offers that structures lack? If you can't, then there is really no reason use GOTO since you are adding a bunch of negative aspects to your code without gaining any benefit.

This post has been edited by mojo666: 12 October 2012 - 02:47 PM

[AdamSpeight2008]

baavgai, on 12 October 2012 - 01:56 PM, said:

LOL. I suspect you'll use recursion, which is looping using the stack. Curiosity, though... Do this without loops.

void printTable(int n) {
	for(int row=1; row<=n; row++) {
		for(int col=1; col<=n; col++) {
			printf(" %3d", row * col);
		}
		printf("\n");
	}
}

Challenge Accepted.

void printTable(int n)
{
  _printTable(n);
}
private void _printTable(int n,int row, int col)
{
  if( row<= n )
  {
    if( col<=n )
    {
      printf(" %3d", row * col);
      _printTable(n,row,col+1);
    }
    else
    {
      printf("\n");
      _printTable(n,row+1,1);
    }
  }
}

Challenge thrown down do it using a Fix Point Combinator then.
Eg Fix(Of T)

This post has been edited by AdamSpeight2008: 12 October 2012 - 03:43 PM

[ccubed]

Wow, we got this conversation going on for a pretty long time didn't we.

I don't necessarily think that GOTO is bad or evil. It's certainly no more evil than a for statement or an if statement. Reserved keywords are just that, words that mean something to a compiler in a language. They're neither good nor bad. The issue comes when you're writing code or someone else is. Keywords don't make bad code, coders do.

Thus it is with the GOTO. The GOTO is considered functionally bad because of what it tells you is an acceptable use case. GOTO can go to a label immediately and brakes the natural progression of control flow. It's not so much that there is any clear, technological reason that GOTO is worse, because GOTO is used in ASM and Machine Language anyways once your code is compiled. That's not the point though, the point is that in the recent years we've gotten to a point where we can pretty well define, control and direct the flow of a program on any platform in any language. This wasn't always so easy or possible back in the days when GOTO was rampant. In fact, GOTO was the bees knees so to speak, it allowed a semblance of control flow. It was also responsible for tons of undefined behavior. That's not important though. What is important is that we no longer have that issue. GOTO has fallen to the wayside in favor of more clearer and easier to use, read and understand control flow statements. Not because they're somehow better or more powerful than GOTO, but because they allow us three things.

• They're exponentially easier to read
  
• They only exist in current scope
  
• They only do one thing

In essence, what happened is that paradigms were created and modern programmers decided that the look and feel of the control flow we have today is better. It's not because GOTO was bad, it's because it's hard to read. And it is. I can't think of anyone who would argue that your examples using GOTO are easier to read than our examples using modern control flow.

I will agree with you that anyone that argues that there is anything inherently evil with GOTO has to do so on grounds that are either shaky, untrue or outright opinionated. The argument against GOTO has never been technical (Except in the case of productivity), it has always been about readability and universality. The fact is that there are a lot of coders now. Like any good group of fellow white collar workers, we're trying to regulate ourselves and increase productivity. Therein lies the only reasonable technically related argument about GOTO, productivity when trying to code a large scale application using GOTO is considerably lower. Again though, beyond that, there is no technical reason not to use it.

That being said, as everyone else has pointed out, you shouldn't use GOTO. Not because it is technically weaker or less dynamic, but because it is hard to read. It is not modern, it is not part of any universalized paradigm or method of building an application. It is slow, hard to plan around and complicated in large scale productions. In a massive program like an Operating System, they even forwent GOTO and ASM. They attempt to use it as little as possible. Drivers and the like, low level interactions, those are made using ASM, but as little as possible is made that way because it is hard to maintain. It is massively more complicated than a typical application and in a project as large as an OS it can absolutely kill productivity and even sometimes prevent completion.

So basically, the end of this is that you shouldn't use GOTO because it is hard to read, hard to follow and hard to debug. In a short program example like you give, fine, it looks great, but now put that in a massive project. It doesn't look so appealing. It didn't look so appealing a couple of years ago. It didn't look appealing to the people that grew up on it, they made more languages and better paradigms.

[G0rman]

mojo666, on 13 October 2012 - 05:45 AM, said:

Suppose "bar" is changed to accept a second argument. How many more changes do you need to make to the GOTO version? What if bar were called in more than one place? Are there changes you can forget that wont be caught for you? How does this compare to the structured version? What if you need bar to return 2 values? Apply the same questions to this scenario. How do these extra problems scale as the code gets more complex? GOTO's leave a lot more room for error than the structured counter parts. If you change the function definition, but forget to change the call, the compiler will catch this for you. GOTO's have no such defence for these types of mistakes.

I see what you are getting at, but it seems pretty trivial. Whenever you change what a function inputs, you should check everywhere it is called. It makes no difference whether I /foo() or /foo: And you shouldn't change what a function outputs, you are better just starting again. It honestly seems pretty trivial to write a short bash script that checks that functions are taking and exporting the right number of args. Add it to your integration testing that runs whenever you compile, and you will never have problems!

Plus you just outlined something very interesting about the way that emulating functions works - you can have multiple return values! Most languages aren't too happy with return i, j, "hello" but if you absolutely needed it, you could do it with gotos quite easily.

However I would say that emulating functions is not really in the spirit of my question. But I'll accept it since it's within a scope. So long as you don't expect everything to be inside the global scope! Actually I'd accept that so long as it abides by the aforementioned "30-50 line function length limit", since that was the spirit of the question.

mojo666, on 13 October 2012 - 05:45 AM, said:

Jumps within a block/scope are bad because they encourage you or the next guy that maintains your code to jump out of the block or scope.

Huh? I disagree. When I see a goto I don't think "Oh goodie, now I can happily write bad code". Actually when I see any kind of code I don't automatically decide to write bad code.

I think you muddled something there.

mojo666, on 13 October 2012 - 05:45 AM, said:

Why leave it to the programmer when it can be properly managed for them?

A lot of people would have real trouble in their environments if they weren't allowed to manually manage their own resources.

mojo666, on 13 October 2012 - 05:45 AM, said:

I hope you understand why GOTO's tend to be viewed as poor programming practice. Can you now answer my question? Given the serious advantages structures have over GOTO, strucutures are preferable. Can you come up with an advantage GOTO offers that structures lack? If you can't, then there is really no reason use GOTO since you are adding a bunch of negative aspects to your code without gaining any benefit.

I think this is not a unique approach. A good parallel is baavgai's multiple return. There's no way he would use it if there was no advantage to it. Generally, we don't use any programming element unless there is an advantage in it. Your wording seems to imply "name one good example and you can use it anywhere", but it should be "name one good example and you can use it for that one good example" - which is what I've said all along, you need to be pragmatic about gotos, not dogmatic.

If there appeared a situation where the best way to do it would be with gotos, I would not hesitate to use them. If it's the best tool for the job, I wouldn't not use it just because "it's often not the best tool for the job".

ccubed, on 13 October 2012 - 08:16 AM, said:

• They're exponentially easier to read
  
• They only exist in current scope
  
• They only do one thing

• I disagree - especially with the "exponentially", this is more of a personal problem though.
  
• Many languages have this restriction, and it can be simply convention
  
• Gotos only goto. It is the structure you are talking about. An if can be used in a singleton or factory, etc. Same thing.

ccubed, on 13 October 2012 - 08:16 AM, said:

It is slow, hard to plan around and complicated in large scale productions.

Are goto's really slow and hard to plan around, or even complicated?

Bad code is slow, hard to plan around, and complicated. I don't think that is a trait inherent in using GOTOs. For example my example of emulating sub() using gotos. That would be considerably faster than conventional subs, because you aren't dealing with scoping (not pushing vars on to the stack etc, though you are making your own link stack...). I don't think a within scope jump is complicated or hard to plan around.

ccubed, on 13 October 2012 - 08:16 AM, said:

In a massive program like an Operating System, they even forwent GOTO and ASM. They attempt to use it as little as possible. Drivers and the like, low level interactions, those are made using ASM, but as little as possible is made that way because it is hard to maintain.

I thought that was more to do with the lack of people who code ASM. I would guess that they made a concious tradeoff in some of the parts of the OS that are run more frequently.
Not sure which OS you are talking about, but I'm sure they would have to make a pragmatic choice about whether to make the code "slightly harder to maintain" or slower.

ccubed, on 13 October 2012 - 08:16 AM, said:

In a short program example like you give, fine, it looks great, but now put that in a massive project. It doesn't look so appealing.

I disagree. Employing a scope limiting convention effectively solves this problem.

This post has been edited by G0rman: 12 October 2012 - 09:57 PM

[jon.kiparsky]

G0rman, on 12 October 2012 - 11:47 PM, said:

I see what you are getting at, but it seems pretty trivial. Whenever you change what a function inputs, you should check everywhere it is called. It makes no difference whether I /foo() or /foo: And you shouldn't change what a function outputs, you are better just starting again. It honestly seems pretty trivial to write a short bash script that checks that functions are taking and exporting the right number of args. Add it to your integration testing that runs whenever you compile, and you will never have problems!

Why not just let the compiler do that for you? If I make a mistake calling a function, the compiler will catch it, unless I've overloaded it and called the wrong version. (in which case I'll have to catch it when the logic fails)
Or if I change a function - and that can happen, especially if you're prototyping or experimenting - the compiler will happily point me to every place where the function is called with the wrong signature.

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: this time I'm reinventing the compiler, badly. So in the words of the great Wallace Stevens, you've taken a wonderful solution and divided it neatly into two problems.

[G0rman]

jon.kiparsky, on 13 October 2012 - 12:55 PM, said:

Why not just let the compiler do that for you? If I make a mistake calling a function, the compiler will catch it, unless I've overloaded it and called the wrong version. (in which case I'll have to catch it when the logic fails)

Do you really code like this? Making changes then compiling to see what you need to do? What if you created an error not picked up by the compiler which you rely on so much?

If you change what a function does (which you REALLY shouldn't do), then it should be reflex to check where it is called.

Sorry but I can't accept "the compiler may help me sometimes if I'm lazy" as a reason.

jon.kiparsky, on 13 October 2012 - 12:55 PM, said:

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: this time I'm reinventing the compiler, badly. So in the words of the great Wallace Stevens, you've taken a wonderful solution and divided it neatly into two problems.

I disagree, the script is part of your code.

Do you refer to writing syntactic elements such as } or ; as "spending my time and attention on things which are not important to me"?


Actually a script that checks your code for errors is FAR from useless! The first thing I do when I write code is write up testing suites.
I would hate to see the look on my boss's face if I told him "No I don't write tests of any kind, they just aren't worthy of my time or attention".

[macosxnerd101]

Quote

Do you really code like this? Making changes then compiling to see what you need to do? What if you created an error not picked up by the compiler which you rely on so much?

That's what the compiler is there for, so why not take advantage of it? And if it's a runtime error, it will occur on runtime.

Quote

Sorry but I can't accept "the compiler may help me sometimes if I'm lazy" as a reason.

It's more of an "I don't want to reinvent the wheel" as a reason. And don't we all use the compiler at times? Don't we compile, test our code, then go and add another feature? Isn't that good programming practice? Rather than compiling and testing for errors, let's write a second script to test our current code for errors? Surely you can see the recursive nature of the problem.

Quote

I disagree, the script is part of your code.

Again, recursive nature of the problem.

Quote

Do you refer to writing syntactic elements such as } or ; as "spending my time and attention on things which are not important to me"?

A lot of people do consider this a waste of time. These people migrate towards languages like Python for this very reason. That's an entirely different conversation though.

Quote

Actually a script that checks your code for errors is FAR from useless! The first thing I do when I write code is write up testing suites.

Tests don't check your code for errors. They help check for a certain amount of correctness. You design tests because you want them to pass, not because you are trying to make them fail. And as we all know, no test (or series of tests) will catch every logical flaw or runtime error within the program. And tests don't parse your code for errors. They make use of the existing codebase to assert certain conditions.

[jon.kiparsky]

G0rman, on 13 October 2012 - 12:03 AM, said:

jon.kiparsky, on 13 October 2012 - 12:55 PM, said:

Why not just let the compiler do that for you? If I make a mistake calling a function, the compiler will catch it, unless I've overloaded it and called the wrong version. (in which case I'll have to catch it when the logic fails)

Do you really code like this? Making changes then compiling to see what you need to do? What if you created an error not picked up by the compiler which you rely on so much?

If you change what a function does (which you REALLY shouldn't do), then it should be reflex to check where it is called.
Sorry but I can't accept "the compiler may help me sometimes if I'm lazy" as a reason.

No, usually I'm pretty careful about what I write. But I do make mistakes, and I find that there are very few of those that get by the compiler.
As for changing the signature of a method, yes, we do refactor from time to time. And when we do, it's nice to know that the compiler can pick up any places where we've missed a step.

I do have to say, I'm impressed by your coding chops if you think writing a parser - in bash! - for a new and unspecified language is something so simple that the only reason I'd fail to do it is sheer laziness.

Or I would be, if I believed a word of what you're saying. If you'd ever written a parser by hand, you would know that there are tools which generate parsers, and they generate better parsers than you're going to bang together, so you'd use those. Writing your first parser by hand is exciting and a little bit magical. Writing your second by hand is masochism.

Quote

I disagree, the script is part of your code.

Part of the code? I don't think so. It's part of the support for the code. This is very much Randall Munroe's "General Problem" rearing up its ugly head. You're diverting your attention from solving some business problem - meeting a need - to something which does not provide any functionality to your clients.
There is, today, a program which does everything that your bash script does. If you take steps which result not only in you having to spend time devising new and worse (more error-prone, less optimizable) solutions to already solved problems, you've already lost once. If you then find that you have to spend more time developing tools just to keep your new and worse solutions from blowing up if you change the code (and you will change the code) then you've lost twice. If you suggest writing another program to solve this, you're just losing again.
I don't like to get personal, but are you actually involved in professional software development? I just can't imagine this sort of thing going over very well in an actual development situation. I mean, spending your time writing tools which don't advance the client's interests, but which facilitate your production of unmanageable code doesn't sound like the sort of thing that anyone would be willing to pay for.

Quote

Do you refer to writing syntactic elements such as } or ; as "spending my time and attention on things which are not important to me"?

No.

Quote

Actually a script that checks your code for errors is FAR from useless! The first thing I do when I write code is write up testing suites.
I would hate to see the look on my boss's face if I told him "No I don't write tests of any kind, they just aren't worthy of my time or attention".

But "no, I didn't write any unit tests because I was busy re-inventing the compiler" would be fine? I don't think so.
Test suites are a great way to ensure that you've done your due diligence in terms of design, and they're a great way to spot failure when it happens. What you're describing is not unit tests, though - it's a syntax checker.
I've already got one of those. I don't really want to write another one.

This post has been edited by jon.kiparsky: 12 October 2012 - 10:29 PM

[G0rman]

macosxnerd101, on 13 October 2012 - 01:15 PM, said:

Tests don't check your code for errors. They help check for a certain amount of correctness. You design tests because you want them to pass, not because you are trying to make them fail. And as we all know, no test (or series of tests) will catch every logical flaw or runtime error within the program. And tests don't parse your code for errors. They make use of the existing codebase to assert certain conditions.

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).

jon.kiparsky, on 13 October 2012 - 01:27 PM, said:

I do have to say, I'm impressed by your coding chops if you think writing a parser - in bash! - for a new and unspecified language is something so simple that the only reason I'd fail to do it is sheer laziness.

Or I would be, if I believed a word of what you're saying. If you'd ever written a parser by hand, you would know that there are tools which generate parsers, and they generate better parsers than you're going to bang together, so you'd use those. Writing your first parser by hand is exciting and a little bit magical. Writing your second by hand is masochism.

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.

It's more "coding by contract" than parser.

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.

If you've ever had to write code that is required to follow a specific structure, then stuff like this is nothing new.
A lot of the Java programmers I know automatically generate their getters and setters in a similar fashion.

jon.kiparsky, on 13 October 2012 - 01:27 PM, said:

but are you actually involved in professional software development?

A bit rude... But yes, and we take testing very seriously. Generally we don't forgo writing testing because "the test suite may have errors", that seems... I can't think of the right word for that kind of logic, but it certainly isn't productive.

On a sidenote: this kind of problem is not entirely alien to us, we have written specialized language for use in representing business logic. As well as generating relationships between databases and classes automatically, etc. Perhaps where I work is just more in to "code that makes code" or "code that helps you code" and of course "code that checks code". YMMV, I'm not saying everyone should do this.

jon.kiparsky, on 13 October 2012 - 01:27 PM, said:

it's a syntax checker.
I've already got one of those. I don't really want to write another one.

If the code you are writing has to follow certain conventions that your compiler doesn't check, then why not write them youreself?
As I previously mentioned, often people are required to use getters and setters on all their Java, that's pretty menial and qualifies for "spending my time and attention on things which are not important to me". So why not automate it?

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.




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!

[Lemur]

I stopped believing in the OPs credibility at FORTRAN and other legacy languages being taught.

Perpetuating ignorance and bad code is idiocy. Programming is a science, a pure art, and only consequentially used for business purposes, not the other way around.

Let me put this simply: Businessmen should never make programming languages. Ever.

Let's take two languages for example here: RPG(1959) and LISP(1958).

RPG was invented by businessmen for businessmen. It's the most contrived and annoying language humanly imaginable that's thought to have a practical use. You have forced indentation ('Free' specs are garbage) and a system which imposes a ludicrous amount of rules and regulations that force a programmer to do way more work than should ever be necessary.

LISP was invented by a mathematician as a theoretical language, later implemented by one of his students. It is, without question, the most powerful language in existence. It has no forced form of order, and is described as the programmable programming language (macros). It's still used in modern environments and has well past lasted the test of time.

Now normally people would say something about age. Age is irrelevant, good engineering and design is timeless.

LISP introduced 9 ideas. Tell me if they're familiar at all.

Quote

1. Conditionals. A conditional is an if-then-else construct. We take these for granted now. They were invented by McCarthy in the course of developing Lisp. (Fortran at that time only had a conditional goto, closely based on the branch instruction in the underlying hardware.) McCarthy, who was on the Algol committee, got conditionals into Algol, whence they spread to most other languages.

2. A function type. In Lisp, functions are first class objects-- they're a data type just like integers, strings, etc, and have a literal representation, can be stored in variables, can be passed as arguments, and so on.

3. Recursion. Recursion existed as a mathematical concept before Lisp of course, but Lisp was the first programming language to support it. (It's arguably implicit in making functions first class objects.)

4. A new concept of variables. In Lisp, all variables are effectively pointers. Values are what have types, not variables, and assigning or binding variables means copying pointers, not what they point to.

5. Garbage-collection.

6. Programs composed of expressions. Lisp programs are trees of expressions, each of which returns a value. (In some Lisps expressions can return multiple values.) This is in contrast to Fortran and most succeeding languages, which distinguish between expressions and statements.

It was natural to have this distinction in Fortran because (not surprisingly in a language where the input format was punched cards) the language was line-oriented. You could not nest statements. And so while you needed expressions for math to work, there was no point in making anything else return a value, because there could not be anything waiting for it.

This limitation went away with the arrival of block-structured languages, but by then it was too late. The distinction between expressions and statements was entrenched. It spread from Fortran into Algol and thence to both their descendants.

When a language is made entirely of expressions, you can compose expressions however you want. You can say either (using Arc syntax)

(if foo (= x 1) (= x 2))

or

(= x (if foo 1 2))

7. A symbol type. Symbols differ from strings in that you can test equality by comparing a pointer.

8. A notation for code using trees of symbols.

9. The whole language always available. There is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime.

Running code at read-time lets users reprogram Lisp's syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp's use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea recently reinvented as XML.

http://paulgraham.com/diff.html

Again, good design is timeless. Goto is a relic of the past that should have never existed, along with FORTRAN, RPG, COBOL, and the like.

Oh, and for those of you curious to try LISP or a derivative, look into 'The Little Schemer' or 'Practical Common Lisp.'

[jon.kiparsky]

Quote

Oh, and for those of you curious to try LISP or a derivative, look into 'The Little Schemer' or 'Practical Common Lisp.'

I haven't spent much time with the latter, but TLS is a charming little book, and surprisingly deep. I enthusiastically second that recommendation.

Especially since it takes you into a language where the idea of the "goto" is simply nonsensical. At least, I can't imagine how or why you'd ever think of an unconditional branch in a lisp.


Conrad Barski's Land of Lisp is also worth a look, and of course Structure and Interpretation of Computer Programs is the classic of the bunch.
For java heads, I'm finding Scala to be quite intriguing, although I can't really recommend Odersky's book. It's maybe adequate, but not very much more than that.

[Lemur]

When I had to study VB, RPG, COBOL, and the like I felt like I was jailed. Creativity was stifled and it was all about 'productivity' instead of making things that worked. In the days where you had to write catches for any possible combination of obscure errors generated by junk code like gotos and overly muted variables, when 90% of your code was boilerplate (I classify frameworks the same way), and getting things done was often laughed at. That's not programming, that's a specially engineered hell for anyone with a dream and with some passion.

Ruby was the language that started me down the road to functional. Boilerplate code started to fade, mutation far less common, and catches were no issue with pure functions. It was beautiful, everything just worked. THAT is what programming should be. Enlightenment, freedom, inspiration, muse.

The main thing I have against other languages? They're frankly not beautiful, nor are they particularly elegant. This is especially true for mainframe languages like RPG, FORTRAN, and COBOL.

Ah, Sussman's book is good from what I've read. I need to finish it. Next on the list after I get through those are 'Let over Lambda' and 'On Lisp'

[G0rman]

Lemur, on 13 October 2012 - 01:57 PM, said:

I stopped believing in the OPs credibility at FORTRAN and other legacy languages being taught.

That's a shame.
In first year we are taught some ASM and VHDL, Java, C, C++, Bash and Perl
In second year we were taught Ada, Algol, C#, Eiffel, FORTRAN, Pascal, Prolog, Ruby Smalltalk and Scheme.
In third year the focus is on libraries and IDEs rather than languages, I don't think we learnt any.

If you think my course of study makes me uncredible, then that's a shame.
YMMV, I don't know of any regulations as to which language CS graduates should know.

Lemur, on 13 October 2012 - 01:57 PM, said:

Programming is a science, a pure art, and only consequentially used for business purposes, not the other way around.

I concur.

Though I'm not sure if you were implying something with "Perpetuating ignorance and bad code is idiocy"... Who exactly is perpetuating ignorance?

Lemur, on 13 October 2012 - 01:57 PM, said:

Again, good design is timeless. Goto is a relic of the past that should have never existed

Before the invention of the if/then/else, for loop, while loop, do-while loop, switch and func() patterns, I'm sure goto was necessary. Before the invention of the singleton, there were people using classes where only 1 object would be exist at a time. Saying you can have a langauge without goto is fine, but saying it never should have existed is questionable. It seems like an important stepping stone in the development of the common patterns that languages now implement.

Lemur, on 13 October 2012 - 02:19 PM, said:

The main thing I have against other languages? They're frankly not beautiful, nor are they particularly elegant. This is especially true for mainframe languages like RPG, FORTRAN, and COBOL.

Ah, Sussman's book is good from what I've read. I need to finish it. Next on the list after I get through those are 'Let over Lambda' and 'On Lisp'

I like your philosophy, but beauty in code seems like a topic for elsewhere

Will definitely look in to those books though.

This post has been edited by G0rman: 12 October 2012 - 11:35 PM

[jon.kiparsky]

Sussman and Abelson is available on line (as is a recording of the course they taught based on it). PCL and On Lisp are also on line. If you work fast, you could also dive into Martin Odersky's Functional Programming in Scala course on Coursera. It's halfway through, but but the assignments are not to crushingly difficult, you could probably get caught up by the end if you worked at it. The material is worth the effort.
Little Schemer (and its followup volumes) must be purchased in dead tree flavor, same with Land of Lisp. (maybe available in ebook form, I suppose)

Whichever of these floats your boat, learning a Lisp and maybe a more modern functional language as well will likely change a lot of your thinking about programming. It did for me, anyway.

[Lemur]

GOTO was invented with FORTRAN in 1954. Conditionals and loops along with various other things used frequently in modern programming were invented with LISP in 1958. You had 4 years where that might have been even slightly valid.

At this point, you are by insisting upon not doing your homework on these matters. I denied credibility, even more so now that you mention all those languages and hold to goto and other such trite poor implementations of code.

You say you learned scheme. I have my doubts. If you really learned it you would know why GOTO and spaghetti code techniques are idiocy. Spending a week on a language does not count. Unless you get to Macros you have not learned LISP. For the sake of divine enlightenment, I encourage you to go back and learn it in its entirety.