Sounds good to me.Heater wrote:DavidS,Not really.Does this seem acceptable to all interested in taking Heater up on his suggestion (including Heater)?
My suggestion was to actually do something. Anything. Anyhow. Whatever shakes your tree.
I don't care how many files it takes. I would be happier if the result was interesting/useful to users of any platform not just ARM. GUI is optional, could be a robot control thing or whatever. Never mind the forum attachment, we have github, bitbucket, etc, through which we can share code. Recycling code from others is quite OK if it helps get the job done (Licensing allowing of course).
Go forth and hack!
Full of surprises aren't I? No I was not being facetious.Oh. My. God. I was not expecting that...
By writing a Logo interpreter and linking it a robot, I passed both CS and electronics A level (on a BBC micro).Heater wrote: I believe that is why people were putting languages like Logo in front of young children back in the day.
WOW.And to a beginner they're a godsend. A logical flow that's easily visible to anyone that can count. Yes, they mirror assembly language beautifully and make the transition from high level to low so much easier. "You see that BASIC code? Well asm is just like that, but the building blocks are much, much smaller. But so much more powerful".
Regular PCs, using a utility called "BASin" (BASIC Interpreter) that emulates a ZXSpectrum with ROM hooks to integrate an IDE and tools. So basically, kids are writing simple code in BASIC (with line numbers!) in a very safe sandboxed emulated machine. This is BASin:Heater wrote:@ZXDunny,
Wow, what machines are they using that Sinclair BASIC on?
When I was at school I was told that computers were a passing fad, so I wasn't allowed to study them. It was expected that I would grow up to work on one of the neighbouring farms insteadThat sounds great. When I did my CS A level in 1974 the course was 30% statistics, 30% numerical analysis and only 30% anything about computers. Only a small part of that was about programming. Luckily that small part was not just solving equations in BASIC but also a bit of assembler. You know, the "real stuff"
Exactly, which is precisely how it would be done in asm, no? The parallels are obvious, yet BASIC is ignored when teaching beginners. And by "beginners" I mean people who have had absolutely zero exposure to programming. How can anyone be expected to pick up Python or Java with no experience of how BASIC works? They must spend an inordinate amount of time in the classroom before they even begin to start coding. With BASIC, you can start on day one.DavidS wrote:Though with a subset of BASIC using line numbers, you can do anything. You can construct any kind of loop with just IF cond THEN GOTO line at the bottom of the loop, and what ever is needed at the top of the loop. You can construct subroutines with GOSUB using what ever means of passing parameters you desire (although I am not sure of how you would do local variables in that case, unless you use an array and integer as a stack). And you can do an equivalent to a simple switch case simply using ON expression GOTO line.
Running a code club in a primary school I have to tell you that you are wrong. Children pick up coding scratch much quicker that they could ever do with clunky old basic. Your nostalgia is clouding your vision.ZXDunny wrote: How can anyone be expected to pick up Python or Java with no experience of how BASIC works? They must spend an inordinate amount of time in the classroom before they even begin to start coding. With BASIC, you can start on day one.
We're moving the kids onto more advanced stuff like Scratch after they've learnt how code flows in BASIC. Exposing them before that just required more pre-code lessons. So far, it's doing pretty well and we have a lot of teachers reporting good results, so I'd say it's working.PeterO wrote:Running a code club in a primary school I have to tell you that you are wrong. Children pick up coding scratch much quicker that they could ever do with clunky old basic. Your nostalgia is clouding your vision.ZXDunny wrote: How can anyone be expected to pick up Python or Java with no experience of how BASIC works? They must spend an inordinate amount of time in the classroom before they even begin to start coding. With BASIC, you can start on day one.
At uni CS course languages like B were frowned upon because they were typeless. I suspect if a student even mentioned BASIC they would have been thrown off the course. We started with Pascal because it was an elegant, structured, strongly typed language.DougieLawson wrote:I tend to think Edsger Dijkstra was right in his pontification about BASIC.
https://www.brainyquote.com/quotes/quot ... 01164.html
Python & Scratch may be insane, but they're in no way as insane as BASIC.
Code: Select all
do 10 i = 1,5 ... ... 10
Code: Select all
do 10 i = 1.5 ... ... 10
Totally with you there.For me, BASIC is a toy that I like to play around with - I can prototype algorithms much faster with it than I can even in Delphi (and certainly much faster than I can in C++ or asm!) but as far as using it for production code goes? Hell no.
No, we were taught lisp as well of course, and Fortran, COBOL, and Ada etc. Our lecturers came from industry - they knew perfectly well that lisp wasn’t used for production code in the real world.Heater wrote:Which is odd because CS departments used to teach in languages like lisp and scheme. No types there.
But lots of code in the real world is written in Java. Far more code is written in Java than Scheme. At uni I guess they are not interested in quick results. Its worth spending the extra time to teach people to program properly in a proper language.Heater wrote:Then I watched 20 odd hours of the new version of the same course. The new prof used Java. It was painful. He had to spend half the course teaching how Java worked before even starting on the actual CS meat of the course. The ideas the course was intended to teach were buried under a morass of irrelevant language detail.
Or might not. Even been to a customer demo? The customer says "can it do this?" which the programmers/test dept never thought of - and it crashes.Heater wrote:Types are useless. Sure they catch some errors at compile time. But if you are fussy about your code working properly you will be testing it. Covering all the code paths. Any type errors will pop out soon enough.
Or they never tested that path. I'm sure NASA tested their code as far as humanly possible.Heater wrote:Your Fortran example, as given, is a case in point. I would argue that the problem there is that they never tested the thing!
Strong typing only picks up just one class of errors. There are obviously many others - as here. In this case it would fail in any programming language.Heater wrote:Types are useless in other ways. At least as implemented in most languages. For example I can write:
int amps = 10;
int volts = 3;
int result = amps + volts;
See the problem there?
Hmm... My experience in testing avionics software tells me that testing 100% of code paths is possible, indeed it was required. It's much easier to do if the code is designed and written in a way, and in a language, that makes it testable. The Lucol language was the best for this. Ada the worst. God help those using C++.Or they never tested that path. I'm sure NASA tested their code as far as humanly possible.
Totally with you there. However in the space of all possible errors, type checking only helps in one small corner. A corner that will show up almost immediately in testing anyway.Thinking you can solve all programming problems by thorough testing is a mistake. The program should be designed and written properly in the first place.
Yes. See above. Strong typing does not buy you much.Strong typing only picks up just one class of errors....
Oh yeah. One of the first things you are taught when studying physics is "dimensional analysis". https://en.wikipedia.org/wiki/Dimensional_analysis Such that when you are wading though a pile of mathematics, trying to prove this or that, it's a good idea to check that the units are being used in the right way. If your finished equation ends up adding a time to a mass then you know you have screwed up somewhere along the line.You seem to be fixated with types!
The latter of course, but at the same time they did also want CS students leaving the university to be able to program. Only part of the first year was spent on it.Heater wrote:I guess it depends what one expects from a Computer Science education. Is it about learning a bunch of languages that may get you a good job at the end of the day? Or is it about, well, computer science?
That's a sad insight considering the enormous amount of money and six years the DoD spent developing Ada!Heater wrote:It's much easier to do if the code is designed and written in a way, and in a language, that makes it testable. The Lucol language was the best for this. Ada the worst. God help those using C++.
Is that when you started using JS?Heater wrote:As such I used to be a great fan of types in programming languages.
Only recently did I start to realize that they don't help at all.
Ada is great and all but...That's a sad insight considering the enormous amount of money and six years the DoD spent developing Ada!
These things are sort of coincident in time. But I would not say there was a cause and effect relation between them. My use of JS was an accident of necessity at the time. Lucol, a language specifically designed for creating safety-critical, hard real-time, had precious little idea of types. Perhaps I just did not think about it so hard at the time.Is that when you started using JS?
No - that's amazing.Heater wrote: In the Lucol language this was easy to verify. The compiler reported the maximum execution time of every module or a collection of modules. So you knew if there were problems with the time budget looming without ever running it. Runing out of execution time was an error the same as any syntax error!
Have you ever used a programming language system that can do that?