Interestingly, A level computing students study OOP but only in the upper year. As such, they'll at least get a decent run on the individual elements in turn before being expected to put it all together. I wonder if their success rates are different to university students as a result?
Good point. I don't know about A levels, but is it possible that the point of teaching OOP from the start is that you don't HAVE to progress to programming? You might want to be a designer, or a project manager. That's one of the points of OOP - splitting design from code. I can't design a website or software because my design skills are shite, but I can sure code em!
using Sinclair Basic on multiGHz machine is really pitty and waste of potential, resources.
This is an outdated point of view. With computers having very fast processors and lots of memory and disk space available, programmers of most applications don't need to squeeze every last bit of speed and resource available anymore. Higher-level languages are making a comeback - not just BASIC, but Perl and Python and other interpreted languages too. They do the job well enough, and they're a lot easier to program than say C/C++/C#, etc. BASIC has the additional benefit that non-BASIC programmers are usually able to understand the code without much problem.
Ease of programming has become an important issue again, and no one can deny that picking up BASIC (true BASICs, that is, not the VB rubbish) is a lot easier for programmers that picking up C.
Using BASin to learn programming in general as well as BASIC has value, no matter what age you are.
And to prove the point that computer resources and use of higher-level languages are not an issue anymore: I wrote my 2D and 3D animation packages in Perl, and you can see the results in the YSRnRY documentary.
Good point. I don't know about A levels, but is it possible that the point of teaching OOP from the start is that you don't HAVE to progress to programming? You might want to be a designer, or a project manager. That's one of the points of OOP - splitting design from code. I can't design a website or software because my design skills are shite, but I can sure code em!
That's one way of looking at it, but I wouldn't teach those skills using OOP. ISTR at Uni we had a special module for that which dealt with abstract design which would accomplish all that you just said.
That's one way of looking at it, but I wouldn't teach those skills using OOP. ISTR at Uni we had a special module for that which dealt with abstract design which would accomplish all that you just said.
But.... are they all coming together now? I don't know when you were at uni, but how did they teach programming at the time? When I start a project now, I do the documentation & send to a designer. I don't start coding the front end until the designs come back, by then, I have already done the back end. This is all possible because of the OOP ideals.
You should be pride because you making something for children. Did I said ever that Basin is worthless - no. You have some complex obviously about value of your work/hobby or whatever in Speccy sphere.
Dunny shouldn't use bad language on these forums, it's true, but how do you expect him to react when you state that BASin is suitable only for children, and can be of no serious or worthwhile use? Saying:
"BASin or Sinclair Basic is suited for 5 year olds."
is as insulting as it is innacurate. I've never used BASin, as my programming days are long behind me, having neither the time, the need nor the wish to program nowadays. But if I wanted to program something then I cerainly would consider if it could be done using BASIN, as in the '80s I was a very competent BASIC programmer (if I say so myself :roll: ) and it would be far easy for me to familiarise myself with Sinclair BASIC than to learn a new programming language. Alright, so you could never write a PC game in BASin, but if you want to write something like a formulae converter (scientific, currency or Metric to Imperial for example), or your own version of Suduko, or a game or program to run on both real Spectrums and Speccy emulators then BASin sounds ideal.
We Spectrum fans benefit enormously from the hard and mostly unpaid work of people like Dunny, and to rubbish his work unjustly is unnaceptable. I've never used BASin, and probably never will, just as I've never used Tommygun or most other PC programs available on WOS. But the fact that I have no need of most of them, and can't even see the reason for the existance of some of them in no way entitles me to class their users as stupid or time wasters.
And if you believe, as you say "using Sinclair Basic on multiGHz machine is really pitty and waste of potential, resources" then you must surely believe that emulation is a waste of potential [and] resources, as why use your computer to play Chaos or Skooldaze, when you could be pushing the PC to it's limit with F.E.A.R. or Half-Life 2?
And I agree whole heartedly with Ralf and others, a real advantage of BASIC over other languages is the ability to jump into BASIC and start programming haphazardly and see the results straight away. True, programming in that style is hardly likely to give the best results, but when you're twelve or thirteen you don't want to sit down and work out what libraries to load, work out before hand exactly what and how many variables you'll need, and then have to compile the code before you run it. Typing in a few lines of BASIC, as they occur to you, then typing
RUN [ENTER]
and seeing the results really encourages you to keep at it. And in time, you learn that you either have to optimize your code and plan ahead, or you'll either run out of memory or you're program will be so convoluted that you can't trace that annoying bug. By then, you're so commited to programming that you don't really mind starting again, and thinking ahead. But if you had to pre-plan everything everytime, even the first time you ever tried to program the Spectrum, then I think a lot of people just wouldn't have bothered.
Interestingly, A level computing students study OOP but only in the upper year. As such, they'll at least get a decent run on the individual elements in turn before being expected to put it all together. I wonder if their success rates are different to university students as a result?
Wow there are schools doing OO...
Part of my research is looking into what formal programming experience our freshmen have prior to university. What I have found is shocking differences between schools. They all can interpret the A/AS Level syllabus in so many ways.
MY old high school calls its self a 'School of Computing and Mathematics Excellence'. One look at their syllabus showed me that the pupils covered no real programming at all. They only covered the systems analysis parts of programming.
It seems many schools are like this. However, there are some schools wich are doing excelling things with their pupils. It all comes down to the skills of the teaching staff I suppose.
Rather than teaching any useful computing skills it seems that many schools are teaching to the exam. I have seen recent exam papers containing Bacus Normal Rorm??? Is this of use to a high school student??
What I think novice programmers are lacking is the basic problem solving skills that programmers of all levels need. I think we need to remove the dependence on syntax as much as possible. Get the problem solving skills up to scratch and then bring in the syntax gently.
Has anyone seen KPL (Kids Programming Language). Its a bad choice of name but looks like a great language for learning at all age levels. Just like Basic the user can get instant results.
Part of my research is looking into what formal programming experience our freshmen have prior to university. What I have found is shocking differences between schools. They all can interpret the A/AS Level syllabus in so many ways.
MY old high school calls its self a 'School of Computing and Mathematics Excellence'. One look at their syllabus showed me that the pupils covered no real programming at all. They only covered the systems analysis parts of programming.
It seems many schools are like this. However, there are some schools wich are doing excelling things with their pupils. It all comes down to the skills of the teaching staff I suppose.
Rather than teaching any useful computing skills it seems that many schools are teaching to the exam. I have seen recent exam papers containing Bacus Normal Rorm??? Is this of use to a high school student??
I just had another quick look at syllabus and it's definitely in there. That said, they only need to cover the basics concepts of OOP, not actually write programs in it or anything.
Programming should still be a major part of the syllabus though and is supposed to figure as a major part in student projects. That said, you could probably cobble together an Access database or write a website in Frontpage and tick most of the necessary boxes.
As for teaching students how to pass the exam rather than the fundamentals of the subject... well... that's about what you'd expect from a system that judges schools on their pass rates and students on how many pieces of paper they can collect. It's also nothing new, I passed my O level French that way. :lol:
What I think novice programmers are lacking is the basic problem solving skills that programmers of all levels need. I think we need to remove the dependence on syntax as much as possible. Get the problem solving skills up to scratch and then bring in the syntax gently.
Has anyone seen KPL (Kids Programming Language). Its a bad choice of name but looks like a great language for learning at all age levels. Just like Basic the user can get instant results.
That looks just the job. I guess you'd have to run a class doing it and one doing Java or C# in parallel and see how they get on, though.
Anyway, I think it's a good choice of name. The last thing you want people doing with a teaching language is trying to write serious programs in it.
But.... are they all coming together now? I don't know when you were at uni, but how did they teach programming at the time?
This was back in 1992-1995 (at Liverpool Uni, CompSci degree). The first year was algorithm-centric together with teaching data-types and data-structures using ADA (an OO language sorta like Pascal), but without doing any OO stuff beyond what was needed to get the program running (i.e. very basic package definitions to satisfy the ADA compiler). After one year you could write a program which could do a LOT of data processing, but more importantly, you had learned the skill of breaking down the problem to solve into individual algorithms and knew how to transfer those algorithms into code.
The second year was when we learned UNIX ANSI C (although I'd taught myself C beforehand), together with C++ and went into OOP.
There was all sorts of other stuff on the syllabus (assembler, circuitry, hardware, etc), but the programming route went roughly as above.
And all the above is now out of date as some schools are now teaching C in A-Level courses(!). You really don't need a CompSci BSc to go into the IT industry anymore, but it can certainly help.
When I start a project now, I do the documentation & send to a designer. I don't start coding the front end until the designs come back, by then, I have already done the back end. This is all possible because of the OOP ideals.
Sounds more to me like good API design, but without knowing more details (and that's NOT an invitation, btw ;)) I can't really comment.
Has anyone seen KPL (Kids Programming Language). Its a bad choice of name but looks like a great language for learning at all age levels. Just like Basic the user can get instant results.
I think LOGO is a *great* choice for pre-GCSE students, but I think it's considered passe' as the graphics it produces just don't look "state of the art" these days - it was impressive back in the days of the BBC B! But LOGO taught the first few steps into thinking of programs as a series of steps, with each step having a consequence that affects subsequent steps.
But... kids get computer-literate a hell of a lot faster these days, so it wouldn't surprise me if they can get head-long into BASIC by that time using BASin.
That's one of the points of OOP - splitting design from code.
From my interactions with budding programmers (freshers that is) who join our company, this is exactly the point they all seem to miss.
It would appear that our universities teach students how to code but not how to design or think. From the majority of the code by freshers that I've reviewed in our company, nearly every one of them seem to have use OOPs concepts but in a haphazard random way with little thought given to the design process. Apparently, they code first and then try to meet the requirements by tweaking/hacking the code to hell.
Surprisingly, I've found it much harder to teach freshers how to design than how to code even though some of these folks are amongst the smartest in the industry. Guess bad habits die hard.
It would appear that our universities teach students how to code but not how to design or think. From the majority of the code by freshers that I've reviewed in our company, nearly every one of them seem to have use OOPs concepts but in a haphazard random way with little thought given to the design process. Apparently, they code first and then try to meet the requirements by tweaking/hacking the code to hell.
That's more a flaw in the university system which teaches by lectures, books and project work - little or no exposure to current real-world practices. I doubt you'll ever get around that beyond forcing students to take a year out in industry.
When I start a project now, I do the documentation & send to a designer. I don't start coding the front end until the designs come back, by then, I have already done the back end. This is all possible because of the OOP ideals.
OOP is only one style of programming and what you're
saying here is not a unique feature of OOP.
OOP more or less means you tackle a problem by
identifying interacting objects / things and then
encapsulate the things these objects can do in
the methods. The degree of interaction between
objects and the relative isolation between objects
with little conceptual connection determines whether
you've made a good partition of the problem or not.
This is different from a modular structured programming
approach where the problem is divided into smaller
independent problems, first based on hierarchy. After
hierarchical decomposition into more-or-less independent
functional units, you start dividing these larger units into
related simpler tasks (bottom-up, top-down or a mix)
influenced by algorithm choices and data structure
choices.
You can see the approach is different -- OOP is trying
to model real-world interactions between real-world
objects while the second approach is centred around
a more abstract set of algorithms and data structures.
OOP seems to be fantastic for large projects with lots
of programmers involved that may face a long lifespan
(and therefore many additions, revisions, etc). It's a
lot easier for a large OOP design to be robust over time
in the face of changing requirements.
However OOP is NOT appropriate for a certain segment
of problems out there and for some problems either
method is equally good. Only for really large projects
would I consider OOP having a clear advantage. An
example of where it's usually no good is in embedded
devices where OOP just adds to bloat and results in
more expensive products. For small and medium size
projects, to me, it just adds to development time.
Part of what I am researching is why have the failure rates in introductory programming modules increased since 1997. Part of my belief is that universities in the UK now let in a broader range of students so we have a higher proportion of duffers.
I think this is probably a very important point. I don't know what it's been like recently in the UK but over here enrolment in CS doubled over about a 5-year span, all likely because of the dot com thing. I suspect that most of these new students are not interested in any scientific training at all and are just looking for a free pass to get into IT jobs. I was a TA for a few years some years ago, marking projects and doing tutorial classes. One of the courses was a cs course in operating systems. I found that about 10% of the class was pretty sharp and 20% I had no idea how they made it that far (third year course). Their programming skills were poor to terrible. I also found a certain amount of cheating going on that likely explained that 20%. Several students were caught turning in code where they only changed variable names, one or two had downloaded stuff from the internet to do their assignments and some were using pd libraries to solve the problem (and therefore they got marks approaching 0). Another thing that baffled me is this: here 50% of classes are composed of foreign students from Asia. Nothing wrong with that; in order to get in they have to write an English proficiency exam and then when here they have to take some first year English classes like everyone else. But I found that some students couldn't string together an English sentence without making spelling mistakes and grammatical errors everywhere. Their spoken English was passable but I often wondered if their English was good enough to read the textbook. The only way those students could have passed an English proficiency exam was by cheating. The university I was at allowed these tests to be written in students' home countries as long as an independent exam supervisor was present, for example from a local school or college...
Anyway when I left there was a lot of talk in the department about the relatively recent problem with cheating and what to do about it. It is actually quite sad as academia is really built on a foundation of trust and honesty. As you mention, I blame this on a significantly increased interest from students with no desire at all to get a science degree. They should have been in an IT tech school or management information systems. There's no doubt in my mind they contributed to higher failure rates, although I didn't see any such statistic.
Is the problem the programming languages in use for introductory programming today??
Does the problem worsen with the OO first approach??
Personally, I think teaching OO from step 1 is a very poor idea. OO belongs in a software engineering course where it can be presented as one way to organize solutions to large programming problems. And software engineering belongs after material on what a computer is and how it works (this means introductory material on hw and basic programming concepts like looping, functions, variables and scope, etc) and after a mathematical foundation that can introduce algorithms and ideas about speed and space efficiency. I just don't see how you can teach someone to construct a house without knowing what a hammer is, what a 2-by-4 is, what concrete is, etc. and expect them to be any good at it?
Anyway, is it really true that OO is being taught from square one in the UK? I would actually be surprised if it was... Over here the first language formally taught is usually C++ but OO concepts are only touched on. Mandatory courses on other language types (functional, imperative, etc) are also given so you get a broader overview.
Also when you learned to program what did you find the hardest hurdle (introductory concepts only up to say recursion )??.
Hmm.. that would be back in the Spectrum days. I don't think any of it was really any more difficult than anything else, honestly. When I started with assembler I did have trouble figuring out how one could accomplish so much with so little. When I did finally "get it" it was like a switch being flipped: the previous day I could only write trivial programs and the next day I was able to do pretty much anything. So maybe the most difficult thing would have been translating high level ideas into teeny-tiny steps in assembler. I can't really say what would have been more difficult at a more formal university setting as I wasn't starting from square one. Programming was fairly second nature by that time so I never had much difficulty in software courses in school.
OOP seems to be fantastic for large projects with lots
of programmers involved that may face a long lifespan
(and therefore many additions, revisions, etc). It's a
lot easier for a large OOP design to be robust over time
in the face of changing requirements.
However OOP is NOT appropriate for a certain segment
of problems out there and for some problems either
method is equally good. Only for really large projects
would I consider OOP having a clear advantage. An
example of where it's usually no good is in embedded
devices where OOP just adds to bloat and results in
more expensive products. For small and medium size
projects, to me, it just adds to development time.
I totally agree here, sadly some people have this idea that a program is somehow bad if it isn't a totally object oriented design... even if making it that way means being larger and more complex.
I wrote a small java app (under 1200 lines not counting HTML) for a major broadband company so that people could check their account and update their credit card info. It was simple, partially OO, took 2 days to write most of the code and worked from the first time it was tested. (more than I can say for the system it had to communicate with) But my program manager said it was a "cludge" because I wasn't totally OO and I parsed the XML myself. If I had done it his way it would have been over 2000 lines, would have had performance and memory issues and wouldn't have been finished so quickly.
Someone needs to explain to students that there is no perfect design and just because something is or isn't 100% object oriented doesn't mean it is or isn't a good design.
From my interactions with budding programmers (freshers that is) who join our company, this is exactly the point they all seem to miss.
It would appear that our universities teach students how to code but not how to design or think. From the majority of the code by freshers that I've reviewed in our company, nearly every one of them seem to have use OOPs concepts but in a haphazard random way with little thought given to the design process. Apparently, they code first and then try to meet the requirements by tweaking/hacking the code to hell.
Surprisingly, I've found it much harder to teach freshers how to design than how to code even though some of these folks are amongst the smartest in the industry. Guess bad habits die hard.
I think it has to do with them having lots of small assignments or projects but never really having to do anything large in college. I see a lot of them that just don't know where to start.
I've also noticed a lot of entry level (or even experienced) programmers that start coding too soon. I refuse to start coding before the design is finished and it almost drives some managers nuts because they think you can design and code at the same time to shorten development time.
They don't seem to understand that it often takes longer to go back and fix a program that doesn't meet the final design than it takes to do it from scratch!
Heck!! How did I ever forget about mentioning Logo. Never did much with it really except program some turtle graphics routines - vagerly recall doing something else with it - oh yeah, program some Traffic light routine on an Apple IIe, though I recall doing something more serious with it.
I think it has to do with them having lots of small assignments or projects but never really having to do anything large in college. I see a lot of them that just don't know where to start.
I've also noticed a lot of entry level (or even experienced) programmers that start coding too soon. I refuse to start coding before the design is finished and it almost drives some managers nuts because they think you can design and code at the same time to shorten development time.
They don't seem to understand that it often takes longer to go back and fix a program that doesn't meet the final design than it takes to do it from scratch!
Manager also don't realise that a good design up front will save a lot of development time.
Where as coding too soon will only ever create problems in the future.
Most managers because they are not engineers are just plain stoopid idiots.
They should manage the engineers time not how they do their job.
If an engineer says it will take 5 weeks for the design and 3 for the coding and 4 for the testing then he should believe him.
Another engineer could say well I don't plan to do the design, so I'll code for 6 weeks and test for 3, but they'll end up having to rewrite code due to poor design choices and thus testing will balloon out to more than 10 weeks or worst the whole cycle restarts and it ends up being a "feature driven" development cycle where the "features" are to remove all the bugs.
Like I said earlier - short sighted idiots!
I have only ever had 2 good managers who understand this problem, and have had more than I can count that don't.
Anyway, is it really true that OO is being taught from square one in the UK? I would actually be surprised if it was... Over here the first language formally taught is usually C++ but OO concepts are only touched on. Mandatory courses on other language types (functional, imperative, etc) are also given so you get a broader overview.
Yes Michael Kölling and David J. Barnes are very influential figures in the world of introductory programming . They have published several books on the approach and are the authors of BlueJ (www.BlueJ.org). The OO first approach is now adopted by a large proportion of UK universities, London Metropolitan, University of Kent and South Bank University being three of them.
Other well known advocates are Fintal Culwin, John Morris, who have published several books and papers on the topic.
I found that about 10% of the class was pretty sharp and 20% I had no idea how they made it that far (third year course). Their programming skills were poor to terrible. I also found a certain amount of cheating going on that likely explained that 20%. Several students were caught turning in code where they only changed variable names, one or two had downloaded stuff from the internet to do their assignments and some were using pd libraries to solve the problem (and therefore they got marks approaching 0).
Well, I hate to say it but I've found that only about 10% of all programmers are really good. Another 15%-25% can get by but don't write the best code and the rest I have to wonder how they can keep a job.
When I worked for MCI I think half the people involved in our project (over 30 devs) had learned the application they were working on and were afraid to leave because they couldn't handle a new position.
I've worked with a lot of "programmers" that don't know how to program at all and they depend on other people to do their work for them. One woman I worked with never completed a single piece of code on her own while I worked at that consulting firm. Her approach was to bat her eyes, wear tight sweaters and to pick some geek that loved her attention to do her work. Several of us hated her because having her on a project meant you had to split up her work. She was good looking though! ;)
Another thing that baffled me is this: here 50% of classes are composed of foreign students from Asia. Nothing wrong with that; in order to get in they have to write an English proficiency exam and then when here they have to take some first year English classes like everyone else. But I found that some students couldn't string together an English sentence without making spelling mistakes and grammatical errors everywhere. Their spoken English was passable but I often wondered if their English was good enough to read the textbook. The only way those students could have passed an English proficiency exam was by cheating. The university I was at allowed these tests to be written in students' home countries as long as an independent exam supervisor was present, for example from a local school or college...
Foreign students loaded CS classes at the university I was at and they always traded code, tests and assignments. Professors rarely changed their tests so they could just study the old tests and assignments to coast through. One professor we complained to about this kind of cheating reworded all the questions so they sounded similar but had different answers. Every Asian student in the class failed the test. But that wasn't enough evidence to give the CS department a wakeup call.
What bothers me is I've had a lot of foreigners on my teams and you end up explaining things over and over because they don't understand the language.
A kid just out of college from the UK... I'd tell him once and it was done right and the first time. The guy from India wouldn't follow directions and would get it about half right and the rest was how he thought it should be done. So I'd have to check what he was doing on a day to day basis to make sure he understood what we wanted but once you straitened him out he did a good job The guys from Asia would tell you they understood to save face but would sit there and do nothing rather than ask a single question and I had to constantly keep an eye on them.
Most managers because they are not engineers are just plain stoopid idiots.
They should manage the engineers time not how they do their job.
If an engineer says it will take 5 weeks for the design and 3 for the coding and 4 for the testing then he should believe him.
Yeah, well I had a program manager that was supposedly a former programmer and I told him the minimum delivery date was in 6 weeks even if we worked 60+ hours a week.
He promised to give us more time than that and then caved to pressure from the client and gave us 5 weeks.
One engineer on the project was the useless woman I mentioned, one was a guy that suddenly scheduled his vacation to start 1 day before the end of the project and the other guy refused to do things he agreed to because he didn't know how. I lived there that last week, didn't sleep the last three days and delivered the working product 3 hours before the client meeting was to start where we were to present the final product.
I got laid off 3 days later and they kept the other people on the project even though I did 90% of the work. Why? They had lower salaries.
Lets face it... just giving someone the title "manager" can cause their brains to drain out their ears.
I have only ever had 2 good managers who understand this problem, and have had more than I can count that don't.
I've had 1 good manager like that. The rest were idiots.
James, that is a pretty controversial point (Asian Student / Programmer thing).
I see this behaviour in many students not just Asian ones.
Their approach to learning is that they come to university expecting to be given the answers rather than being guided to discover it themselves i.e. Cargo Cults.
James, that is a pretty controversial point (Asian Student / Programmer thing).
I see this behaviour in many students not just Asian ones.
I was stating a fact... I see no controversy here other than you are trying to be politically correct and I don't give a crap. It was a well known dirty secret in that CS department but it was tolerated because a large % of the grad students were foreigners. It really upset the rest of us that were doing out own work.
FWIW, anyone that has been in a fraternaty knows this goes on with other groups.
As far as other students go, I didn't see much of it above the freshman or sophomore level. Most people of that type switched majors because the math for a CS major was murder.
Well I dunno if every Asian (which incidentally includes quite a sizeable population of the world) in the UK is a bad programmer. That's quite a statement to be claimed as a fact.
Anyway, Kiwi brings up a good point regarding managers. However, I'm not entirely convinced that managers with engineering/technical backgrounds make any better managers. I've seen a couple of them in action and they aren't any better than the other non-engineer ones.
In my company's case it appears that the sales/marketing team apparently operates in a different universe to the rest of us. Often they agree to unrealistic timelines and then pressure us to deliver on the time *they* promised. Thankfully, this ridiculous situation is changing now and timelines are agreed upon in consultation with the tech dept, although there is still a fair amount of give and take involved.
Well I dunno if every Asian (which incidentally includes quite a sizeable population of the world) in the UK is a bad programmer. That's quite a statement to be claimed as a fact.
Exactly where did I say that?
They were more interested in saving face than say they didn't understand. That was the problem.
Ah ok, I'm glad you don't think that's true then (although you don't say that either).
About the saving face part...hmm... this might have to do with the language problem too. People are generally shy to speak up on a language related problem since as you said they might "lose face" in front of others. This scenario is not limited to the UK alone. I see this everyday in my company (in India) where people from different cultural and ethnic backgrounds generally display different levels of confidence in speaking up. I notice that people who don't have a good hold over English hesitate to query or seek advice on technical problems from me and instead will go to someone who speaks his or her own regional language. That's fine by me so long as they *do* get their coding problems fixed.
But it does start getting difficult when I have to hold training sessions for everyone since I know that around 25% people aren't getting it but wouldn't admit to it, which rather defeats the purpose of training them.
I've seen enough good and bad programmers of every ethnicity to know that it's not a factor.
As for why British and American universities are full of incapable overseas students that have to cheat to survive the course, it's a problem of their own making. The universities bend over backwards to accommodate them as they represent a major income stream. As such, they're hardly going to go out of their way to expose plagarism or screen applicants for language skills and academic abilitity. So long as the students keep paying the money, they'll get the bits of paper they're after in return and that's pretty much the deal.
Indeed, your first line was to tell me to stop posting. Where do you get the right to tell me to stop, if you yourself will not?...
You're really going to hate what I'm doing next then. Still, you don't have to use it.
D.
Must here note couple things:
Incorrect - I said that you stop with incorrectness, irrelevant things, with vulgar tone (moderate yourself) . Didn't say that you stop posting. You see what is not written - calm down...
It is irrelevant am I hate something or not. Just because you making some support for Sinclair Basic I should not say anything against it? This is pure egoistic behavior. Why should I care what you and maybe others make about old Sinclair Basic. I just said my opinion about it's value today. You may also hate what I said, but it gives not right to act as you acted, and using such language.
Btw. I don't hate Basin. I simple don't care about it.
Comments
Good point. I don't know about A levels, but is it possible that the point of teaching OOP from the start is that you don't HAVE to progress to programming? You might want to be a designer, or a project manager. That's one of the points of OOP - splitting design from code. I can't design a website or software because my design skills are shite, but I can sure code em!
This is an outdated point of view. With computers having very fast processors and lots of memory and disk space available, programmers of most applications don't need to squeeze every last bit of speed and resource available anymore. Higher-level languages are making a comeback - not just BASIC, but Perl and Python and other interpreted languages too. They do the job well enough, and they're a lot easier to program than say C/C++/C#, etc. BASIC has the additional benefit that non-BASIC programmers are usually able to understand the code without much problem.
Ease of programming has become an important issue again, and no one can deny that picking up BASIC (true BASICs, that is, not the VB rubbish) is a lot easier for programmers that picking up C.
Using BASin to learn programming in general as well as BASIC has value, no matter what age you are.
And to prove the point that computer resources and use of higher-level languages are not an issue anymore: I wrote my 2D and 3D animation packages in Perl, and you can see the results in the YSRnRY documentary.
But.... are they all coming together now? I don't know when you were at uni, but how did they teach programming at the time? When I start a project now, I do the documentation & send to a designer. I don't start coding the front end until the designs come back, by then, I have already done the back end. This is all possible because of the OOP ideals.
Dunny shouldn't use bad language on these forums, it's true, but how do you expect him to react when you state that BASin is suitable only for children, and can be of no serious or worthwhile use? Saying:
"BASin or Sinclair Basic is suited for 5 year olds."
is as insulting as it is innacurate. I've never used BASin, as my programming days are long behind me, having neither the time, the need nor the wish to program nowadays. But if I wanted to program something then I cerainly would consider if it could be done using BASIN, as in the '80s I was a very competent BASIC programmer (if I say so myself :roll: ) and it would be far easy for me to familiarise myself with Sinclair BASIC than to learn a new programming language. Alright, so you could never write a PC game in BASin, but if you want to write something like a formulae converter (scientific, currency or Metric to Imperial for example), or your own version of Suduko, or a game or program to run on both real Spectrums and Speccy emulators then BASin sounds ideal.
We Spectrum fans benefit enormously from the hard and mostly unpaid work of people like Dunny, and to rubbish his work unjustly is unnaceptable. I've never used BASin, and probably never will, just as I've never used Tommygun or most other PC programs available on WOS. But the fact that I have no need of most of them, and can't even see the reason for the existance of some of them in no way entitles me to class their users as stupid or time wasters.
And if you believe, as you say "using Sinclair Basic on multiGHz machine is really pitty and waste of potential, resources" then you must surely believe that emulation is a waste of potential [and] resources, as why use your computer to play Chaos or Skooldaze, when you could be pushing the PC to it's limit with F.E.A.R. or Half-Life 2?
And I agree whole heartedly with Ralf and others, a real advantage of BASIC over other languages is the ability to jump into BASIC and start programming haphazardly and see the results straight away. True, programming in that style is hardly likely to give the best results, but when you're twelve or thirteen you don't want to sit down and work out what libraries to load, work out before hand exactly what and how many variables you'll need, and then have to compile the code before you run it. Typing in a few lines of BASIC, as they occur to you, then typing
RUN [ENTER]
and seeing the results really encourages you to keep at it. And in time, you learn that you either have to optimize your code and plan ahead, or you'll either run out of memory or you're program will be so convoluted that you can't trace that annoying bug. By then, you're so commited to programming that you don't really mind starting again, and thinking ahead. But if you had to pre-plan everything everytime, even the first time you ever tried to program the Spectrum, then I think a lot of people just wouldn't have bothered.
Wow there are schools doing OO...
Part of my research is looking into what formal programming experience our freshmen have prior to university. What I have found is shocking differences between schools. They all can interpret the A/AS Level syllabus in so many ways.
MY old high school calls its self a 'School of Computing and Mathematics Excellence'. One look at their syllabus showed me that the pupils covered no real programming at all. They only covered the systems analysis parts of programming.
It seems many schools are like this. However, there are some schools wich are doing excelling things with their pupils. It all comes down to the skills of the teaching staff I suppose.
Rather than teaching any useful computing skills it seems that many schools are teaching to the exam. I have seen recent exam papers containing Bacus Normal Rorm??? Is this of use to a high school student??
What I think novice programmers are lacking is the basic problem solving skills that programmers of all levels need. I think we need to remove the dependence on syntax as much as possible. Get the problem solving skills up to scratch and then bring in the syntax gently.
Has anyone seen KPL (Kids Programming Language). Its a bad choice of name but looks like a great language for learning at all age levels. Just like Basic the user can get instant results.
Any how that?s my bit....
I just had another quick look at syllabus and it's definitely in there. That said, they only need to cover the basics concepts of OOP, not actually write programs in it or anything.
Programming should still be a major part of the syllabus though and is supposed to figure as a major part in student projects. That said, you could probably cobble together an Access database or write a website in Frontpage and tick most of the necessary boxes.
As for teaching students how to pass the exam rather than the fundamentals of the subject... well... that's about what you'd expect from a system that judges schools on their pass rates and students on how many pieces of paper they can collect. It's also nothing new, I passed my O level French that way. :lol:
That looks just the job. I guess you'd have to run a class doing it and one doing Java or C# in parallel and see how they get on, though.
Anyway, I think it's a good choice of name. The last thing you want people doing with a teaching language is trying to write serious programs in it.
This was back in 1992-1995 (at Liverpool Uni, CompSci degree). The first year was algorithm-centric together with teaching data-types and data-structures using ADA (an OO language sorta like Pascal), but without doing any OO stuff beyond what was needed to get the program running (i.e. very basic package definitions to satisfy the ADA compiler). After one year you could write a program which could do a LOT of data processing, but more importantly, you had learned the skill of breaking down the problem to solve into individual algorithms and knew how to transfer those algorithms into code.
The second year was when we learned UNIX ANSI C (although I'd taught myself C beforehand), together with C++ and went into OOP.
There was all sorts of other stuff on the syllabus (assembler, circuitry, hardware, etc), but the programming route went roughly as above.
And all the above is now out of date as some schools are now teaching C in A-Level courses(!). You really don't need a CompSci BSc to go into the IT industry anymore, but it can certainly help.
Sounds more to me like good API design, but without knowing more details (and that's NOT an invitation, btw ;)) I can't really comment.
I think LOGO is a *great* choice for pre-GCSE students, but I think it's considered passe' as the graphics it produces just don't look "state of the art" these days - it was impressive back in the days of the BBC B! But LOGO taught the first few steps into thinking of programs as a series of steps, with each step having a consequence that affects subsequent steps.
But... kids get computer-literate a hell of a lot faster these days, so it wouldn't surprise me if they can get head-long into BASIC by that time using BASin.
From my interactions with budding programmers (freshers that is) who join our company, this is exactly the point they all seem to miss.
It would appear that our universities teach students how to code but not how to design or think. From the majority of the code by freshers that I've reviewed in our company, nearly every one of them seem to have use OOPs concepts but in a haphazard random way with little thought given to the design process. Apparently, they code first and then try to meet the requirements by tweaking/hacking the code to hell.
Surprisingly, I've found it much harder to teach freshers how to design than how to code even though some of these folks are amongst the smartest in the industry. Guess bad habits die hard.
Bytes:Chuntey - Spectrum tech blog.
OOP is only one style of programming and what you're
saying here is not a unique feature of OOP.
OOP more or less means you tackle a problem by
identifying interacting objects / things and then
encapsulate the things these objects can do in
the methods. The degree of interaction between
objects and the relative isolation between objects
with little conceptual connection determines whether
you've made a good partition of the problem or not.
This is different from a modular structured programming
approach where the problem is divided into smaller
independent problems, first based on hierarchy. After
hierarchical decomposition into more-or-less independent
functional units, you start dividing these larger units into
related simpler tasks (bottom-up, top-down or a mix)
influenced by algorithm choices and data structure
choices.
You can see the approach is different -- OOP is trying
to model real-world interactions between real-world
objects while the second approach is centred around
a more abstract set of algorithms and data structures.
OOP seems to be fantastic for large projects with lots
of programmers involved that may face a long lifespan
(and therefore many additions, revisions, etc). It's a
lot easier for a large OOP design to be robust over time
in the face of changing requirements.
However OOP is NOT appropriate for a certain segment
of problems out there and for some problems either
method is equally good. Only for really large projects
would I consider OOP having a clear advantage. An
example of where it's usually no good is in embedded
devices where OOP just adds to bloat and results in
more expensive products. For small and medium size
projects, to me, it just adds to development time.
Write games in C using Z88DK and SP1
I think this is probably a very important point. I don't know what it's been like recently in the UK but over here enrolment in CS doubled over about a 5-year span, all likely because of the dot com thing. I suspect that most of these new students are not interested in any scientific training at all and are just looking for a free pass to get into IT jobs. I was a TA for a few years some years ago, marking projects and doing tutorial classes. One of the courses was a cs course in operating systems. I found that about 10% of the class was pretty sharp and 20% I had no idea how they made it that far (third year course). Their programming skills were poor to terrible. I also found a certain amount of cheating going on that likely explained that 20%. Several students were caught turning in code where they only changed variable names, one or two had downloaded stuff from the internet to do their assignments and some were using pd libraries to solve the problem (and therefore they got marks approaching 0). Another thing that baffled me is this: here 50% of classes are composed of foreign students from Asia. Nothing wrong with that; in order to get in they have to write an English proficiency exam and then when here they have to take some first year English classes like everyone else. But I found that some students couldn't string together an English sentence without making spelling mistakes and grammatical errors everywhere. Their spoken English was passable but I often wondered if their English was good enough to read the textbook. The only way those students could have passed an English proficiency exam was by cheating. The university I was at allowed these tests to be written in students' home countries as long as an independent exam supervisor was present, for example from a local school or college...
Anyway when I left there was a lot of talk in the department about the relatively recent problem with cheating and what to do about it. It is actually quite sad as academia is really built on a foundation of trust and honesty. As you mention, I blame this on a significantly increased interest from students with no desire at all to get a science degree. They should have been in an IT tech school or management information systems. There's no doubt in my mind they contributed to higher failure rates, although I didn't see any such statistic.
Personally, I think teaching OO from step 1 is a very poor idea. OO belongs in a software engineering course where it can be presented as one way to organize solutions to large programming problems. And software engineering belongs after material on what a computer is and how it works (this means introductory material on hw and basic programming concepts like looping, functions, variables and scope, etc) and after a mathematical foundation that can introduce algorithms and ideas about speed and space efficiency. I just don't see how you can teach someone to construct a house without knowing what a hammer is, what a 2-by-4 is, what concrete is, etc. and expect them to be any good at it?
Anyway, is it really true that OO is being taught from square one in the UK? I would actually be surprised if it was... Over here the first language formally taught is usually C++ but OO concepts are only touched on. Mandatory courses on other language types (functional, imperative, etc) are also given so you get a broader overview.
Hmm.. that would be back in the Spectrum days. I don't think any of it was really any more difficult than anything else, honestly. When I started with assembler I did have trouble figuring out how one could accomplish so much with so little. When I did finally "get it" it was like a switch being flipped: the previous day I could only write trivial programs and the next day I was able to do pretty much anything. So maybe the most difficult thing would have been translating high level ideas into teeny-tiny steps in assembler. I can't really say what would have been more difficult at a more formal university setting as I wasn't starting from square one. Programming was fairly second nature by that time so I never had much difficulty in software courses in school.
Write games in C using Z88DK and SP1
I wrote a small java app (under 1200 lines not counting HTML) for a major broadband company so that people could check their account and update their credit card info. It was simple, partially OO, took 2 days to write most of the code and worked from the first time it was tested. (more than I can say for the system it had to communicate with) But my program manager said it was a "cludge" because I wasn't totally OO and I parsed the XML myself. If I had done it his way it would have been over 2000 lines, would have had performance and memory issues and wouldn't have been finished so quickly.
Someone needs to explain to students that there is no perfect design and just because something is or isn't 100% object oriented doesn't mean it is or isn't a good design.
I've also noticed a lot of entry level (or even experienced) programmers that start coding too soon. I refuse to start coding before the design is finished and it almost drives some managers nuts because they think you can design and code at the same time to shorten development time.
They don't seem to understand that it often takes longer to go back and fix a program that doesn't meet the final design than it takes to do it from scratch!
CP/M User.
Where as coding too soon will only ever create problems in the future.
Most managers because they are not engineers are just plain stoopid idiots.
They should manage the engineers time not how they do their job.
If an engineer says it will take 5 weeks for the design and 3 for the coding and 4 for the testing then he should believe him.
Another engineer could say well I don't plan to do the design, so I'll code for 6 weeks and test for 3, but they'll end up having to rewrite code due to poor design choices and thus testing will balloon out to more than 10 weeks or worst the whole cycle restarts and it ends up being a "feature driven" development cycle where the "features" are to remove all the bugs.
Like I said earlier - short sighted idiots!
I have only ever had 2 good managers who understand this problem, and have had more than I can count that don't.
Yes Michael Kölling and David J. Barnes are very influential figures in the world of introductory programming . They have published several books on the approach and are the authors of BlueJ (www.BlueJ.org). The OO first approach is now adopted by a large proportion of UK universities, London Metropolitan, University of Kent and South Bank University being three of them.
Other well known advocates are Fintal Culwin, John Morris, who have published several books and papers on the topic.
Andrew
When I worked for MCI I think half the people involved in our project (over 30 devs) had learned the application they were working on and were afraid to leave because they couldn't handle a new position.
I've worked with a lot of "programmers" that don't know how to program at all and they depend on other people to do their work for them. One woman I worked with never completed a single piece of code on her own while I worked at that consulting firm. Her approach was to bat her eyes, wear tight sweaters and to pick some geek that loved her attention to do her work. Several of us hated her because having her on a project meant you had to split up her work. She was good looking though! ;)
Foreign students loaded CS classes at the university I was at and they always traded code, tests and assignments. Professors rarely changed their tests so they could just study the old tests and assignments to coast through. One professor we complained to about this kind of cheating reworded all the questions so they sounded similar but had different answers. Every Asian student in the class failed the test. But that wasn't enough evidence to give the CS department a wakeup call.
What bothers me is I've had a lot of foreigners on my teams and you end up explaining things over and over because they don't understand the language.
A kid just out of college from the UK... I'd tell him once and it was done right and the first time. The guy from India wouldn't follow directions and would get it about half right and the rest was how he thought it should be done. So I'd have to check what he was doing on a day to day basis to make sure he understood what we wanted but once you straitened him out he did a good job The guys from Asia would tell you they understood to save face but would sit there and do nothing rather than ask a single question and I had to constantly keep an eye on them.
He promised to give us more time than that and then caved to pressure from the client and gave us 5 weeks.
One engineer on the project was the useless woman I mentioned, one was a guy that suddenly scheduled his vacation to start 1 day before the end of the project and the other guy refused to do things he agreed to because he didn't know how. I lived there that last week, didn't sleep the last three days and delivered the working product 3 hours before the client meeting was to start where we were to present the final product.
I got laid off 3 days later and they kept the other people on the project even though I did 90% of the work. Why? They had lower salaries.
Lets face it... just giving someone the title "manager" can cause their brains to drain out their ears.
I've had 1 good manager like that. The rest were idiots.
I see this behaviour in many students not just Asian ones.
Their approach to learning is that they come to university expecting to be given the answers rather than being guided to discover it themselves i.e. Cargo Cults.
Andrew.
FWIW, anyone that has been in a fraternaty knows this goes on with other groups.
As far as other students go, I didn't see much of it above the freshman or sophomore level. Most people of that type switched majors because the math for a CS major was murder.
Anyway, Kiwi brings up a good point regarding managers. However, I'm not entirely convinced that managers with engineering/technical backgrounds make any better managers. I've seen a couple of them in action and they aren't any better than the other non-engineer ones.
In my company's case it appears that the sales/marketing team apparently operates in a different universe to the rest of us. Often they agree to unrealistic timelines and then pressure us to deliver on the time *they* promised. Thankfully, this ridiculous situation is changing now and timelines are agreed upon in consultation with the tech dept, although there is still a fair amount of give and take involved.
Bytes:Chuntey - Spectrum tech blog.
They were more interested in saving face than say they didn't understand. That was the problem.
Ah ok, I'm glad you don't think that's true then (although you don't say that either).
About the saving face part...hmm... this might have to do with the language problem too. People are generally shy to speak up on a language related problem since as you said they might "lose face" in front of others. This scenario is not limited to the UK alone. I see this everyday in my company (in India) where people from different cultural and ethnic backgrounds generally display different levels of confidence in speaking up. I notice that people who don't have a good hold over English hesitate to query or seek advice on technical problems from me and instead will go to someone who speaks his or her own regional language. That's fine by me so long as they *do* get their coding problems fixed.
But it does start getting difficult when I have to hold training sessions for everyone since I know that around 25% people aren't getting it but wouldn't admit to it, which rather defeats the purpose of training them.
Bytes:Chuntey - Spectrum tech blog.
As for why British and American universities are full of incapable overseas students that have to cheat to survive the course, it's a problem of their own making. The universities bend over backwards to accommodate them as they represent a major income stream. As such, they're hardly going to go out of their way to expose plagarism or screen applicants for language skills and academic abilitity. So long as the students keep paying the money, they'll get the bits of paper they're after in return and that's pretty much the deal.
Oh, and select P45 :)
Well, I would. I have a problem, I have analysed it, Chosen my language and tools... I even have the cans. There's something missing though... :-p
D.
Must here note couple things:
Incorrect - I said that you stop with incorrectness, irrelevant things, with vulgar tone (moderate yourself) . Didn't say that you stop posting. You see what is not written - calm down...
It is irrelevant am I hate something or not. Just because you making some support for Sinclair Basic I should not say anything against it? This is pure egoistic behavior. Why should I care what you and maybe others make about old Sinclair Basic. I just said my opinion about it's value today. You may also hate what I said, but it gives not right to act as you acted, and using such language.
Btw. I don't hate Basin. I simple don't care about it.