### Author Topic: Diversity of languages  (Read 2391 times)

0 Members and 1 Guest are viewing this topic.

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Diversity of languages
« on: April 04, 2011, 06:04:06 pm »
One of the things I've noticed lately is that there is some level of language superiority among programmers. While this is not restricted in the least to members within the calculator community (programmers are actually worse on many forums that I've seen), this post was nonetheless written for that niche group.

Programming is, at it's very core, the art of writing instructions to be carried out by a deterministic machine. This is the underlying concept of programming and all languages necessarily adhere to it. It also easily defines the various levels of programming.

At the most basic level, one can program in the machine's native language of Binary (or Hexadecimal, if you prefer the easy way out). This was an extremely common form of programming in the early days of computers, but was quickly replaced by higher level logical abstractions. The first of these was the family of languages known as Assembly. Assembly essentially takes every binary instruction recognized by the underlying circuitry and replaces it with an easier mnemonic that generally describes what the instruction does that is translated to machine code by an Assembler. This allows programmers to work more quickly and easily with the logical abstractions of the mnemonics rather than the machine code. The advantage in using either of these languages is that no program can ever be performed more efficiently than by a program written in them. For any given processor, an optimal assembly or machine code program is necessarily at least efficient as a functionally identical program in any other language and often more so (in addition to being the fastest programs possible). Furthermore, all instructions on a processor are available for use (and thus all programs are possible in ASM/Hex). In many higher level languages, these instructions are not usable, which can result in much unnecessary work in writing code such as mathematical operations without machine word sizes. Of the two, Assembly language is the easier, but machine code offers some other advantages as well. For one thing, Assemblers may generate errors on otherwise valid code. Machine code will only ever return an error if the hardware (or emulator) can't handle the code. Secondly, the style of programming known as Self-Modifying Code is significantly easier in machine code than in Assembly. This often results in highly efficient programs, even above normal Assembly. Finally, Machine code has almost no "compilation" time. Whenever the code is ready to be tested, it can be copied/pasted into the executable and run.

After Assembly came the first major jump in abstraction: the compiled language. Compiled languages replace the oftentimes obscure syntax of machine code and Assembly with that of a higher level language containing instructions that don't necessarily correspond to hardware level instructions. The program which translates these instructions to machine code (called a compiler) uses routines of lower level code to synthesize these high level instructions. A good example of such a language is C. As a language, C offers a wide variety of commands and instructions in order to do many different tasks, most of which are not available directly in lower languages. This high degree of logical abstraction allows programmers to work more quickly on many common tasks and generally avoid having to program difficult things such graphics. However, contrary to popular belief, it does NOT increase portability. Compiled programs are turned into machine code, so unless they're compiled on-site by the user (often not the case), they are no more portable than an appropriately written ASM/Hex program. Compiled programs are often extremely fast, but still lower and less memory efficient than an equivalent program written by a [skilled] ASM/Hex coder.

Beyond compiled programs (which often have obscure syntax themselves) come interpreted programs. Interpreted programs are parsed at runtime by a program known as an interpreter, which contains all of the valid routines for that language. The advantage of interpreted languages is that they typically offer extremely simple syntax compared to other types of languages and even higher level instructions. However, this comes at a significant price. Since the interpreters must be kept in memory and parse the program at run-time, interpreted languages often have very high memory footprints and are generally much slower than compiled or assembled languages.

Misconceptions:

There are a few common misconceptions about these languages that I'd like to address as well.

Machine code: Hexadecimal (I'm not aware of anyone who programs in Binary) is often regarded as impossibly complex and unwieldy to program in. This is, at least in my experience, no the case. Rather, it demands a different mentality in programming than almost all other languages. Another common misconception about Hexadecimal is that it doesn't allow convenient program formatting. This is in fact not true. I offer up my own code as an example
Code: [Select]
 6323 //Store A to second variable 3308 E420 001A //Start division 74FF 3104 2448 8FFB //End division 4324 3325 021A //Move answer back to R2
It may look complicated and obscure, but to an experienced Hex coder (which I am not), that should be reasonably obvious as B = (A-N)*(A/N). It also demonstrates the use of comments in hex programming, something that many believe to be impossible. Use of the backspace key to remove those is encouraged before pasting into an executable.

Assembly: Assembly is often regarded as obscure and irrelevant as a language. On many programming forums, questions concerning how to do certain things in Assembly are almost inevitably greeted with at most one or two reasonable responses and a minimum of six posts saying "Why r u using that! try using ruby or c." Frankly, this astounds me as there can be very good reasons for using Assembly (good luck fitting the Python interpreter in the 4 KB of RAM on the Apollo 11 computers, buddy). However, as was stated earlier, Assembly is also the fastest possible language on a processor. That means that any other language can at most be as fast as a well written Assembly program. If Windows were written in Assembly, it'd probably run significantly faster in many places. It'd also have twice as many bugs and only come out around once a century, but those are other matters

Another common misconception of Assembly is that it's slow and painful to write. While more time is certainly spent in initial debugging, a skilled Assembly programmer can often rival a good programmer in a higher level language with most of the difference merely due to typing.

Compiled languages: Compared to ASM and Machine code, compiled languages are typically slower and less memory efficient. However, they offer significant advantages to programmers. For one thing, the nature of the hardware is much less important than it is in Assembly or Machine code. The programmer is also not required to have an intimate knowledge of many common algorithms because they are provided through routines in the language itself. Most importantly, however, they allow for relatively fast program design and the management of massive projects without getting bogged down in processor details. To use the earlier example, if Windows was written in a compiled language, it would be slower and kind of memory hungry, but come out on a reasonable release schedule and not have as many bugs. All of these are of course true since Windows is in fact compiled. Compiled languages also make problems that would be a nightmare in lower languages such as the coordination of the 3000 some processors composing IBM's Watson possible at an acceptable speed. No Assembly programmer in their right mind would hesitate to say that such a complex problem is almost always better left to a higher level compiled language.

Probably the most common misconception of compiled languages is that of "the compiler is always right." Some programmers genuinely believe that compilers produce optimal code. Frankly, that couldn't be farther from the truth. Modern compilers are extremely good at producing efficient code, but they are not and nor will they ever be (in the near future) better the task than humans. One particular case of this misconception that I remember is that of a redditor who, when faced with the challenge of designing a circuit with the minimum number of gates necessary to compute Conway's Game of Life, offered up the explanation to "just compile some vhdl with no timing and strict area constraints." The error in this suggestion should be obvious.

Interpreted languages, while conceptually similar to compiled languages, tend to occupy a niche in the programming marketplace that makes them distinct from compiled languages. One of the most prevalent misconceptions surrounded interpreted languages is that they're slow and inefficient. While this can indeed be true, many modern interpreted languages are quite fast and powerful if the considerations are adjusted properly. They typically don't achieve the speeds of compiled languages, but they're also typically higher level and thus must often deal with more computationally intensive operations than compiled languages. The main advantage of interpreted languages, TI-BASIC in particular, is that they are extremely easy to quickly mock up complex programs and algorithms in. Furthermore, the lack of compilation time makes them valuable for testing purposes. It also turns out that the lack of speed may be a good thing for many programmers' education, for there's nothing for forcing you to learn how to optimize like trying to squeeze that last bit of speed out of your quadratic solver.

Anyway, this is probably enough, as I'm pretty sure I have a giant wall of text by now...

EDIT: 1583 words!
« Last Edit: April 04, 2011, 06:05:29 pm by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### Goplat

• Posts: 289
• Rating: +82/-0
##### Re: Diversity of languages
« Reply #1 on: April 04, 2011, 07:39:55 pm »
Hexadecimal (I'm not aware of anyone who programs in Binary) is often regarded as impossibly complex and unwieldy to program in. This is, at least in my experience, no the case.

It depends on the program. If you have a program that is just a single chain of actions, each of which is individually simple, then you only ever need short relative jumps ("jr" instructions on the Z80), and programming in hex will work just fine. But large programs usually end up frequently needing to call subroutines or jump to far away code. Keeping track of addresses becomes a big problem - if you add just a single byte to one piece of code, everything after it now has its address shifted by 1. Now you have to go through the whole program and adjust all the calls/jumps... a very tedious (and error-prone!) process.
Of course, an alternative would be to never change the size of any code once it's written, and just 'patch' it to jump somewhere else, do something, and jump back. But this would turn your program into a bloated and convoluted mess after a while.

The big benefit that an assembler gives the programmer isn't instruction mnemonics, it's labels.
Numquam te deseram; numquam te deficiam; numquam circa curram et te desolabo
Numquam te plorare faciam; numquam valedicam; numquam mendacium dicam et te vulnerabo

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Diversity of languages
« Reply #2 on: April 04, 2011, 07:43:39 pm »
Labels are entirely possible as well with proper formatting. They just don't go into the final code. Yes, it's a bit more tedious to keep track of them, but you can always use a jump table if you want.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### ralphdspam

• Posts: 841
• Rating: +38/-1
• My name is actually Matt.
##### Re: Diversity of languages
« Reply #3 on: April 04, 2011, 09:16:06 pm »
Thanks! You explained everything very well.
ld a, 0
ld a, a

• The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
• LV10 31337 u53r (Next: 2000)
• Posts: 1970
• Rating: +128/-15
• I put on my robe and pixel hat...
##### Re: Diversity of languages
« Reply #4 on: April 04, 2011, 09:37:02 pm »
Don't forget that languages aren't neccessarily locked into being compiled or interpreted; there are C interpreters and vicse-versa. there are some features that are hard to immplement in a compiler, and some that are hard to do in an interpreter.
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names

I'm a performer at heart; I stole it last week.
My Artwork!

#### DJ Omnimaga

• Clacualters are teh gr33t
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55931
• Rating: +3153/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Diversity of languages
« Reply #5 on: April 06, 2011, 04:07:11 am »
I'm still shocked someone managed to write an entire Flash APP (BatLib) in hex, though.

Anyway personally you must use the language you feel comfortable with. If you learned ASM but just can't get used to it, you might end up writing sloppy code and your game quality and content will suffer because you spent more time writing code than designing the game and fixing bugs. I also hear that there are languages in which it's a major pain to write stuff. For example: RPGs in ASM. Notice how long it takes for even a veteran like Iambian to code one. I took 2 months to write two grayscale RPGs in BASIC, 3 weeks to design an entire job system for another (although I never finished the game) and 3 weeks for complex RPG system for another, all in BASIC and using ASM libs.

That said, using certain languages will be more efficient than others for some tasks, but personally you should use what you like better and shouldn't be called a "tard" for using hex instead of assembly. It's saddening to see great programmers call others names because they prefer a language/coding style to another.
« Last Edit: April 06, 2011, 04:12:39 am by DJ_O »