mirror of
https://github.com/Wessel/nhl-levenshtein.git
synced 2026-06-05 23:55:45 +02:00
35 lines
2.1 KiB
TeX
35 lines
2.1 KiB
TeX
\section{Introduction}
|
||
\label{sec:introduction}
|
||
This report will focus on understanding functional programming
|
||
languages and their differences compared to imperative languages.
|
||
The implementation of the Levenshtein ratio algorithm is discribed in three
|
||
different programming styles and compares the results on multiple fronts.
|
||
|
||
The Levenshtein ratio algorithm is a commonly used
|
||
algorithm to measure the similarity between two strings.
|
||
It is applied in various fields such as spell checking, DNA sequencing, and plagiarism detection.
|
||
By implementing this algorithm in different programming languages, we can analyze the impact of
|
||
the programming paradigm on performance, code complexity, and maintainability.
|
||
|
||
The following languages were chosen for this comparison, each representing a different paradigm:
|
||
\begin{itemize}
|
||
\item[-] \makebox[3.2cm]{\textbf{Haskell (Functional)}\hfill} A purely functional language that
|
||
emphasizes immutability and recursion. Known for its concise and expressive code.
|
||
\item[-] \makebox[3.2cm]{\textbf{Csharp (Imperative)}\hfill} An object-oriented language mainly
|
||
used to develop Windows applications and games.
|
||
\item[-] \makebox[3.2cm]{\textbf{TypeScript (Semi)}\hfill} A language that supports both imperative
|
||
and functional constructs. Known for its leniant interperter.
|
||
\end{itemize}
|
||
|
||
The comparison is based on the following criteria:
|
||
\begin{enumerate}
|
||
\item[I.] Speed – time complexity and memory usage.
|
||
\item[II.] Readability – how simple and intuitive the code is.
|
||
\item[III.] Maintainability – how well the code scales and is extendable.
|
||
\item[IV.] Complexity of implementation – how difficult it is to correctly implement the algorithm in the chosen language.
|
||
\end{enumerate}
|
||
|
||
To objectively test the implementations, identical test datasets are used. Multiple test cases are designed that increase in complexity and size, with an expected output. The correctness of the implementations is verified with asserts or unit tests.
|
||
|
||
This approach provides insight into how different programming paradigms affect the practical implementation of a well-known algorithm.
|