-4

I take that the obvious advantages are maintainability, programmer-friendliness etc. but what are the disadvantages?

Is the compiler being put under extra work to convert where it may not be necessary?

Are there situations where low-level languages are better suited to a task because of aforementioned disadvantages?

dunck
  • 398
  • 1
  • 5
  • 18
  • The first thing I'm thinking of is the simple definition of high-level languages: those languages are built on previously defined layers who define some kind of configuration, implementation, ..., which are quite common. If you mean to create a program which obeys those common configurations, implementations, ..., I'd say, go ahead for a high-level language. However if you want to create a program who does things in a completely new way the usage of low-level languages might be helpful. Imagine you don't like the look of the scrollbar. You can only change this by using low-level languages. – Dominique Nov 06 '15 at 10:36
  • They're slower than a *well written* low level program that does the same thing. Of course, a poorly-written program in a low-level language can easily be slower. (e.g. a naive linked list + linear search implemented by hand in C, instead of just using Python's hash table) – Peter Cordes Aug 20 '16 at 00:34

2 Answers2

1

In short: Low Level Languages can yield better performance due to very specific optimizations.

Advantages of Low Level Languages:

  • You can specifically target and utilize chip features (or registers)
  • Generally it can be (a lot) faster if you know what you do, but this is a rare case.

Disadvantages of High Level Languages:

  • You need some sort of compiler to get the HLL to LLL
  • In some cases (e.g. Java / C#) you have an interpreter in between which also consumes resources (but can also optimize itself while running the program!)

Here a more detailed list of Advantages of LLL:

  • you can access machine-dependent registers and I/O
  • you can control the exact code behavior in critical sections that might otherwise involve deadlock between multiple software threads or hardware devices
  • you can break the conventions of your usual compiler, which might allow some optimizations (like temporarily breaking rules about
    memory allocation, threading, calling conventions, etc)
  • you can build interfaces between code fragments using incompatible conventions (e.g. produced by different compilers, or separated by a
    low-level interface)
  • you can get access to unusual programming modes of your processor (e.g. 16 bit mode to interface startup, firmware, or legacy code on
    Intel PCs)
  • you can produce reasonably fast code for tight loops to cope with a bad non-optimizing compiler (but then, there are free optimizing
    compilers available!)
  • you can produce hand-optimized code perfectly tuned for your particular hardware setup, though not to someone else's
  • you can write some code for your new language's optimizing compiler (that is something what very few ones will ever do, and even they not often)
  • i.e. you can be in complete control of your code

Source: http://www.tldp.org/HOWTO/Assembly-HOWTO/x133.html

M156
  • 1,044
  • 1
  • 12
  • 29
0

Not allocating memory yourself is one thing. The programmers behind the languages create garbage collectors and they sometimes (mostly) give you a huge amount of memory.

Take JavaScript for example. If you do var arr = array(501); it may give you 600 bytes, or 1000 or even more.

For low level programs like an operating system on embedded devices or video games (games on PS4, etc.) memory is VITAL. So you can't afford to take more space than you need.

Bruce P
  • 19,995
  • 8
  • 63
  • 73
Jean-Claude Pratt-Delzenne
  • 441
  • 1
  • 3
  • 12