Page 5 of 5

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Tue May 05, 2009 5:25 pm UTC
by ash.gti
See for me the ideal programming language is one that lets me describe what I want using language that is verbose enough to understand without having to decipher whats point at who's mother but still lets me describe things in a way that lets me tell it the finer details when they are nessicary. This most certainly isn't C nor is it Basic. Ruby gets close to this, not perfect in some places but it does a good enough job that its my prototype language of choice and it has a lot of convenient features to let you drop down to say C or anything else you can write a library in without any real trouble.

Telling a programming language "make me a website and I want it to function they way I imagine it would" is as equally impossible as telling that to another human being. If I can't describe it to another person then there is no reasonable way a computer would be able to magically turn that into anything at all.

For me its more of "the ideal car would drive it self when it needs to, but let me drive when it doesn't have a map of the road we are on", hence why ruby is better than basic.

Which is very much off the topic of 'C vs Basic' but that discussion is a dead end as we have seen from this thread. A more interesting would would of been 'Basic vs most other modern higher level languages'

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Tue May 05, 2009 7:42 pm UTC
by SJ Zero
netcrusher88 wrote:See, funny thing. They aren't.

Ideally, they would be.

See? You don't seem to understand what that word "ideal" means.

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Tue May 05, 2009 11:57 pm UTC
by Philwelch
SJ Zero wrote:So the ideal programming language would be able to have a discussion with a quasi-programmer to determine requirements, just like an actual programmer would.


Impossible. It's impossible for a computer to prove a program's completeness or correctness. This is fundamentally true and mathematically proven. And it has the interesting consequence that the compiler wouldn't know what to bring up in discussion.

We could write a set of specifications to test the program against, but what if we made an error in the specifications rather than in the program, or even worse, if we made an error in both the program and the specifications such that they agree with each other but both are wrong? Now you've done twice the work for not really any more certainty than before.

Even if we could have a dialogue, it would have to take place in a mathematically precise language and probably take days, weeks, or months to complete. So we would have to save our description of the program in some easily-understood format like, say, text that conformed to some type of recognizable syntax, so we could pick up where we left off the next day. Your "ideal" is still not quite so far from programming as it is.

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Wed May 06, 2009 12:26 am UTC
by SJ Zero
A programmer doesn't need a mathematically precise language to get how a program is made.

Again, ideal. Ideally, an AI with a large body of knowledge could interpret requirements and know what questions to ask.

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Wed May 06, 2009 2:29 am UTC
by b.i.o
Your definition of 'ideal' starts mattering just as soon as you can provide such an AI. Right now you're essentially saying that the ideal method of programming things is to imagine them into being.

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Wed May 06, 2009 5:10 am UTC
by Philwelch
SJ Zero wrote:A programmer doesn't need a mathematically precise language to get how a program is made.


They probably do. Programming languages are the modes in which we think of how to make programs. What the programmer has in their head prior to code is just a vague idea that only becomes fully specified, designed, and understood once implemented.

It might be possible to express programs in natural language, but writing them that way would be more time-consuming, error-prone, and altogether difficult than expressing them in a mathematically precise language.

SJ Zero wrote:Again, ideal. Ideally, an AI with a large body of knowledge could interpret requirements and know what questions to ask.


That's mathematically impossible. The AI would have to know whether the program was complete before even starting to ask questions. Completeness is undecidable because the problem of determining completeness entails the halting problem, and the halting problem is undecidable.

Your statement is just as useless as "the ideal internal combustion engine would be 1000% efficient or more".

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Wed May 06, 2009 5:51 am UTC
by phlip
Philwelch wrote:Your statement is just as useless as "the ideal internal combustion engine would be 1000% efficient or more".

Except even more so, because if you're going to use this as a way of claiming that BASIC is better since it superficially resembles your ideal (by being more English-like and abstracting certain things... after all, a compiler that'd accept "Make something awesome that'll make me lots of money" would be English-like and abstract) then the statement is just as reasonable as "the ideal car wouldn't run on petrol, but would use some other source of energy, like solar power. This car doesn't run on petrol, and doesn't have any other source of energy. Therefore it's closer to the ideal than a petrol-driven car, because at least it matches one of the points."

Just stating something as an ideal, and saying that something is similar to that ideal, and thus better, isn't enough... you need to explain why that's the ideal (note that ideals are subjective... my experience with programming-for-kids-and-newbies tools suggests that English-recognising probably isn't the ideal.) and then show that the way your suggestion is similar to the ideal is significant.

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Wed May 06, 2009 6:43 am UTC
by OOPMan
SJ Zero wrote:So the ideal programming language would be able to have a discussion with a quasi-programmer to determine requirements, just like an actual programmer would.

This seems more like "The ideal car would drive itself." "But cars aren't smart enough to drive themselves!" to me.


Except quasi-programmers have an even poorer understanding of requirements than most programmers. Non-programmers have even less understanding than either.

This is very much the case in web development right now. The following really happens:

Client X sees Website Y
Client X comes to Company Z and says:
I want you to make a website for me like Website Y, but Better!

Client X fails to understand that the construction of Website Y is a complex task and will only pay us (W/10), where W is the estimated cost for an equivalently complex site.
Company Z Develop Website A for Client X, a sub-par, mediocre copy of Website Y at 1/10th of the cost.
Client X complains to Company Z that Website A is broken
Company Z explains that it was developed to in the context of vague requirements and insufficient funding and hence Client X had is welcome to take over the site on their own

Or something...

Some of that last bit varies...

I think the summation would be:

Garbage In, Garbage Out

Specifying good requirements is difficult enough for trained professionals, let alone the quasi-simians that inhabit most of this planet...

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Wed Jun 17, 2009 5:04 am UTC
by Bassoon
SJ Zero wrote:A programmer doesn't need a mathematically precise language to get how a program is made.

Again, ideal. Ideally, an AI with a large body of knowledge could interpret requirements and know what questions to ask.


"Ideal" and "Real" are two very, very different things. What's ideal is not necessarily real or doable and what is real or doable is not necessarily ideal. Fuck yeah it would be nice if cars were 100% energy efficient, but it just doesn't work that way. Fuck yeah it would be nice if programs wrote themselves. That would mean no bugs and no errors, because the computers would be perfect.

The problem with finding ideals is that they can't always be applied to real life. You can try to build your energy-efficient car, but it will never be 100% efficient. We can build computers to program and edit, but they'll never be able to do it 100% right without our divine intervention. When you have to check things in a system that is meant to check itself, the efficiency of the system should be called into question. Is it really worth it to build computers that check themselves but don't do it right? Why not just do it ourselves the first time?

Hence, C.

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Wed Jun 17, 2009 6:40 am UTC
by Berengal
You write as if BASIC was ideal.

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Mon Jun 22, 2009 12:55 am UTC
by Troy Martin
C wins hands-down. BASIC was designed for beginners and doesn't really go much past them. C is a systems language, meaning it's f**king simple to write an operating system in it. I'm in the process of writing one myself. BASIC is also very runtime-dependant, so it's not easily portable. With C, if an operating has a C compiler and library, you can port many decent-sized programs to it.

Oh, and one last anti-BASIC statement: DONKEY.BAS

--Troy

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Sun Jan 13, 2019 7:33 am UTC
by sfuentes.zsh
just resurrecting this thread

"BASIC vs. C (BASIC wins, obviously)" that's a pretty stupid statement....

I'm designing a texture descriptor for color images to use in a NN for clasification, maybe BASIC is a good language to do the final implementation... now seriusly I tought python or C (more inclined to C due to the performance factor), I think C is here to stay for a long time and BASIC was just a toy, you just can't write complex algorithms in BASIC (you don't have recursion, abstract data types, dynamic allocation) or it will become impractical in terms of how many lines you need to write in a monolithic text file, no support for running test cases, debug memory, etc.

even in the years when BASIC was a trending language, true developers don't used it (atari retail games where written in native code, DOS programs were native machine executables files) and was just used by hobby programmers (who learned BASIC with sample codes from magazines)

Re: BASIC vs. C (BASIC wins, obviously)

Posted: Mon Jan 14, 2019 4:04 pm UTC
by Soupspoon
sfuentes.zsh wrote:you just can't write complex algorithms in BASIC (you don't have recursion, abstract data types, dynamic allocation)
Can't you? You could on the BBC Micro. All of those, albeit the middle one was fiddly by today's standards, but the other two were routine if not expected. Clearly the Gates-empire implementation was inferior. ;)

or it will become impractical in terms of how many lines you need to write in a monolithic text file, no support for running test cases, debug memory, etc.
I once wrote so many lines for a BBC BASIC program that there wasn't any space left in the memory. But that's an interpreted language's inefficiency, rewriting some in 6502 Assembler would save space. It had been tested, already, in sub-component form*. Only when each and every module of the project was read back in from tape (recorded as streams of text including appropriately offset line-numbering) did I find I couldn't get the full thing to fit in the 32k(?) of RAM that wasn't ROM or screen-memory.

Oh, it was a horribly spoiling language to learn (trivial pixel-flipping by direct memory access, far easier than most current systems that rely upon specialist canvas objects and often try to get you to create drawing-objects as child structures, even if you don't want to maintain the object metapointer to change x/y-positioning properties, etc, and just want to splash dots on "the picture") and I wouldn't recommend it as a starter, except that it was often the main one available to a whole generation, unless you were already into Assembler of whatever kind. By the time PCs came along, I had other things to use (e.g. Pascal, which I never got to peek and poke with, but years later at least let me use Delphi for my first proper GUI creations.)


From reading just the first page of the thread (so far, more later!), I think OP is wrong for all the reasons everyone else gave, but cheers for the nostalgia anyway.


* - You could also directly interact with the RAM and ROM (peek and poke, at least with the former).