High-level programming language: Difference between revisions

Revision as of 02:49, 15 November 2024

Revision as of 02:49, 15 November 2024

Line 14:

== Abstraction penalty ==

High-level languages intend to provide features that standardize common tasks, permit rich debugging, and maintain architectural agnosticism; while low-level languages often produce more efficient code through [[program optimization|optimization]] for a specific [[Computer architecture|system architecture]]. ''Abstraction penalty'' is the cost that high-level programming techniques pay for being unable to optimize performance or use certain hardware because they don't take advantage of certain low-level architectural resources. High-level programming exhibits features like more generic data structures and operations, run-time interpretation, and intermediate code files; which often result in execution of far more operations than necessary, higher memory consumption, and larger binary program size.<ref>{{cite For this reason, code which needs to run particularly quickly and efficiently may require the use of a lower-level language, even if a higher-level language would make the coding easier. In many cases, critical portions of a program mostly in a high-level language can be hand-coded in assembly language, leading to a much faster, more efficient, or simply reliably functioning optimised program.journal

|author=Surana P

|title=Meta-Compilation of Language Abstractions.

|year=2006

|url=http://lispnyc.org/meeting-assets/2007-02-13_pinku/SuranaThesis.pdf

|access-date=2008-03-17

|url-status=live

|archive-url=https://web.archive.org/web/20150217154926/http://lispnyc.org/meeting-assets/2007-02-13_pinku/SuranaThesis.pdf

|archive-date=2015-02-17

}}</ref><ref>{{cite web

| last = Kuketayev

| title = The Data Abstraction Penalty (DAP) Benchmark for Small Objects in Java.

| url = http://www.adtmag.com/joop/article.aspx?id=4597

| access-date = 2008-03-17

| archive-url = https://web.archive.org/web/20090111091710/http://www.adtmag.com/joop/article.aspx?id=4597

| archive-date = 2009-01-11

| url-status = dead

}}</ref><ref>{{Cite book

| last1 = Chatzigeorgiou

| last2 = Stephanides

| editor-last = Blieberger

| editor2-last = Strohmeier

| contribution = Evaluating Performance and Power Of Object-Oriented Vs. Procedural Programming Languages

| title = Proceedings - 7th International Conference on Reliable Software Technologies - Ada-Europe'2002

| year = 2002

| pages = 367

| publisher = Springer

}}</ref> For this reason, code which needs to run particularly quickly and efficiently may require the use of a lower-level language, even if a higher-level language would make the coding easier. In many cases, critical portions of a program mostly in a high-level language can be hand-coded in [[assembly language]], leading to a much faster, more efficient, or simply reliably functioning [[Program optimisation|optimised program]].

However, with the growing complexity of modern [[microprocessor]] architectures, well-designed compilers for high-level languages frequently produce code comparable in efficiency to what most low-level programmers can produce by hand, and the higher abstraction may allow for more powerful techniques providing better overall results than their low-level counterparts in particular settings.<ref>

{{Cite journal

High-level languages are designed independent of a specific computing system architecture. This facilitates executing a program written in such a language on any computing system with compatible support for the Interpreted or JIT program. High-level languages can be improved as their designers develop improvements. In other cases, new high-level languages evolve from one or more others with the goal of aggregating the most popular constructs with new or improved features. An example of this is Scala which maintains backward compatibility with Java, meaning that programs and libraries written in Java will continue to be usable even if a programming shop switches to Scala; this makes the transition easier and the lifespan of such high-level coding indefinite. In contrast, low-level programs rarely survive beyond the [[Computer architecture|system architecture]] which they were written for without major revision. This is the engineering 'trade-off' for the 'Abstraction Penalty'.

|author1=Manuel Carro |author2=José F. Morales |author3=Henk L. Muller |author4=G. Puebla |author5=M. Hermenegildo | journal = Proceedings of the 2006 International Conference on Compilers, Architecture and Synthesis for Embedded Systems

| title = High-level languages for small devices: a case study

| url = http://www.clip.dia.fi.upm.es/papers/carro06:stream_interpreter_cases.pdf

| year = 2006

| publisher = ACM

}}</ref>

High-level languages are designed independent of a specific computing [[Computer architecture|system architecture]]. This facilitates executing a program written in such a language on any computing system with compatible support for the Interpreted or [[Just-in-time compilation|JIT]] program. High-level languages can be improved as their designers develop improvements. In other cases, new high-level languages evolve from one or more others with the goal of aggregating the most popular constructs with new or improved features. An example of this is [[Scala (programming language)|Scala]] which maintains backward compatibility with [[Java (programming language)|Java]], meaning that programs and libraries written in Java will continue to be usable even if a programming shop switches to Scala; this makes the transition easier and the lifespan of such high-level coding indefinite. In contrast, low-level programs rarely survive beyond the [[Computer architecture|system architecture]] which they were written for without major revision. This is the engineering 'trade-off' for the 'Abstraction Penalty'.

== Relative meaning ==