mirror of
https://github.com/thma/WhyHaskellMatters.git
synced 2024-10-26 14:32:24 +03:00
36 lines
1.3 KiB
Markdown
36 lines
1.3 KiB
Markdown
This is my zettelkasten (don't look at it)
|
|
|
|
|
|
type classes
|
|
- complex interfaces
|
|
- interpreter style
|
|
|
|
|
|
- Static and Strong typing (Es gibt kein Casting, sealed traits)
|
|
- Type Inferenz. Der Compiler kann die Typ-Signaturen von Funktionen selbst ermitteln. (Eine explizite Signatur ist aber möglich und oft auch sehr hilfreich für Doku und um Klarheit über Code zu gewinnen.)
|
|
|
|
- Eleganz: Viele Algorithmen lassen sich sehr kompakt und nah an der Problemdomäne formulieren.
|
|
|
|
- Weniger Bugs durch
|
|
|
|
- Purity, keine Seiteneffekte
|
|
|
|
- Starke typisierung. Keine NPEs !
|
|
|
|
- Hohe Abstraktion, Programme lassen sich oft wie eine deklarative Spezifikation des Algorithmus lesen
|
|
|
|
- sehr gute Testbarkeit durch "Composability"
|
|
|
|
- TDD / DDD
|
|
- higher order functions assembly
|
|
- Typklassen dispatch (https://jproyo.github.io/posts/2019-03-17-tagless-final-haskell.html)
|
|
|
|
- Memory Management (sehr schneller GC)
|
|
|
|
- Modulare Programme. Es gibt ein sehr einfaches aber effektive Modul System und eine grosse Vielzahl kuratierter Bibliotheken.
|
|
|
|
("Ich habe in 5 Jahre Haskell noch nicht ein einziges Mal debuggen müssen")
|
|
|
|
- Performance: keine VM, sondern sehr optimierter Maschinencode. Mit ein wenig Feinschliff lassen sich oft Geschwindigkeiten wie bei handoptimiertem C-Code erreichen.
|
|
|
|
|