What it is in the context of is terminal computers connected to a main frame that time shares its processing time out between each terminal.
Well, that also still goes on today, indeed, it's extremely common. It's just the terminals have a bit more baggage these days, and the new trendy term is "cloud computing" and the trendy term for a terminal is now "thin client".
Even in the traditional sense, how many millions of sysadmins open an ssh session to their unixy web server?
Even Microsoft are pushing the "old" mainframe model hard. Terminal services is widespread in many businesses. This is not some "legacy" service but Microsoft trying to make Windows properly multiuser.
Plus ca change, plus c'est la meme chose.
Mainframes themselves aren't obsolete, not even in the slightest; IBM is making more mainframes than ever. When you want real IO capacity and real five 9s uptime, you don't get jumped up PCs masquerading as servers, you get an IBM zSeries mainframe, or perhaps one of the big Sun SPARC systems. It's a mistake to think the "old" concept of lots of terminals connected to a mainframe is obsolete, if anything it's stronger than it's ever been.
Well, that also still goes on today, indeed, it's extremely common. It's just the terminals have a bit more baggage these days, and the new trendy term is "cloud computing" and the trendy term for a terminal is now "thin client".
Even in the traditional sense, how many millions of sysadmins open an ssh session to their unixy web server?
Even Microsoft are pushing the "old" mainframe model hard. Terminal services is widespread in many businesses. This is not some "legacy" service but Microsoft trying to make Windows properly multiuser.
Plus ca change, plus c'est la meme chose.
Mainframes themselves aren't obsolete, not even in the slightest; IBM is making more mainframes than ever. When you want real IO capacity and real five 9s uptime, you don't get jumped up PCs masquerading as servers, you get an IBM zSeries mainframe, or perhaps one of the big Sun SPARC systems. It's a mistake to think the "old" concept of lots of terminals connected to a mainframe is obsolete, if anything it's stronger than it's ever been.
Having worked on mainframes for 20 years, I can confirm that for the last 20 years, mainframes have been on their way out and not worth learning. My guess is that in 20 years, mainframes will still be on their way out and not worth learning.
1. The system shall print the numbers from 1 to 100 inclusive.
2. The system shall print "Even number" before each even number, terminated with a carriage return.
3. The system shall print "Odd number" before each odd number, terminated by a carriage return.
I think I've found the answer. There are no introductory books because it is assumed that anyone with a passing interest in programming will eventually become a script kiddie.
But on the flip side, the fewer people learning the nuts and bolts of computing equates to better job security for those of us who remain in the trade :-) Unfortunately, it means we also must deal with an increasing quantity of Daily WTFs.
public class Untitled
{
public static void main(String[] args)
{
for (int n = 1 ; n < 100 ; n+= 2 )
{
System.out.println(n);
}//End For
}//End Main
}//End Class
Out of interest Winston (now that a few people have contributed code) were you expecting some sort of divide between people actually checking each number for evenness/oddness (say, with a modulus function) and people just looping through, printing the numbers with 'even' and 'odd' alternating?
But on the flip side, the fewer people learning the nuts and bolts of computing equates to better job security for those of us who remain in the trade :-) Unfortunately, it means we also must deal with an increasing quantity of Daily WTFs.
Well that depends. It also means that companies may go else where for their workforce and thoseon the west are too expensive.
Mind you I'm all for a bigger pay check.
Currently arround the academic comunity in computing there is this franzy of "Owwww nooo the nubers in enrolling in computing courses are going down!! Experts have prediced that in three years time there will be a short fall of qualified people in this country. This is bad for business!!" type thing.
True there is a drop of in numbers but hopefully this will mean we have more focused students comming through the door. Because of the internet boom we had a lot of extrinisicly motivated students who were only there because they thaught it was a meal ticked to high wages, or their own internet based start up that would make them millionnaires. Usually, they were lazy sods and didn't acheive much because they didn't want to practice their trade. They expected to turn up to lectures and tutorials, have the knowlege poured in (or spoon fed) then go home, without doing any work outside of class.
we had a lot of extrinisicly motivated students who were only there because they thaught it was a meal ticked to high wages, or their own internet based start up that would make them millionnaires. Usually, they were lazy sods and didn't acheive much because they didn't want to practice their trade. They expected to turn up to lectures and tutorials, have the knowlege poured in (or spoon fed) then go home, without doing any work outside of class.
1. The system shall print the numbers from 1 to 100 inclusive.
2. The system shall print "Even number" before each even number, terminated with a carriage return.
3. The system shall print "Odd number" before each odd number, terminated by a carriage return.
Gah! My earlier code does meet the requirements but needs slight cleaning up for printing. So here is the code again with slight revision:
Basic code
10 FOR f = 1 TO 100 STEP 2
20 PRINT "Odd number: ";f: PRINT "Even number: ";f+1
30 NEXT f
Equivalent C++ code
for (int f = 1; f < 100; f += 2)
cout << "Odd number: " << f << "\nEven number: " << f+1 << "\n";
Well using the very obvious keywords and operators in Java it could be done thus.
public class oddsAndEvens
{
public static void main(String[] args)
{
int i = 0;
boolean odd = true;
for ( i = 1 ; i <= 100 ; i ++ )
{
if (odd )
{
System.out.println("odd " + i);
odd = false ;
}//End If
else
{
System.out.println("even " + i);
odd = true ;
}//End Else
}//End For
}//End Main
}//End Class
However,using Ajuns C example as a basis a better solution would be.
public class oddsAndEvens
{
public static void main(String[] args)
{
for (int i = 1 ; i <= 100 ; i +=2 )
System.out.println("Even " + i + "\nodd " + (i+1));
}//End Main
}//End Class
However, its interesting and worrying that the first solution that spang to mind once I realised Winston's problem spec (Was not reading properly before), was the first example. Once I had written it, it was obvious that it was way bigger than it needed to be.
However, my reasoning behind why I chose the first one is that its simplified and unconglomorated steps very analogus to a flowchart or psudo code. Also the second problem is more greater abstaction from the problem spec than the first one is.
Out of interest Winston (now that a few people have contributed code) were you expecting some sort of divide between people actually checking each number for evenness/oddness (say, with a modulus function) and people just looping through, printing the numbers with 'even' and 'odd' alternating?
I was expecting to see (from this crowd) perhaps 3 approaches:
1. Checking the least significant bit and reporting the oddness and evenness from the state of the LSB. These people strongly think in base 2 when programming and are most likely to be acquainted with the bare metal.
2. For loops counting in increments of two.
3. Determining the oddness/evenness by using modulus. These people tend to think in base 10 when programming and are probably least acquainted with the bare metal.
And variations therein - for example you may see a structure like this:
Out of interest Winston (now that a few people have contributed code) were you expecting some sort of divide between people actually checking each number for evenness/oddness (say, with a modulus function) and people just looping through, printing the numbers with 'even' and 'odd' alternating?
FWIW, if I was writing that in the real world (as opposed to a time-critical inner loop in Z80, say) I'd instinctively go for the former approach:
1.upto(100) do |i|
if i%2 == 0
puts "Even number #{i}"
else
puts "Odd number #{i}"
end
end
(First attempt, I put = instead of ==. Oh the shame...)
Less efficient, but closer to the way the spec is written, which means that a) it's less work if the client came back and said "Oh, did I not mention that 13 is a special case?" and b) less work for another programmer to see what's going on - and programmer time is usually infinitely more valuable than computation time...
FWIW, if I was writing that in the real world (as opposed to a time-critical inner loop in Z80, say) I'd instinctively go for the former approach:
It also depends on what the real world is :-) Last year I wrote a program in C for an AVR with 1K of flash and 64 bytes of RAM! (Only in C because I've not yet learned AVR asm, but since the resulting executable was 700 bytes long it hardly matters in that particular case).
This is the other thing I think is in danger of being lost. For every PC that's sold there's probably 100 8 bit microcontrollers sold, and someone needs to know how to bit-twiddle so our microwaves, dishwashers, central heating, low-powered sensors etc. do the right thing. A musician friend of mine was remarking on the lengths he has to go to, to save what seems like trivial amounts of space (he's a professional sound recordist who makes the sound effects for things like toys) - because 2K is a lot in the embedded world.
Checking the least significant bit and reporting the oddness and evenness from the state of the LSB. These people strongly think in base 2 when programming and are most likely to be acquainted with the bare metal.
Yes, that was approach I took, I wrote 2 versions, 1 in Z80 and 1 in C++. I guess that goes back to me being a Z80 coder back in the 80's.
I was expecting to see (from this crowd) perhaps 3 approaches:
1. Checking the least significant bit and reporting the oddness and evenness from the state of the LSB. These people strongly think in base 2 when programming and are most likely to be acquainted with the bare metal.
2. For loops counting in increments of two.
Here is another viewpoint:
From your original spec (and the revision thereof), it was clear to me that the problem was to simply print numbers from 1 to 100 in odd/even form. In which case, checking for oddness/evenness is a moot point. The For loop achieves that purpose.
Secondly, the second way is more portable! ;)
I guess if the original problem had stated a requirement to include checking of oddness/evenness, I would have taken a different approach which would certainly have included the modulus operator (because it's the simplest?).
Having said that, I think you are spot on when you say people taking the first approach are more likely to be acquainted with the low level stuff. I instinctively took the second approach because I wasn't thinking low level.
Indeed, my first thought was thinking how I could implement it both in BASIC and C, which perhaps gives away the fact that I'm not attacking it from a low level perspective.
Reminds me of my early BASIC coding attempts. I remember sitting at a computer round my dad's mate's house, aged about seven, trying out its variant of BASIC by inputting ZX BASIC code and seeing what it did. I wrote a program for it to cycle through the border colours, in the exact same way Ralf is spoofing above. My dad, who worked with and indeed taught computers at FE level, wandered over and as gently as possible, so as not to hurt my feelings, suggested a loop and a variable...
Once I understood him, it was like having the top of my head opened up. I'm sure that was some sort of tipping point in my understanding technology rather than just using it. I'm still no pro coder, but I've made my career in what is, for many people, the confusion-packed gap between IT and the rest of the world - I really enjoy it here - and I owe it to the Spectrum that was sat in the dining room for the whole of my childhood, a chance to experience and muck about with technology, ordering it about rather than just using it passively.
The argument that the Youth of Today won't get to use these sorts of skills in their everyday adult life is sort of missing the point IMHO. I don't use ZX BASIC at work, after all. It's more about curiosity, logical thinking, self-directed discovery learning, and confidence messing with systems - I'd be interested to hear from current teachers, or people with school-age children, whether kids are getting exposure to these skills either through computers or some other route. (Lego Mindstorms anyone?)
My own revelation was when a mate of mine was explaining how to move an object on-screen - by holding the coords in X/Y, and using LET X=X+1 to move the thing.
Bang, that was amazing. The concept that you can add a variable to itself really opened up programming for me. Until that point, it was all just lists of instructions - now I was really cooking with gas.
Boot up a modern PC or Mac and the operating system is all windows; if you want to program then you have to go looking for a specific piece of software first, there's no "instant access".
Not quite so true of the Mac, which comes with a couple of decent high-level programming languages pre-installed. But of course, unlike the Speccy, you get nothing in the box that teaches you how to use them.
Comments
Well, that also still goes on today, indeed, it's extremely common. It's just the terminals have a bit more baggage these days, and the new trendy term is "cloud computing" and the trendy term for a terminal is now "thin client".
Even in the traditional sense, how many millions of sysadmins open an ssh session to their unixy web server?
Even Microsoft are pushing the "old" mainframe model hard. Terminal services is widespread in many businesses. This is not some "legacy" service but Microsoft trying to make Windows properly multiuser.
Plus ca change, plus c'est la meme chose.
Mainframes themselves aren't obsolete, not even in the slightest; IBM is making more mainframes than ever. When you want real IO capacity and real five 9s uptime, you don't get jumped up PCs masquerading as servers, you get an IBM zSeries mainframe, or perhaps one of the big Sun SPARC systems. It's a mistake to think the "old" concept of lots of terminals connected to a mainframe is obsolete, if anything it's stronger than it's ever been.
Having worked on mainframes for 20 years, I can confirm that for the last 20 years, mainframes have been on their way out and not worth learning. My guess is that in 20 years, mainframes will still be on their way out and not worth learning.
Equivalent C++ code
Age 31
Bytes:Chuntey - Spectrum tech blog.
Oh, ok. I assume you want a bit more 'specialisation' than gasman's (very valid) effort though:
BASIC
Equivalent C++ code
;)
Still, Age 31.
Bytes:Chuntey - Spectrum tech blog.
Doh.
Remind me to never write requirements :-)
1. The system shall print the numbers from 1 to 100 inclusive.
2. The system shall print "Even number" before each even number, terminated with a carriage return.
3. The system shall print "Odd number" before each odd number, terminated by a carriage return.
But on the flip side, the fewer people learning the nuts and bolts of computing equates to better job security for those of us who remain in the trade :-) Unfortunately, it means we also must deal with an increasing quantity of Daily WTFs.
Java
public class Untitled { public static void main(String[] args) { for (int n = 1 ; n < 100 ; n+= 2 ) { System.out.println(n); }//End For }//End Main }//End ClassBy Andrew Scott Age 32
Well that depends. It also means that companies may go else where for their workforce and thoseon the west are too expensive.
Mind you I'm all for a bigger pay check.
Currently arround the academic comunity in computing there is this franzy of "Owwww nooo the nubers in enrolling in computing courses are going down!! Experts have prediced that in three years time there will be a short fall of qualified people in this country. This is bad for business!!" type thing.
True there is a drop of in numbers but hopefully this will mean we have more focused students comming through the door. Because of the internet boom we had a lot of extrinisicly motivated students who were only there because they thaught it was a meal ticked to high wages, or their own internet based start up that would make them millionnaires. Usually, they were lazy sods and didn't acheive much because they didn't want to practice their trade. They expected to turn up to lectures and tutorials, have the knowlege poured in (or spoon fed) then go home, without doing any work outside of class.
Wow that's my education history in a nut-shell
Gah! My earlier code does meet the requirements but needs slight cleaning up for printing. So here is the code again with slight revision:
Basic code
Equivalent C++ code
Bytes:Chuntey - Spectrum tech blog.
public class oddsAndEvens { public static void main(String[] args) { int i = 0; boolean odd = true; for ( i = 1 ; i <= 100 ; i ++ ) { if (odd ) { System.out.println("odd " + i); odd = false ; }//End If else { System.out.println("even " + i); odd = true ; }//End Else }//End For }//End Main }//End ClassHowever,using Ajuns C example as a basis a better solution would be.
public class oddsAndEvens { public static void main(String[] args) { for (int i = 1 ; i <= 100 ; i +=2 ) System.out.println("Even " + i + "\nodd " + (i+1)); }//End Main }//End ClassHowever, its interesting and worrying that the first solution that spang to mind once I realised Winston's problem spec (Was not reading properly before), was the first example. Once I had written it, it was obvious that it was way bigger than it needed to be.
However, my reasoning behind why I chose the first one is that its simplified and unconglomorated steps very analogus to a flowchart or psudo code. Also the second problem is more greater abstaction from the problem spec than the first one is.
I was expecting to see (from this crowd) perhaps 3 approaches:
1. Checking the least significant bit and reporting the oddness and evenness from the state of the LSB. These people strongly think in base 2 when programming and are most likely to be acquainted with the bare metal.
2. For loops counting in increments of two.
3. Determining the oddness/evenness by using modulus. These people tend to think in base 10 when programming and are probably least acquainted with the bare metal.
And variations therein - for example you may see a structure like this:
if(even) print("Even: $i\n"); else print("Odd: $i\n");or something like this:
if(even) print("Even: "); else print("Odd: "); print ("$i\n");Both work, but one is more space efficient than the other (and one may be more time efficient than the other, depending on the language).
FWIW, if I was writing that in the real world (as opposed to a time-critical inner loop in Z80, say) I'd instinctively go for the former approach:
1.upto(100) do |i| if i%2 == 0 puts "Even number #{i}" else puts "Odd number #{i}" end end(First attempt, I put = instead of ==. Oh the shame...)Less efficient, but closer to the way the spec is written, which means that a) it's less work if the client came back and said "Oh, did I not mention that 13 is a special case?" and b) less work for another programmer to see what's going on - and programmer time is usually infinitely more valuable than computation time...
It also depends on what the real world is :-) Last year I wrote a program in C for an AVR with 1K of flash and 64 bytes of RAM! (Only in C because I've not yet learned AVR asm, but since the resulting executable was 700 bytes long it hardly matters in that particular case).
This is the other thing I think is in danger of being lost. For every PC that's sold there's probably 100 8 bit microcontrollers sold, and someone needs to know how to bit-twiddle so our microwaves, dishwashers, central heating, low-powered sensors etc. do the right thing. A musician friend of mine was remarking on the lengths he has to go to, to save what seems like trivial amounts of space (he's a professional sound recordist who makes the sound effects for things like toys) - because 2K is a lot in the embedded world.
Here is another viewpoint:
From your original spec (and the revision thereof), it was clear to me that the problem was to simply print numbers from 1 to 100 in odd/even form. In which case, checking for oddness/evenness is a moot point. The For loop achieves that purpose.
Secondly, the second way is more portable! ;)
I guess if the original problem had stated a requirement to include checking of oddness/evenness, I would have taken a different approach which would certainly have included the modulus operator (because it's the simplest?).
Having said that, I think you are spot on when you say people taking the first approach are more likely to be acquainted with the low level stuff. I instinctively took the second approach because I wasn't thinking low level.
Indeed, my first thought was thinking how I could implement it both in BASIC and C, which perhaps gives away the fact that I'm not attacking it from a low level perspective.
Bytes:Chuntey - Spectrum tech blog.
.data align 4 lsbtable: dd p_even_txt dd p_odd_txt p_even_txt: db "Even ",0 p_odd_txt: db "Odd: ",0 .code proc printuselessnumbers uses ebx local numstr[12]:BYTE xor ebx, ebx .while ebx <= 100 invoke dw2a, ebx, addr numstr mov eax, ebx and eax, 1 print dword ptr [lsbtable+eax*4], offset numstr, 13, 10 inc ebx .endw ret endpAge: Still far younger than Karingal.I would expect this to fail on some compilers. But then it's been 25 years since I coded any BASIC so I'm probably wrong.
Surely
Not in Sinclair BASIC - it checks that the variable hasn't gone over the limit before looping.
D.
You guys in your programs use variables, loops, conditions, modulo and other complicated things.
What will you say about my code. Pure simplicity. Do I win? ;)
What one its own? With a While, An Until or a Goto?
:D
Reminds me of my early BASIC coding attempts. I remember sitting at a computer round my dad's mate's house, aged about seven, trying out its variant of BASIC by inputting ZX BASIC code and seeing what it did. I wrote a program for it to cycle through the border colours, in the exact same way Ralf is spoofing above. My dad, who worked with and indeed taught computers at FE level, wandered over and as gently as possible, so as not to hurt my feelings, suggested a loop and a variable...
Once I understood him, it was like having the top of my head opened up. I'm sure that was some sort of tipping point in my understanding technology rather than just using it. I'm still no pro coder, but I've made my career in what is, for many people, the confusion-packed gap between IT and the rest of the world - I really enjoy it here - and I owe it to the Spectrum that was sat in the dining room for the whole of my childhood, a chance to experience and muck about with technology, ordering it about rather than just using it passively.
The argument that the Youth of Today won't get to use these sorts of skills in their everyday adult life is sort of missing the point IMHO. I don't use ZX BASIC at work, after all. It's more about curiosity, logical thinking, self-directed discovery learning, and confidence messing with systems - I'd be interested to hear from current teachers, or people with school-age children, whether kids are getting exposure to these skills either through computers or some other route. (Lego Mindstorms anyone?)
Bang, that was amazing. The concept that you can add a variable to itself really opened up programming for me. Until that point, it was all just lists of instructions - now I was really cooking with gas.
D.
Ah I was not sure what language you were refereing to.
In Sinclair Basic there a countless ways it can be done.
My real world problem is that what should be constants frequently end up as variables.