WoW loves Oracle!
I honestly can’t complain about Oracle myself as far as opening a text editor and putting together queries or PL/SQL code. SQLPlus and SQLLoader are easy to use and if I need something graphical I just pop in SQLDeveloper. My editors of choice are either Notepad++ or VI depending on the machine I’m working from…hic!
C++ is just another version of COBOL with hardware abstraction and PCL6 compatibility. So technically WOW is made with COBOL.
No… WoW is written on Commodore 64 BASIC.
10 FOR I = 0 TO 9
20 POKE 53280,I
30 POKE 53281,I+1
40 FOR J = 1 TO 1000
50 NEXT J
60 NEXT I
It will be called Blizzard World
OMG! A blast from the past. My first computer was a TRS-80 with a tape player for storage. It also had BASIC built in. ![]()
Man C++ backend sounds like a nightmare to develop, given all the ways C++ gives you footgun and hard-crash the whole mess and accidentally open up all kinds of vulnerabilities. I get that it’s done for performance reasons, but still.
I wonder if Rust is considered mature enough for this kind of usage yet. From the perspective of a front-end mobile developer it looks like a great alternative, maintaining most of C++'s performance while making it easier to write safe code.
Yeah, but COBOL is made from Assembly Language so technically WoW in written in assembly.
…but wait a minute! Assembly is written by the Keebler Elves, so technically, WoW is written in COOKIE
![]()
Aren’t traffic lights coded in cobold? Lol
if you know anything about coding then you would know C++ is not COBOL lmao. But what do i know. I just went to Devry for programming.
They should make a coding language thats like an actual language so it’s easily translated between.
It confuses me cause I assume numbers are universal and that’s what code talk is, so shouldn’t any code be readable?
There have been attempts at auto-translating between programming languages, and the resulting auto-translation can be made to technically run, but the problem is because each language is architected differently, the quality of the translation can be quite bad. Languages that are built similarly to each other translate better but even that’s usually not good enough to use without a human going through and doing manual fixes and touchups.
For an analogy, think of how bad machine translated human language is, even now in the era of machine learning. It often makes major errors and bleaches out the most subtleties, resulting in a translation that sometimes works well enough to get the gist across, but isn’t suitable for much more.
Now to get where programming language translation stands, imagine machine human language translation, except the languages involved don’t necessarily have any common base. Unlike human languages, which are all built on top of the same set physiopsychological functions and have roughly similar expressive capabilities, programming languages can built any number of different ways with differing levels of expressiveness.
It would likely help to design a programming language specifically for translation, but it’d still be limited due to all the languages you’d want to translate to not being designed for it.
Reading this thread while working in Excel today just made me feel like I wear a propeller hat 24/7 and make brrrrr sounds.
Surprised you didn’t create a container class Beer_Keg for containing Beer objects ![]()
I was actually more tempted to post some COBOL and assembly code I wrote. 
…hic!
01001000 01000001 01001000 01000001 00100000 01110100 01101000 01101001 01110011 00100000 01101001 01110011 00100000 01100110 01110101 01101110 01101110 01111001 00100000 01100010 01100101 01100011 01100001 01110101 01110011 01100101 00100000 01100001 01110100 00100000 01110100 01101000 01100101 00100000 01100101 01101110 01100100 00100000 01101111 01100110 00100000 01110100 01101000 01100101 00100000 01100100 01100001 01111001 00100000 01100001 01101100 01101100 00100000 01111001 01101111 01110101 01110010 00100000 01100011 01110000 01110101 00100000 01110101 01101110 01100100 01100101 01110010 01110011 01110100 01100001 01101110 01100100 01110011 00100000 01101001 01110011 00100000 01111010 01100101 01110010 01101111 01100101 01110011 00100000 01100001 01101110 01100100 00100000 01101111 01101110 01100101 01110011
