Actually he did, which however doesn't justify such massive broadcasts unless those were, hehe, the S.O.S.'s of a sinking Titanic. Were they really, do you think?dizt3mp3r wrote:Whether or not the OP is a troll, he started a thread that caused some good responses.
No, it isn't and no, they shouldn't. QB64 is fundamentally a BASIC-to-C++ translator parasitizing on top of GCC. Pretty much like BCX that is yet another similar crutch to aid people in crossing the otherwise ^^unfathomable^^ gap between BASIC and ANSI C. From my perspective, both are equally conceptually and therefore syntactically scant if not altogether defective.Quickbasic 64 has a QB 4.5-cloned IDE and emits C++ code. It is what all languages should be...
You don't have to really. There are at least a dozen mature and well-maintained 3rd-generation BASIC's around to choose from. Many are interpretative, some are interpretative and JIT compilable, still some others are JIT and statically compilable to machine code without the intermediation of another product. Nearly half of them support verbatim Intel-style assembly, either inlined or procedure-level. And there is at least one that supports verbatim BASIC, verbatim multiple procedure ANSI C, and verbatim multiple procedure Intel-style assembly -- alternating arbitrarily and co-operating in an all-in-one script -- thus enabling the user to select language instruments that would be the most appropropriate for a particular application or for a particular task within a complex application.I abandoned QB4.5 years ago ... I keep looking for a reason to pick it up again and use it.
Well, I don't.PurpleGurl wrote:I concur with what the devs have already said on lower level languages.
This maxim is rather arguable. Look at all this markup hell all around you: even modern multi-GHz CPU's and nanometer technologies can't cure the lopsided shapes, broken links, unloadable images, turtle slow graphics, etc. in your browser windows. And not only that; look at Java, or PHP, or Python -- are their speeds comparable even to high-level C++, to say nothing of low-level C or hand-coded assembly? Not in the least. Now take GCC, the sanctum sanctorum of C partisans, and watch it doubling the size of GCC-generated executables while halfing their speed with every major version number change! And finally, think about countless legions of programmers the world over that are busy developing their products for, and burning them into, 32KB EEPROM's of CNC's, or kitchen utensils, or vacuum cleaners, or chewing gum dispensers. Can they use "stuff like php, tcl, xml, xsl, sql"? The question is obviously rhetoric. The overproduction of IT staff has lowered, definitively and dramatically, the SW industry quality standards and consequently, the level of craftsmanship in this profession.ekohl wrote:Modern compilers do a pretty good job at converting high level language code into assembly language or machine code.
A PHP or Python guru, hehe? The only guru on the block that can make me relatively uneasy would be a LISP guru. The CPU is a perfect solid-state stack machine ideally suited for a fundamentally stack-based LISP or Scheme compiler. So, a competent Lisper would make a worthwhile opponent to an assembly practician, speed-wise, while an average C programmer wouldn't unless he's fully aware of how a particular C compiler works and exactly what it is capable of doing behind the scenes.
It is too early to say no to low level languages, sir, if ever. I can name a few dozens BASIC, C, or Pascal implementations written in pure assembly but so far I know none such written in xsl or php. Nor am I likely to name one in the foreseeable future, no matter what next generation CPU geometries are going to be.