Search code examples
programming-languageslanguage-designabstractionhigh-level

How high should/will high-level languages go?


I know this is very abstract, however I believe it is very focused.

There are plenty of high-level languages today: C#, Java, VB, Python, etc., all created to abstract away low-level complexity and provide a more user-friendly programming experience. High-level languages can reduce, and most of the time completely remove, the necessity to perform low-level, process specific operations (such as pointer manipulation and memory management). Many also remove platform details (like file manipulation, user interface generation, etc.)

My two questions are:

  1. What else can/should be abstracted? Are there any more low-level semantics present in today's high-level languages that will be/should be abstracted away further?
  2. At what point does a general-purpose, high-level language become very high-level, a.k.a goal oriented?

Solution

  • One of the problems with including very high level abstractions in a language is that sometimes they're not adequate for everything you want to get done, so you end up needing the lower level abstractions, too. The problem with having high and low level abstractions in the same language is that the high level abstractions can become leaky very easily if you can probe them via low level abstractions.

    Java, for example, is not even that high level a language, but it is designed to be safe (in the sense that abstractions don't leak) first and foremost. Therefore, some things are just impossible to do in Java. For example, you can't write Java's garbage collector within Java, or roll your own object system using pointer cast polymorphism, or write an operating system (at least not a traditional one).

    In contrast, D offers both high level and low level facilities. D's garbage collector, for example, is written in D. This sounds good and for the most part it is. However, when you start mixing abstraction levels in a single codebase the abstractions can leak, especially if you use casts or unions to defeat the type system. Therefore, to successfully program in D you might occasionally need to be aware of some low-level details to deal with leaky abstractions, even if you don't need them for the task at hand.